sdr delays

Discussion in 'Ham Radio Discussions' started by KI3U, Nov 12, 2015.

ad: L-HROutlet
ad: l-rl
ad: Subscribe
ad: L-MFJ
ad: Left-3
ad: MessiPaoloni-1
ad: Left-2
  1. KI3U

    KI3U Ham Member QRZ Page

    A few days ago over in the Homebrew and Kits Projects forum in KK4YDR's thread " How do you use this thing? I am thinking of getting into SDR " I brought up the topic of the time delay introduced by sdr versus realtime :

    ..... SDR comes at the price of a time lag - when receiving, the signal audio you hear and its spectrum you see are slightly delayed compared with a straight through analog radio. ..... I also tuned in an AM BC station. When the station announcer spoke he got off about 3 words in analog before they came in on sdr. .....

    The rig in question was an sdrPlay with an old Dell 5100 machine running XP with 1.5 GB RAM. I am curious what sorts of typical delays other sdr operators are seeing with their respective setups, everything from cheapie dongles to the presently acknowledged Duesenbergs.

    Your data is welcome.

    Berj / KI3U
  2. VE3KUT

    VE3KUT Ham Member QRZ Page

    I get about the same (Three word delay) on 2 I7 laptops & my Note 3 phone, using one of the cheapo RTL-SDR's...
  3. KY5U

    KY5U Subscriber QRZ Page

    When the station announcer spoke he got off about 3 words in analog before they came in on sdr. .....

    So? You scared you're going to miss the end of the world by 3 seconds? Don't worry, you won't.
  4. KB9BVN

    KB9BVN Ham Member QRZ Page

    This is one of the reasons CW ops don't flock to SDR just yet.
    K1OIK likes this.
  5. KE6KA

    KE6KA Ham Member QRZ Page

    I have an SDRplay. Most of the time the latency is about half a syllable behind the IC-7000. If I do anything that requires more processing power the latency increases, but is still nothing to be concerned about for most uses.
  6. KI3U

    KI3U Ham Member QRZ Page

    Yes I briefly mentioned last weekend's CW contest in the other thread - observing the sdr delays had me mull over some what-ifs.

    A further question is : what is the variation in the time delay for a fixed setup? For example suppose an advanced sdr is set up to monitor a constant periodic signal, say a rubidium-referenced pulse oscillator radiating sufficiently to the sdr antenna. The setup is allowed to run continuously, and the I.F. bandwidth is open enough so that changing propagation conditions change the total spectrum in the I.F. channel albeit may be dominated by the local periodic pulses. How does a typical amateur sdr react - will it keep an acceptably constant time delay regardless of all else going on in the I.F. channel, or will there be significant delay drift, and how much drift? It's not all that easy to build and code a really good "real-time" system, i.e. one which remains in step with a periodic reference signal.

    These questions interest me because I view sdr's more as radio-spectrum instruments than as "radios". And these questions are obviously of importance to radio astronomers. To me a real "radio" delivers signals at analog speed, perhaps an old-fashioned view but nevertheless preferable.

    Berj / KI3U
  7. N9DG

    N9DG Ham Member QRZ Page

    Unfortunately the comments made no mention of what the SDR software that was being used was. It does make a huge difference for what you will experience for latency of the signal through the system. And depending on the program being used, there may be considerable latitude to change how much latency there is. In general when you create filtering that has very steeps skirts you will be adding latency. And also the size of the data chunks being fed into the number crunching algorithms for those filters also plays a role in how much latency there is. These trade-offs are not unique to "SDRs", even "DSP IF" radios have the same considerations, though nobody that I'm aware of who built a DSP IF radio has ever provided the end user any means to adjust any of that. You just live with the designer's choices. That is also true of the vast majority of the SDRs implemented as traditional radios.

    PC based SDRs also have to deal with the latencies of the operating system that was never meant to be real-time. And there is considerable variation from one computer to the next. It is that variability which was a one of the big reasons for why Flex moved the DSP work of the 6K series into the radio hardware box. Simply put, they have a lot more control over it doing it that way. And bringing the DSP work into the radio box also provides more control over the RX/TX turnaround time as well.

    My own experiences have been that the RF to audio latency of the signal while passing through the Flex 5K and 6K series radios I have is indistinguishable from an all analog radio like a Ten Tec Corsair. The HPSDR hardware with PowerSDR is pretty much the same. In all cases these direct radio to radio comparisons were done with the exact same signal being fed to each radio via a passive signal splitter, and then listening to the audio out of each radio with their own speakers.

    The one SDR program that I have used that does have significant signal propagation latency is HDSDR. Its high latency is present whether I'm feeding is a signal from a cheap dongle, HPSDR hardware, or even feeding it a DAX IQ signal from the 6K radio. HDSDR just plain has latency. Although I have never tried to see how much I could improve it via settings changes. Pursuing that just wasn't important to me.

    The bottom line is that you can't simply make a blanket statement that all SDRs will have more latency than a traditional or all analog radio will.
  8. KI3U

    KI3U Ham Member QRZ Page

    Lets try a little Gedanken-experiment :

    Consider a very simplified hypothetical scenario, contrived in the spirit of Schroedinger's Cat:

    a monitoring station is given a reference clock along with a mission - to continuously monitor a specific normally-quiet frequency at some specific bandwidth. The station is to continuously await a possible trigger signal on that frequency. The trigger signal is simply a specific short pulse, analogous to a CW dit.

    If a trigger signal is received, it means the monitoring station must take some action before the next tick of the reference clock, or else it will be blown into oblivion and the station kitty will meow no more.

    Let :

    Tk = be the reference clock time immediately preceding the trigger signal

    Tk+1 = the reference time one tick after Tn

    delta-TT = the time interval from Tk when the trigger signal arrives at the monitor receiver system input

    delta-TA = the time interval between trigger arrival and Tk+1

    So therefore : delta-TA = ( Tk+1 - Tk ) - delta-TT

    Let :

    delta-td = be the delay time of the monitor receiver system between its input and output

    delta-ta = the time available for preventive action before doom

    Therefore :

    delta-ta = delta-TA - delta-td

    delta-ta = ( Tk+1 - Tk ) - delta-TT - delta-td

    which shows that the available time to prevent doom decreases with greater receiver delay (as expected), and also decreases the later the trigger signal occurs after Tk.

    The result can be cast into a "doomsday ratio" :

    DDR = | ( delta-TT + delta-td ) / ( TK+1 - Tk ) |

    As the DDR approaches 1 the time left to prevent doom is less and less.

    The above is simplified of course, it does not take into consideration items such as the rise time of the leading edge of the trigger pulse, and receiver bandwidth - every receiver, even analog will delay a pulse more as the bandwidth is reduced. Also the actual delta-ta is an infinitesmal amount less than per above. But nevertheless the simplification retains the essential idea being explored (assuming no algebra errors).

    I think it would be very interesting to set up a model experiment per above and compare some good but simple-architecture analog receivers against various sdr receivers. Most interesting would be a contest between analog and digital engineers to see who can build the system with the lowest DDR - this would likely entail frequency classes.

    Berj / KI3U
  9. KM9R

    KM9R Ham Member QRZ Page

    Your pc seems very dated. Regardless, not only do I experience zero delay w/ my sdr wrt cw or phone but I also experience zero delay when operating afsk based digital (either psk250 or rtty) even while utilizing software (fldigi or mmtty) to run those modes.

    Also fyi a major contest superstation just ran SSCW 2015 so2r with a single flex6700 and a beta version of an upcoming software update. He placed in the top 5 of his category and reported even better things to come. The op would not tolerate a delay that you suggest. Food for thought.

    However, if you think there is a delay, then by all means there is a delay.
    Last edited: Nov 14, 2015
  10. N8MSA

    N8MSA Ham Member QRZ Page

    This is a frequent topic of discussion on SDR mail-lists and forums. Processing delays exist in all modern radios, including Yaesu/Icom/Kenwoods, as the DSP processors (mostly TI TMS320-family devices) still need a modest amount of processing time to output baseband audio. The two most widely-used current SDR transceiver platforms (OpenHPSDR and Flex Signature Series) have different architectures, but both have a bit more latency than "DSP" radios as there are more processing elements in the signal chain.

    OpenHPSDR processing latency has been thoroughly characterized and can, to a large extent, be controlled by the operator. There is a fixed amount of time that data needs to move through the FPGA (which functions as a "virtual mixer", performs data reduction (decimation) and some initial filtration before handing the data off to the PC. The delay through the PC is a function of sample rate and data buffer size; sample rate is related to panadapter width and buffer size influences filter "sharpness" (more buffers give steeper filter skirts). There are also delays in the PC audio drivers and Ethernet stack, so ultimately the latency looks something like this:

    CW Receive Latency:
    512 buffers 58msec
    1024 buffers 87msec
    2048 buffers 133msec

    It's worth noting that speed of PC's CPU doesn't have a major influence on latency, rather it's the quality of the I/O subsystems that have the greatest influence on PC-influenced latency. The OpenHPSDR version of PowerSDR works on relatively modest PCs without increased latency, and then simply becomes erratic long before any delays are noted.

    The Flex Signature Series delays are less well-known, as there is less known about the architecture (relative to the open-source OpenHPSDR) but there have been a lot of measurements shared in the Flex User Community. Below is a link to an excellent Community discussion on this topic, including references to a section of manual where this topic is expanded on:


    Mike - N8MSA
    2E0TZX likes this.

Share This Page