How to Acquire and Track GPS Signals with NI-USRP 2932

[erickschmidt]

Hello all,

I have been trying to solve this issue for a long while now. First some key aspects about my testbed/experiment that I would like to mention:

1. I'm sure people are aware of the big GPS SDR project from Dr. Dennis M. Akos [1], which is an SDR GPS baseband receiver based in MATLAB. (Website: https://ccar.colorado.edu/gnss/). It is the platform I am testing with pre-recorded GPS signals.

2. I have been trying to capture GPS signals with an NI-USRP 2932 and save them in a binary format with int16 data type and I-Q interleaved samples: I0 Q0 I1 Q2 I2 Q2 ....etc

3. I would also like to mention I am using the NI GPS Simulation toolkit for transmitting GPS signals. This GPS Toolkit works fine because I have tested it with a Commercial GPS Receiver (i.e. Garmin, etc). I'm specifically using the NI GPS Direct Streaming Generation.vi

4. Most of my attempts of collecting data is by directly connecting the transmitter (NI PXIe-1075 with a I/Q Generator, RF Generator, Vector Generator, MXI Express connected to a PC with LabVIEW and NI GPS Toolkit), to the receiver (NI-USRP 2932) via an SMA cable. I've tried with and without attenuators. 

5. For capturing data I've tried INT16, INT8 mostly, by using the Property Nodes at the receiver such as Host Data Type, Sample Width, Expected Peak, etc.

So I was wondering if anyone has had issues with this or is something missing. I am aware the NI-USRP 2932 has an OCXO clock, which even without the GPSDO, should perform well enough for post-processing baseband GPS signals.  By the way, just as a note, this MATLAB SDR is able to track signals when recorded with the SiGe GN3S Front-End which has a 1.5 ppm TCXO clock, but not with the NI-USRP 2932 which has a 2.5 ppb OCXO clock. My main issue here is Tracking. Acquisition works just fine, finding the satellites that are being simulated in the NI GPS Direct Streaming Generation.vi.

Here is a picture of the spectrum I'm getting, which in my opinion looks pretty clean:

Now, whenver I run the tracking loops with the MATLAB-SDR, the tracking loops look very noisy. (Again, Acquisition does work fine.)

I'm unsure what is the issue and was wondering if anyone had worked with this MATLAB receiver and if anyone has been successful at processings GPS signals with NI-USRP 2932.

Right now any idea works for me since I've been dealing with this issue for a while now.

Thanks!

Erick

[1] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, S.H. Jensen, A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach, Boston, Birkhauser, 2006.

[Sastry]

Hi Erick,

Can you throw some more information on the setup ? Here are some questions. I will also make some comments. Please let me know if they are not correct : 

1. What is your source of the signal ? Is it the GPS Simulation Toolkit ? What is the Vector Generator ? Is it the USRP's TX port or some other Vector Generator like NI PXIe-5673 or Vector Signal Transceiver?

2. When you SiGe GN3S is working fine, who is  giving the signal to it? Is it the same source that is giving to USRP as well ?

What is the observation ? Acquisition till it locks? Or it never locks at all ?

Show me some snapshots of the data acquisition part? for the working SiGe part as well as USRP part?

Regards,
Sastry

[erickschmidt]

Hi Sastry,

Sorry for the delay, I really thought this post was long forgotten.

1. Source of Signal: NI PXIe-5611 Vector Modulator to NI-USRP 2932 via direct SMA with 30dB attenuator.

Using NI GPS Toolkit Simulator. Specifically Direct Streaming Generator.vi. Tested with Garmin Commercial GPS, it is giving a simulated position and changes when modifying the Lat/Lon/Height in configuration in the aforementioned VI.

2. When using GN3S as well as USRP 2932, I hook it up as seen in the pictures above, to avoid adding any more wireless unknown variables to the mix for now. I record GN3S signals in a Linux program, and the signal IS continuous.

Now about my first message, actually I was able to acquire and track the signals later on, but it seems the signals are interrupted somehow and that affects the tracking algorithms. I thought USRP data collection VIs streamed continuous data and not interrupted. The reason it worked is that I increased the "chunk of data" size to collect from the RX Fetch.vi 

Here is a VI I created to collect data to a file and then later on post-process it to the SDR in MATLAB. I used a Record FM.vi found somewhere in this forums, but added the "Producer Consumer" loop, since I thought that helped LabVIEW deal with continuous data, as how I require it now for GPS.

***I've also attached the VI itself if anyone wants to give it a try.

So, when I record with this VI, by using chunks of data of 100ms, I get the following in MATLAB with the GPS SDR I mentioned before:

