regression: wrong timestamps with gpsdo

[nldudok1]

With the latest UHD git I get wrong timestamps in my samplestream when using gpsdo. The full seconds should be the full seconds from GPS time. But I get half of that.

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 (1445258479) But with 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 the future. (This may be an unrelated problem)

It is either a regression in the UHD drivercode or I missed some recent change in the API which means enduser code has to change.

[mbr0wn]

@nldudok1 Sorry for leaving this unattended for so long. Are you still having issues?

@michael-west FYI

[nldudok1]

Hi Michael, Thanks for handling this. I will check whether it solves it as soon as I am Back at my development pc.

With best regards, Martin

mbr0wn notifications@github.com schreef op 15 augustus 2016 20:01:46 CEST:

@nldudok1 Sorry for leaving this unattended for so long. Are you still having issues?

@michael-west FYI

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/EttusResearch/uhd/issues/49#issuecomment-239877781

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[michael-west]

Discussion regarding the issue has been on the mailing list (http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-October/016378.html).

[michael-west]

The root cause of this issue is that the auto tick rate feature is changing the tick rate whenever the sample rate is changing. Since the clock is set in ticks on the device, this makes the tick count previously set incorrect. The workaround is to either explicitly set the master_clock_rate and/or sample rates before setting the time on the device.

[mbr0wn]

Closing this. This issue is split into multiple tasks / action items:

• When changing the tick rate, times are off. That's just how the device works. Need to document better.
• The hours-into-the-recording is probably a rounding issue.