SDS100/SDS200: SDS100 debug logs

[hruskacha]

You can enable debug logs on the SDS100 by holding "Avoid" and the "Power" button when powering up and selecting it in the settings menu. I did so and it generated a log that I cant quite understand. I have experience with logs from SDRTrunk, DSDPlus, and Unitrunker but none of them look like the logs from the SDS100.

Heres a trimming from a log file, is there any info on how to decipher this? It was used on Muskegon County Simulcast of MPSCS

As of now, Im just curious about the logs and what they show, but I hope I can try this on conventional channels to see if I can calculate the scan speed...

0022578 LL,08535250
0022761 PLL,08537750
0022819 PLL,08539875
0022827 SP1    DA1: 0253    FIR2: 16F7
0022843 SC1    DA1: 01EF    FIR2: 16F7
0023118 3300233840640A251584484B  IU TDMA0000 0002 0003 0E10 0064 0A251584
0023118 output_control_ch()
0023118 OK : output_trunk_freq(channel_lch = 65535) = 08539875
0023118 PLL,08539875
0023131 330033A580640915756275FC  IU TDMA0000 0003 0003 2960 0064 09157562
0023131 B9000332020D0401BB04B7CD  SCCB   0000 0003 0032 020D 0004 01BB 0004
0023236 00900BFE0BFD0BFD0BFD58D6  MOT PAT0090 0BFE 0BFD 0BFD 0BFD
0023255 0B9000000000000001DDC1D6  Unknown(0B)
0023272 85904080C000000008005F47  UTUAR  0090 0040 0080 00C00000 00000800
0023311 3C00003796032F01677060FE  ASB    0000 0000 0003 0796 0003 002F 0167 0070
0023330 160000C002B1FFFF0001F50D  SDCAE  (16)
0023346 89900F000000000000000B4B  Unknown(09)
0023414 evnt_idscan_sigrec(C)
0023414 3D000322D0320A2510A263A0  IU 800 0000 0000 0064 00B4 0032 0A2510A2
0023416 3D001325E032091575621B36  IU 800 0000 0001 0064 0178 0032 09157562
0023421 B9000332020D0401BB04B7CD  SCCB   0000 0003 0032 020D 0004 01BB 0004
0023460 300000042A302D9F097E5347  HAR PAT0000 0000 042A 00302D9F 097E
0023487 3A00003796033201DD70C0A6  RSB    0000 0000 0003 0796 0003 0032 01DD 0070
0023503 BB00009249379601DD7033A7  NSB    0000 0000 00092493 0796 01DD 0070
0023535 00900BFE0BFD0BFD0BFD58D6  MOT PAT0090 0BFE 0BFD 0BFD 0BFD
0023535 evnt_idscan_id_decode()
0023535 id_dec(P1)
0023535 id_dec(E1)
0023556 05904080C00000000800BB73  UTUAR  0090 0040 0080 00C00000 00000800
0023571 BC00003796031D012B700DEA  ASB    0000 0000 0003 0796 0003 001D 012B 0070
0023610 160000C002B1FFFF0001F50D  SDCAE  (16)
0023634 000004058D2C6986EFFBED6E  GVCG   0000 0004 058D 2C69 0086EFFB
0023634 evnt_idscan_id_decode()
0023634 id_dec(P1)
0023634 id_dec(P2)
0023634 dualcom_id_decode_sub()
0023647 89900F000000000000000B4B  Unknown(09)
0023706 3300233840640A251584484B  IU TDMA0000 0002 0003 0E10 0064 0A251584
0023712 000004058D2C6986EFFBED6E  GVCG   0000 0004 058D 2C69 0086EFFB
0023712 evnt_idscan_id_decode()
0023712 id_dec(P1)
0023712 id_dec(P2)
0023712 dualcom_id_decode_sub()
0023721 B30033A580640915756291C8  IU TDMA0000 0003 0003 2960 0064 09157562
0023761 39000332020D0401BB0453F9  SCCB   0000 0003 0032 020D 0004 01BB 0004
0023792 0200058D2C69058D2C69DC39  GVCGU  0000 058D 2C69 058D 2C69
0023792 evnt_idscan_id_decode()
0023792 id_dec(P1)
0023793 id_dec(P2)
0023793 dualcom_id_decode_sub()

 

