jks

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

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

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

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

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.

Kiwi TDoA certainly works using the timestamps embedded in the .wav file recorded by kiwirecorder when the "-w" or "-kiwi_wav" argument is used (IQ mode files only).

There is some example code in kiwi/wavreader.py of the kiwiclient repo that shows how to extract the timestamp info from the .wav file.

Kiwi TDoA certainly works using the timestamps embedded in the .wav file recorded by kiwirecorder when the "-w" or "-kiwi_wav" argument is used (IQ mode files only).

There is some example code in kiwi/wavreader.py of the kiwiclient repo that shows how to extract the timestamp info from the .wav file.