[time-nuts] signal transit time through WWV receiver

[jimlux]

On 1/6/20 11:08 AM, GERRY ASHTON wrote:
> I am aware that WWV signals are intended to reflect the correct time at the instant the signal leaves WWV's antenna. It's up to me to allow for propagation through air and space to my antenna, and transit through my receiver. With newer direct-sampling receivers, the processing time in the receiver's computer circuitry may greater than we are accustomed to.
> 
> Are there any simple tricks to measuring the transit time. My thought is to create a pulsed 10 MHz source, with AM modulation when the signal is on, and compare a path directly into one channel of an oscilloscope with the audio output of the receiver feeding into the other channel. Any easier or better suggestions? My test equipment is much more limited than many other members of this list.


That's the sort of approach that works.

A *lot* depends on the implementation of your SDR.
If your processing chain is deterministic in delay (for instance, it's 
doing all the DSP in a FPGA in logic) then you can directly measure the 
number of clocks between RF signal coming in and demodulated signal 
coming out.  That's what I did on a HF receiver for a satellite - we 
time stamp the ADC "start sampling" instant (when samples start to flow 
into the chain) with a counter that also snaps the count when we get a 
1pps from GPS or onboard atomic reference.

I triggered a arbitrary waveform generator with the 1pps - so I have a 
RF signal that begins at a known time, and a sampling epoch that begins 
at a known time, so I can line it up.

If your SDR is done mostly in software in the CPU, then you have to 
worry about interrupts, etc.   This was a huge problem for the early 
FlexRadio SDRs - people are used to operating CW with a delay (from 
propagation and analog electronics) but NOT used to having a variable 
delay, and the comments on the forums were copious and hostile. Over the 
years they fixed their buffering strategies, etc.


Unfortunately, most software radio folks, especially people doing 
implementations for their thesis or dissertation, just care about moving 
the bits through a virtual wire, and don't care about absolute timing. 
As long as the bits in the recorded data are correct, they're happy.

Most SDR software running on PCs (e.g. gnuradio) just doesn't care. 
There's no real attempt to try and have deterministic timing, just that 
you don't drop samples. People who need a constant delay implement some 
scheme of a FIFO buffer, run the front end ahead to make sure the FIFO 
has enough samples in it, and then start the playback from the FIFO 
using the media player API of the host OS to make sure that samples come 
out synchronously (the problem is identical to making sure that the 
audio and video tracks line up).





> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>