Type II with status bits or Type I system?

[trunker]

Been trying to figure out a Motorola SMR (851-866 MHz) system. Found a control channel, programmed it as a type II system with status bits turned on with CC-only in my BR330T, and did a search and store. Got a big list of 200 IDs.

Most are odd numbered (or even and not divisible by 16) and a few are true type II ids-per block. One block (5) is all true type II ids. One block (1) is not even used.

How do I know if the mixed blocks are type I or type II using status bits? I've read that you can't have both (type I and type II ids) in the same block. Would that confirm it's a type II block with status bits?

I've found 3 other systems the same way and the ids show up just like this system. Are status bits that common with these types of systems?

I'm going to try to figure out the fleetmap if the system is indeed a type I or type II hybrid.

 

[jaythescanman]

Try using Uni-Trunker if you have the ability...Meaning you have a discriminator tap in your scanner, this program can tell you many things about the system your listening too...Have a look in the other forums for info regarding this program

 

[fmon]

Try this Status bit Calculator. They could all be type II.

I don't know who the author of this program is.

 

[SCPD]

Try using Uni-Trunker if you have the ability...Meaning you have a discriminator tap in your scanner, this program can tell you many things about the system your listening too...Have a look in the other forums for info regarding this program

The program can confirm Type II banks. However, finding the exact sizecode for a particular bank is very difficult. There are a few tricks that involve looking, logging and lots of listening.

Trick #1: look for two Type I radio ids inside the same bank that are numerically close to each other. If they appear on different channels at the same time - you can eliminate some size codes. You also need to understand some binary math.

Trick #2: listen for replies that seem to be the same conversation. If you're certain that one radio was replying to another - they must both be inside the same group. Again, this helps eliminate some sizecodes.

Trick #3: variation of #2 - uses logging instead of listening. This works on systems that use transmission trunking but won't work on systems that use message trunking. Look through the logs for consecutive group call radio ids on the same channel. If the ID changes abruptly - it is probably someone's reply. From that you infer both parties are in the same group. This doesn't always work ... you may need several "hits" to confirm a relationship.

Eventually ... you can narrow your choices down to three or four size codes.

 

[trunker]

...finding the exact sizecode for a particular bank is very difficult. There are a few tricks that involve looking, logging and lots of listening.

Understood. I'm using "Determining Motorola Type I Fleetmaps" (http://wiki.radioreference.com/index.php/Determining_Motorola_Type_I_Fleetmaps).

Trick #1: look for two Type I radio ids inside the same bank that are numerically close to each other. If they appear on different channels at the same time - you can eliminate some size codes...

Yes, (400-406), they do appear on different (random) frequencies. How would I eliminate size codes this way?

Trick #2: listen for replies that seem to be the same conversation. If you're certain that one radio was replying to another - they must both be inside the same group. Again, this helps eliminate some sizecodes.

Understood.

Trick #3: variation of #2 - uses logging instead of listening. This works on systems that use transmission trunking but won't work on systems that use message trunking...

What's the difference between the transmission trunking and message trunking?

...Look through the logs for consecutive group call radio ids on the same channel...

Do you mean same frequency?

...If the ID changes abruptly - it is probably someone's reply...

I thought replies would have to be in the same talkgroup (block).?

 

[DaveNF2G]

In transmission trunking, the talkgroup being used is sent to a new frequency after every transmission.

In message trunking, the talkgroup stays on its original frequency until the conversation is over.

To answer some things that rfmobile's excellent post didnt exactly cover - it is possible to have both Type I and Type II radio IDs in the same block. If you find this condition, it means that you are monitoring a Type IIi system, which does require a fleetmap.

You didn't mention what scanner you're using. Both Type I and Type II systems use status bits, but the datastream from the control channel is different and some scanners or software can be misled by the Type I info.

Good luck in your quest. Hunting talkgroups is as much fun as hunting frequencies, IMO.

 

[Jay911]

I found a spreadsheet which calculates the type 1 talkgroup IDs for any given type 2 talkgroup value. If you collect a bunch of type 2 "talkgroups", plug 'em in and you should be able to see if they have a common thread. I believe I got it off the trunker yahoogroup, but I reposted it to the thread http://www.radioreference.com/forums/showthread.php?p=371824#post371824 in the Western Canadian forum.

