Coherent vs. Non-Coherent Implementation

[cochenob]

This is a follow up to this post.

Two questions here.

First...Consider this situation.  With the generator off, I turn on my analyzer.  It begins acquiring IQ samples, though they have no meaning since I'm not sending any data.  I then go and turn on the generator, which starts spitting out multiple IQ samples for every symbol.  Question:  How does the receiver figure out when I started to send "real" data?  It's a question similar to this post.  An NI rep said that file transfer had been accomplished when the Tx/Rx were in the same chassis, but a wireless (i.e. two independent PXI chassis) implementation had not been done (by NI or the poster).  Is there something being passed in hardware?  Or is there some VI that the receiver uses to determine when "valid" IQ samples start to flow.  A similar question could be asked when you turn the generator on first, and the analyzer on sometime in the middle of a data stream.  The short question: How does the receiver know in a stream of IQ samples where one symbol begins and another ends?

Second... A related question.  What's going on in generation (and/or in demod.) to determine a coherent scheme and a non-coherent scheme?  Is there a PLL in the receiver chain?  Are the internal clocks synched (or not synched in the case of non-coherent) via the backplane?  (Note:  I understand the differences between coherent and non-coherent, rather my question is to how this is physically implemented in the NI hardware/software toolkit.)

Thanks!

---

Brandon

[Andy_Hinde]

Hello Brandon,
This is a good question. Basically this is a similar situation to an oscilloscope question where you can be acquiring time domain data with a scope of noise when a signal is suddenly applied to the input. How does the scope know when the signal being input is now 'meaningful'?

The answer is via triggering or some form of syncronization. If the IQ stream into the analyzer is 'off' and a signal then is applied, one can trigger of this rising edge of 'magnitude' data. The IQ data can be interepreted as mag/phase data in polar coordinates. When the signal is off, these IQ samples will have magnitude data close to 0. When the signal is applied, the magnitude data will have a rising edge. This is the rising edge which can be configured as the trigger point for the PXI-5661 in the NI-RFSA driver using the IQ Power Edge trigger type. This is useful for capturing cursted RF signals, or RF signals which may be off and become 'on' at an unknown point in time in the future.

If there is no change in signal magnitude which can be used as a reference, the other option is to create some syncronization between the generator and receiver, where the generator sends out a digital pulse which can be used as a digital trigger for the analyzer.

As for determining which IQ samples acquired are symbols, this relates to the concept of oversampling the IQ data to allow pulse shaping. If bits were mapped to IQ constellation points and no oversampling / interpolation performed top increase the sampling rate of this IQ data, it could not be pulse shaped effectively. Since you end up with some IQ data rate that is some multiple of the symbol rate, the question arises as to how to know which IQ samples are the symbols that need to be mapped back to bits.

This process is done in the NI RF platform in the Modulation Toolkit demodulation algorithms. The algorithms have a process they perform which is known as symbol clock recovery. After the IQ data is resampled to an integer number of samples per symbol, each sample is checked for its 'closeness' to ideal symbol locations specified in the symbol map. If one sample is very close to an ideal symbol location, we are using 8 samples per symbol, and the sample that is 8 samples after the one that is close is also close to an ideal symbol location, then there is a high probability that these samples are the samples that occurr at the symbol clock period and should be mapped to bits.

In any case, this is an issue for the demodulation software and should not impact you, as it is already being done.

As for phase coherency in the NI RF hardware, the PXI-5600 and PXI-5610 down and upconverter modules each generate their own LO signals. As they do not share commone LO signals, they cannot be phase syncronized and are not phase coherent. The PXI-5600 and PXI-5610 (and thus the PXI-5660/5661 and PXI-5670/5671) can be frequency locked via a 10 MHz reference, but they will not have 0 degrees phase offset.

Regards,
Andy Hinde
National Instruments

[cochenob]

Andy-

Thanks for the response.  This makes a lot of sense, and would explain why in my experience with the examples that it takes a moment from when you hear that "click" from turning on the downconverter to when you actually see the constellation diagram start displaying correct data.  Either way, it's pretty amazing that software figures out all of this clock recovery in a matter of moments!  Science marches on!

Regarding Coherent vs. Non-Coherent, I understand now from your reply that the up and downconverter modules have their own LO.  Perhaps I should have worded my question another way.  What are the differences in implementation between say BPSK and DPSK?  In DPSK, the advantage is that the LO's can be non coherent since you detect only changes in phase symbol to symbol.  But for BSPK, does the downconverter LO phase lock to the incoming signal through some sort of PLL/Costas Loop?  Or is there more behind the scenes software magic going on?

---
Brandon 

[Andy_Hinde]

Hi Brandon,
In the case of the NI RF platform, the downconverter (PXI-5600) does not know what type of modulation the signal passing through it contains. It is a general purpose downconverter, with all of the issues you present being issues for the Modulation Toolkit software. I

Is there some issue you are facing with the use of the NI RF products? If you're having an issue perhaps there is some way to resolve it without having to delve into the IP of our software, which becomes understandably sticky....

Regards,
Andy Hinde
National Instruments

[cochenob]

Andy-

No problems with the devices.  Everything works great.  I just wanted to understand a little better what was going on under the hood.  Is there a general way you can describe coherent vs. non-coherent implementation without getting into IP?

---
Brandon

[Andy_Hinde]

Hi Brandon,
Perhaps the most satisfying answer to your question would be to refer you to the MT Demodulate PSK.VI itself. You can open the block diagram of this subVI (PSK Demodulator) and see exactly the steps we take to take generic IQ data from the analyzer and PSK demodulate it.

Look in:
C:\<LabVIEW>\vi.lib\addons\Modulation\Digital\Demodulation\MT Demodulate PSK.vi

Hopefully this gives you all the info you're interested in!

Regards,
Andy Hinde
National Instruments