Hi

A lot depends on just how this or that was implemented. The bottom line is 
still that 
ionosphere issues will give you a “couple of milliseconds” sort of ill defined 
variation. 
If your RF chain is below 10 MS (which it likely is) is a bigger delay, but not 
a bigger
variation. 

Bob

> On Dec 2, 2017, at 6:22 PM, jimlux <[email protected]> wrote:
> 
> On 12/2/17 12:57 PM, Patrick Barthelow wrote:
>> Just about to go across town to pick up TWO  Radio Shack Timecube radios,
>> that someone will sell cheap.  Been 35 years since I have seen one.   Used
>> one in College to bring time to astronomy instruments in the field.
>> From a newbie: Has anyone measured or does anyone have an idea of the
>> propagation delay between an audio tick signal on the RF carrier at the
>> antenna port, to an audio waveform on the demodulator/audio amp?
>>  Microseconds?  more? less?
>> If I hang a scope on the speaker audio out, and RF modulated input signal,
>> how much delay would there be?     Same question for  an SDR.
>> Best, 73,   Pat Barthelow AA6EG
>> apol <[email protected]>[email protected]
> 
> 
> Milliseconds - mostly from the audio processing chain.  For analog systems, 
> the delay is inversely proportional to bandwidth and proportional to number 
> of sections.
> 
> In SDR implementations (obviously not the Timecube) the latency can be quite 
> long, and can be variable. Most SDR implementations don't pay much attention 
> to RF/Baseband delays as long as the pipeline doesn't run dry.
> 
> 
> This was a big, big deal in the early days of the Flexradio, because it used 
> a half duplex processing chain with buffers - Tx/Rx turnaround could only 
> occur on a buffer boundary, and if you cranked the bandwidth down (for CW), 
> the buffer had to be fairly big.
> 
> 
> Gnuradio and Pothos (two popular frameworks for SDR) don't really have any 
> provision for accurate timing - they're basically "signal flow graph" based 
> systems, and the latency through a block is whatever the software gives you.
> 
> The USRP, in the usual "RF up/downconverter from digital samples" mode is 
> also noncoherent between RF and digital side - there's buffering in the USB 
> or Ethernet interfaces.
> 
> The RTL-SDR pod is "coherent within a stream" - that is, once you're 
> streaming, there aren't any dropped samples, but the absolute timing between 
> RF sample and a particular USB data packet is uncertain (due to USB device 
> driver stuff).
> 
> _______________________________________________
> time-nuts mailing list -- [email protected]
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Reply via email to