Frequency offset during triggered demodulation

[cochenob]

I have set up a PSK link where the transmitter (5421 AWG and 5610 Upconverter) generates a packet of bits via a software trigger.  I export this trigger on a PFI line, and use it to trigger the receiver (5600 Downconverter and 5620 A/D).

There's a little bit of latency between the transmitter trigger and the time that data is generated.  As such, when the receiver sees the trigger, it begins acquisition of "nothing" until the real data comes along.  Furthermore, just as a safety measure, I made my acquisition time longer than my packet length to avoid missing any bits at the end of the packet.  So...the A/D ends up capturing a bunch of samples with zero magnitude, then the data, then some more sample of zero magnitude.

Upon passing this into the PSK Demod VI, at the output I observe a large frequency offset/drift during the window of acquisition (i.e. - the constellation has the right magnitude, but appears to have "spun" around).

After some tinkering, I found that if I truncate the samples with zero magnitude at the beginning and end, then things start to get better.  My frequency offsets/drifts start to lower, and the constellation appears normal. 

I'm guessing that the algorithms that remove the frequency offset in the demod VI don't like these "empty" samples, however I haven't been able to convince myself why this is.  Is there a simple way to explain this (without advertising too much IP?)

---
Brandon

[Andy_Hinde]

Hi Brandon,
The delay you are seeing is due to the propogation delay of the signal through the PXI-5610. The 5421 outputs its digital trigger at the same time as the analog output from the board (which feeds the 5610). The 5610 has a ~1200 ns propogation delay which ends up causing the trigger to be 'ahead' of the RF output by about ~1200 ns.

If the RF output is connected to an RF analyzer (PXI-5660, PXI-5661), there will be another delay of ~1200 ns as the signal goes through the 5600 to the digitizer. If the digital trigger of the arb is connected to the digital trigger of the digitizer, then the delay may be doubled again. I think with the 5661 supported by the NI-RFSA that the NI-RFSA driver accounts for this in digital triggering (not sure). The 5660 which is currently not supported by the NI-RFSA driver API does not account for this.

So your data may have a delay of ~1200 or ~2400 ns is my guess. I am attaching an example that shows how to account for this delay by delaying the trigger out of the 5421 via scripting in NI-RFSG.

Hope this helps!

Regards,
Andy Hinde
National Instruments

[cochenob]

I figured there was a way to delay the trigger on the Tx end...I'll give this a try.  I tried this on the Rx end, but the unfortunately the 5620 A/D doesn't support trigger delay.

I am still curious however why the PSK Demod.VI introduces all of that frequency error when presented with a bunch of zero magnitude data.  I assume it's an algorithm thing, but I don't know enough about what's going on inside there to be sure.  Could you provide any insight there?

---
BC

[cochenob]

Andy-

When I looked at the example, I found that it operates differently than I thought.  Allow me to be more specific on my application.

On the Tx side, I'm generating packets on a software script trigger.  I also export that software script trigger to the PFI line...and use it to trigger acquisition of my Rx code.

The example code you provided allows making the delay longer between trigger and generation.  I'd wish to make them shorter.

As you mentioned previously, there's a propagation delay that I won't be able to get around.  This is fine...so...it looks like we need to have the Rx shorten up the time between trigger and data.  The RFSA VI's have a "trigger delay" option which tells the A/D how long to wait between trigger and acquisition....which is ideal...however not supported with the 5420 A/D.  I looked into trying to write a script that would receive the trigger...wait some...then start acquisition...but it seems like scripting is a generation feature only.  Perhaps I'm wrong here.

In any case...it looks like the only way to do it is in software by detecting where samples with zero magnitude end, and the ones with >0 magnitude begin.  Then of course is my question above...which is why the demod VI gets spoiled when I send in zero magnitude data.

A related question...for a long time...I thought the "Waveform Quantum" was a property of the modulation scheme (i.e. bits/symbol).  While out of context this is partly true...it is NOT the same Waveform Quantum that the RFSG VI's consider...rather it's a hardware characteristic.  I've been searching the help documents for some info on this other than "it's the number your data size has to be an integer multiple of".  Anyway, the Waveform Quantum seems to suggest that each time LabView goes to the buffer...it grabs 4 samples at a time...so make sure there are always 4 samples there to get.  My question is....why only 4?

Thanks.

BC