v1.360+: DRM extension now available
This discussion was created from comments split from: Who runs Linux for their main OS/Browser [how to run Dream on Linux].
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/b3/8d505793f4de9a175762dd3409e271.png
Ron
KA7U
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.
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
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/f0/15097a81aef5e3a1212eb275e18804.jpg
Neat.
From the Wikipedia page you reference "The principle of DRM is that bandwidth is the limited element, and computer processing power is cheap; modern CPU-intensive audio compression techniques enable more efficient use of available bandwidth, at the expense of processing resources."
Does this make a kiwi solution most likely limited to the BB AI?
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.
Ron
KA7U
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:
A new DRM transmitter, an ASI CE-50000WS, was installed in April 2018. The transmitter is rated at 15 kW and is using the Rhombic antenna at 062 degrees. The authorized schedule for this transmitter is: Monday-Friday 0700-1000 on 7315 kHz, 1000-1200 on 9265 kHz, 1200-1700 UTC on 13690 kHz.
https://www.drm.org/ktwr-december-drm-schedules/
https://www.drm.org/what-can-i-hear/broadcast-schedule-2/
But no audio, just quieting
audio here
Dec 25 1228-1243UTC
Dec 26 0121UTC
As with other extensions you can make a bookmark that selects DRM and an existing station in the menu, e.g. The cached build mechanism is still not working, so this update will take around 35 minutes.
But it is early days yet. I am working on improving the efficiency of the code. In recent tests I am able to run one DRM plus 3 ordinary connections provided they don't do anything harsh like run the WSPR extension.
And there is also hope that eventually two active DRM sessions will be able to run on a stock BBG/B Kiwi.
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/ea/c34a8b56a8bf7f3b5bcd184af271b8.pdf
I have a fairly popular KiwiSDR due to my rural location with few RFI issues. I've vowed to put a second KiwiSDR online, as soon as they're back on Drop
Ron
KA7U
Ron
KA7U