You can clearly see the DLL loop having a big shift every 100ms, thus concluding that the signal could be "slightly" delayed every 100ms. Also, if I choose something like 1ms, ithe tracking loop doesn't even work. It gives me the results I showed in my first message. It seems the delay every 1ms can't be handled by the DLL.

So my question here is, how can I record continuous data from LabVIEW and NI-USRPs? I need something like 60seconds or so for GPS navigation testing.

Thanks

Erick

[erickschmidt]

Hi Sastry,

Sorry for the delay, I really thought this post was long forgotten.

1. Source of Signal: NI PXIe-5611 Vector Modulator to NI-USRP 2932 via direct SMA with 30dB attenuator.

Using NI GPS Toolkit Simulator. Specifically Direct Streaming Generator.vi. Tested with Garmin Commercial GPS, it is giving a simulated position and changes when modifying the Lat/Lon/Height in configuration in the aforementioned VI.

2. When using GN3S as well as USRP 2932, I hook it up as seen in the pictures above, to avoid adding any more wireless unknown variables to the mix for now. I record GN3S signals in a Linux program, and the signal IS continuous.

Now about my first message, actually I was able to acquire and track the signals later on, but it seems the signals are interrupted somehow and that affects the tracking algorithms. I thought USRP data collection VIs streamed continuous data and not interrupted. The reason it worked is that I increased the "chunk of data" size to collect from the RX Fetch.vi 

Here is a VI I created to collect data to a file and then later on post-process it to the SDR in MATLAB. I used a Record FM.vi found somewhere in this forums, but added the "Producer Consumer" loop, since I thought that helped LabVIEW deal with continuous data, as how I require it now for GPS.

***I've also attached the VI itself if anyone wants to give it a try.

So, when I record with this VI, by using chunks of data of 100ms, I get the following in MATLAB with the GPS SDR I mentioned before:

You can clearly see the DLL loop having a big shift every 100ms, thus concluding that the signal could be "slightly" delayed every 100ms. Also, if I choose something like 1ms, ithe tracking loop doesn't even work. It gives me the results I showed in my first message. It seems the delay every 1ms can't be handled by the DLL.

So my question here is, how can I record continuous data from LabVIEW and NI-USRPs? I need something like 60seconds or so for GPS navigation testing.

Thanks

Erick

[ErikL]

This almost looks like a 'finite' acquisition instead of 'continuous'.  Maybe explicitly set this in a property node.  I've successfully recorded and played back GPS data using this vi: https://decibel.ni.com/content/docs/DOC-22174

It should save continuous data without issue.

I've never seen the behavior you are describing.

I have seen a USRP's GPSDO lock on the GPS coming out of the other instrument (Despite the fact there is no antenna) and had it create a weird scenario where the GPS i the USRP was trying to sync off of the GPS signal from the instrument and recording or playing it back at the same time... almost in sort of an analog race condition. That does not seem to be the case here.

Erik

[erickschmidt]

Thank you ErikL,

You're correct. I've seen the same behavior regarding having a "GPS lock" even without having an antenna connected, but just to make sure it doesn't use the GPSDO, I forced it to use the "Internal" Clock as you can see in the VI.

I will try your VI. Thanks.

Quick question, how do you explicitly set the acquition to be 'continuous' in the VI, as you mentioned? I've never seen any option in the property node that relates to that:

Thanks

Erick

[erickschmidt]

Hello again,

I tried recording with your VI, assuming it's in int16 format interleaved I-Q, but got nothing when analizing with the MATLAB GPS Script.

Am I missing anything here? Although the VI has a comment of "Complex Double Samples" in one of the tabs, the VI is called I16, so I'm assuming right it's int16 samples right?

Thanks

Erick

[Sastry]

Hi Erick,

Just a small comment. Check the endian-ness between the applications and ensure that they are the same.

Sastry

[vvkakade]

Hi Erick,

The way your code is setup it should be doing continuous acquisition implicitly, as far as I know.

But to explicitly set continuous acquisition you can use the niUSRP Configure Number of Samples VI. Use it outside the acquisition loop before you call initiate.

Set the number of samples is finite to FALSE. Also I don't see why you need to set the timeout to a negative value. The default 10 sec timeout should work just fine.

If you want to use property nodes to set continuous acquisition instead, set the "Number of Samples is Finite" property to FALSE.

Refer to the detailed labview help on the niUSRP Configure Number of Samples VI to learn more.

[erickschmidt]

Sastry,

I've checked endianness. It's little endian. I am using an Intel Core 6th Gen i7 with Windows 7 x64. That's mostly little endian. Or else not even would I have acquired and tracked the signal. But the interruption every 100ms is still there.