Ocean County Trunked System

[Highpockets]

I usually just scan id's I have in for the oc tsr, today I searched for new id's. Come across 35336 that is apco25 encrypted, and is busy, any ideas?

 

[DJ88]

I'm just guessing here, but I'm thinking it tmay be either the Prosecutors or Sheriffs. Another new one, 35328, P25 encrypted. also, gets acitve at times. I could never firgure out why they didn't have enctyption capabilities in the past, if in fact it is them using it now, especially the Prosecutors Task Force, for when they're out chasing down the druggies.

 

[Highpockets]

I'm just guessing here, but I'm thinking it tmay be either the Prosecutors or Sheriffs. Another new one, 35328, P25 encrypted. also, gets acitve at times. I could never firgure out why they didn't have enctyption capabilities in the past, if in fact it is them using it now, especially the Prosecutors Task Force, for when they're out chasing down the druggies.

First one I have heard, being encrypted I guess we'll never know. Thanks for your reply! I guess I'll have to search more often.

 

[robbinsj2]

35328 and 35336 are the same talkgroup -- 35336 is 35328 with the +8 status bit, indicating DES encryption on 35328.

I'm too far to help you out, but perhaps someone with Trunker or Unitrunker could look at the radios affiliating with 35336 and determine what agency/department is using it.

Jim

 

[crazyboy]

Prosecutors

 

[DJ88]

In order to receive TG 35336, am I to assume that, on my scanner, the Status Bit has to be ON?

 

[robbinsj2]

In order to receive TG 35336, am I to assume that, on my scanner, the Status Bit has to be ON?

To get technical, no. There is no such talkgroup as 35336 so there is nothing to receive.

If Status Bit is turned on then Uniden scanners will display encrypted digital comms on 35328 as 35336.

With one exception, if Status Bit is turned off then everything which comes over the talkgroup will come through scanners with an ID of 35328. That exception is if the scanner firmware automatically ignores encrypted calls, or all digital digital calls in the case of an analog trunktracker, or has a similar preset rule about other call types. If this is the case it may also apply to 35336 when Status Bit is on. I don't know what scanner you have, plus I have no experience with Uniden digital trunktrackers, so I can't be any more specific.

Let's look at some other examples. If you turn Status Bit on then suddenly 35328 calls would be as follows:
35328 = ordinary analog calls only
35329 = all talkgroup call
35330 = analog emergency call
35331 = patched call
35332 = patched emergency call
etc...

The Wiki page I linked to above may explain it more clearly.

Jim

 

[DJ88]

Okay Jim, thanks. I checked out the manuals for both the 785 and 396. The 785D defaults to status bit ON and everything would be heard on 33528. No mention of how it works with the status bit off. On the 396, with the status bit ON, it treats each TG as unique, and I would actually see TG 35336. With it OFF, it rounds off all TG down to the next interval of 16. Not that all of this even matters here, because the TGs are encrypted and we can't monitor them anyway, but at least I'm learning about status bits and these unique TGs. Well, half learning. I still can't figure out why the unique TGs are used, when there are standard TGs already available in a trunk system, or how they come to be, ie: manually programmed into the system, programed or selected automatically by the computer, etc., but that's a subject for another thread. Thanks again for your help.

 

[Highpockets]

Okay Jim, thanks. I checked out the manuals for both the 785 and 396. The 785D defaults to status bit ON and everything would be heard on 33528. No mention of how it works with the status bit off. On the 396, with the status bit ON, it treats each TG as unique, and I would actually see TG 35336. With it OFF, it rounds off all TG down to the next interval of 16. Not that all of this even matters here, because the TGs are encrypted and we can't monitor them anyway, but at least I'm learning about status bits and these unique TGs. Well, half learning. I still can't figure out why the unique TGs are used, when there are standard TGs already available in a trunk system, or how they come to be, ie: manually programmed into the system, programed or selected automatically by the computer, etc., but that's a subject for another thread. Thanks again for your help.

