3
$\begingroup$

It's well-known that the signal processing of an SDR adds a significantly amount of latency, the SDR software on the computer adds more latency due to data buffering, FFT, decoding, demolutaion, audio buffering, etc, not to mention that most computer systems aren't a real time system and have unpredictable delays as well.

It's usually not a concern, but can be a problem when one wants to extract the precise time-mark of a signal. To elaborate the question, imagine a SDR running on a typical desktop computer, operated by a program powered by GNU/Radio, and consider two scenarios:

  1. Time Synchronization - SDR is tuned to a frequency and listens for an incoming pulse. A pulse is generated at 00:00:00 UTC. Upon receiving it, the SDR immediately set the system's real-time clock to 00:00:00 UTC (for example, in a time synchronization experiment). What would be the error between UTC and system's real-time clock now? Ignore all insignificant sources of errors.

  2. Time-mark extraction - SDR is tuned to a frequency and listens for an incoming pulse. As soon as the pulse is generated, the SDR records the wall-clock time (for example, in a propagation-delay experiment). Assume the system's real-time clock has no error, what would be the error of the time measurable by the program?

Both questions ask for a simple parameter: The typical total delay/latency in the entire signal path of the an SDR setup on a desktop computer. We also assume the latency is not predetermined and calibrated to zero prior to these experiments.

I expect the latency is much worse than what the operating system on a desktop computer is capable of. For example, protocols like NTP uses a PLL-like algorithm and finish the time synchronization in multiple steps, an final error of less than 10 milliseconds over the Internet is not impossible given a datacenter network with symmetric routes (see this statistics), but extracting the time-mark of an one-off event is harder for a desktop computer with SDR, and I expect the delay of an unoptimized implementation has a latency of a dozen of milliseconds. If an accuracy comparable to NTP is required, it's better use a specialized circuit, not a SDR.

That all being said, while I can find some research papers and projects on the architecture of a low-latency SDR, I cannot find a solid measurement or analysis of latency/delay of a typical SDR, such as a RTL-SDR, HackRF, LimeSDR, with gqrx or GNU Radio. I was inspirited by Dan Luu's experiments on the typical latency between entering a keystroke and a screen update on various computer hardware, or the typical latency of latency between a keystroke and a keyboard scancode using a logic analyzer, some experiments for SDR software and hardware would be greatly useful.

I believe this can be an useful reference question. Any data, analysis, and measurements are appropriated. I think I could do some measurements in the future.

Improve this question
$\endgroup$
8
  • 1
    $\begingroup$ As a result, you cannot use a cheap SDR to extract a precise time-mark from radio signals. That is technically incorrect. You can achieve arbitrary (OK, limited Heisenberg) timing accuracy on a radio observation within the time framework of the radio stream, no matter how high the processing delay is. If you want to synchronize your clock, you'd better use a specialized circuit: Synchronize which clock to what achieving which accuracy? $\endgroup$
    – Marcus Müller
    Sep 26, 2019 at 14:12
  • $\begingroup$ By "desktop SDR" you mean an SDR that uses an ordinary desktop computer running a common OS like Windows, Linux, or Mac OS? Or you mean an SDR that can fit on a desktop? $\endgroup$
    – Phil Frost - W8II
    Sep 26, 2019 at 14:44
  • $\begingroup$ @MarcusMüller Edited. $\endgroup$
    – 比尔盖子
    Sep 27, 2019 at 2:54
  • $\begingroup$ @PhilFrost-W8II Title edited. $\endgroup$
    – 比尔盖子
    Sep 27, 2019 at 2:54
  • 1
    $\begingroup$ Aaaah! Now, this makes this a technically answerable question! In that case, you could assume a minimum latency and some variability in latency. Think in the dimension of single-digit milliseconds; all the processing delay is totally irrelevant here. You don't need to set the clock to 0:0:0 the moment you can decode that, you can just as well then calculate how much time has gone by since that pulse was seen and add that to the time you set. $\endgroup$
    – Marcus Müller
    Sep 27, 2019 at 14:36

3 Answers 3

Reset to default
3
$\begingroup$

