[USRP-users] PPS get_time_last_pps()

Dave NotTelling dmp250net at gmail.com
Wed Jul 5 17:55:22 EDT 2017


Thanks for the reply Martin!  I tried using an FPGA to generate a nice 10
MHz and 1 PPS output, but I guess my matching was terrible.  Looked great
on the scope, but looked like poo over an SMA cable.  Almost 2 Vpp of
ringing O.o  Finally found a timing card on eBay and will be giving that a
go.

On Wed, Jul 5, 2017 at 5:34 PM, Martin Braun via USRP-users <
usrp-users at lists.ettus.com> wrote:

> 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
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170705/c5e0b65f/attachment-0002.html>


More information about the USRP-users mailing list