[buddrousa]

It has a meaning to the Uniden Engineers when you are having problems

 

[jtwalker]

And it looks more like a memory dump to me than it does any kind of log file.

 

[hruskacha]

This log also makes MUCH more sense when scanning conventional frequencies. Just timestamps and frequencies.

 

[hexagon_keyhole]

This log also makes MUCH more sense when scanning conventional frequencies. Just timestamps and frequencies.

Interesting! You following the SDS 100/200 Motorola Type II public beta thread?

I just wrote (Post #27) about something they had on their change log for Beta Main v1.23.03A [and Sub v1.03.04] that when you hold down Avoid and Power On the scanner, it shows the demodulation being used where the clock would be. This now makes sense for the dump/debug log that can be potentially used by Uniden to help develop a fix.

 

[Ubbe]

I hope I can try this on conventional channels to see if I can calculate the scan speed...

Yes, please do that. It used to be a 1ms counter that where used and later Uniden changed that to be 2ms and at the same time introduced the bug that lowered the scan rate to half at 45ch/s and has been like that for a couple of years.

PLL means that the logic sends a new frequency to the receiver. going from 853.5250 to 854.7750 takes 183 increments and to 853.9875 takes 58 increments. A 45ch/s rate would be either 22 or 44 increments if its using 2ms or 1ms increments. So having 183 or 58 increments show some kind of scan issue, maybe using auto for the filter will do that.

SP1 DA1 showing 0253 are the squelch opening and FIR are what it decodes of the audio.
If SC1 DA1 are 01EF it indicates some sort of valid data detected.
FIR2 of 16F7 seems to be P25 and 13D8 to be DMR.

It says TDMA0000 that probably means it is not TDMA so is the control channels single slot that are decoded.
It says "OK output control channel" so it decodes that the control channel are 853.9875 and sends that to the receiver PLL,08539875 although it's already tuned to that CC.

Those MOT PAT0090 and HAR PAT000 are probably looking for any TG patches that are active, in a P25 Motorola system or in a Harris system. If TG1 and TG2 are patched they will go silent and the scanner needs to instead listen to the patch, that can be something like a TG 65000, instead of a programmed TG1 or TG2 in the scanner.

That GVCG 0000 are probably Grants for Voice Call Groups, the info if any talk groups starts to be active but with 0000 there are probably none. The values that are non zero might be already ongoing active calls in the system.

evnt_idscan indicates it has found a call at the site and id_dec that it probably decrements a pointer that looks thru the TG and UID tables to find a match.

/Ubbe

 

[hruskacha]

Yes, please do that. It used to be a 1ms counter that where used and later Uniden changed that to be 2ms and at the same time introduced the bug that lowered the scan rate to half at 45ch/s and has been like that for a couple of years.

PLL means that the logic sends a new frequency to the receiver. going from 853.5250 to 854.7750 takes 183 increments and to 853.9875 takes 58 increments. A 45ch/s rate would be either 22 or 44 increments if its using 2ms or 1ms increments. So having 183 or 58 increments show some kind of scan issue, maybe using auto for the filter will do that.

SP1 DA1 showing 0253 are the squelch opening and FIR are what it decodes of the audio.
If SC1 DA1 are 01EF it indicates some sort of valid data detected.
FIR2 of 16F7 seems to be P25 and 13D8 to be DMR.

It says TDMA0000 that probably means it is not TDMA so is the control channels single slot that are decoded.
It says "OK output control channel" so it decodes that the control channel are 853.9875 and sends that to the receiver PLL,08539875 although it's already tuned to that CC.

Those MOT PAT0090 and HAR PAT000 are probably looking for any TG patches that are active, in a P25 Motorola system or in a Harris system. If TG1 and TG2 are patched they will go silent and the scanner needs to instead listen to the patch, that can be something like a TG 65000, instead of a programmed TG1 or TG2 in the scanner.

That GVCG 0000 are probably Grants for Voice Call Groups, the info if any talk groups starts to be active but with 0000 there are probably none. The values that are non zero might be already ongoing active calls in the system.

evnt_idscan indicates it has found a call at the site and id_dec that it probably decrements a pointer that looks thru the TG and UID tables to find a match.

/Ubbe

Outstanding answer. Thank you so much!