Propagation delay within analog radio, (Radio Shack Timecube) and an SDR, at HF
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@gmail.comloeme@gmail.com
"The most exciting phrase to hear in Science, the one that heraldsnew
discoveries, is not "Eureka, I have found it!" but:
"That's funny..." ----Isaac Asimov
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@gmail.comloeme@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).
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@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@gmail.comloeme@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Message resent... I had forgotten that this group is HTML-fobic....
---========================
On 12/3/2017 12:22 AM, jimlux wrote:
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.
It also depends whether the audio output is done using the PC sound subsystem, or instead the
SDR has its own DAC. For example, the Elad FDM-DUO, when used stand-alone, without a PC, has
a latency that judging by ear is not distinguishable form that of an analog radio.
Same for the HPSDR Ozy+Mercury combo, when the DAC on board of the Mercury is used.
Only when using Windows or Linux for the rendering of the demodulated audio you can have
hundreds of milliseconds of latency.
73 Alberto I2PHD