hotspot_dmr_decode_trouble
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
hotspot_dmr_decode_trouble [2022/03/06 15:28] – created alexswl | hotspot_dmr_decode_trouble [2022/03/06 16:34] – alexswl | ||
---|---|---|---|
Line 3: | Line 3: | ||
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, | 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, | ||
- | When in normal YSF mode, the data the hotspot is transmitting can be decoded | + | When in normal YSF mode, the data the hotspot is transmitting can be decoded |
When in DMR2YSF mode, I am having trouble getting clean decodes. Here are the pieces of software I have tried: | When in DMR2YSF mode, I am having trouble getting clean decodes. Here are the pieces of software I have tried: | ||
Line 22: | Line 22: | ||
====== SDRangel DSD Demodulator ====== | ====== SDRangel DSD Demodulator ====== | ||
+ | SDRangel' | ||
+ | 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), | ||
+ | |||
+ | 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' | ||
+ | |||
+ | ====== Test Tone ====== | ||
+ | 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 t 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): | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ====== Any ideas? ====== | ||
+ | I am quite stumped by this one. < | ||
+ | |||
+ | Here is a baseband recording I took: https:// | ||
+ | |||
+ | 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' |
hotspot_dmr_decode_trouble.txt · Last modified: 2022/03/06 16:36 by alexswl