BCD325P2/BCD996P2: C-Ch Only: Odd behavior

[bcorbin]

Hi folks!

Brand new BCD996P2, programmed-up for the L.A. region. P25, DMR, NXDN, analog systems all working fine. This one has me stumped...

* I run a custom-search through 851-869 with C-Ch Only turned on.
* On most systems, the radio stops on the control channel and I get an SID: line on top that corresponds (correctly) to the site found.
* However - when the radio stops on a CWIRS site ( SID: 0105h-...) the SID line is replaced by "Louisville/Jeff"...

- Hmmm, a) not something I'm ever likely to program into a California scanner, and b) replacing the SID in search mode with an alpha-tag is undocumented behavior (though I could certainly use a feature like that).

Now - first thing I did when I un-boxed the radio was read the 'plug' out and save it (using ProComm), so, thinking this was something like GRE used to do (programming up the VS with regional frequencies so new users could hit the aether running), I checked the 'plug' and - nope, it was pristine, no systems.

It's not going to be a big issue for me - so, mostly just curiosity -

Any ideas?

 

[buddrousa]

Doing a custom scan the scanner will never trunk track you have to setup a trunking system in a favorite and add the sites and talkgroups for it to work.

 

[bcorbin]

Doing a custom scan the scanner will never trunk track you have to setup a trunking system in a favorite and add the sites and talkgroups for it to work.

Actually… if C-Ch Only is set, the radio will trunk-track some systems (eg - P25).

But that’s irrelevant to this issue

 

[GTR8000]

Hi folks!

Brand new BCD996P2, programmed-up for the L.A. region. P25, DMR, NXDN, analog systems all working fine. This one has me stumped...

* I run a custom-search through 851-869 with C-Ch Only turned on.
* On most systems, the radio stops on the control channel and I get an SID: line on top that corresponds (correctly) to the site found.
* However - when the radio stops on a CWIRS site ( SID: 0105h-...) the SID line is replaced by "Louisville/Jeff"...

- Hmmm, a) not something I'm ever likely to program into a California scanner, and b) replacing the SID in search mode with an alpha-tag is undocumented behavior (though I could certainly use a feature like that).

Now - first thing I did when I un-boxed the radio was read the 'plug' out and save it (using ProComm), so, thinking this was something like GRE used to do (programming up the VS with regional frequencies so new users could hit the aether running), I checked the 'plug' and - nope, it was pristine, no systems.

It's not going to be a big issue for me - so, mostly just curiosity -

Any ideas?

The DMA scanners have a lot of old systems permanently programmed into them, not affected by or removable by end-user programming. I guess all of that junk carried forward all the way to the latest DMA models like the 996P2.

This is the old system your scanner thinks is what it has found. Note that old Motorola 3600 systems had a four-character SysID (taking the leading zero into account) vs the three-character for P25, however Uniden apparently never wrote in the code for the scanners to disregard a leading zero for a P25 system, hence the mismatch.

Louisville Metro Government (Analog) Trunking System, Louisville, Kentucky

Louisville Metro Government (Analog) Trunking System Profile

www.radioreference.com

 

[GTR8000]

Doing a custom scan the scanner will never trunk track you have to setup a trunking system in a favorite and add the sites and talkgroups for it to work.

Wrong.

Having C-Ch Only enabled in Custom Searches for the DMA scanners will cause the scanner to tune to traffic channels when the band plan is known. For older 3600 systems you could enter a custom band plan for the custom searches, and for P25 systems the band plan is broadcast over the control channel (extremely rare exceptions when it might not be). Bottom line is that the scanners will absolutely follow P25 traffic while sitting on a control channel in custom search mode if you enable that option.

 

[buddrousa]

Good to know but where was this info publicly posted never heard this before.

 

[bcorbin]

The DMA scanners have a lot of old systems permanently programmed into them, not affected by or removable by end-user programming. I guess all of that junk carried forward all the way to the latest DMA models like the 996P2.

[…]

Ah - ok. I figured must be something along those lines. Thanks

 

[GTR8000]

PS - I bet C-Ch Only Custom Search only works for FDMA P25 voice (Phase I), not TDMA voice (Phase II), as Uniden loves to half-azz everything. There are still a few TDMA features lacking in even the SDS series. No worries, it's all on Joe's now four year old list.

 

[buddrousa]

Like I said I had never heard of this so learning something new.

 

[wtp]

my 396T has it.
FTM: Editing a Custom Search Range
Set C-Ch Only - lets you search for a Motorola control channel. If it finds one, the scanner scans the system.

 

[buddrousa]

I guess these are leftovers from the BC785D's?

 

[bcorbin]

PS - I bet C-Ch Only Custom Search only works for FDMA P25 voice (Phase I), not TDMA voice (Phase II), as Uniden loves to half-azz everything. There are still a few TDMA features lacking in even the SDS series. No worries, it's all on Joe's now four year old list.

Ran a quick experiment a few minutes ago, and - yup - tracking does not work for TDMA in custom search... Color me surprised (not). Good catch.

 

[GTR8000]

Yeah, I tested it out earlier as well and it was acting weird with TDMA grants. Oh well, it's still somewhat handy with FDMA talkgroups.

The other issue of why Uniden decided to hard code 15+ year old systems into the persistent memory of those DMA models is bizarre, though. I can almost understand them doing it with some of the earliest models as a cool feature, but by the time the 996P2 came out, that should've all been cleared out since many of those systems were already gone by that point. Or at the very least, fix the code so that P25 and Type II SysIDs were treated differently (i.e. ignore the leading 0 for P25).

But also kind of amusing to have "discovered" a 25 year old Type II system from Kentucky in SoCal

 

[bcorbin]

Yeah, I tested it out earlier as well and it was acting weird with TDMA grants. Oh well, it's still somewhat handy with FDMA talkgroups.

The other issue of why Uniden decided to hard code 15+ year old systems into the persistent memory of those DMA models is bizarre, though. I can almost understand them doing it with some of the earliest models as a cool feature, but by the time the 996P2 came out, that should've all been cleared out since many of those systems were already gone by that point. Or at the very least, fix the code so that P25 and Type II SysIDs were treated differently (i.e. ignore the leading 0 for P25).

But also kind of amusing to have "discovered" a 25 year old Type II system from Kentucky in SoCal

Having written plenty of code of my own, I get it. If something works, the temptation to build on it incrementally is awfully hard to ignore. At some point the code gets ugly, unwieldy and bloated with kruft - you know you have to get in and clean it up - but the risk of breaking something and setting the project back gives you the perfect rationalization for putting off the code-clean up while you add the next iteration of incremental cruft. Been there, done that, probably own some movie rights.

At some point, the long-postponed clean-up becomes write-new-from-scratch and the rest of us are out cash for the new latest-greatest toy 8*)

Before I posted, I did take a look at trunked systems in Jefferson County - but I limited my search to systems that are currently active. The thought that this might be archeologically-significant kruft in the internal software never crossed my mind (new to Uniden, long-time Regency and GRE user). Thank you again - you made my afternoon 8*)