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. 

[ankitkupa]

Hello I am also using USRP B200 in GNU radio and facing issues in time synchronization to receive data between USRP SINK AND USRP Source block. How to solve this issue?

[ETTUS777]

It's been a while since I worked with the B200 but as I recall I was able to identify the issue was specific to the TCXO onboard GPSDO I had. I moved it into an x310 w/ ubx-160 cards and it exhibited the same errors. My company then proceeded to buy an OCXO onboard GPSDO and the issue went away. I never went back to the B200. It was determined it would cost us more to attempt to recover losses on the TCXO then to move on. 

As you can see, this forum is a ghost town, I would look elsewhere if I currently had an issue with one of their products. 

Good luck