[USRP-users] Receiving UTC time synced samples with B210 and C API
andre.puschmann at softwareradiosystems.com
Mon Nov 25 08:59:01 EST 2019
I have a B210 with GPSDO that I'd like to receive samples at - lets say
full UTC time seconds - with. I am using the C API for that and have
gotten as far as that I can reproducibly receive samples from a also
GPS-synced transmitter. There are a few unknowns yet that I'd like to
ask help for. I've uploaded the function that contains most of the code
of interest (1). It's not a fully working example but I could create one
if needed. Here is the console output of an app that uses the function
cited below to set the USRP time to the current GPS time.
Current USRP time is 0 + 0.858
gps after rounding full_secs=1574688964
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
Calibration samples received start at 1574688966 + 0.202
Next desired recv at 1574688967 + 0.0000000000
Difference between first recv is 0 + 0.7982902607 or 12261738 samples
Realigning frame, reading 12261738 samples
Received 12261738 samples during alignmnet
Received samples start at 1574688967 + 0.0009999731
Ok - wrote 1536000 samples to /tmp/out2.dat
Anyway, the first issue I was having was when reading the GPS time from
the device using the C API. As one can see the full_secs is always zero.
But instead frac_secs contains the full seconds. Is this how it is
supposed to be or is "uhd_sensor_value_to_int" perhaps not the right way
to convert the GPS time?
A quick solution is to cast the frac_secs double to int to set the USRP
The second issue is that using "uhd_usrp_set_time_next_pps" doesn't seem
to work, but "uhd_usrp_set_time_unknown_pps" does. If I am not mistaken
this shouldn't be the case, should it?
And last but not least, receiving the actual samples. Note that I am
using a continues streamer so the way I align samples to full UTC
seconds is to receive first, then, from the receive timestamp, calculate
the number of samples to the next full second and then drop that many
samples from the next calls. This seems to work fine but from the first
receive call after the calibration, the returned rx_time is roughly one
ms more than expected. I.e. "Received samples start at 1574688967 +
0.0009999731". Isn't the timestamp supposed to start from the first
sample in the buffer?
More information about the USRP-users