Trunk88 not decoding correct system freqs

[kma371]

I'm using Trunk 88 on the following system:
Sacramento Regional Radio Communications System (Public Safety) Trunking System, Various, California - Scanner Frequencies
with a 996xt.

It decodes the control channel just fine, but it's spitting out frequencies that don't belong on the system, like 854.5125, 855.3875 etc.

Could this be solved by changing the "base/offset/step" in the c116.ctl file? Please let me know.

Thanks.

 

[slicerwizard]

I assume you're seeing the correct system frequencies along with some bogus entries. I also assume that you're using the 996XT's control channel dump feature.

The bogus data that TRUNK88 is reporting is coming straight from your scanner's broken OSW decoding logic. All of Uniden's DMA scanners, from the 246T to the 996XT, share this flaw. The defect has remained largely hidden, since a bogus decode generally tunes the scanner to a dead channel (no RF present), so the scanner immediately returns to the control channel and users are none the wiser.

With the CC dump feature, the flaw is readily exposed. Here's a Uniden CC dump recorded from a system while it was idling (no active voice calls); the OSW stream consists of various status messages - messages that do not randomly change. Yet there's just one of hundreds of bad decodes that the scanner spit out during the decoding session - a 600C network status OSW got turned into a 611C. Status messages don't change and then change back in a fraction of a second, so the misdecode is irrefutable.

3BF G 30E8  NS1
3C0 G 4AC0  SS2
3C0 G 30E8  SS1
3BF G 600C  NS3  legit
3BF I 42C0  NS2
3BF G 30E8  NS1
3C0 G 4AC0  SS2
3C0 G 30E8  SS1
3BF G 61CC  NS3  bogus
3BF I 42C0  NS2
3BF G 30E8  NS1
3C0 G 4AC0  SS2
3C0 G 30E8  SS1
3BF G 600C  NS3  legit
3BF I 42C0  NS2
3BF G 30E8  NS1
3C0 G 4AC0  SS2
3C0 G 30E8  SS1
3BF G 600C  NS3

Other bad decodes look like call grants on random channels, which is why you're seeing extra RF channels. I assume that TRUNK88 has logged all of the legitimate channels, so I would suggest that you lock the channel list (System Menu / Edit Settings / Misc / Lock Channel List) and delete the bogus channels (System Menu / Edit Channels / scroll to bogus records / PageDown to delete)

The forward error detection and correction used in Motorola's over the air protocol is strong enough to limit the number of undetectable misdecodes to a manageable level, but none of the Uniden DMA scanners properly implement this error detection and correction scheme, which leads to a metric crapton of bad decodes being passed on to software decoders like TRUNK88, Unitrunker, etc.

IIRC, the 246T came out way back in late 2004 - that's about six years with no fixes for this bug and nothing but silence from Paul Opitz whenever this issue is raised. If one had to move mountains to solve this problem I could understand the stonewalling, but the fix is dirt simple. Go figure.

 

[kma371]

Well, if it makes any difference..I was decoding system 3938 and had the same problem. Changed the base/offset/step and it worked just fine.

So I thought this might have been the problem

 

[SCPD]

The bogus data that TRUNK88 is reporting is coming straight from your scanner's broken OSW decoding logic

Andy - I share your frustration. I strongly wish that Uniden and GRE had both opted for providing the raw bit stream instead of trying to imitate a Motorola RIM box (that's so 1992; I stopped playing with 'em in 1994).

leads to a metric crapton of bad decodes being passed

I've added that to my spell checker.