BCD436HP/BCD536HP: EDACS Unexpected Behavior

[bearcat]

I was monitoring the Manatee Co FL EDACS system. The RRDB contains one Department for all Sheriff TGs. Since this system covers such a large area. I decided to add three new Departments which would contain just the TGs for the North, West and East. This way I can just listen to the Zone that I am actually in. Well much to my surprise I heard nothing on any of these new Departments even if I put them on HOLD.
The original Department still work fine. If I turn off the original Department the three new Departments start working.

It appears that there is an issue with having duplicate TGIDs in the same system turned on at the same time.

All appropriate FLs, QKs, and SQKs were turned on. ID Search/Scan made no difference. So that is not the issue.

Is this a known/expected behavior?

Have others seen this on EDACS systems?

 

[jonwienke]

It's a stupid way to program the system. Don't.

Program sites to match the actual physical location of the towers.

Program departments to match the organization of the system. Have a statewide department for statewide talkgroups, countywide department for county-level talkgroups, and regional departments for regional talkgroups.

Put talkgroups under the appropriate department. Do not enter duplicate talkgroups with the same ID.

 

[bearcat]

That really did not answer my question. I have no idea why that is stupid? Programming specific groups of users in Departments is the power that dynamic programming gives the user. Duplicating TGs can have benefits. What if you wanted to create a Department with just specific TGs that may all become active in a major incident? I can think of many reasons to duplicate TGs with in a system.

 

[jonwienke]

That really did not answer my question. I have no idea why that is stupid? Programming specific groups of users in Departments is the power that dynamic programming gives the user. Duplicating TGs can have benefits. What if you wanted to create a Department with just specific TGs that may all become active in a major incident? I can think of many reasons to duplicate TGs with in a system.

Re-read my post.

There are no benefits to having duplicate TGID definitions in a system. Logically, it shouldn't even be allowed.

If your Department structure is correct, there is no need to duplicate talkgroups. Talkgroups should be placed under the Department where they belong, period, no exceptions. If you want to toggle arbitrary talkgroups on and off together, you can tag those talkgroups with a custom Service Type. That will also allow you to group a mix of analog conventional channels and talkgroups from multiple trunked systems. For example, you could set up service type Custom 9 as hazmat response, and tag all federal, state and local hazmat response conventional frequencies and digital talkgroups with the service type Custom 9. If there is a hazmat incident, turn off all service types other than Custom 9, and you'll be listening only to channels responding to the incident, even if they are from multiple mixed conventional and trunked systems. You'll accurately see who is talking and their correct departmental affiliation for all traffic, which would not be possible the way you're trying to kludge things.

 

[bearcat]

Re-read my post.

There are no benefits to having duplicate TGID definitions in a system. Logically, it shouldn't even be allowed.

If your Department structure is correct, there is no need to duplicate talkgroups. Talkgroups should be placed under the Department where they belong, period, no exceptions. If you want to toggle arbitrary talkgroups on and off together, you can tag those talkgroups with a custom Service Type. That will also allow you to group a mix of analog conventional channels and talkgroups from multiple trunked systems. For example, you could set up service type Custom 9 as hazmat response, and tag all federal, state and local hazmat response conventional frequencies and digital talkgroups with the service type Custom 9. If there is a hazmat incident, turn off all service types other than Custom 9, and you'll be listening only to channels responding to the incident, even if they are from multiple mixed conventional and trunked systems. You'll accurately see who is talking and their correct departmental affiliation for all traffic, which would not be possible the way you're trying to kludge things.

None of this explains why the radio is not seeing the department with the duplicate TG. I works correctly on the DMR system I tried the same setup. We can agree to disagree. There are reasons for duplicate groups. It is not as quick to turn off all Service Types then turn back ON the one or two you want. Much easier to just HOLD on preprogrammed Department.

Logically, it shouldn't even be allowed........

Some commercial trunked radios contain duplicate TGs in various zones/banks. It is not uncommon.

 

[jonwienke]

It is not as quick to turn off all Service Types then turn back ON the one or two you want. Much easier to just HOLD on preprogrammed Department.

That's not true if the copy of the talkgroup under the "wrong" department (not the composite/catchall/special purpose one) is being scanned when you get traffic. You either have to wait until the copy of the talkgroup under the "right" department gets traffic, or hold and manually scroll through the system to select the catchall department. And your way doesn't allow talkgroups or frequencies from multiple systems to be grouped.

Logically, it shouldn't even be allowed........

Some commercial trunked radios contain duplicate TGs in various zones/banks. It is not uncommon.