The spreadsheet is already giving me some good ideas about my local systems. What I do is combine the captured type 2 IDs from Unitrunker with the recordings I make from Scannerbase AVC396 (which saves scanner audio coupled with the system name, type 2 TG (since I have the bank set to type 2 and report status bit), etc. So I can tell that 20546, 20547, 20549, 20553 ... etc are all part and parcel of the same system, both from listening to voices and other cues (similar sounding radios, etc) and observing a semi-contiguous "block" of type 2 IDs, such as the example above.

 

[trunker]

You didn't mention what scanner you're using. Both Type I and Type II systems use status bits, but the datastream from the control channel is different and some scanners or software can be misled by the Type I info.

I'm using a BR330T. The (same) conversation is usually 1,2,5 ids apart (401,402,405) and just stuff like dispatching chatter so it doesn't appear to be status bits.

Also, seems to be transmission trunking but hard to tell. If the scanner leaves the frequency before a reply (delay set to off) I will get a different freq and (sometimes different but close) ID for the reply.

If I get a reply before the scanner leaves the frequency the ID stays the same (maybe that's all the scanner can do with that situation).

 

[SCPD]

In transmission trunking, the talkgroup being used is sent to a new frequency after every transmission.

In message trunking, the talkgroup stays on its original frequency until the conversation is over.

Oh crud. I think what you're saying means that my Trick #3 above won't work at all. The idea is that a fast reply would happen on the same channel - which allows you to infer that the two IDs are related - without actually listening. The control channel needs to announce the ID of the radio that is replying to an on-going conversation. My understanding is that message trunking only tells you the radio ID of the person initiating the conversation. If transmisison trunking grants a different channel then this trick doesn't work at all.

 

[DaveNF2G]

Yeah, message trunking is also known (mainly in EDACS Land) as "aggressive trunking."

 

[ocscan]

I thought EDACS was always TX trunking? and message trunking was moslty a leftover of Motorola Type I trunking????

 

[slicerwizard]

In message trunking, the talkgroup stays on its original frequency until the conversation is over.

Until the voice channel hang timer expires.


Motorola group comm trunking options:

Transmission trunking: Radios will not attempt to transmit if the talkgroup is active. All PTT's generate a request on the control channel.

Message trunking: Radios will just tailgate on the current voice channel if the channel hang timer has not expired. When they do this, their RID will not be seen on the control channel. If the talkgroup is not active, a normal request is made on the control channel and the RID will be seen on the control channel.

Wireline PTT-ID: Like message trunking, radios will attempt to transmit even if the talkgroup is active, but like transmission trunking, they will always generate a PTT request on the control channel. If the controller blocks the request (due to the group being busy), it will issue the 2C47 group busy / talk over not allowed rejection.


Pro's and cons:

Transmission trunking:
Pro: SAC enforced.
Pro: Good system access (for all groups) maintained due to more frequent call terminations.
Pro: All successful PTT RID's are seen on the control channel.
Con: Failed PTT RID's are not seen on the control channel (because the radio won't even try).

Message trunking:
Pro?: Conversations can continue without interruption on busy systems (to the detriment of other groups). Motorola calls this a feature, but I don't see it that way - long calls are an impediment to smooth trunking.
Con: Users can talk over each other (good if you like hetrodyning).
Con: SAC not enforced when tailgating.
Con: Tailgater RID's are not seen on the control channel.
Con: Repeated tailgating can reduce system access for other groups.
Con: Hang time (typically one or two seconds) dramatically reduces total system capacity; Average group call time on a commercial system is about six seconds per PTT - adding a two second hang timer represents an additional 33% overhead for dead air.
Note: Message trunking is the preferred choice when programming rogue/jammer radios (particularly ones with invalid/disabled ID's, including RID 0 and RID FFFF); the radio user can tailgate or talk over legitimate users and avoid SAC enforcement.

Wireline PTT-ID:
Pro: SAC enforced.
Pro: Good system access (for all groups) if hang timer is very short (e.g. zero).
Pro: All successful PTT RID's are seen on the control channel.
Pro: Failed PTT RID's are seen on the control channel (via 2C47 group busy rejection).
Con: Same system access degradation and wasted airtime issues if hang timer is non-zero.

 

[WayneH]

Transmission trunking: Radios will not attempt to transmit if the talkgroup is active. All PTT's generate a request on the control channel.

Simply put, as soon as the conversation ends the radios return to the control channel. It's by this method that all conversations end up requiring a grant on the CC.

PTT-ID is simply message trunking with the addition of requiring all replies to be given a grant on the CC. Sometimes PTT-ID can be seen like transmission trunking but in reality just has the hang-time set very low.

The delay in disconnect tone at the end of the conversation will give away which method is being used.

-W