B200 TCXO GPSDO Time of Day Accuracy

[ETTUS777]

Hi everyone,

What is the expected accuracy/variance of the rx_time received from the radio when using a GPSDO with respect to GPS time and the first IQ sample?

I have an interesting problem. Im using a B200 w/ GPSDO (TCXO version) installed to watch a reference signal with very stable timing. I'm using GNU as my interface to the radio. I have a 5v antenna mounted to a roof and the GPSDO returns locked when i run the query and the lock indicator is on. If i record data for 1 hour I can see the reference signal timing is very stable during capture, however if i turn off the flowgraph and restart the flowgraph and look at the timing difference with respect to the new rx_time from the radio i get a jump on the order of 1-10uS. 

more details:

-The USRP source block's time, clock, and sync are all set to GPS/GPSDO

-The rx_time is saved to a meta file at start 

-IQ data is saved to file and processed with respect to the rx_time for each file

-sample rate is ~1.6msps, a sample counter keeps time in the processing with respect to the rx_time

Obviously theres alot of places something could be going wrong, however I have taken many steps to validate every from GNU radio to the data processing, but i have no current way to validate that the rx_times are accurate down around the 50nS range. 

thank you for any insights

[ETTUS777]

It seems my problem could be related to non-determinism of stream commands within the B2xx. I found a previous comment on the USRP-users archive which at face value contradict the B2xx documentation.

https://www.mail-archive.com/usrp-users@lists.ettus.com/msg09782.html

All of that said, the b2xx doesn't support timed operations that interface
> with the AD936x, including timed TX and RX. As I understand it the group
> delay on RX samples would be from Antenna -> AD936x > Radio Core, and this
> delay would be non-deterministic. No additional delay (from a CHDR
> timestamp perspective) is introduced downstream.

https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD

• There will be a delay between an absolute time passing and the AD936x actually beginning a streaming operation. This delay has been observed to be consistent for streaming, but other operations like gain setting require SPI readback from the RFIC and are non-deterministic.

I don't think both statements can be true and certainly "observed to be consistent" does not inspire confidence. If "consistent" means within 1-10us then yes, but that's likely not how a reasonable person who bought a GPSDO for timing applications would interpret the language. The errors I've observed over multiple test configurations support the theory of a non-deterministic streaming command. 

If this is the case I feel it appropriate the NI/Ettus correct their documentation to prevent further buyer's remorse. Truth in advertising.