PSK Demod.VI doesn't demodulate the enitre message

[cochenob]

I'm attempting to create my own PSK link similar to the PSK Transmitter and Receiver examples shipped with the NI Comm Toolkit.

Before getting the hardware in the loop, I tried to create a simple transceiver simulation, similar to the MT PSK Transceiver(with FFT Spectrum) found in the simulation examples folder.

Starting with BPSK, I began by defining my own simple 8-bit message...prepended by a few guard bits, and an 8-bit sync sequence.  No problems there.

However, after using the PSK Demoduate VI...I notice that not all of my bits are getting demodulated.  In otherwords...it finds the sync location correctly, and starts it's demodulation, but not all of my message bits get demodulated.  It's as if they weren't even there to begin with.

I looked at the MT PSK Transceiver (with FFT Spectrum) example a little deeper, and found that the same thing happens.  There's a mysterious VI called Align Array that comes after the PSK Demod VI thats chopping the orignal TX message to the length of what gets demodulated, so that the front panel advertises a "See...they're the same!", when in reality, not all of the tx sequence got demodulated.

Why is this?  I suspect that it has something to do with the filtering...but I thought that this was the purpose of the guard bits...to give the filters something to chew on during the first few samples so that group delay through the filters didn't mess with you signal.  It almost seems as if I need some guard bits at the end of my message as well so that demod of my message bits can continue even after the filters begin to "empty"? 

---
Brandon

[Giarc]

Hi Brandon,

You are correct in thinking that the Align Array VI has something to do with filtering, it is compensating for digital filter delay in the PSK demodulator.  You'll also notice that the Align Array VI doesn't throw away any bits after the first time its ran (when it discards the guard bits).  After this any bits that can't be matched in the present iteration of the loop are matched in the next iteration by storing them up in a shift register.  In this transceiver example, this has to be done this way because there is a direct correlation between the number of symbols the modulator produces and the number of symbols that come out of the demodulator.  In continuous mode with the Modulation Tools, because of the filter, there will always be some symbols that will be delayed going through the filter and will come through the next iteration of the loop.

Once you go to hardware, you would see a similar issue if you are doing continuous acquisition.  Continuous acquisition is challenging to do because demodulation takes a lot of processing and in general it is difficult to keep up with the VSA's buffer.  Normally, I have seen people do a finite acquisition, making sure that the amount of data acquired is long enough to account for the filter delay and then discarding symbols at the start.  You'll notice that the hardware examples do this by using a subVI called mod_Truncate Filter Transient.

Regards,

Craig

Systems Engineering

National Instruments