[time-nuts] Propagation delay within analog radio, (Radio Shack Timecube) and an SDR, at HF

[Bob kb8tq]

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 <jimlux at earthlink.net> 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 <apolloeme at gmail.com>loeme at gmail.com
> 
> 
> 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 -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.