Typical DRM SNR for decode?

BjarneBjarne
in Configuration and Operation
After the MW season all but ended, I have enabled DRM on my Kiwis (KongSDR and ArcticSDR). I have tested functionality a bit, and I am impressed by the user interface. What I would like to hear is if there are variations in which level the SNR brings a stable decode. I have read that it may vary from station to station, but does it vary from Kiwi to Kiwi? Few have been decoded here, but judging from Kuwait-15110, I can get stable decode above around 12 dB SNR. Occasionally below, as low as 9.5, but I suspect that the AGC can play a role here so that sudden peaks aren't captured by the SNR reading.

Comments

  • WA2ZKDWA2ZKD
    seems to vary depending on mode, BW etc that the station uses.
  • Brendan_WBrendan_W
    Hi Bjarne, WA2ZKD is correct, the SNR will vary according to how 'rugged' the mode is, what the datarate is, and naturally, propagation. If you are decoding Kuwait with 12dB, you're doing well. Sounds to me like a datarate of about 11-15kbps: I consider this the 'sweet spot' for DRM, as it combines a moderate datarate, lower SNR required for decoding, and fairly robust reception over hemispheric distances. Audio quality begins to deteriorate with slower speeds, with faster speeds being FM-like. I hate to add that polar paths will generally make DRM nearly impossible to decode, what with all that strange propagation, but I think you knew that. ;)
  • ka9qka9q
    edited September 2020
    The most important factor is the choice of modulation; the higher order constellations (especially 64QAM) require a much higher SNR to decode. In my opinion, many DRM broadcasters are overly optimistic about 64QAM. I rarely decode even a 16QAM signal, though here on the west coast I don't see much DRM in the first place. Only China.

    I am especially baffled by WINB. For many months they've been using some particularly inefficient transmitter settings that throw away half their bandwidth and half their power on a set of useless unmodulated tones in their entire "lower sideband" and then cramming all their data into the upper half with 64QAM. (Not that I really care about hearing their programming anyway.)
  • jksjks
    Antonio's excellent blog has information that WINB may indeed carry data on the LSB portion of the signal: http://i56578-swl.blogspot.com/search?q=winb
    ka9q
  • ZygZyg
    edited September 2020
    WINB is using half of their 10 kHz signal bandwidth for DRM. That means, obviously, that their DRM signal is only 5 kHz wide. DRM was designed with a specific number of modes. The only mode where a 5 kHz DRM BW is specified is in the LW or MW bands for simulcast purposes, where an analog 5 kHz wide AM signal is transmitted next to the 5 kHz wide DRM signal.

    WINB uses a combo signal that is non-DRM 5 kHz data together with a 5 kHz DRM signal. This is a non-standard DRM transmission as it is used in the SW bands (DRM specifies simulcast only for LW and MW bands, not SW).

    Now follows a very, very, simplified explanation of DRM and its bandwidth requirements.

    The way DRM was designed is that a default 10 kHz wide DRM signal uses 64-QAM modulation. DRM has an integrated Forward Error Correction (FEC) in the signal. For tougher propagation conditions where a 64-QAM signal may suffer decoding problems, the use of 16-QAM is "permitted". The 16-QAM signal is of a lower audio quality, i.e. uses less information bits, than the 64-QAM but still requires the 10 kHz bandwidth. This is because the 16-QAM signal bit stream now uses a stronger FEC to help fight the poor conditions. The tougher FEC requires more information bits, which are used to occupy the space that has become available with the use of the lower quality audio.

    A DRM 5 kHz BW signal has only enough space for a 64-QAM signal but does not have any space for the more robust 16-QAM type FEC. That is why WINB cannot use 16-QAM on their combo transmission.

    Furthermore, that is why the 64-QAM 5 kHz DRM BW is only meant for simulcast in the LW and AM bands (where the propagation problems for broadcast purposes are not as severe as for shortwave).

    Now why is WINB using this non-standard combo DRM signal on shortwave? The FCC filing, made by WINB, describes a linear amplifier that is fed by a DRM exciter but does not specify another data signal except to show in a block diagram a "data" input. It appears that the use of non-DRM data was meant to be hidden from the narrative.

    It is speculated that this non-DRM data is to be used for latency arbitrage purposes where the ability to send financial trading information faster across to Europe than via fiber optic transatlantic cables is the goal.

    DRM was designed to provide high quality audio and other multi-media broadcast products. We have not had good experience with this system in North America. I do remember listening to my first reception of high quality music in stereo from Germany in 2006 on the 80 meter band. That transmission from Deutsche Welle was using 64-QAM and it was spectacular. The use of 64-QAM wasn't "overly optimistic" provided the reception was in the designed broadcast coverage area. Europe had numerous good examples of high quality reception of 64-QAM transmissions.

    -Zyg- AF4MP
    ka9q
  • ka9qka9q
    Thanks for the details. It's just a fact of life that the closer a modulation/coding scheme gets to the theoretical limit, the more "brittle" it must become. That's why so many digital schemes either work perfectly or not at all. Even analog FM exhibits this property when the bandwidth expansion ratio is high. Modems designed for two-way communication can continuously adapt with feedback to whatever the channel can support at that moment, but a broadcast scheme like DRM (or HD Radio, or DVB, or ATSC) just doesn't have that luxury.
Sign In or Register to comment.