Anyone have the Motorola sub audible trunking tone protocol?

[gmclam]

Perhaps this is more information than Motorola would like to be public, but with all the other stuff I have found here, I figured it was worth a shot.

I am looking for a technical spec for how the Motorola (sub-audible) tones are transmitted. You know like frequencies, durations and audio level. The trunk codes look like a 16 bit hex value, so what is the protocol for transmitting & receiving those bits?

I have tried http://www.trunkedradio.net but the site is not up.

Thanks in advance.
George

[Bruce1807]

do you mean low level trunking data?

[wavetar]

FYI, trunkedradio.net is now http://www.radioreference.com been that way for a couple of years now.

I'm not clear on your question. The only sub-audible tone used in Motorola trunking is the "connect tone", which is factory standard at 105.88Hz, but can be changed to 76.6, 83.72, 90.0, 97.3, 116.13, 128.57, and 138.46. It's filtered through to the controller to let it know the conversation is ongoing...once it drops out, the controller will drop the repeater once the hangtime expires.

Todd

[N9LLO]

I think he means the low speed data transmitted by the trunking system to the users radio along with the TX audio. Not the high speed or "control channel" data. Sorry I dont have any specifics on the data format.

Chris
N9LLO

[gmclam]

I am refering to the sub audible tones that ID the talk group which are transmitted with each transmission. The tones on the control channel are audible.

Thanks,
George

[gmclam]

FYI, trunkedradio.net is now http://www.radioreference.com been that way for a couple of years now.
Todd

LOL. I've been on Radio Reference for quite some time and they pointed me here. They certainly have all the user stuff like the talk group codes. What I am looking for is the protocol on how the codes are transmitted.

Thanks again.
George

[Wowbagger]

I believe what he wants is the protocol for the Smartnet voice channel subaudible data stream.

You are not likely to find that out in the wild, unless somebody has reverse engineered it - that is something you only get if you license it from Motorola and sign an NDA.

[Johnny Galaga]

Remember how the original PRO-92 scanners tracked /\/\otorola systems by scanning the voice frequencies and reading the sub-audible data?

Maybe that's what he's talking about.

[xmo]

In a Motorola trunked system, calls are set up through the control channel signaling formats. An initiating unit sends an inbound request [ISW]. The call is then validated by the trunking controller and a channel assignment is made. This causes a channel grant to be inserted into the outbound control channel data [OSW]. The OSW directs that unit and appropriate other units to a voice channel.

[ISW = Inbound Signaling Word, OSW=Outbound Signaling Word]

Once the unit(s) switch to the voice channel at the direction of the control channel OSW, they begin decoding the low speed data. It is sent on the voice channel as subaudible signaling similar to DPL. The purpose of the low speed signaling is to allow the unit(s) to continuously verify that they are receiving a good signal on the correct channel.

The low speed data is comprised of the first 11 data bits from the OSW. A synchronization sequence and parity bits are combined with these data bits to create a 21 bit sequence which is transmitted at 150 bits per second.

The mobile and portable units use a specific algorythm based on successful decode of a certain number of the low speed words to decide if the their receive audio should be muted or if they should return to the control channel. This protocol allows for the system to insert low speed words that contain the information necessary to implement the priority talkgroup scan feature.

[gmclam]

Remember how the original PRO-92 scanners tracked /\/\otorola systems by scanning the voice frequencies and reading the sub-audible data?

Maybe that's what he's talking about.

Actually that is what I am talking about. While the later firmware in PRO-92s now get the talkgroup data from the control channel in scan mode, they read the talkgroup ID from the "voice channel" when you are stopped (manual mode) on that channel. How is that talkgroup ID transmitted?

[Johnny Galaga]

Excellent explanation xmo. I knew about the whole OSW/ISW thing, but not about how all the priority crap worked. Must be nice having those confidential sources.

I once had the Optocom (made by Optoelectronics) which used the same trunktracking method as the original PRO-92's. It sucked out loud. The thing couldn't follow a hole in it's a$$ much less a conversation.

[bellersley]

I'm confused as to how the PRO-92 (and other products) tracked talkgroups with only the low-speed data. The low speed data only transmits which talkgroups are active - it doesn't provide any information with respect to what voice channel is being used. When a radio programmed for priority scan sees a talkgroup it is interested in, it must switch back to the control channel to get the voice channel being used by that group.

[gmclam]

I'm confused as to how the PRO-92 (and other products) tracked talkgroups with only the low-speed data. The low speed data only transmits which talkgroups are active - it doesn't provide any information with respect to what voice channel is being used. When a radio programmed for priority scan sees a talkgroup it is interested in, it must switch back to the control channel to get the voice channel being used by that group.

There are two versions of f/w or PRO-92s. I have f/w ver 3.28 in the PRO-92B and it works when scanning by monitoring the control channel. The control channel provides the talkgroup ID and the "channel #" of a communication. If the talkgroup ID is in my list (or I am in open mode) and not locked out, the scanner selects that channel. In manual mode you are stuck on a single frequency. The talkgroup ID of whoever happens to transmit there is decoded and displayed (in five BCD digits).
What I understand about the original PRO-92 (f/w ver 1.00) is that it did not use the control channel; it scanned each communication looking for those low speed codes and that was the problem. By the time it decoded them and figured out if it was something the user wanted to hear, the communication was well started, or even completed.