I have disabled the DRM extension in the admin console for the moment. Running V 1.364. However, even when accessing from outside my local network, the DRM button is still active, and turns green when pressed. It kills the audio, but the waterfall continues running, so I assume that the DRM mode is actually not running.
The SAM button is greyed-out. I believe this is a placeholder for a future update?
Yes, in the next release the DRM button will be properly disabled (greyed-out) when DRM is disabled.
Yes, SAM (synchronous AM) is a placeholder. I figured people were going to be upset enough when I changed the mode buttons (they were) that I better only do it once. Even if it meant using placeholder(s) for anticipated future changes. Depending on your browser if you hover over SAM a tooltip should say "not yet implemented".
When one channel is running DRM today's v1.367 release allows the other channels to connect (audio and waterfall), with the limitation that they cannot use any extensions. This is because the Beagle cpu processing requirements of most extensions might be beyond the point needed to support DRM. This condition might be relaxed in the future as more improvements to the DRM code efficiency is made.
You can limit the number of non-DRM channels allowed to connect with a new setting available on the DRM sidebar of the admin "extensions" tab.
The code to detect and enforce these conditions was tricky to write and it is quite likely that there are problems remaining.
v1.368 should make Kiwi DRM much closer to the performance of Dream. AGC was missing in the DRM IQ input path. This caused a huge loss of precision for weaker signals.
In the past I've been turning AGC off while using IQ mode. This seemed to improve the DREAM audio decoding. Should AGC be left on with the DRM extension or off, or does it matter? Ron KA7U
Yes you can turn off AGC, which of course means you have to set a manual gain value.
The problem was that the AGC / manual-gain code wasn't being called at all which was very bad for small IQ values after a floating point to 16-bit integer conversion.
After a few minutes of DRM use, my Kiwi stops and I cannot communicate with it for a minute or two. This has happened a few times. I can't connect via admin either. No problems via Dream or general use. It maybe a temperature related thing but will try and troubleshoot. I Just thought I'd mention it in case anyone else has had this happen too.
2 nights in a row now I've been unable to pick up any of the signals which is odd. I check schedules and some of them I should be able to get. But waterfall is empty in those places or covered by a legit analog signal. I pick up the broadcast stations at night from North America to places in Romania, Africa etc.
So you should just pick a channel and it will start to decode automatically if you are picking up anything right?
In my location, most of the day it needs to be a solid S6-7 due to the QRM (just below that, worse since Xmas). As the signal is digital it's "all or nothing" you won't hear a noisy digital decode, it also doesn't like dropouts so "two seconds good and one second bad" will probably not allow it to decode. We had short run of decent HF conditions here (UK) with the recent minor sunspots but since then it has gone dead again. Stu
> >2 nights in a row now I've been unable to pick up any of the signals which is odd. I check schedules and some of them I should be able to get. But waterfall is empty >in those places or covered by a legit analog signal. >
You are doing nothing wrong, most of the published DRM schedules are hopelessly out of date.
To be honest DRM has so many problems for HF broadcasting purposes that I really don't know why they bother.
It't pretty much the same with any digital signal that is subject to very deep fades and multipath.
Although OFDM is probably one of the better modulation standards, the main issue is the time taken to resync when it does drop out, as is the case with all digital broadcasting. Buffering can help, but only up to a certain point.
I think some form of multicasting on the same frequency from multiple sites in order to help mitigate some of the propagation issues would have been worthy of further research.
I'm currently listening to Radio New Zealand - DRM on 9780KHz using a 210' top dipole (G5RV type) and my 8073 KiwiSDR. I was also able to decode it, but marginally with a dual 120cm diameter active loop antenna set. S6 with the loops, S6-8 with the dipole. As I type the signal is fading and the decode is becoming intermittent on the dipole. The following dropbox link has a considerable bit of decoded audio.
Re: WINB. If you zoom up and adjust the WF min/max you'll see a proper DRM signal in the 5 kHz USB part of the IQ signal. Note that the "Chan" indicator at top left correctly says "5 kHz". I don't know what those carriers are in the LSB part. They seems to make initial lock more difficult. As Eric mentions you should trim the passband. An easy way to do that is type "/0,5k" into the frequency box after the DRM extension is running.
Once you get lock restoring the passband with "/-5k,5k" maintains lock. So that's kind of interesting. I'll change the code so that selecting WINB from the schedule/menu sets the one-sided passband automatically.
Hi guys, love the DRM mode! I just noticed that when the signal is lost from one station, all other info is erased from the info window, except the station info (not all stations even have that) at the bottom of the window. See image below:
Comments
The SAM button is greyed-out. I believe this is a placeholder for a future update?
Jim Barrett
Yes, SAM (synchronous AM) is a placeholder. I figured people were going to be upset enough when I changed the mode buttons (they were) that I better only do it once. Even if it meant using placeholder(s) for anticipated future changes. Depending on your browser if you hover over SAM a tooltip should say "not yet implemented".
You can limit the number of non-DRM channels allowed to connect with a new setting available on the DRM sidebar of the admin "extensions" tab.
The code to detect and enforce these conditions was tricky to write and it is quite likely that there are problems remaining.
Ron
KA7U
The problem was that the AGC / manual-gain code wasn't being called at all which was very bad for small IQ values after a floating point to 16-bit integer conversion.
Jim Barrett
So you should just pick a channel and it will start to decode automatically if you are picking up anything right?
As the signal is digital it's "all or nothing" you won't hear a noisy digital decode, it also doesn't like dropouts so "two seconds good and one second bad" will probably not allow it to decode.
We had short run of decent HF conditions here (UK) with the recent minor sunspots but since then it has gone dead again.
Stu
>2 nights in a row now I've been unable to pick up any of the signals which is odd. I check schedules and some of them I should be able to get. But waterfall is empty >in those places or covered by a legit analog signal.
>
You are doing nothing wrong, most of the published DRM schedules are hopelessly out of date.
To be honest DRM has so many problems for HF broadcasting purposes that I really don't know why they bother.
It't pretty much the same with any digital signal that is subject to very deep fades and multipath.
Although OFDM is probably one of the better modulation standards, the main issue is the time taken to resync when it does drop out, as is the case with all digital broadcasting. Buffering can help, but only up to a certain point.
I think some form of multicasting on the same frequency from multiple sites in order to help mitigate some of the propagation issues would have been worthy of further research.
Regards,
Martin - G8JNJ
Hopefully the displayed schedule will more accurate over time. Maybe I can show verified times in a different color.
https://www.dropbox.com/s/ye81r0fpvsqiuoh/R-NewZealand-020-01-14T17_50_52Z_9780.00_drm.mp3?dl=0
So depending on propagation, DRM can be fun, but that is shortwave in a nutshell.
The new and improved DRM extension is wonderful! Thank you John.
Ron
KA7U
Once you get lock restoring the passband with "/-5k,5k" maintains lock. So that's kind of interesting. I'll change the code so that selecting WINB from the schedule/menu sets the one-sided passband automatically.