[USRP-users] PPS get_time_last_pps()

Martin Braun martin.braun at ettus.com
Wed Jul 5 17:34:09 EDT 2017


On 06/28/2017 11:03 AM, Dave NotTelling via USRP-users wrote:
> I still think it's odd that the radio is drifting at 12-14 us per second
> when using the PPS to sample the time.  Am I incorrect in my assumption
> that calls to get_time_last_pps() will work with just the PPS input and
> no 10 MHz reference?  If that does work, and my 1 PPS reference is
> stable and accurate, then I would expect to see a very slow drift.  In
> my mind the clock on the radio should be almost as accurate as my timing
> reference that is generating the 1 PPS output.  Meaning that calls to
> get_time_last_pps() should be almost exactly 1 second apart and should
> show a time that is almost 1 second ahead of the last call.  Granted, in
> the long run the time will be wonky since there is no 10 MHz reference
> to keep time rolling at an accurate rate, but in the short term (< 1
> minute) I feel like things should be pretty spot on.

It doesn't matter how stable your PPS is if your clock is not stable
though. Let's assume your PPS is *perfect*. How many times does your
clock toggle between two PPS flanks? That's unrelated. 10µs seems a lot
though....

But in general, a PPS by itself, and then using an internal clock
source, is not a useful combination.

Cheers,
Martin




> 
> On Wed, Jun 28, 2017 at 1:16 PM, Dave NotTelling <dmp250net at gmail.com
> <mailto:dmp250net at gmail.com>> wrote:
> 
>     Just ran across an old version of this same question I asked a while
>     back (sorry for the dupe)
> 
>     [post]
>     To add to the comments, the USRP clock is virtually guaranteed to
>     drift away from the host system time if the time is set once and the
>     clocks on the host and USRP are left to run on their own oscillators
>     with no PLL between them.  To keep a USRP synchronized in time takes
>     a 10 MHz reference to which the USRP can use to lock the PLL and
>     a PPS to make sure the time on the USRP is set at a precise moment. 
>     Some USRPs (B2xxmini and E3xx) can lock the PLL to the PPS, so the
>     10 MHz is not necessary, but they are far less accurate.  Unless
>     your host system can put out a 10 MHz and PPS, the times will be
>     off.  This is why a GPSDO is commonly used to synchronize devices
>     that are not close to each other and a common 10 MHz and PPS (i.e.
>     distributed by an Octoclock) is used to synchronize devices that are
>     close to each other.
> 
>     Also, the calls to getTime() and usrp->get_time_now() are not
>     synchronous or atomic and will have varying amounts of latency
>     between the return values so the accuracy of the measurement is
>     probably not very good at trying to measure something less than a
>     few milliseconds.
>     [/post]
> 
>     Seems that I completely goofed and I need *both* 10 MHz and 1 PPS :(
> 
> 
>     On Wed, Jun 28, 2017 at 12:57 PM, Dave NotTelling
>     <dmp250net at gmail.com <mailto:dmp250net at gmail.com>> wrote:
> 
>         Also, I updated to UHD_003.010.001.HEAD-0-gc705922a and got the
>         same issue of the time being off by ~ 14 us every second.
> 
>         On Wed, Jun 28, 2017 at 9:04 AM, Dave NotTelling
>         <dmp250net at gmail.com <mailto:dmp250net at gmail.com>> wrote:
> 
>             I just recently hooked my N210 up to a 1 PPS source and was
>             expecting that calls to radio->get_time_last_pps() would
>             return a number really close to 1 second from the previous
>             call.  Instead I get the following:
> 
>             [output]
> 
>             $ g++ t.cc -o t -luhd -lboost_thread -lboost_system && ./t
>             linux; GNU C++ version 4.8.4; Boost_105400;
>             UHD_003.009.004-0-gfb928f42
> 
>             -- Opening a USRP2/N-Series device...
>             -- Current recv frame size: 1472 bytes
>             -- Current send frame size: 1472 bytes
> 
>             UHD Warning:
>                 Unable to set the thread priority. Performance may be
>             negatively affected.
>                 Please see the general application notes in the manual
>             for instructions.
>                 EnvironmentError: OSError: error in pthread_setschedparam
>             0.000012
>             0.000024
>             0.000035
>             0.000047
>             0.000059
>             0.000071
>             0.000083
>             0.000094
>             0.000106
>             0.000118
>             0.000130
>             0.000142
>             0.000153
>             0.000165
>             0.000177
>             0.000189
> 
>             [/output]
> 
>             The drift is fairly constant at ~ 11-12 us per second.  It
>             should be noted that I am not using a 10 MHz reference. 
>             Just the 1 PPS.
> 
>             Here is the code I'm using:
> 
>             [code]
> 
>             #include <boost/thread.hpp>
>             #include <uhd/usrp/multi_usrp.hpp>
> 
>             int main(){
>                 uhd::usrp::multi_usrp::sptr radio =
>             uhd::usrp::multi_usrp::make(std::string("addr=192.168.12.2"));
>                 radio->set_time_source("external");
>                 radio->set_time_next_pps(uhd::time_spec_t(0, 0));
>                 boost::this_thread::sleep_for(boost::chrono::seconds(2));
> 
>                 while(1){
>                     uhd::time_spec_t t = radio->get_time_last_pps();
>                     fprintf(stderr, "%0.6f\n", t.get_frac_secs());
>                    
>             boost::this_thread::sleep_for(boost::chrono::seconds(1));
>                 }
>             }
> 
>             [/code]
> 
>             And here is the output of the test_pps_input command:
> 
>             [output]
> 
>             $ /tmp/test_pps_input --args addr=192.168.12.2
>             linux; GNU C++ version 4.8.4; Boost_105400;
>             UHD_003.009.004-0-gfb928f42
> 
> 
>             UHD Warning:
>                 Unable to set the thread priority. Performance may be
>             negatively affected.
>                 Please see the general application notes in the manual
>             for instructions.
>                 EnvironmentError: OSError: error in pthread_setschedparam
> 
>             Creating the usrp device with: addr=192.168.12.2...
>             -- Opening a USRP2/N-Series device...
>             -- Current recv frame size: 1472 bytes
>             -- Current send frame size: 1472 bytes
> 
>             UHD Warning:
>                 Unable to set the thread priority. Performance may be
>             negatively affected.
>                 Please see the general application notes in the manual
>             for instructions.
>                 EnvironmentError: OSError: error in pthread_setschedparam
>             Using Device: Single USRP:
>               Device: USRP2 / N-Series Device
>               Mboard 0: N210r4
>               RX Channel: 0
>                 RX DSP: 0
>                 RX Dboard: A
>                 RX Subdev: UBX RX
>               TX Channel: 0
>                 TX DSP: 0
>                 TX Dboard: A
>                 TX Subdev: UBX TX
> 
> 
>             Attempt to detect the PPS and set the time...
> 
>             --     1) catch time transition at pps edge
>             --     2) set times next pps (synchronously)
> 
>             Success!
> 
>             [/output]
> 
>             Am I doing something wrong?
> 
> 
>             Thanks!
> 
> 
> 
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 





More information about the USRP-users mailing list