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

Martin usrp-users-list at olifantasia.com
Thu Oct 22 05:05:02 EDT 2015


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
>>
>





More information about the USRP-users mailing list