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

[erickschmidt]

Thank you vvkakade I will check that option you mention in the property node and get back to you.

[erickschmidt]

Hello all,

I am getting the same result with the non-continuous recording with NI-USRP2932.

Actually I was wondering if anyone has experienced the following, which I believe is called "cycle slip", (that is a sudden change of frequency/phase).

In this example, only one PRN is shown, but in actuality, ALL tracking channels get dropped at the same time:

The reason I found out about it is by increasing the PLL Noise BW to 120-130 Hz which is a very high number, but it seems it's able to avoid dropping all the channels at once since it "catches" the sudden change of frequency "jump":

This happens with an NI-USRP2932 as well as an N210, both with GPSDO.

Is there a way to find out if the USRP is dropping packets through the Ethernet connection or something like that?

Thanks

[ErikL]

I have Some thoughts...  Here are some different vectors of brainstorming:

1. Software only:  What if you try this using the generated IQ data straight from the GPS Generation VI bypassing any hardware?  Maybe something in the decoder code is doing this such as a FOR loop that has filter wind up?

2. Synchronization: When using the GPSDO have you moved the jumper so that its using the 10MHz from the GPSDO?

3. Oscillator drift between the PXI chassis and the USRP:  Use the 10 MHz out from the chassis to discipine the USRP. (you'll need to move the jumper back and use front panel port)

If its your acqusiton sofwtware / hardware actually dropping samples you can test it by sending and receiving a standard AM signal, slightly off from DC (because there is a filter at DC) you should see the discontinuity in that too. You should be able to hear that if you record and playback an FM radio station too.

Erik

[erickschmidt]

ErikL

Thank you for the information. I will try those approaches that you have mentioned.

In the meantime I wanted to ask again if there is any known documentation regarding Overflows/Underflows for NI-USRPs? Since this is a very important aspect in Front-Ends.

For instance, I have seen for UHD from Ettus that there is actual documentation regarding this, and since UHD is run in Command Line, it actually outputs in stdout letters D or O, indicating that an overflow/underflow is occuring at the moment. I actually recorded signals with GNURadio and saw these DDDs and when I analyzed my signal I did see some discontinuities.

Since LabVIEW does not have Command Line to see what happens at a specific time, there's no way if there are actual packets being dropped, since it uses UDP protocol for transmission through the Ethernet cable.

Shouldn't there be an easy way to see if packets are dropped from NI-USRPs, any built-in indicator in LabVIEW or the sort?

Thanks

[alynch]

The niUSRP Fetch RX Data vi will output an error on the error out terminal if there is an overflow and you can connect that to an indicator on the front panel if you want to see it immediately.  The niUSRP Write Tx Data vi will similarly report an error on underflow. The examples provided with the driver will stop on such an error and present it to the user after closing the session. 

The error will look like this:

USRP Fetch Rx Data (CDB WDT).vi<ERR>Overflow: an internal receive buffer has filled before the data could be returned.  Consider reducing the IQ rate, increasing the Fetch rate, or increasing the number of samples per Fetch.

[erickschmidt]

alynch,

Yes I am aware of that error and also other errors such as "out of sequence", etc. In fact my VI's have the error in/out connected all throughout the program. 

I do see this error from time to time, but this is when I use I/Q rates of 20, 25 MHz or so. This error seems to be a "fatal error" meaning the program can't continue, thus it stops completely.

I was thinking more about dropping one or two packets now and then, but still continuing (Like UHD from Ettus, which displays DDs now and then, meaning it dropped a couple packets but still keeps running). Since the protocol used is UDP, there is no acknowledgement of packets.

Thanks

[erickschmidt]

ErikL,

I read in other posts that you have previously recorded GPS L1 signals of several minutes with your "Record & Playback with USRP" VI. Although I wasn't able to run that VI, I was wondering if these files are available somewhere, so I can test them?

Thanks

[HarryHook]

I have usrp-2922  with TXCO clock  and laview on hand.  I intend to use active antennas to collect satellite data

But the question now is how do I get useful data from usrp in which format,  bin, NEMC etc?

In order to calculate on matlab and get the right information.

Thanks  for your reply.

[Shalini.M]

Hi HarryHook, 

We recommend creating new threads for new questions and linking to relevant threads instead of posting on old ones so it is more visible to the community. 

When you create your new question, it would be helpful to clarify what file formats the 3rd party software can accept to get your desired result and provide more context on your software setup (are you using LabVIEW, LabVIEW Communications Suite, GNU Radio? Are you using a shipping example? Are you getting any errors?).

[Makmerfy]

Hello,Erik) I have  one question,you are using gpsdo synchronisation and generate gps at the same time?