Creating multiple definitions for a unique entity in a single context is always stupid. If you have multiple banks or zones that cannot be active simultaneously, then having an instance of the unique entity in more than one bank/zone does not violate this principle. You're comparing apples and oranges.

 

[bearcat]

That's not true if the copy of the talkgroup under the "wrong" department (not the composite/catchall/special purpose one) is being scanned when you get traffic. You either have to wait until the copy of the talkgroup under the "right" department gets traffic, or hold and manually scroll through the system to select the catchall department. And your way doesn't allow talkgroups or frequencies from multiple systems to be grouped.



Creating multiple definitions for a unique entity in a single context is always stupid. If you have multiple banks or zones that cannot be active simultaneously, then having an instance of the unique entity in more than one bank/zone does not violate this principle. You're comparing apples and oranges.

I agree it does not do what Service Types can do, but for ME it has a purpose. An example of my way would be during my stay in Manatee I went to the beach. They have 3 Lifeguard TGs and I wanted the North Sheriff TG also. It was very easy to listen to those 4 TGs by putting them in a Department and holding on that Department. Not so easy to do that with Service Types.

Once again the issue here is not your method or mine. It is why the 436 id ignoring a duplicate TG. It should not. I have tested it with DMR Con+ and P25 trunking and they do not ignore a duplicate.

That is the question

 

[UPMan]

The scanner assumes the TGID status of the first instance it finds in memory. If that one is locked out or in a disabled department, it looks no further. The state is actually ambiguous, as you've told the scanner you both want to hear the TG and you don't want to hear the TG...

Make a new instance of the system with the department divided and scan that one when you want to differentiate.

 

[jonwienke]

The state is actually ambiguous, as you've told the scanner you both want to hear the TG and you don't want to hear the TG...

Another example of why it's stupid to have multiple instances of a unique entity in a single context.

Alternative to Upman's suggestion, put the "alternate" version of the system in a separate Favorite List. That way you can quickly toggle the FL on and off, but still toggle multiple digital and analog systems together.

 

[bearcat]

The scanner assumes the TGID status of the first instance it finds in memory. If that one is locked out or in a disabled department, it looks no further. The state is actually ambiguous, as you've told the scanner you both want to hear the TG and you don't want to hear the TG...

Make a new instance of the system with the department divided and scan that one when you want to differentiate.

I knew that turning one off, one on would cause problems. Neither of the duplicates TGs or Departments were turned OFF/Avoided. They were just in different departments. This only appears to be an issue with EDACS. I just wanted to be able to HOLD on a Department with a specific group of TGs in it. As long as I was not holding on the Department with the duplicate TG everything worked fine. It does not seem to be an issue on P25 or DMR Con+ systems.

I am not implying it needs fixed. I am just pointing it out.

 

[bearcat]

The scanner assumes the TGID status of the first instance it finds in memory. If that one is locked out or in a disabled department, it looks no further. The state is actually ambiguous, as you've told the scanner you both want to hear the TG and you don't want to hear the TG...

Make a new instance of the system with the department divided and scan that one when you want to differentiate.

Let me re-phrase it.

If I had this with nothing avoided and all QKs turned on
Department1
TG 0-001
TG 0-002

and

Department2
TG 0-001
TG 0-003

If I held on either Department would you expect to hear traffic on those TGs even though one is a duplicate?

Thanks

 

[k3fs]

I had inadvertently done the same thing with a DMR system. I keep a department of unknown TG. At one point I had failed to delete a TG from the unknown department when updating my programming, and placing that TG into a known department.

I had locked out (disabled) the known department with the TG in it. My intent was to scan only unknowns. I was scanning and recording only the unknown department. I was getting many hits on the TG I had updated. That's how I noticed I missed something in my programming.

Granted this was not an EDACS system. But, it does show that in another trunking mode, it works like you had expected it to work. This may be an issue with EDACs. I do not have any local EDACs systems I could test this out on.

So in summary,

Dept 1
TG 1
TG 2
TG 3

Dept 2
TG 1
TG 4
TG 5

I locked out (disabled) Dept 1. I was receiving Dept 2, TG 1.
I have both departments enabled. I receive Dept 1 TG 1, and Dept 2, TG 1. Just depends on the luck of the draw which department will receive it.

If there is one thing I have noticed is that no two scanners are programmed a like. Kind of like snow flakes. Every one has their own interests, habits, idiosyncrasies, and whatever else. I can see instances where this could be handy. Far easier to turn departments off and on, to narrow things down in big systems. I can see cases where one TG could find it's way into more than one department as well, now that I think about it.