The answer is that the SDR hardware devices are all very different, so is the optimization quality of the SDR code. So one pretty much needs to calibrate for their specific setup: device, current method of connection, OS, and software running.

I find network latency between the SDR hardware server and the software client to be one of the biggest variables, especially over multiple WiFi hops. But in general, there could be ADC buffering, FPGA buffering, hardware filtering and downsampling buffering, USB output buffering (depending on USB transfer block size), USB driver input buffering, OS network buffering (depending on MTU size), Ethernet buffering, WiFi access point buffering, OS driver IO buffering, application network buffering, SDR software filtering buffering, SDR demodulation buffering, audio processing buffering, OS audio driver output buffering, audio DAC DMA buffering, and etc. All these buffers are covering for latency jitter in the various interfaces, caused by asynchronous timing and contention for various buses, WiFi bandwidth, OS processes, and etc., which vary widely between setups.

Note that an SDR radio can shortcut many of these latencies by having all this hardware and software on a single board or a single chip running a real-time OS or even no OS.

I test SDR total system latency by keying a QRP transmitter (preferably fully analog) into a dummy load, then listening to the delay between my keyer sidetone and when I hear the sidetone out of one of my SDR apps. You can record these two in stereo and view the waveform rise-time deltas for a more precise measurement. Depending on which SDR device I'm using, and whether the data is hardwired or from an SDR server over WiFi. I can hear latencies of from around 100 mS to over 1 Second.

Improve this answer
$\endgroup$
2
$\begingroup$

It's difficult to give an exact number, because the overall latency involves at least:

  • Processing of the signal on the given SDR
  • Transferring data over USB 2.0 / USB 3.0 / PCIe (depending on what is used)
  • Latencies on USB controllers on both SDR and PC (+ USB hubs, if used)
  • Latency caused by other USB devices (keyboard, touchpad, webcam, ...) on the bus. Note that USB devices are always pulled by the PC, USB device can't just push data over the bus without being asking for it.
  • Latency in the device driver
  • Latency between ring0 and ring3 levels in the particular operating system (involves process switching, data copying => memory latancy, etc)
  • Processing of the data by the given software (GNU Radio / Python / C++)

My rough approximation would be that all this chain typically takes no more than 10 ms (probably much less). But it's difficult to give a more accurate number because there are too many unknown variables.

It's also difficult to measure this number experimentally. You could write an application that receives a signal, somehow replies to it, measure the time between sending request and receiving response (roundtrip time) and divide it by two. The problem is - where you can find a measuring equipment with near-zero internal latency? I can only think of using an analog transmitter and receiver and measure the roundtrip time using an oscilloscope.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Measuring the delay between RF-in and Audio-out is actually a very practical experiment for anyone with an external-triggerable pulse generator and a digital storage oscilloscope, even though the audio subsystem on most systems is not real-time either and adds more latency, but should be a good sanity check. Another way I can think of is syncing the system clock to NTP (error is ~20 of milliseconds), tuning to WWV, and measure the system clock when a pulse is received, if the software latency is greater than the system clock error, it should be obvious, rdtsc provides high time resolution. $\endgroup$
    – 比尔盖子
    Sep 26, 2019 at 12:20
  • 2
    $\begingroup$ "where you can find a measuring equipment with near-zero internal latency?" Analog oscilloscope? GPS receiver? And you don't actually need zero latency, you just need to accurately measure relative times. $\endgroup$
    – Phil Frost - W8II
    Sep 26, 2019 at 14:20
  • 1
    $\begingroup$ Typical USB and OS audio buffers are usually longer than 10 mS in length. RTL2832U USB buffers can be particularly long, well over 100 mS in some cases. $\endgroup$
    – hotpaw2
    Sep 26, 2019 at 15:09
1
$\begingroup$

Dr Warren Pratt, NR0V, introduced low-latency FIR filters to the 2018 SDR Academy. Dr Pratt reminded the audience that mimimum phase FIR filters deliver much lower latency than linear phase filters and opined that ease of design has driven the persistence of linear phase filters. I have observed a dramatic reduction in latency by switching to Dr Pratt's WDSP library in the SDRs I employ.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .