Idle Submission Status

[Bolt21]

I made several submissions on the 21st, and all were posted within a day or so except for one, which only had half of the submission completed. Submitted the omitted info again on the 24th, and it is still in open status. Please take a look at Ticket# 97769. Thanks.

 

[loumaag]

I looked at this. Please see the current ticket you submitted for status.

 

[Bolt21]

Lou, 343 is a "Multi-Select" Motorola function of the main EMS Dispatch TGID of 336. Please take a look at this link - Easier to Read BCD396T/UBCD396T Manual bits which explains Motorola status bits. Uniden scanners (and possibly newer RS models - not sure, don't have one) will accept and monitor Motorola status bit talkgroups. There are plenty of other status bit TGIDs in the database. Please update the Citrus system. Thank you.

 

[loumaag]

The status bits do not make a new TG. I am quite familiar with how it works. If you could point out these "other" status bit TG's in the DB, I would be glad to remove them. They are not separate TGs.

 

[Bolt21]

OK, don't post my update. But I'm not going to direct you to the "other" status bit non-TGs just so you can delete them. Seems like you're just withholding something that would be useful to the scanning community. EMS calls on the Citrus system are transmitted on the 343 "non-TG." If one was not familiar with Citrus County and used the db to program their scanner (and left their scanner in scan mode as opposed to search mode), they would never hear the call, just "Medic 4 responding" on TGID 336.

Not trying to be hostile, and I hope you don't take it as such - it's just my 2 cent suggestion.

 

[loumaag]

OK, don't post my update. But I'm not going to direct you to the "other" status bit non-TGs just so you can delete them. Seems like you're just withholding something that would be useful to the scanning community. EMS calls on the Citrus system are transmitted on the 343 "non-TG." If one was not familiar with Citrus County and used the db to program their scanner (and left their scanner in scan mode as opposed to search mode), they would never hear the call, just "Medic 4 responding" on TGID 336.

Not trying to be hostile, and I hope you don't take it as such - it's just my 2 cent suggestion.

I don't think you are being hostile, nor do I think you understand how Motorola trunked systems work.

If you are ignoring status bits (the default on all Uniden scanners and the only thing available on the majority of all other brands) and are listening to 336, you hear everything on 336 plus all status bits, which will include everything but encrypted (a separate issue) transmissions. That means 343 will also be heard. If you don't hear it, it is because you have chosen not to ignore status bits (a very specialized setting on Uniden scanners) and then you will only hear what you specifically have set to hear. IOW your argument above is wrong, indeed most scanners in use (including Uniden) will reject loading 343 to a Motorola system as an invalid TG.

The use of status bits on TGs do not add TGs, it simply sub-divides the TG by status, it doesn't change the fact that all of the information is still based on the base TGID.

 

[Bolt21]

All I can tell you is that I can load "343" into my BCD396T all day long and it'll take it, no questions asked.

For my status bit setting, I have the option of "Yes" or "Ignore." I have it set on "Yes" so I can identify which talkgroups utilize the status bit function. I travel through dozens of different counties and find it interesting that some utilize status bits, and some appear to have never heard of it.

 

[Bolt21]

So in other words, you're saying that if I left the setting on "Ignore" I'd hear the Multi-Select function?

 

[GTR8000]

It's easy to see where the confusion comes in for those unfamiliar with or lacking an understanding of exactly what status bits are, and how they affect the display of a decimal talkgroup ID.

For starters, only certain decimal talkgroup ID's are valid as "base" talkgroups with no status bits. Everything in between is a reflection of the status bit for that particular base decimal talkgroup ID, and not an actual talkgroup itself. Each decimal ID is broken down into 16 digit binary, the first 12 digits representing the base talkgroup ID, and the last 4 digits representing the status bits. Thus, for every base ID, there are 15 possible status bits aside from the base 0000, for 16 total.

Let's use base decimal ID 34944 as an example. 34944 expressed as binary is 1000 1000 1000 0000, the last four zeros indicating no status bits. 34944 with an unencrypted emergency status bit now becomes binary 1000 1000 1000 0010, or decimal 34946, the last four digits 0010 this time representing the emergency status bits. To the untrained eye, 34946 appears as a new talkgroup, when in fact it's still 34944, just with a different status bit. An encrypted emergency transmission on 34944 now becomes 1000 1000 1000 1010 in binary, or 34954 in decimal.

34944 (1000 1000 1000 0000) is the base ID with no status bits, i.e. a normal, unencrypted transmission

34945 (1000 1000 1000 0001) indicates talkgroup 34944 with the unencrypted fleetwide status bits enabled

34946 (1000 1000 1000 0010) indicates talkgroup 34944 with the unencrypted emergency status bits enabled

34959 (1000 1000 1000 1111) indicates talkgroup 34944 with the encrypted multi-select status bits enabled, and is the last of the 34944 talkgroup

34960 (1000 1000 1001 0000) starts the next base talkgroup with no status bits, and the process begins over again


As you can see, it's easy to mistake all these decimal ID's as completely new talkgroups if you're not familiar with what is going on behind the scenes, so to speak. If we started listing every base talkgroup ID along with the different status bits possibilities, it would quickly get out of hand. Again, you're looking at 16 possible status bits per base talkgroup which equals 16 possible decimal ID's!

A scanner set to ignore status bits will always display 34944, regardless of the status bits. On the other hand, a scanner set to honor status bits will display 34944 for the base talkgroup, as well as 34945, 34946, and so on for each possible status bit.

Hope this helps explain things better.

 

[GTR8000]

To add to what I've already posted, you can make good use of the status bits if you wish. There is no reason you couldn't enter any of the "additional" decimal talkgroup ID's directly to either lock them out or to assign an alpha tag to them. You'd need to set the scanner to honor status bits for that to be effective, however.

Let's say you wanted to set an alpha tag for the 34944 talkgroup emergency status bits, you would enter 34946 and assign a different alpha tag to it to indicate it was an emergency transmission. Likewise, if you wanted to lock out encrypted transmissions on the 34944 talkgroup, you could lock out ID 34952 to accomplish that.

I can see a problem arising if you track in closed mode, and you have the scanner set to honor status bits. I can't speak for all scanners, but it's quite possible that the scanner would in fact not open up for anything other than the base talkgroup you have entered, and would essentially treat the status bits as a separate talkgroup. I think that's where Bolt's concern comes in. The database assumes the scanner is always ignoring status bits.

 

[qlajlu]

It is useful to know these things as explained by Chauffeur6, because listeners will occasionally "find new" TGs. Once this happens, the first thing to do is to divide the DEC TGID by 16. If it divides evenly, then this well may be a "new" TG. If it cannot be divided evenly, then it is a TG carrying a status bit. Applying a little math and the exact TGID can be identified. This only applies to Motorola systems.

A list of status bits and their meaning can be found here in the RR Wiki.

 

[GTR8000]

With all that crap I posted, I can't believe I forgot to mention the "base talkgroups are divisible by 16" point. Thanks for adding it to the discussion!

 

[Bolt21]

I understand the basic status bit theory/divisible by 16 thing. I guess what I didn't know is that I needed to set my status bit option in my scanner to "Ignore." Looks like the default IS "Ignore" - somewhere along the line I changed it to the "pay attention" mode. Thanks to everyone for the explanations.

 

[WayneH]

Please use the Database forum for content specific to the Database next time. This is not a topic that affects the Wiki, DB, Live Audio and Forums as a whole. So moved.