Re: USRP b210 time stamp corrupted with two-channel receive

[Marcus D. Leech]

On 2022-04-28 23:45, Edwin Peters wrote:

Hi,

I am using an Ettus B210 in two-channel receive and require accurate time stamps. The B210 is connected to an external 10 MHz clock and PPS source.

Setting the time on the B210 works fine, and reading back the time reports the expected time.

When streaming a single channel, everything works as expected, and if I read back the time after ending the stream, the time reported by the USRP is correct. The time in the hdr metadata files is correct as well.

2022-04-29 13:39:02.117 | INFO     | __main__:start:317 - Before stream start: system time 1651203542.1179564 usrp time 1651203542.0 (2022-04-29 13:39:02.000000)
2022-04-29 13:39:02.118 | WARNING  | __main__:start:329 - Starting recording immediately
2022-04-29 13:39:02.118 | INFO     | __main__:start:331 - Calling start()
2022-04-29 13:39:02.119 | INFO     | __main__:start:335 - Time after issuing start stream command: 1651203542.1197705 usrp time 1651203542.0 (2022-04-29 13:39:02.000000)

When streaming two channels, the setup works fine, but after the top_block.start() command is issued, the time read back is somehow the current time stamp multiplied by 2. The time in the hdr metadata files has the first time stamp being the time stamp around calling top_block.start() multiplied by 2. It however increments properly (from the corrupted origin) when counting the samples.

2022-04-29 13:39:20.120 | INFO     | __main__:start:317 - Before stream start: system time 1651203560.1199565 usrp time 1651203560.0 (2022-04-29 13:39:20.000000)
2022-04-29 13:39:20.120 | WARNING  | __main__:start:329 - Starting recording immediately
2022-04-29 13:39:20.120 | INFO     | __main__:start:331 - Calling start()
2022-04-29 13:39:22.012 | INFO     | __main__:start:335 - Time after issuing start stream command: 1651203562.012672 usrp time 3302407122.0 (2074-08-25 17:18:42.000000)
Where 3302407122 = 1651203560*2 + 2

I have tested this with both UHD 4.1 and UHD 4.2. GNU radio version: 3.8.0.0 (Python 3.8.10)

Is anyone on this mailing list familiar with the issue and have a solution/workaround for this?

I have attached log output and a not so small MWE

Thanks,

-- 
Edwin Peters (PhD,MEng)
Research Fellow - UNSW Canberra Space

    I've looked at your code, and I cannot find a problem with your
    code.
    
    I have some queries in to Ettus/NI R&D to see if this is a known
    issue.
    
    Are you able to fall-back to pre-4.x to see if this was a problem
    prior to 4.x?