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

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

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.

So things got worse beginning with v1.337. I found one reason and have fixed that for today's v1.359 release. But there is still a performance problem I don't understand. v1.337 was a complex release with waterfall averaging and a lot of BBAI-related changes.

I haven't looked at it, but it is possible the denoiser and auto-notch can be moved from the Beagle to Javascript running on the browser. Assuming the browser is running on a decent device (desktop pc or recent mobile device) the performance should be sufficient to support it.