[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

File metadata rx_time scaled 4x

From: Chadwick, Andrew
Subject: File metadata rx_time scaled 4x
Date: Fri, 16 Jul 2021 20:01:32 +0000

Hello list,


I want to record UTC-timestamped USRP data, and I’ve created a flowgraph using the file meta sink. I set the USRP time via set_time_now (in the final version this will become set_time_next_pps) before the file sink is created, and reading back immediately using get_time_now returns the same time. The files contain all the inline header fields… but the rx_time appears to be consistently 4 times the true value!


Example 1:

USRP time set to 1626425142 seconds after epoch -> 07/16/21 08:45:42

get_time_now returns 1626425142 seconds

In the file header ‘rx_time’ is followed by: 0c 00 00 00 02 0b 00 00 00 01 83 c5 1c d9 04 …

0x0000000183c51cd9 = 6505700569 full secs


Example 2:

USRP time set to 1626439661 seconds after epoch -> 07/16/21 12:47:41

get_time_now returns 1626439661 seconds

File header ‘rx_time’ is followed by: 0c 00 00 00 02 0b 00 00 00 01 83 c5 ff b5 04 …

0x0000000183c5ffb5 = 6505758645 full secs


Example 3:

USRP time set to 100 seconds exactly

get_time_now returns 100 seconds

File header ‘rx_time’ is followed by: 0c 00 00 00 02 0b 00 00 00 00 00 00 01 91 04 …

0x0000000000000191 = 401 full secs


It looks like the fractional seconds part is affected in the same way – inserting, say,  a 0.1 sec sleep after setting the USRP time results in approximately 0.4 sec additional delay in rx_time.


Can anyone explain this!? All other header values come out as expected. I’m using Gnuradio version with UHD 3.15.0.






Andrew Chadwick

Consultant Engineer


Phone +44 (0)1794 833257  




Follow Us: LinkedIn | Twitter | Facebook

Roke Manor Research Limited, Romsey, Hampshire, SO51 0ZN, United Kingdom. Part of the Chemring Group. Registered in England & Wales. Registered No: 00267550. The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Limited and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]