• To anyone looking to acquire commercial radio programming software:

    Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.

    If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.

    To obtain Motorola software see the Sticky in the Motorola forum.

    The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.

    For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).

    This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.

Type II with status bits or Type I system?

Status
Not open for further replies.

trunker

Member
Joined
Jul 21, 2002
Messages
358
Location
Michigan
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

Member
Joined
Sep 14, 2006
Messages
36
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

Silent Key Jan. 14, 2012
Joined
May 11, 2002
Messages
7,741
Location
Eclipse, Virginia
Try this Status bit Calculator. They could all be type II.

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

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
jaythescanman said:
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

Member
Joined
Jul 21, 2002
Messages
358
Location
Michigan
...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).?
 
D

DaveNF2G

Guest
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

.
Feed Provider
Joined
Feb 15, 2002
Messages
9,316
Location
Bragg Creek, Alberta
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

Member
Joined
Jul 21, 2002
Messages
358
Location
Michigan
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

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
DaveNF2G said:
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.
 
D

DaveNF2G

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

ocscan

Member
Premium Subscriber
Joined
Dec 19, 2002
Messages
361
Location
Ottawa, On
I thought EDACS was always TX trunking? and message trunking was moslty a leftover of Motorola Type I trunking????
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
6,889
Location
Toronto, Ontario
DaveNF2G said:
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

Forums Veteran
Super Moderator
Joined
Dec 16, 2000
Messages
7,501
Location
Sitting in an airport somewhere
slicerwizard said:
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
 
Status
Not open for further replies.
Top