BCD325P2/BCD996P2: Radio ID's

I have a BCD996P2, a BCD396XT and a BCD996XT. I have recently received al of the radio ID's for my local jurisdiction. I know you can only have up to 500 radio ID's. To that end I have a list of 499 radio ID's I am trying to add a system that has had as many as 300 radio ID's prior to obtaining the entire list.

I receive this error message; "Error Creating New Trunk Channel, No Resources Available. A trunk system can only store 500 id's."

Any ideas? help??

Thanks,
Richard

The limit of 500 considers both talkgroups and radio IDs that you have programmed. If you were trying to program 499 radio IDs, then you would only have room for 1 talkgroup. In guessing you have several talkgroups programmed too. Unfortunately, this is a limitation of the 396 / 996 line of scanners.

That is what I was afraid of........ Why only 500 per system? Especially when it comes to radio ID's, most major departments have a lot of radios....

I'm guessing memory limitations...probably just the way Uniden decided to manage memory - per system vs. per radio. It could also be something to do with radio performance in terms of looking up the alpha tags for each radio ID. But I'm only speculating....

rvyingling said:

That is what I was afraid of........ Why only 500 per system?

Click to expand...

Not sure their rationale for 500 limit. That was always a problem for me. Systems in my area have more than 500 talkgroups and thousands of Radio IDs, so I had to spilt into multiple systems. The 436 / 536 line does not have this 500 talkgroup/ID limitation.

The unit id for these radios did not exist at the time of hardware manufacture. The unit id feature was added via firmware after the 500 limit had been created in the hardware/memory. Without unit id's, 500 was a pretty big size back when these radios came out.

The 325p2 and 996p2 have the same limits because the same hardware/memory structure is used.

The limit is actually 500 objects. This includes frequencies, talkgroups and ID's.

