hotspot_dmr_decode_trouble
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
hotspot_dmr_decode_trouble [2022/03/06 15:28] – created alexswl | hotspot_dmr_decode_trouble [2022/03/06 16:36] (current) – 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 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): | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | ====== 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.1646580502.txt.gz · Last modified: 2022/03/06 15:28 by alexswl