jks

The elves have delivered. In time for Xmax / Boxing Day (depending on your timezone) v1.360/61 contains a DRM Beta test.

This will be a long update as a new compiler is installed and the DRM code takes 10 times longer to compile than the rest of the Kiwi code. The DRM compiled code is cached so future updates won't take as long.

There are many bugs and limitations currently:

• Use of the DRM extension on stock Kiwis using the BeagleBone Green/Black is limited to a single channel. DRM won't start unless there is no other activity. All other activity is excluded while DRM is running. Kiwis using a BeagleBone AI can run 4 DRMs simultaneously (but watch your CPU temperature!)
  
• If you don't want DRM available on your public Kiwi because of the above exclusions then disable it in the admin "extensions" tab. DRM entry, "User enabled?" switch. But consider leaving it enabled as we need geographically dispersed DRM Kiwis for testing.
  
• DRM doesn't currently work on Kiwis configured for 20 kHz channels.
  
• The stations in the India MW menu won't play because Dream xHE_AAC codec development is not finished.
  
• The frequencies in the menus are currently static and DRM frequencies are known to change. We are working on a scheme to dynamically update them.
  
• Exactly why some signals "drop-out", even though they are relatively strong, is an interesting topic. We hope to write about this at some point. It has to do with selective fading and the DRM transmission options selected by the broadcaster (e.g. QAM options, coding rates, protection levels).
  

No, which surprised the heck out of me. Right now you can run the DRM extension on one channel of a regular BBG/B Kiwi. The waterfall slows to a crawl and there can be no other connections that take resources (including things like WSPR autorun etc.) But it works. GPS can be enabled. On the BBAI DRM takes roughly 30% (@ 1 GHz) of the second cpu (less @ 1.5 GHz). So it's likely several instances can be run simultaneously.

But I have spent no time doing performance measurement and optimization yet. It is quite likely that applying ARM Neon vectorization (similar to Intel SSE) to the inner loops will speed things up. Christoph did this for our GPS code.

The screenshot above is running on an ordinary Kiwi in the UK that I'm using for development that has good DRM reception.

Progress with the DRM extension continues.

I recently found a simple bug in Dream with the interface code to the FDK codec that prevented mono services from producing audio (e.g. the two-channel All India Radio 7550 kHz). But it took a long time to find. The problem doesn't exist with the older FAAD2 codec, but it has other problems. FDK seems to require less cpu resources so naturally I want to use it.

The DRM waveform is really interesting. If you zoom in with the Kiwi waterfall you'll notice three apparent "dead" carriers on the right-hand side of the passband. To explain: Mode B DRM OFDM modulation consists of 206 carriers spaced every 46.875 Hz across the (almost) 10 kHz wide DRM signal. You can sort of see them when you zoom in. The image below is RFI at 3965 kHz. You can see that central carrier is missing. The unmodulated carriers are at 16, 48 and 64 carrier positions away from the center. These turn out to be intentional unmodulated "frequency pilots" used by the software to do correction for receiver mistuning. The diagonal "ripples" in the waveform is (frequency) selective fading seen on virtually every other HF signal.

https://en.wikipedia.org/wiki/Digital_Radio_Mondiale
https://www.drm.org/wp-content/uploads/2019/02/DRM-Handbook.pdf

The search result page now contains an assortment of filtering options.
Hopefully this will improve your chances of finding what you're looking for.

@rohit Well, there is not much to say at this point. I have been working on re-packaging the open source Dream code into a Kiwi extension for about 4 weeks now. Much as I have done for other open source work (e.g. the Kiwi SSTV and CW decoders).

When might it be available? I would say weeks to months. The work has been very, very difficult for a number of reasons. And I don't fully understand the legal issues about the codec and how exactly I have to handle its installation. This is a major limitation and annoyance with Dream and I want to completely automate a solution (part of the Kiwi philosophy).

The biggest surprise is that it works on a stock Kiwi using the Beaglebone Green/Black. Although right now only with severe limitations. Essentially nothing else of significance can be happening on the Kiwi except for GPS. The waterfall nearly comes to a halt due to the lack of cpu cycles. So for now it is a single-user solution.

BUT this is better than nothing. I initially expected it would only work using the Beaglebone-AI which is not available as a standard Kiwi product (you have to put one together yourself). But note that no effort has been put into optimization of the code yet. There is a lot that can be done. So I have hope it will perform better on the BBG/B in the future.

You are correct that All India Radio on MW (e.g. Delhi 828, 1368) uses the xHE_AAC codec and there is currently no support in Dream for xHE even though the codec I use in Dream (fdk-aac) does support it. Julian Cable of Dream development said a year ago he's working on it. But so far nothing has happened.

Note that the patent situation is not unique to xHE_AAC and Fraunhofer (fdk-aac developer) as your post implies. It is a general issue with all AAC codecs and intellectual property. Fraunhofer has made the copyright of their codec somewhat open (subject to limitations) and this is why it has recent support in Dream. But this does not change the patent situation including Fraunhofer's additional patent claims.