Average vs. Peak Symbol Power

[cochenob]

Hardware specs...

AWG - 5421

Upconverter - 5610

Downconverter - 5600

A/D - 5620

Thanks for the work around.  I will give it a try.  I'll have to dig a little deeper into the code to remind myself why there's resampling going on before writing to the AWG, but it certainly seems plausible that doing so may produce some round-off error might push a decimal point in the wrong direction.

I'll let you know how it works out.

---
BC

[cochenob]

Andy.

The patch works....sort of.

From the generation side of things...everything is good.  By probing before the resample...after the resample....and after the scaling....I now understand what you explained previously.  In any case, the new Generate QAM works without error in average power and peak power modes.

As a test, I used this Generate QAM example, and opened up the QAM Receiver example (located in the RFSA example folder)...and then connected the up and down converter modules with a small SMA cable.  In "average power" mode, the receiver demodulates things just fine (this of course was the case before).  However, if I configure the transmitter for "peak power" mode...the constellation diagram spins and twists and is generally unstable.  I'd send a screenshot, but it's pretty dynamic (i.e. - a movie would be better).  Furthermore, the "Peak Power" measurement on the receiver front panel doesn't match the "Peak Power" I define on the transmtter front panel.  I'm only using a short SMA cable between the two, and the difference is at least a dB or more. 

Is the resulting modulated signal in "peak" mode coming out of the upconverter that drastically different than what it would be in "average" mode (since the IQ pairs are different?).  I wouldn't expect it to be, since we should just be scaling the original transmitted constellation.  This behavior might be reasonable if the relative distances between symbols became drastically smaller with the scaling...however I have plenty SNR (since my channel is just a short cable) and I'm even using a simple scheme (4-QAM).

What's going on here?  🙂  Any thoughts?

---
Brandon

[Andy_Hinde]

Hi Brandon,
I don't know the answer to your questions off the top of my head so I'll look at this and figure out what the situation is. The signal should be exactly the same but for the magnitudes be slightly smaller.

Thanks,
Andy

[Andy_Hinde]

Hi Brandon,
The problem was that I was scaling the data after resampling. When I changed the code to scale the magnitude and then resample, everything works as expected.

Attaching an updated example and removing the previous one.

Thanks,
Andy

[cochenob]

Andy-

Unfortunately...this did not work for me. 

The first thing you call is the "Get IQ Scaling.VI" or something to that effect.  This VI always returns "1" for the peak magnitude of all the ideal IQ samples in your sequence...as expected I suppose, unless you're using some sort of custom constellation set that doesn't have any symbols a distance 1 away from the orgin.

After it, you've added what looks like a "fudge factor" of 1.005, since in most cases (as above), the peak magnitude is unity.  So the data gets scaled by 1.005.  Ok so far.  Unfortunately, the resample and write routine that follows still throws the "your magnitude is >1" error.  I tried playing around with the fudge factor (between 1 and 2).  Depending on the modulation scheme, symbol rate, samples/symbol, and a few other variables, I was able to get it to work but I can't really say I found any correlation between all the variables.

This leads me to something I've never quite understood well.  Why is it necessary to resample before writing to the hardware in the first place?  For example,  I've been working on modifying the PSK Generate example for a particular application.  When I replace the existing VI where the sequence is generated with my own VI's that generate data specific to my application, and try to observe the outcome using the PSK Receiver example program...I notice gaps in my data (i.e. - the constellation flashes due to long strings of "0's" in the transmitted sequence.).  I'm using regular PSK schemes, so I'm not anticipating any issues with phase continuity during generation.  I've traced the problem down to the Resample and Write VI that's in both the PSK and QAM Generation examples.  For some reason, when resampled, some chunks of my sequence don't always completely fill the buffer, resulting in "gaps".  I haven't yet determined the nuances here as to why this is.

Could you provide some insight in to the motivation behind resampling before writing?  It might help me understand what's going on with the rescaling of the QAM data, as well as understanding my PSK generation problem.

Thanks again for all your help!

---
BC

[TheWoost]

Hi Brandon,

Is this behavior only occurring when you configure the pulse shaping filter to "none"?  Regarding the need for resampling, this is done only as a function of our hardware and is not something inherent to modulation.  The hardware DUC can only do integer interpolation.  To get any arbitrary IQ rate, you need either an arbitrary sample rate (external clock) or software fractional resampling.  The RF Signal Generators Help (Start>>Programs>>National Instruments>>NI-RFSG>>Documentation) provides some more detail about the hardware and the effects of resampling in software.  I would recommend specifically the sections about the NI 5441 DUC, the NI 5670 IQ Rates, and the NI 5671 Overview in general.

Regards,
Andrew W
National Instruments