DRM bandwidth/passband
Hi John,
Is it possible to increase the DRM mode bandwidth/passband to 18kHz which many indian DRM stations use? Now the maximum seems to be 12kHz and it is not enough to decode all the data they are sending.
Best regards,
Pekka
Comments
Only if the KiWi admin has decided to put it in three channel mode during initial configuration.
Plenty of previous discussions in this forum about the number of channels vs. bandwidth.
From the KiWi admin configuration page.
"The original Kiwi FPGA with its 4 tuneable audio/waterfall receiver channels and 12 GPS channels was completely full. But it is now possible to load a different FPGA configuration where 2 of the waterfalls have been traded for adding more audio-only receiver channels. "
"now a third option More bandwidth. The audio bandwidth is increased from 12 to 20 kHz. This supports wide passbands for hi-fidelity listening of AM BCB and SW stations. And also wide IQ bandwidths for external applications processing large parts of the spectrum."
Regards,
Martin
Seems to me that it is not working that way. I defined one of my Kiwis to only three channels and tried to do some DRM testing. But got this...
Pekks
I assume you mean for the use of DRM in India on the AM BCB.
I went back over my notes. But I couldn't remember exactly why DRM doesn't work in Kiwi 20.25 kHz mode currently. It's possible there's just not enough Beagle processing power to do it.
So I need a recording to check if a BBAI or BBAI-64 is capable of handling a DRM 18/20 kHz channel signal on a Kiwi configured in 3-channel 20.25 kHz mode.
Unfortunately all the TWR Kiwis in India are configured for 8-channel 12 kHz mode. So if anyone knows of a 3-channel Kiwi that gets reception please let me know.
my 8073 box is back in 3-ch mode
I worked on this all day yesterday but couldn't get it to work. I'm not sure why.
I resampled the DRM extension "test" files to 20.25k and removed the restrictions that prevents operation in 3-channel, 20.25 kHz mode.
As far as I could tell that should have worked. The only possible issue could be a problem in the resampling to 24k. Dream works internally at 24k (or multiple thereof). In Kiwi 12k mode resampling from 12k to 24k is easy of course. But from 20.25k to 24k is fractional and depends on a good resampling algorithm.
The resampler supplied with Dream is also used by the ALE and HFDL extensions because they have a similar issue. ALE works at 8k internally and HFDL at 36k. So there is resampling up and down from 12k.
Both ALE and HFDL have the similar restriction of not working in 3ch, 20.25 kHz mode. So I did the same trick of resampling the test files to 20.25k and removing the restriction. And both worked fine. So it seems the Dream resampler is okay in those cases.
I also tried changing Dream to operate at 48k internally so the resampling was 20.25k to 48k. But that didn't help.
from my experience, sox with the proper lib does fractional resampley and is often the only thing that works in some of these situations.
I don't know if sox is available as an arm library that could be linked in with the Kiwi application. That's what I would need.
Looks like it is. But I'd probably have to spend another day figuring how to get it connected up in a compatible way.
you'll also need libsoxr-dev
My use of sox was to take wav files recorded by kiwirecorder and resample them accurately to the desired/required sample rate. It worked like a charm.
So I have this working now. But it's kind of moot if we can't get some of the TWR Kiwis to change to 3-channel 20.25 kHz mode.
Unless someone knows of 18/20 kHz mode DRM transmissions outside of India AM BCB.
I'd like to offer DRM and 20.25 on one of my public kiwis so if users want "narrow DRM" there it could then work
The v1.621 release going out today will have 20.25k DRM support.
I'm going to ask TWR if the guys that run the India Kiwis could change one of them to 20.25k mode for a few days so we could test using real 18/20 kHz DRM signals.
TWR kindly setup a Kiwi in Dehli in 3-channel, 20.25 kHz mode. But here's the deal. Even 20 kHz is not enough for the 18 kHz mode DRM signal. How can that be?
After going to the DRM spec (page 119) I realized that in mode A an 18 kHz DRM signal is asymmetrical. Meaning if you tune in IQ mode to carrier=0 then the LSB extends to -4.5 kHz, and the USB to +13.5 kHz (=3*4.5). See table 48 and figure 31. So what we need is an IQ mode that is at least 26 kHz wide to capture the full USB**. When I get some time (famous last words these days) I'm going to look at adding a 2-channel, 26.625 kHz mode (that's the closest number that works out).
** The actual numbers are slightly smaller than 4*4.5 = 18 kHz if you look at table 49. In mode A the OFDM carrier count works out to a signal that is really only 17 kHz wide. The LSB is -4.084 and USB +13.084 kHz. And the "18 kHz" mode DRM signal in India is indeed only slightly over 17 kHz wide: 1040 to 1057 kHz on the MW band.
A ±13kHz config would be interesting. It's becoming less and less common, but Canadian AM stations are allowed to push out to ±12.5kHz analog audio bandwidth. CFQR 600 and CFNV 940 as seen on the Montréal SDR exhibit this. ZNS-1 1540 and ZNS-3 810 in the Bahamas also has very wide (~±15-18kHz bandwidth). Deep 9kHz and 10kHz notch filters would be desirable for analog use, especially at night or if a distance from the TX.
I know of a few folks who run their own "Part 15" AM-stereo transmitters to demonstrate AM-stereo with the Kiwi who would probably welcome the wider mode too.
A ±15kHz bandwidth would be needed if anyone were to ever use the Kiwi to attempt to decode the digital HD (IBOC) sidebands some AM stations still run here in the US. The current ±10.125kHz mode should work with all-digital MA3 mode (if anyone were to ever attempt to make a decoder for that...if anyone can get a solid crack of the codec). The original patents for HD IBOC must be close to running out, if they haven't already.
Hopefully the 2-channel mode doesn't replace the 3-channel mode though...if you ever get around to it.
We can have an arbitrary number of firmware options. It just needs to be another entry in the menu/table that selects a different 2 MB FPGA bitstream file.
Hi John,
If you are doing this, any chance of a one channel as wide as possible bandwidth channel ?
It would come in very handy for occasional I/Q captures of some of the more exotic wideband digital modes.
Only if it's not too difficult though.
Regards,
Martin