[USRP-users] wrong timestamps with gpsdo in recent uhd 3.10.git-34-g90b88a27

Martin usrp-users-list at olifantasia.com
Fri Oct 23 08:23:57 EDT 2015


Hi

  On 23-10-15 00:14, Michael West wrote:
> There is actually a known issue prior to 3.9.0 where this kind of clock
> cycle slip can occur.  It is one of the reasons we strongly urge people
> to move to 3.9.1.
OK, I will move to 3.9.0 or above then on all my systems.


> Another thing to keep in mind is that the GPSDO is a disciplined
> oscillator and will adjust over time and temperature, so the clocks will
> drift.
Yes, I know. Maybe I should stop capturing every few minutes, re-set the 
uhd clock to gps time and start capturing again.

Could it hurt to do this while capturing ?


> Each GPSDO has a 50ns tolerance, so you can have up to 100ns of
> difference between 2 of them.  The change in time difference you are
> detecting is 250ns,

  which means that you are setting the master clock
> rate to 4e6 (making each tick 250ns).
No, my master_clock is set to 32 Mhz.
The receive samplerate is set to 4 Mhz.
So this means that I have slipped one sample (= 8 clockcycles)


But the other larger problem is the more then 10.5 msec timestamp 
difference that has been there from the start. (0.0105210625 seconds)

This corresponds to 336674 clockcycles or 42084.25 samples.
Note the .25. It is  not even on a sample edge.

I do not know yet where this difference is coming from.

I hope that will go away with uhd 3.9.x
I will let you know after the next tests.


>  I recommend setting the master
> clock rate as high as possible to minimize the potential difference.
> For a 4e6 sample rate, that is 32e6 (for 1 channel) or 16e6 (for
> multiple channels).
I will keep the samplerate at 32 Mhz
>
> The GPSDO is also sensitive to temperature changes, so putting the
> boards in enclosures and allowing the temperature to stabilize will help
> minimize that.
That will be a furture enhancement. Let's first get the timestamp 
difference below 10 msec. Then below 1 usec, which should be enough for 
now for this system.


Thanks and Regards,

