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

Michael West michael.west at ettus.com
Thu Oct 22 08:24:45 EDT 2015


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>
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>> 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>
>>>      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>
>>>      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>
>>>      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/20151022/0ac0bd48/attachment-0002.html>


More information about the USRP-users mailing list