The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz

DRM Heard

1235»

Comments

  • I agree that he latency would probably be too high for HF Trading, but there has been some speculation that WINB has been using the lower half of its transmitted DRM spectrum for that purpose, and the Red Lion transmitter site is in a suitable location for the New York Traders.

    At the moment the HF traders seem to be trying all sorts of modulation schemes and data rates, but I have yet to be convinced that any of them are getting the results and reliability they require for it to be a viable service. However I guess they only need one or two instances a day when it does work to be able to make enough money to make it worthwhile continuing.

    With DRM I just don't know if there are enough listeners to make it worthwhile.

    Unless supported by governments, individuals or organisations that have other motives for running analogue Short Wave broadcasts stations, many of the them are struggling to deal with rising operational costs and a diminishing number of listeners. So DRM would seem to be an unnecessary additional burden.

    It's surprising how many people now use streaming apps on their mobile phones instead of listening to traditional broadcast radio.

    I was amazed that some builders, who were working next door, were playing a music radio station at an incredibly loud volume just from their phone. In the past it would have been a paint spattered portable radio, that was stuck on one station.

    How times have changed...

    Regards,

    Martin

  • HF traders use some tokenized data scheme and a lot of FEC

  • When DRM works and at decent bitrates it's not bad, I have been amazed at how well I can pick up CNR at just 30 Kw.

    Funklust is decent but it's the wrong band for Europe to be stable long enough. It would be better in the 49m band but this would require a much larger antenna, or even in the MW band but that would require an even larger antenna.

    It's a pity Funklust couldn't use one of the closed transmitters in Germany even at 10 Kw it would have good European coverage. If those transmitters even exist or their antennas today, probably not, what a waste.

  • ZygZyg
    edited February 2023

    >but there has been some speculation that WINB has been using the lower half of its transmitted DRM >spectrum for that purpose, and the Red Lion transmitter site is in a suitable location for the New York >Traders.

    If you look at the WINB 10 kHz wide transmitted signal, half of it is DRM (and when decoded shows the BW to be 5 kHz) and the other half is a non DRM data signal.

    The FCC filing showed that WINB adds a low level DRM signal with the non-DRM data, and then feeds the combined signal into a 10 Kw linear amplifier.

    The problem with running 5 kHz wide DRM is that there is no room for the error correction bits that would allow a more robust mode (that a normal 10 kHz bandwidth can provide).

  • "If you look at the WINB 10 kHz wide transmitted signal, half of it is DRM (and when decoded shows the BW to be 5 kHz) and the other half is a non DRM data signal.

    The FCC filing showed that WINB adds a low level DRM signal with the non-DRM data, and then feeds the combined signal into a 10 Kw linear amplifier.

    The problem with running 5 kHz wide DRM is that there is no room for the error correction bits that would allow a more robust mode (that a normal 10 kHz bandwidth can provide)."

    -----------

    That is my point, I think the WINB data service may be more important to them for generating revenue rather than the DRM. The DRM just helps them with the licencing, and the HF Trading probably covers the overall running costs, with a bit of profit too.

    Regards,

    Martin

  • Yes, exactly.

    The licencing issue, here, is that it appears that the FCC did not fully understand, at the time, what WINB was going to do.

    The WINB 5 kHz DRM signal has a 3 Hz audio bandwidth that is not exactly hi-fi. So it is certainly a very poor example of a DRM signal!

  • Schedule update,

    I'm hearing WINB on 9805 Khz here in Ireland, UTC 07:30 - 08:00 am, I don't know what their schedule is on this frequency. According to the Kiwi schedule, they should be on 7380 Khz.

    Did anyone figure out what the other half of the signal they transmit is ?

    Are they aware or even care that the quality is absolutely sickening to listen to ? what a waste.

  • BBC DRM now on 15620 Khz 08:06 UTC, it's not listed on the Kiwi schedule.

    No decode despite nearly S7 signal, which is one reason I don't like about DRM.

  • edited May 2023

    The KiwiSDR net seems to keep reverting to an old copy of the DRM schedule. Not sure what is going on. 15620 is definitely not in the current schedule database at drmrx.org

  • Sorry, BBC is currently on 17720. If the Kiwi is showing "Akashvani (AIR)" instead of "All India Radio" for 9620 kHz it is the latest version schedule from drmrx.org

  • jksjks
    edited May 2023

    Let me take a look. Lots of bit rot going on lately. Not only with the Kiwi stuff, but with me too, lol.

  • The last upload from drmrx.org was about 45 minutes ago (attached below). It has the "Akashvani (AIR)" change and BBC on 17720. I tried a few random Kiwis from rx.kiwisdr.com and they all were seeing the latest schedule when in DRM mode. Same with my development Kiwi here.

    Let me know if there is a specific Kiwi that isn't seeing the latest schedule and I can try and figure out why. You can also test connectivity to the schedule source by typing in the Kiwi admin console:

    jsonc curl -s drm.kiwisdr.com/drm/drmrx.cjson
    



  • That was my last update that I pushed from drmrx.org. Prior to that I noticed that my own Kiwis had reverted to an old schedule. I've seen this happen a couple of times, but don't know why. Not sure if it is connected to KiwiSDR firmware updates or not. I shall keep an eye on it.

  • Never mind. There's a problem in one of the periodic backup scripts that's clobbering the file. 🙄

  • edited May 2023

    Hmmmm - I just checked http://kiwisdr1.owdjim.gen.nz:8073/ and it is now showing an old schedule, not the one I pushed a while ago (which was working after I pushed it). http://kiwisdr2.owdjim.gen.nz:8075/ is showing the correct schedule.


    OK - a few minutes later and all seems unclobbered 🙂

  • Okay, I think this is fixed now. I tested all the backup scripts. This must have been broken for quite a while? I don't quite see where a change was made that made it start failing.

    Apologies for this..

  • jksjks
    edited May 2023

    @o00scorpion00o About DRM decoding success: It's not about signal strength as much as it is about selective fading. This is because if too many of the redundant carriers get taken out at the same time then even all the FEC (forward error correction) that DRM has won't be able to decode any audio.

    You can only see the selective fading if the waterfall max/min controls are adjusted properly. The waterfall aperture auto mode many not be good enough (WF button on main control panel, aper menu). You may need manual (man) mode.

    See the DRM control panel help button for more info.

  • Thanks for the info John.

    I've alwas been amazed at how well I can pick up CRNR on the 31m band which transmits at 30KW, can't beat the sound of Analogue though. Even funklust, as good as it is can't match Analogue.

    I'd like to hear funklust at around 20 Kbps.

  • jksjks
    edited May 2023

    The other problem is that the broadcaster can set some DRM transmission parameters which tradeoff decreased redundancy for increased media/payload bandwidth (e.g. sound quality).

    We don't know how each broadcaster arrives at these decisions (my guess is it likely depends on what the reception target is). But I'd bet that some just go "full-tilt boogie", "turn it up to eleven" without really understanding the consequences. But that's pure speculation.

    These parameters are shown in the DRM status panel at top left:

    DRM mode: A/B/C/D

    SDC: 4/16 QAM

    MSC: 16/64 QAM

    All of this is described in great detail in the DRM Handbook: http://kiwisdr.com/files/DRM/DRM-Handbook.2019.pdf

  • Good morning

    does anyone have an idea what the M4J - 17670 Khz transmitter is transmitting in addition to the audio signal, taking into account, if I am not mistaken, that the receiver plugin does not receive it

    and Dream reports "unsupported data application"
    
    
    


  • You might also ask on the DRM RX forum: https://www.drmrx.org/forum/

  • What was the audio content? Music? I suspect it may be a "playing now" music playlist. The recent tests from SE-TA appeared to have similar non-decodable content. It looks to me as if some DRM content servers have introduced a "version 1.1" for multi-media content, but Dream seems only to support "version 1". I haven't spent much time looking into it though.

    Cheers, Chris

  • Music 4 Joy is a broadcast from a commercial station in Nauen, Germany, consisting of an hour of ad-free “techno” music.

    For the rest I don't know what it sent in channel 2 it could very well be the audio file in some kind of downloadable format taking into account that it was the data transmitted was double the value of the audio file.

  • 5875kHz here in Finland now 0500UTC.

  • PSOPSO
    edited April 23

    Also Journaline working nicely.

  • https://youtu.be/iRXtbWcg6Po?feature=shared

    Mainland China started to adopt 1557khz DRM-carrier interference after June 2024.

    Using DRM for this purpose can reduce transmission power consumption by more than half compared to AM signals. In today's world where ESG is highly advocated, this can be taken into consideration that being a low-carbon and environmental-friendly 😂. Even if you disagree with the Communist Party's political viewpoints, you should still highly recommend their behavior. 😅

  • I was able to decode 13810 CNR 7,000+ miles away using a cheap random length loop on ground antenna in front of my urban yard in the San Francisco Bay Area. More broadcasters should use DRM. It is impressive on the shortwave bands.

Sign In or Register to comment.