Martin
>
> Regards,
> Michael
>
> On Thu, Oct 22, 2015 at 2:45 PM, Martin <usrp-users-list at olifantasia.com
> <mailto:usrp-users-list at olifantasia.com>> wrote:
>
>     Hi,
>
>     > multi_usrp::make()
>     > set master clock rate and/or TX rate and RX rate
>     I set master_clock
>     and I also set RX rate to e46
>     > wait for GPS lock by polling gps_lock sensor
>     I also do that. After gps_lock has been detected I wait for 8 extra
>     seconds. Just to be sure.
>     > wait for PPS edge by polling multi_usrp::get_time_last_pps()
>     I have not done the above yet. I will add this.
>     > set time to GPS time using multi_usrp::set_time_next_pps()
>     I do that
>
>     The only thing that is hard to change in my application is that the
>     RX rate is set again right before capturing.
>     (Set to the same rate as set before, 4e6)
>     Would that make any difference?
>
>     If it can make a differrence I can test with this code temporarily
>     commented out.
>
>
>     Note that 3.8.1 may initialize the time wrong (automatically), but
>     that should be solved by using the algorithm descriobed above,
>     before capture starts.
>
>     I did a test with uhd 3.8.1 with the algorithm above
>     I captured using two B2X0 devices receiving ADS-B signals from the
>     same antenna (through a splitter).
>
>     The timestamps from the two captures should be the same (+/-
>     timestamp granularity) but they differed by exactly 0.0105210625
>     seconds.
>     This lasted for a period of 186 seconds. (A few hundred signals
>     detected with all a timestamp difference of exactly 0.0105210625
>     seconds)
>     Then the timestamp difference changed to 0.0105208125 seconds and
>     stayed that way until the end of the test (185 seconds later)
>
>     So something is still not going well with the timestamps.
>
>     But the multi-second or multi-year differences in the timestamps are
>     gone with 3.8.1 and the algorithm above.
>
>     I am not sure if the remaining timestamp differences are a uhd
>     problem or a problem in my signal decoding code. I will have to
>     check the whole chain of handling timestamps. There might be a
>     problem with dropped packets or something like that.
>     I will try to create some simpler testcode which just outputs
>     timestamps when signal power is detected above some threshold.
>     And then input some square test pulses to two or four systems.
>
>     Or is there already such testcode available somewhere ?
>
>     I will also do the same test with uhd 3.9 and maybe uhd 3.10 and see
>     if that makes any difference.
>
>     I am working on multilateration.
>     I have all algorithms in place to calculate the position of
>     transmitters according to the timestamps of four receivers. I just
>     have to get the timestamps right.
>
>     Thanks for the help so far.
>
>     With best regards,
>
>     Martin Dudok van Heel
>
>
>
>     On 22-10-15 14:24, Michael West wrote:
>
>         Hi Martin,
>
>         I understand your frustration, but I can assure you that much
>         testing
>         has been done with clock synchronization and that the
>         set_time_next_pps() does set the time at the next PPS edge.
>
>         I am concerned that reverting to UHD 3.8.1 may actually mask a
>         problem
>         in your application.  In UHD 3.8.1, the times are set to the time
>         reported by the GPSDO automatically during initialization if a
>         GPSDO is
>         detected, whether or not there is GPS lock.  You may think you are
>         getting a good time because it looks reasonable, but it may be wrong
>         because the GPSDO is not locked.
>
>         For any version of UHD, I would recommend using the following
>         algorithm:
>
>         multi_usrp::make()
>         set master clock rate and/or TX rate and RX rate
>         wait for GPS lock by polling gps_lock sensor
>         wait for PPS edge by polling multi_usrp::get_time_last_pps()
>         set time to GPS time using multi_usrp::set_time_next_pps()
>
>         Regards,
>         Michael
>
>         On Thu, Oct 22, 2015 at 2:05 AM, Martin
>         <usrp-users-list at olifantasia.com
>         <mailto:usrp-users-list at olifantasia.com>
>         <mailto:usrp-users-list at olifantasia.com
>         <mailto:usrp-users-list at olifantasia.com>>> wrote:
>
>              Hi,
>
>              The timestamps seem to be now in the right range (>1445000000)
>
>              I am still not convinced that setting the time at next PPS
>         will set
>              the time at next PPS. It might be a few seconds late, which
>         would
>              result in timestamp differences of a few seconds.
>
>              I am now doing some tests with multiple USRPs capturing at
>         the same
>              time.
>              I am trying to find out if the timestams from the different
>         USRPs
>              now correspond.
>              (They are connected to the same receive antenna with the same
>              cable-length so timestamps should correspond exactly)
>
>              Due to all the differences/regressions in uhd 3.9 and uhd 3.10
>              regarding timestamps and clocking I will probably go back
>         to uhd
>              3.8.1 until this has all been sorted out and tested properly.
>
>              With best regards,
>
>              Martin
>
>
>              On 20-10-15 18:52, Martin Braun wrote:
>
>                  Hi Martin,
>
>                  can you please give us an update if Michael's
>         suggestion worked? We
>                  appreciate it a lot!
>
>                  Cheers,
>                  Martin
>
>                  On 19.10.2015 12:27, Michael West via USRP-users wrote:
>
>                      Hi Martin,
>
>                      I believe this may have something to do with the
>         auto clock
>                      rate feature
>                      introduced on the B-Series in UHD 3.9.0.  The
>         master clock
>                      rate will
>                      automatically adjust depending on the sample rates
>                      requested.  The
>                      master clock rate is the rate at which the clock
>         ticks, so
>                      the value of
>                      the time translated from the tick count can be
>         thrown off if
>                      the rate
>                      changes.  The simple solution is to make sure you
>         set the TX
>                      and RX
>                      sample rates before setting the time and/or disable
>         the auto
>                      clock rate
>                      feature by setting the master clock rate
>         explicitly.  For
>                      example:
>
>                      usrp->set_master_clock_rate(16e6);
>                      usrp->set_tx_rate(1e6);
>                      usrp->set_rx_rate(1e6);
>                      // set the time here
>
>                      Regards,
>                      Michael
>
>                      On Mon, Oct 19, 2015 at 7:19 AM, Martin via USRP-users
>                      <usrp-users at lists.ettus.com
>         <mailto:usrp-users at lists.ettus.com>
>                      <mailto:usrp-users at lists.ettus.com
>         <mailto:usrp-users at lists.ettus.com>>
>                      <mailto:usrp-users at lists.ettus.com
>         <mailto:usrp-users at lists.ettus.com>
>
>                      <mailto:usrp-users at lists.ettus.com
>         <mailto:usrp-users at lists.ettus.com>>>> wrote:
>
>                            Hi
>                            With the latest UHD git I get wrong
>         timestamps in my
>                      samplestream
>                            when using gpsdo.
>
>                            I used B200 with installed mini-gpsdo-tcxo,
>         with GPS
>                      antenna and and
>                            good GPS reception (GPS-lock).
>                            I initialize by setting the clocksource and
>                      time-source to gpsdo
>                            I wait for GPS lock.
>                            I get the GPS time from the gps-time sensor
>         and set
>                      the usrp time on
>                            next pps to this time +1 (next second =
>         1445256623)
>
>                            Then I start capturing and get the timestamps
>         from the
>                      samplestream.
>
>                            With UHD 3.8.1 I get correct timestamps
>                            But with current uhd 3.10.git-34-g90b88a27 I
>         get wrong
>                      timestamps
>                            where the full_seconds seem to be half of
>         what they
>                      should be
>
>                            full_secs = 722628352
>                            Which in human readable time is Tue, 24 Nov 1992
>                      18:05:52 GMT
>
>                            With uhd 3.8.1 I get the correct timestamp
>                            full_secs = 1445258479
>                            Which translates to  Mon, 19 Oct 2015
>         12:41:19 GMT
>
>                            WIth uhd 3.9.0 with e310 I get correct
>         timestamps at
>                      start of
>                            capturing but after a few hours capturing I get
>                      timestamps which are
>                            a few hours in th future. (This may be an
>         unrelated
>                      problem)
>
>                            It is eather a regression in the UHD
>         drivercode or I
>                      missed some
>                            recent change in the API which means I have
>         to change
>                      my code.
>
>                            Has anybody seen this too?
>                            Can anybody confirm this ?
>
>                            Where in the code shoudl I look for changes?
>
>                            Thanks,
>
>                            Martin
>
>
>                            Detailed logs below.
>
>                            uhd 3.8.1 with B200 with mini-gpsdo-tcxo:
>                            linux; GNU C++ version 4.8.2; Boost_105400;
>                      UHD_003.008.001-46-g2d3f3c6c
>                            Initialize by setting USRP time to current
>         GPS time
>                      1445258479
>                            timestamp full_secs correct: 1445258479
>
>         http://www.onlineconversion.com/unix_time.htm => Mon, 19 Oct
>                      2015
>                            12:41:19 GMT
>
>                            uhd 3.10.git-34-g90b88a27 with same b200 with
>                      mini-gpsdo-tcxo:
>                            linux; GNU C++ version 4.8.4; Boost_105400;
>                      UHD_003.010.git-34-g90b88a27
>                            Initialize by setting USRP time to current
>         GPS time:
>                      1445256623
>
>                            timestamp full_secs wrong: 722628352
>         http://www.onlineconversion.com/unix_time.htm => Tue, 24 Nov
>                      1992
>                            18:05:52 GMT
>
>                            The number seems to be exactly half of what
>         it should be.
>
>                            With e310 with uhd 3.9.0 I seem to get the
>         correct
>                      timestamp at start.
>                            But then I see too high timestamps after
>         several hours
>                      of capturing.
>                            (Timestamps a few hours in the future)
>
>
>                            Wrong behaviour on uhd 3.10 on b200 (same b200)
>                            linux; GNU C++ version 4.8.4; Boost_105400;
>                      UHD_003.010.git-34-g90b88a27
>
>                            -- Detected Device: B200
>                            -- Operating over USB 2.
>                            -- Detecting internal GPSDO.... Found an
>         internal GPSDO
>                            -- Initialize CODEC control...
>                            -- Initialize Radio control...
>                            -- Performing register loopback test... pass
>                            -- Performing CODEC loopback test... pass
>                            -- Setting master clock rate selection to
>         'automatic'.
>                            -- Asking for clock rate 16.000000 MHz...
>                            -- Actually got clock rate 16.000000 MHz.
>                            -- Performing timer loopback test... pass
>                            Available clock sources: ('internal',
>         'external', 'gpsdo')
>                            Available time sources: ('none', 'internal',
>                      'external', 'gpsdo')
>                            gps_locked status: GPS lock status: locked True
>                            Setting USRP time to GPS time: 1445256623.0
>         <tel:1445256623.0>
>                      <tel:1445256623.0 <tel:1445256623.0>>
>         <tel:1445256623.0 <tel:1445256623.0> <tel:1445256623.0
>         <tel:1445256623.0>>>
>
>                            gps_locked status: GPS lock status: locked True
>                            gps_gpgga_string=
>
>
>         $GPGGA,121022.00,5211.5273,N,00522.3578,E,1,11,0.9,8.0,M,46.0,M,,*65
>                            checksum is valid:  0x65
>                            GPS Fix status:GPS fix
>                            GPS time: 12:10:22.00
>                            GPS position: latitude: 52.1921216667 longitude:
>                      5.37263 altitude: 8.0 M
>
>                            timestamp_full_secs = 722628352 (wrong)
>
>                            Correct behaviour on uhd 3.8.1 on b200 (same
>         b200)
>                            linux; GNU C++ version 4.8.2; Boost_105400;
>                      UHD_003.008.001-46-g2d3f3c6c
>
>                            -- Operating over USB 3.
>                            -- Detecting internal GPSDO.... Found an
>         internal GPSDO
>                            -- Initialize CODEC control...
>                            -- Initialize Radio control...
>                            -- Performing register loopback test... pass
>                            -- Performing CODEC loopback test... pass
>                            -- Asking for clock rate 32.000000 MHz...
>                            -- Actually got clock rate 32.000000 MHz.
>                            -- Performing timer loopback test... pass
>                            -- Setting master clock rate selection to
>         'automatic'.
>                            -- Setting references to the internal GPSDO
>                            -- Initializing time to the internal GPSDO
>                            -- Successfully tuned to 1090.000000 MHz
>                            --
>                            Available clock sources: ('internal',
>         'external', 'gpsdo')
>                            Available time sources: ('none', 'internal',
>                      'external', 'gpsdo')
>                            gps_locked status: GPS lock status: locked True
>                            Setting USRP time to GPS time: 1445258479.0
>         <tel:1445258479.0>
>                      <tel:1445258479.0 <tel:1445258479.0>>
>         <tel:1445258479.0 <tel:1445258479.0> <tel:1445258479.0
>         <tel:1445258479.0>>>
>
>                            gps_locked status: GPS lock status: locked True
>                            gps_gpgga_string=
>
>
>         $GPGGA,124118.00,5211.5288,N,00522.3621,E,1,10,1.2,8.4,M,46.0,M,,*6C
>                            checksum is valid:  0x6c
>                            GPS Fix status:GPS fix
>                            GPS time: 12:41:18.00
>                            GPS position: latitude: 52.1921466667 longitude:
>                      5.37270166667
>                            altitude: 8.4 M
>
>                            timestamp_full_secs = 1445258479
>
>                            correct behaviour on uhd 3.9.0 on e310
>                            linux; GNU C++ version 4.9.2; Boost_105700;
>                      UHD_003.009.000-0-unknown
>
>                            -- Loading FPGA image:
>                      /usr/share/uhd/images/usrp_e310_fpga.bit... done
>                            -- Detecting internal GPSDO .... found
>                            -- Initializing core control...
>                            -- Performing register loopback test... pass
>                            -- Performing register loopback test... pass
>                            -- Performing register loopback test... pass
>                            -- Performing CODEC loopback test... pass
>                            -- Performing CODEC loopback test... pass
>                            -- Setting time source to internal
>                            -- Asking for clock rate 16 MHz
>                            -- Actually got clock rate 16 MHz
>                            -- Performing timer loopback test... pass
>                            -- Performing timer loopback test... pass
>                            WARNING: no 'gpsdo' clock_source available
>         (This is
>                      normal on E310,
>                            which only has 'internal')
>                            Available clock sources: ('internal',)
>                            -- Setting time source to gpsdo
>                            Setting gain to 35
>                            Gain is 35
>                            Rate is 4000000
>                            Using Volk machine: neon_hardfp
>                            my_position_full (52.193268333333336,
>         5.4340183333333334,
>                            7.1799999999999997, '16:33:53')
>                            ...
>                            timestamp_full_secs = 1445186035
>
>
>                            _______________________________________________
>                            USRP-users mailing list
>         USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>                      <mailto:USRP-users at lists.ettus.com
>         <mailto:USRP-users at lists.ettus.com>>
>                      <mailto:USRP-users at lists.ettus.com
>         <mailto:USRP-users at lists.ettus.com>
>                      <mailto:USRP-users at lists.ettus.com
>         <mailto: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 <mailto:USRP-users at lists.ettus.com>
>         <mailto:USRP-users at lists.ettus.com
>         <mailto: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