[USRP-users] E310 GPSDO and PPS sync

Long, Jeffrey P. jplong at mitre.org
Mon Apr 27 15:29:20 EDT 2015

I have a couple of questions regarding the time sync with the E310.

If I run query_gpsdosensors it informs me that the GPS is locked the USRP is locked to the 10 Mhz ref but it says GPS and UHD Device time are NOT aligned last_pps.....Try re-running the program.

It then informs me that NMEA strings are not implemented for this device. Does this mean that we won't ever be able to set GPS time of day or it is just not implemented yet?

My second question I guess is more of an observation with a final question as to whether it is supposed to be doing this. I am trying to get a E310's transmit time aligned with GPS timing. Using the tx_timed_samples example I set up a simple experiment to transmit every second a small burst of samples. Since I want the tx burst to occur right on the 1 PPS I modified the tx_timed_samples to use set_time_next_pps instead of set_time_now so I could ensure that when I call send I can pass times that make the transmit burst occur on the PPS. For reference I set up a E110 with a GPSDO running the same code and verified that its GPS was locked. I should mention that we re-radiate GPS inside our lab. Then for sanity I fired up a symmetricom instrument that provides precision PPS and ref. Putting everything on the scope and triggering with the instruments PPS I verified that the E110s burst was popping out right on the PPS of the instrument.

Now to the E310. In my first attempt I could never get the E310's time to align with either of these two references. It would come up randomly each time. It said its GPS was locked etc and would run fine but it was never aligned. After trying a number of things we finally discovered that if we waited about 10 seconds and then called set_time_next_pps it would stick and the E310 would be locked with the other two systems.

Being more of an FPGA guy and pretty familiar with the Ettus FPGA designs I noticed that there is something new in the E310 design called ppsloop.v. It looks like you are doing something more elaborate to bring in the PPS before you pass it on to the vita time stuff. Is it possible that it is taking longer than planned and calls to set_time_next_pps are not working till that PPS is up?

In any event I have a work around but I would think that it should not take this long so I thought I would bring it to your attention.

Jeff Long
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150427/3d4d047b/attachment-0002.html>

More information about the USRP-users mailing list