One way around this is to enter the same system multiple times (ie once for police, once for fire, etc. Then only enter the police talkgroups and id's in one system, then the fire talkgroups and id's in the next and so on.

Again, these radios do not have the unlimited situation that SD cards bring. Or the problems for that matter. When they were built the unit id feature did not exist, so the memory didn't either.



Mark
WS1095/536/436/996P2/HP1e/HP2e/996XT/325P2/396XT/PRO668/PSR800/PRO652

My point above is that nobody made a deliberate decision to limit UID's to 500 in these radios. When the radios were built I doubt there was a system in the country so big as to take 500 frequencies and talkgroups. Even today that's a huge statewide monster system.

When they enhanced the firmware to decode unit id's and later add text for them, they were already stuck with the limit.

They continued being stuck with it on the newer phase 2 radios based on the same memory structure (325p2 and 996p2) probably because of cost to make the change and because they wanted them to be lower tier radios to their problem - ridden "flagship" radios which have unlimited memory.

Mark
WS1095/536/436/996P2/HP1e/HP2e/996XT/325P2/396XT/PRO668/PSR800/PRO652

The issue .. is that the non SD card scanners only have so much memory / resources available, and as a result .. you will be limited. Thus the 500 item limit.

The OOP design of the GRE scanners were better in this regard but you still could hit a brick wall.

The SD card based scanners are not limited .. and you are only limited by the size of your card.

It was not a deliberate attempt to restrict anything .. you just have to had been around in the MS-DOS days when memory was a premium. Not much has changed .. there are still memory issues on some devices, you just do not always hit the limit in your devices.

You want more .. you pay more, just look at iPhones for example. You pay a lot for that extra capability.

+1 on what Mark said. At the time, that was as much or more than anyone else had.

More recently models (HP-x, BCDx36HP) support virtually unlimited numbers of TGs and UIDs. Many people forget what advancements were made because they focus on other things.

The solution that Marksmith proposed would work, but comes at a cost.

Creating redundant systems for the same system, one for fire the other for police leads to scanner inefficiency and potential missed comms. The scanner spends 1-2 seconds per site and many transmissions are less than that. Thus while you are listening to the "Fire" system, you could be missing something on the "Police" system that you'd otherwise receive.

The limit puts a guy in a tough decision making situation.

ofd8001 said:

The solution that Marksmith proposed would work, but comes at a cost.

Creating redundant systems for the same system, one for fire the other for police leads to scanner inefficiency and potential missed comms. The scanner spends 1-2 seconds per site and many transmissions are less than that. Thus while you are listening to the "Fire" system, you could be missing something on the "Police" system that you'd otherwise receive.

The limit puts a guy in a tough decision making situation.

Click to expand...

The solution is simple .. buy a newer scanner with an SD card.

ofd8001 said:

The solution that Marksmith proposed would work, but comes at a cost.

Creating redundant systems for the same system, one for fire the other for police leads to scanner inefficiency and potential missed comms. The scanner spends 1-2 seconds per site and many transmissions are less than that. Thus while you are listening to the "Fire" system, you could be missing something on the "Police" system that you'd otherwise receive.

The limit puts a guy in a tough decision making situation.

Click to expand...

I'm not really sure how much less efficient redundant systems really are--- I would certainly give that a try as it seems to be a reasonable compromise to get the results you desire. Whether you are scanning 2000 talkgroups in one "system", or 500 talkgroups in 4 "systems", it's still 2000 talkgroups that have to be scanned.

If you want to mix & match services but still have redundant systems, you could try dividing the systems by geographic area instead of services.

1 or 500 TG scan the same, it's the number of sites that will slow it.

About 2 sec per site.

MStep said:

I'm not really sure how much less efficient redundant systems really are--- I would certainly give that a try as it seems to be a reasonable compromise to get the results you desire. Whether you are scanning 2000 talkgroups in one "system", or 500 talkgroups in 4 "systems", it's still 2000 talkgroups that have to be scanned.

If you want to mix & match services but still have redundant systems, you could try dividing the systems by geographic area instead of services.

Click to expand...

MStep said:

I'm not really sure how much less efficient redundant systems really are--- I would certainly give that a try as it seems to be a reasonable compromise to get the results you desire. Whether you are scanning 2000 talkgroups in one "system", or 500 talkgroups in 4 "systems", it's still 2000 talkgroups that have to be scanned.

If you want to mix & match services but still have redundant systems, you could try dividing the systems by geographic area instead of services.

Click to expand...

Actually, scanners don't really scan 2000 talkgroups, they just look 4 different times at the control channel rather than once (presuming a 4-way split of your single system).

This does, as someone mentioned, cause about 2 seconds for every different system to lock on the control channel and check that subset of talkgroups.

I would argue however, that while you may have missed that transmission on the very busy police talkgroup that is always hogging the system, that you will more frequently hear the fire or other stuff you were normally missing because of certain highly active talkgroups when scanning as just one system.

I have found I hear a better cross section of what is going on on that system when it is split up like this.

Just remember that when scanning a trunked system, you don't scan talkgroups, only the control channel, which then directs the scanner to the first active talkgroup on the system, or the first priority talkgroup active.

I have a very busy system broken out to police, fire, and everything else for ID purposes, and I find I hear a lot more of what is going on, because the busy police channels don't monopolize the listening.

I also have a couple other scanners running with each of these "subsystems", so nothing actually does get missed.

Mark
WS1095/536/436/996P2/HP1e/HP2e/996XT/325P2/396XT/PRO668/PSR800/PRO652

I ran into this with having 536 talk groups in a system, so I set it up with FreeScan to run all police/fire/EMS in one system, and all the other governmental functions that were using it like sanitation, public works, jail, and court house in another system. Then I had FreeScan auto arrange it for 100% efficiency. I don't feel like I've missed out on anything or missed transmissions because I'm not as concerned with general services as I am the main PD/Fire/EMT broadcasts.

My post was indeed inaccurately worded. Nevertheless, I think if you break up the redundant systems into areas instead of services, you might get a more effective "mix" --- for example, if a major event is going on in one area, you might be able to catch all the police, fire, ems, etc, for that activity within the one "system". That might also give you the option of shutting down the other area "systems" to concentrate your monitoring efforts on just the one major event that is occurring.

If I understand correctly - the 100% efficenty does little or nothing on current Uniden.

I believe it sorts freqs. in order - but Uniden - it matters very little.

It also finds dupes - but I may program dupes on purpose.

swatpup102 said:

I ran into this with having 536 talk groups in a system, so I set it up with FreeScan to run all police/fire/EMS in one system, and all the other governmental functions that were using it like sanitation, public works, jail, and court house in another system. Then I had FreeScan auto arrange it for 100% efficiency. I don't feel like I've missed out on anything or missed transmissions because I'm not as concerned with general services as I am the main PD/Fire/EMT broadcasts.

Click to expand...

I apologize if this is wordy, but it is hard to explain.

Let's say you have created two "versions" of the same system, one for police TGs and the other for fire TGs.

While on the police version, the scanner is monitoring the control channel for grants but only for police TGs and ignores any fire grants. The scanner is spending 1-2 seconds doing this. If there is a 1.5 second conversation on a fire talkgroup, you'll miss it.

Conversely if the scanner is monitoring the control channel for the fire version, it may miss that 1.5 second police conversation, because the scanner ignores police TGs.

But at the end of the day, you have to decide which is more important to you. If you want to include all the Radio User IDs, the two version method is the only option. I suppose you could cull the list of Radio User IDs to just below the channel/object limitation.

That's true, but you have to work within the limitations you have.

Similarly, if I were using a BC210 to scan an analog trunked system (assuming it's in the coverage of the scanner), I would be able to scan only in conventional mode, and would not be guaranteed to hear complete conversations should the same channel be assigned to another user between transmissions.

Simply put, if you want to scan a trunked system, use a trunking scanner. If you want to scan more than 500 TGs/IDs quickly, use a scanner that supports more than 500 TGs/IDs per system. They do exist now.

I haven't seen the question lately, but in the past, every now and then, someone would ask "What possible reason would anyone have for owning more than (one/two/three/etc,) $500 scanners. Well, this thread sorta answers the question.