I have a bc785d and just checked, my Status bit was set to off, I guess that's why I heard 35336. I changed the setting to on. I also learned something, like you said even though we can't monitor it. Thanks for your input on the subject!

 

[robbinsj2]

... but that's a subject for another thread.

The OP seems to be on-board so I'll extend the lesson a bit. The following will pertain only to Motorola Type 2 systems, not necessarily any other kind of trunked system. I'm also going to simplify a lot to make it easier to understand.

The data coming over the control channel is a constant binary stream -- a continuous flow of 1s and 0s, no spaces unless reception is marginal. There are predefined segments in that stream (think of them as punctuation marks) which let the radios synchronize and know where the start of a new data sentence is.

Continuing this example in binary would be confusing and less condensed, so I'm going to use hexadecimal except where noted otherwise. Hexadecimal is good because each of its digits, with 16 potential values (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F) for each digit neatly and exactly aligns with four binary digits. Decimal won't do this.

A few of the pieces of data which are transmitted over the control channel would be the channel number, talkgroup ID, call type, and radio ID for a currently-active channel. Smash them all together and insert the punctuation and it would look more like this: ...upcalltyperadio.channeltalkgroupcalltyperadio.channeltalkgro... (for some reason the board keeps inserting a space in there, it shouldn't be)

Now let's look more closely at that word, the segment which defines the four pieces of data we're interested in. We'll boil it down so that C represents the channel, G is the TGID, T is the call type, and R is the radio ID. Below each letter is a hypothetical value.

.CCGGGTRRRR.
.018A004567.

The Motorola radio would be hard-programmed to know, for example, that the first two digits are the channel, the next three are the TGID, the one after that is the call type, and the last four are the radio ID. So it breaks that into Channel 01, Group 8A0, Call Type 0, Radio 4567.

Scanners look at it a bit differently because, for whatever reason, they break it down into a two-digit channel number followed by a five-digit TGID, and the last four are ignored by most scanners for group calls. So it reads Channel 01, Talkgroup 8A00.

Let's change from call type 0 to type 8. Here is the result:

          Control Ch     Motorolas see     Scanners see
         .CCGGGTRRRR.    CC GGG T RRRR     CC GGGG RRRR
(before) .018A004567.    01 8A0 0 4567     01 8A00 4567
(after)  .018A084567.    01 8A0 8 4567     01 8A08 4567

Now it's time to convert these hexadecimal numbers into decimal, which we're more used to seeing.

Motorola talkgroup (8A0) = 2208, Call Type 0 = Analog, Call Type 8 = DES Encryption
Scanner "before" talkgroup (8A00) = 35328 (analog)
Scanner "before" talkgroup (8A08) = 35336 (DES encryption)

Some asides:
- The Windows Calculator is useful for converting decimal to hexadecimal -- go to Scientific view, type the decimal value in and click on the hexadecimal radio button.
- Consult the database and note that TGID hex (Motorola) values do not convert directly to the decimal (scanner) values. Add a zero on the end of the hex number, for the standard call type, and they do correspond.
- As per the wiki, Type 2 supports 4095 talkgroups (that's 3 hex digits), 16 call types (1 hex digit), and 65534 radio IDs (4 hex digits).
- As per the wiki, Type 2 supports 28 system channels. If it is like EDACS then "channels" 29-32 are system messages like DENIED or QUEUED. That would fill out 2 hex digits. This is pure, poorly-educated speculation on my part.

I've spent much more time studying EDACS (at the hobbiest level) but all the concepts are the same and much of the implementation is rather similar.

Hopefully this has helped and not hurt your understanding of trunking. For me, anyway, puzzles like that above interest me as much as finding the frequency of a "private channel" I wasn't sure existed.

Jim

 

[DJ88]

Thanks. I will read over it a bit and attempt to understand. Your time and effort are appreciated.