USRP Software Radio
message timing problems
Hi,
This should be easy, but it gives us great headackes.
I'm trying to send accuratelly timed messages. The messages should be timed at intervals of 5 sec. or more. I'm using a URSP-2930, so the timing should be <25 ns accurate. When I send a message triggered a timestamp, we see some very weird things.
The USRP says there is a lock. But when we compare the send signal start to a reference 1 pps, the time offset is 2.6 us (too late).
There is a gps lock, but there does not seem to be a way to check if there is a valid time lock. The ni site says that it's possible to read the skpi output of the firefly. This seems to be copied from the ettus site, the LV driver does not seem to have this option. So how can I check if there is a time lock?
When I send the message in 127 parts, 8192 samples (stream several parts, and end the stream the last message), the next message time jumps 10 us, so the total offset is 12.6 us. So this is a huge jump compared to the 25 ns accuracy! The message is correct though... When I send <5 parts, it jumps back to the regular offset of 2.6 us! In this case we don't have long signals, so we can send it as one part. It's still weird.
I checked this on two PC's, with three USRP's and the USRP example and my own code. It's very reproducable.
I'm sending 1-10 MHz IQ rate (configurable), at 400 MHz, with a LO of about 420 MHz, with the NI-USRP 1.3 driver
Does anyone have any ideas about:
1) the offset of 2.6 us
2) how to know if there is a time lock
3) the jump when sending the signal in parts
Any help is greatly appreciated,
Wiebe.
Search LabVIEW like a graph! 
Hi Brad,
Thanks for the response.
The attached VI is one of the modified examples. Sorry about the messy wiring, it's copied from the USRP example. It shows the exact problems we're having with the production code. I think it must be a combination of problems:
1) the offset of 2.6 us
This could be cable length difference between the GPS antennas? Would expect something like 100 ns...
2) how to know if there is a time lock
This is simple because NI did not make a SCPI interface. So if there is a GPS lock, there might not be a frequency lock. So the 1 pps will not be stable, and there is no way to tell.
3) the jump when sending the signal in parts
We don't need this now, so we choose to ignore the problem (we've got too many real problems at the moment).
Regards,
Wiebe.
- last edited on by
Content Cleaner
Brad,
Thank you for the input.
To help with number two, you can add GPS Lock Status to you niUSRP property node. This should allow you to know when the GPS is locked. Refer to figure 5 at the following link.
I know how to check for a GPS lock, but does this mean there is a frequency lock? Usually, a GPS lock needs to be present for maybe 10 min. before a stable freuqncy lock is possible. Only when there is a stable frequence lock, the 1 pps is reliable. You can check the reliability of the firefly's 1pps with the SCPI interface (if it was actually there).
Can you give me details on how you are calculating the 2.6 us time delay? Information on what time stamps you aer using and how you are comparing the data to get 2.6 us for example. The more information the better.
We set the time stamp on x.000000 seconds. So the signal should be send exactly at a 1 pps. We don't calculate this, we use a two channelscope, 100 MHz (an NI PXI digitizer card) , and put the signal on one channel, and a 1 pps on the other.
What is your overall setup? Are you only using one USRP 2930? Where is the PPS signal coming from?
The USRP has the 1 pps internally comiing from the firefly. The other 1 pps comes from either another firefly (from another USRP) or a spetentrio gnss receiver. In the original setup, we capture the USRP's signal and a second 1 PPS signal.
We've looked at the timing difference between the 1 PPS of two USRPs filreflies, it's < 100 ns.
We've looked at the timing difference between the 1 PPS of a USRP firelfy, and the GNSS receiver, it's <250 ns after 10 minutes firefly warmup-time. This will probably get less after more time.
We've looked at the time difference between the 1 PPS of a USRP filefly, and the signal of the USRP's firefly, and it's exactly 2.6 us!
I forgot to mention, try setting up your trigger after your GPS is locked. As of right now your code is triggering while you are trying to establish the the GPS lock.
If there is no lock, this is true for the 1st next message. As soon as there is a lock, the next trigger is set up while there is a lock. The problem remains.
But even in the current code, the firefly can have a lock at the moment the USRP code starts running.
I also had the wait for lock in front of the code, and it behaves the same.
I also had a has lock property node in a loop waiting for a lock before all the other code, and it behaves the same.
You can use the GPS Lock Status property to control a gas structure for error handling as well.
Not sure what you mean with "gas structure". Anyway, there should always be a lock in our system. Still we need to be able to send messages if a user chooses to ignores the fact that there is no lock. If there is a lock, and we do set up the trigger when there is a lock, the offset of 2.6 us is there.
Regards,
Wiebe.
Brad,
Thanks in advance.
We've found that the 2.6 us is very repeatable. But the bad thing is, when we leave the USRP running overnight, it either jumps or slights to 1.6 us. For a static error we can correct, but if it moves this is impossible...
Regards,
Wiebe.
