|
| From: | Chadwick, Andrew |
| Subject: | RE: File metadata rx_time scaled 4x |
| Date: | Mon, 19 Jul 2021 10:19:14 +0000 |
So, I understand a bit more about what is happening here, although not yet sure how to fix the value in the file header – any advice welcome. The problem seems to arise because I am receiving and then interleaving two channels (I’m using a B210). If I receive one channel only, the header rx_time is always as expected. But
if I receive two channels, the header rx_time depends on the USRP sample rate: At 1 MHz, 2 MHz, 4 MHz: rx_time is 2x the correct value At 8 MHz (the rate I want to use): rx_time is 4x the correct value At 16 MHz: rx_time is correct! I realised I was using the same sample rate value in the File Meta Sink block as in the USRP block, and thought this might be my error – i.e. I need to either double the sample rate
or perhaps set the relative rate to 2, to account for the interleaving – but changing either of these does not seem to have an effect on rx_time (should it?). I then also noticed that, when interleaving 2 channels and depending on the sample rate, I get an extra couple of messages about setting of clock rates. Master clock rate selection
is automatic and on setting up the USRP, I always start with: [INFO][B200] Asking for clock rate 16.000000 MHz… [INFO][B200] Actually got clock rate 16.000000 MHz. [INFO][B200] Asking for clock rate 32.000000 MHz… [INFO][B200] Actually got clock rate 32.000000 MHz. I then get some extra debug output of my own, relating to setting of the USRP time, then a message about setting the minimum output buffer on block 2 (the USRP being block 1) – after
which point there is no more setting of USRP parameters in my top_block. But if sample rate is 4 MHz or less, I now get an extra: [INFO][B200] Asking for clock rate 16.000000 MHz… [INFO][B200] Actually got clock rate 16.000000 MHz. Or if sample rate is 8 MHz: [INFO][B200] Asking for clock rate 8.000000 MHz… [INFO][B200] Actually got clock rate 8.000000 MHz. And if sample rate is 16 MHz – nothing! The actual sample rate i.e. amount of data recorded seems fine but the 32->16 or 32->8 change in clock rate clearly corresponds to my erroneous rx_time, so I guess the number of ticks
that reaches the File Meta Sink has been scaled somehow. Can anyone clarify why there is some extra negotiation of clock rate going on here, and how I should account for it? It does look like the effect is to scale rx_time by exactly 2x or
4x, so I could of course account for that in post-processing – but I would rather have a correct value in the file header to avoid confusion. Thanks for any suggestions. Andy 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. From: Chadwick, Andrew
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 3.7.13.5 with UHD 3.15.0. Thanks, Andy |
| [Prev in Thread] | Current Thread | [Next in Thread] |