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'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).

PiStar comes with a command called pistar-mmdvmcal which allows you to tweak settings of the modem manually to calibrate it, and it then spits out the values for you to type into the pistar dashboard to save your calibration.

Built into this test tool is a DMR test mode called DMR Simplex 1031 Hz Test Pattern (CC1 ID1 TG9) which as you can guess sends out a DMR signal in which the voice audio contains a 1031 Hz audible tone.

DSD+ again successfully decodes this single tone transmission for 10 to 30 seconds producing a clean sounding beep, then loses lock:

DSD demod is able to see the signal and recognises it as DMR, however it keeps losing lock (without consistentcy) and never produces a beep tone or any audio at all (audio is working, because selecting random noise causes no-squelch decode weirdness and random digital noise glitching which is normal):

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. This has been quite discounted by the test tone failure.

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.