This is an old revision of the document!
Table of Contents
I decided to try and decode the DMR data coming out of my hostpsot using various pieces of software, in order to listen to the resulting voice communications from my PC.
For simplicities sake, to get a relatively frequent stream of data, I have opted to enable DMR2YSF mode on my hotspot which will let me listen to an active YSF reflector, AmericaLink, over DMR.
When in normal YSF mode, the data the hotspot is transmitting can be decoded retty cleanly and consistently using SDRangel's DSD Demodulator.
When in DMR2YSF mode, I am having trouble getting clean decodes. Here are the pieces of software I have tried:
- SDR++ with DSD+
- SDR# with DSD+
- SDRangel with the built in DSD Demoulator
DSD+
All DSD+ attempts, regardless of the backing software, go through a VB Audio Virtual Audio Cable straight into DSD+. The decode works for between 10 and 30 seconds, before DSD+ loses sync and starts to decode garbled error filled data, with varying colour codes:
As can be seen, the decode suddenly fails on packet 5 and 6 of voice data then remains garbled and error filled. Each DATA ERR3 line lands on packet 1 of voice data, and no messages appear for packets 2,3,4,5 or 6 almost as if they aren't even being decoded, or at least are ignored.
Here is an example of a clean voice decode, with MS VOICE being packet 1 and 2,3,4,5 and 6 being their respective packets:
SDRangel DSD Demodulator
SDRangel's DSD Demodulator (henceforth referenced as “DSD demod”) is much more successful at decoding the signal, but still has trouble. It does not permenantly lose DMR sync lock unlike DSD+ however it does appear to consistently be losing sync lock continually then picking said lock back up again and continuing to decode.
Each time DSD demod loses lock, there is (naturally) a glitch in the decoded audio. These glitches are consistently spaced (to the human ear).
Going back to DSD+'s spitting out of an error on every single packet 1 once it begins failing to decode, the timing between each packet 1 (and therefore each message displayed in console) is obviously consistent (DMR packet timing is consistent), however if one remembers the timing between each packet 1 in their head, they will realise that the space between each packet 1 lines up with each glitch DSD demod experiences. It isn't hard to put two and two together that each packet 1 lines up with DSD demod losing sync lock.
I also observe something in SDRangel which I was unable to observe in SDR++ or SDR# presumably because the level of detail in their waterfalls is lower than SDRangel. I am not certain, but it seems that each packet 1 (and therefore each glitch) there is a spike of what seems to be carrier only type activity, as pictured in this screenshot:
To my knowledge there is no consistent carrier frequency in DMR, which leads me to wonder if the hotspot's modem is at fault (sending out weird data over RF in spikes) or the waterfall is incorrect (which seems unlikely as nothing around the spike is messed up).
Any ideas?
I am quite stumped by this one. My only guess here is that DMR2YSF is causing on the fly delays which result in the modem being starved of data producing no proper RF for a moment and a failure to decode. I am unable to test normal DMR mode without YSF for the moment as I do not have a DMR capable radio to key the hotspot up.
Here is a baseband recording I took: https://we.tl/t-TKzvQMO56V
If the baseband link expires and you want a copy, please let me know (I'm Alex on Discord). One thing to note about the baseband is DSD+ will not decode it properly, it merely outputs those errors on each packet 1 (which might be useful in the diagnosis) and SDRangel's DSD Demodulator can decode it, but with those consistent glitched as always.