this relates to both users on the local system here (UHF OBT Smartnet)...and my experience with a PS 800 smartnet....
the very nature of a trunked radio system leads me to believe that one user walking over another is impossible... the controller should see a talkgroup in use - and prevent another user from walking on another user who is using the same talkgroup.
however, both of these systems seem to allow people to key up on each other....which theoretically (to me) - should not be possible.
all trunking radios i have seen in the states are programmed for "MESSAGE" trunking - and i think this is more a function of system access time than anything else...in other words - it takes the system just a few additional milliseconds to process a PTT-ID call as compared to a radio programmed as "message trunking"
anyone have any insight here?
doug
Trunking "walk overs"
Moderator: Queue Moderator
Trunking "walk overs"
BRAVO MIKE JULIET ALPHA
"You can do whatever you want, there are just consequences..."
IF SOMEONE PM'S YOU - HAVE THE COURTESY TO REPLY.
"You can do whatever you want, there are just consequences..."
IF SOMEONE PM'S YOU - HAVE THE COURTESY TO REPLY.
Strange... lots of radios around here are set up for PTT-ID, not Message trunking.
Assuming a standard Smartnet system, if a group of radios are monitoring the same talkgroup, radio A is talking, and the other radios are monitoring, my understanding is that, when radio B keys up, it doesn't switch back to the control channel to talk to the controller. This is why you don't see a new OSW with a new individual ID on the control channel (watch a conversation with Trunker... if each user keys up in the hangtime from the last user, you'll only see the individual ID of the initiating unit).
If I'm correct, then the logic to keep radios from "walking on" each other is done solely at the subscriber unit. Theoretically, if two units key up simultaneously, both radios may see the clear channel and start transmitting, causing the problem.
PTT-ID trunking causes the radios to *always* go back to the control channel, request a new channel grant, etc., which should eliminate the problem.
It's also possible to envision a radio in fringe coverage that drops out of the system's view momentarily, causing the next user to key back up, then drift back into coverage, causing a problem.
Assuming a standard Smartnet system, if a group of radios are monitoring the same talkgroup, radio A is talking, and the other radios are monitoring, my understanding is that, when radio B keys up, it doesn't switch back to the control channel to talk to the controller. This is why you don't see a new OSW with a new individual ID on the control channel (watch a conversation with Trunker... if each user keys up in the hangtime from the last user, you'll only see the individual ID of the initiating unit).
If I'm correct, then the logic to keep radios from "walking on" each other is done solely at the subscriber unit. Theoretically, if two units key up simultaneously, both radios may see the clear channel and start transmitting, causing the problem.
PTT-ID trunking causes the radios to *always* go back to the control channel, request a new channel grant, etc., which should eliminate the problem.
It's also possible to envision a radio in fringe coverage that drops out of the system's view momentarily, causing the next user to key back up, then drift back into coverage, causing a problem.
Message trunking leaves the voice channel open or hanging for a set period after the initial party un-keys, allowing the members of the talkgroup to reply on the same channel. At that point, the channel is open to the entire talkgroup (similar to a conventional repeater), and two talkgroup members can walk on one another.
Transmission trunking frees the channel as soon as the initiator un-keys, so that the next member of the talkgroup to key may or may not be assigned to the same channel.
If the system is used heavily, transmission trunking can cause brief breaks in a conversation while users wait for a free channel. Message trunking eliminates that to an extent, but does allow users to get stepped on. Unless the system is seriously overloaded, transmission trunking generally works better in my estimation.
Transmission trunking frees the channel as soon as the initiator un-keys, so that the next member of the talkgroup to key may or may not be assigned to the same channel.
If the system is used heavily, transmission trunking can cause brief breaks in a conversation while users wait for a free channel. Message trunking eliminates that to an extent, but does allow users to get stepped on. Unless the system is seriously overloaded, transmission trunking generally works better in my estimation.
Reset Operator Head Space and Timing
It's a setting somewhere in the system itself. I have currently a 5-channel MTC3600 Smartnet system set-up in my shop. The 'as blown' which came with the system shows 'message' for trunking type. The only options we were given at the time of order were 'message' and 'transmission'.
When my field radios are programmed as message, you can 'walk on' somebody. When they are programmed as 'PTT-ID', you can still walk on somebody.
However, when you try to walk on somebody on our Provincial SmartZone system, you cannot. Since the field radio programming between the two systems are identical, it points to the system itself to determine whether radios can walk over another or not.
I figure when ordering a SmartZone system, you must actually have the choice of 'PTT-ID' for trunking type, along with the 'message' and 'transmission'. It appears when the system itself is set for PTT-ID trunking type, walk ons will not happen when the field radios are programmed as PTT-ID to match.
Todd
When my field radios are programmed as message, you can 'walk on' somebody. When they are programmed as 'PTT-ID', you can still walk on somebody.
However, when you try to walk on somebody on our Provincial SmartZone system, you cannot. Since the field radio programming between the two systems are identical, it points to the system itself to determine whether radios can walk over another or not.
I figure when ordering a SmartZone system, you must actually have the choice of 'PTT-ID' for trunking type, along with the 'message' and 'transmission'. It appears when the system itself is set for PTT-ID trunking type, walk ons will not happen when the field radios are programmed as PTT-ID to match.
Todd
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Message and PTT-ID trunking are the same with the exception that the Radio ID is sent on each PTT in PTT-ID Trunking. Stepping on each other can happen with both.
Transmission Trunking radios are not allowed to key over one another.
The Trunking Type must be set in the Controller, and Suscriber units.
Larry
Transmission Trunking radios are not allowed to key over one another.
The Trunking Type must be set in the Controller, and Suscriber units.
Larry
-
rangerfourever
- Posts: 253
- Joined: Sat Jul 17, 2004 3:39 pm
That is correct, as that's how it works on my current Smartnet message trunked system I'm setting up, regardless of whther I program Message or PTT-ID in the field units.larrybl wrote:Message and PTT-ID trunking are the same with the exception that the Radio ID is sent on each PTT in PTT-ID Trunking. Stepping on each other can happen with both.
Larry
However, you cannot step on someone on our PTT-ID trunked SmartZone system...it acts just like transmission trunking in that respect.
Todd
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
-
wb4bsd
- Batboard $upporter
- Posts: 255
- Joined: Fri Mar 14, 2003 10:07 am
- What radios do you own?: XTS5000v, XTS3000v, XTS2500
I tend to think of this just like a conventional repeater with a PL tone.
If a person keys up using a PL to open the receiver someone else (who isnt transmitting PL) can piggy back into it.
Charleston County has a trunk system that will not let anyone key up unless there ESN is in their system. however, i can get channel grants all day long if i key up while the system is hanging open for that 1 sec or so after the other person unkeys.
Note: This was shown to me by my local MSS, not something i have tried or plan on trying.
If a person keys up using a PL to open the receiver someone else (who isnt transmitting PL) can piggy back into it.
Charleston County has a trunk system that will not let anyone key up unless there ESN is in their system. however, i can get channel grants all day long if i key up while the system is hanging open for that 1 sec or so after the other person unkeys.
Note: This was shown to me by my local MSS, not something i have tried or plan on trying.
Rusty
(I no longer have nextel. I now have an iPhone)
(I no longer have nextel. I now have an iPhone)
"... i can get channel grants all day long if i key up while the system is hanging open for that 1 sec or so after the other person unkeys..."
You are not getting a "channel grant", - you are simply extending a conversation in progress.
As previously stated by others - in a message trunked system - your radio and how ever many others are sitting on that talkgroup [fleet & subfleet for type I] are all directed to the voice channel assigned by the controller to that call in reponse to the originating party's PTT ISW.
It is the originating unit that gets the channel grant. Any other unit can extend the conversation - or - step on traffic in progress - accidentally or otherwise.
Also as noted - with PTT-ID programming each unit attempting to transmit must sent an ISW requesting permission to talk. In that situation - in a Smartzone based system - whether or not that unit can step on a conversation in progress is based on a system parameter.
If the radio user record in the Zone Controller does not allow interrupt - that unit will get a reject OSW and the user will hear a 'bonk' tone.
You are not getting a "channel grant", - you are simply extending a conversation in progress.
As previously stated by others - in a message trunked system - your radio and how ever many others are sitting on that talkgroup [fleet & subfleet for type I] are all directed to the voice channel assigned by the controller to that call in reponse to the originating party's PTT ISW.
It is the originating unit that gets the channel grant. Any other unit can extend the conversation - or - step on traffic in progress - accidentally or otherwise.
Also as noted - with PTT-ID programming each unit attempting to transmit must sent an ISW requesting permission to talk. In that situation - in a Smartzone based system - whether or not that unit can step on a conversation in progress is based on a system parameter.
If the radio user record in the Zone Controller does not allow interrupt - that unit will get a reject OSW and the user will hear a 'bonk' tone.
..
so bottom line here... it's more the system setup than the field programming.
as my last good boss would say
"GOT IT"
doug
as my last good boss would say
"GOT IT"
doug
BRAVO MIKE JULIET ALPHA
"You can do whatever you want, there are just consequences..."
IF SOMEONE PM'S YOU - HAVE THE COURTESY TO REPLY.
"You can do whatever you want, there are just consequences..."
IF SOMEONE PM'S YOU - HAVE THE COURTESY TO REPLY.
larrybl has it exactly right.
Note that there is a big debate within the public safety community as to whether "talk-overs" should be precluded by the system. One side of the debate (talk-overs lead to confusion and muddled comms) is obvious. The other side holds that in an emergency, the ability to talk-over may permit a guy in trouble to break through another guy who is delivering a routine, but not flash priority, message. There is some merit to that view.
So far as I am aware, PTT-ID is exactly the same as Message Trunking with respect to talk-overs; that the short revert to an ISW for ID is solely to facilitate UnitID read-out on the console and, if so programmed, the field units, as the participants to an on-going exchange hand off to one another. I'm not aware that a PTT-ID system can be programmed to block talk-overs (such as would occur with a Transmission Trunking system), since no channel grant is required to permit transmission on the voice channel in a PTT-ID system (following, of course, the initial channel grant).
Note that there is a big debate within the public safety community as to whether "talk-overs" should be precluded by the system. One side of the debate (talk-overs lead to confusion and muddled comms) is obvious. The other side holds that in an emergency, the ability to talk-over may permit a guy in trouble to break through another guy who is delivering a routine, but not flash priority, message. There is some merit to that view.
So far as I am aware, PTT-ID is exactly the same as Message Trunking with respect to talk-overs; that the short revert to an ISW for ID is solely to facilitate UnitID read-out on the console and, if so programmed, the field units, as the participants to an on-going exchange hand off to one another. I'm not aware that a PTT-ID system can be programmed to block talk-overs (such as would occur with a Transmission Trunking system), since no channel grant is required to permit transmission on the voice channel in a PTT-ID system (following, of course, the initial channel grant).
"...So far as I am aware, PTT-ID is exactly the same as Message Trunking with respect to talk-overs; that the short revert to an ISW for ID is solely to facilitate UnitID read-out on the console and, if so programmed, the field units, as the participants to an on-going exchange hand off to one another. I'm not aware that a PTT-ID system can be programmed to block talk-overs ..."
___________________________________________________________
Wrong.
On Smartzone, PTT-ID trunking works exactly as I said above. If one user initiates a talkgroup call and a second user attempts a PTT before the first user releases his PTT - the second user will be rejected and hear a 'bonk' tone.
This rejection is displayed on the System Watch screen as "REJECT --- not allowed to interrupt".
It is possible to set the correct talkgroup "Audio Interrupt" mode and user priority parameters in the Zone Controller to allow 'talk-over' but by default - it works as stated above.
___________________________________________________________
Wrong.
On Smartzone, PTT-ID trunking works exactly as I said above. If one user initiates a talkgroup call and a second user attempts a PTT before the first user releases his PTT - the second user will be rejected and hear a 'bonk' tone.
This rejection is displayed on the System Watch screen as "REJECT --- not allowed to interrupt".
It is possible to set the correct talkgroup "Audio Interrupt" mode and user priority parameters in the Zone Controller to allow 'talk-over' but by default - it works as stated above.
Further to what XMO stated, if you have a radio with an invalid ID, it will also get the 'no access' bonk even during the hang time. This is another advantage of a PTT-ID trunked system over a Message trunked one.RKG wrote: I'm not aware that a PTT-ID system can be programmed to block talk-overs (such as would occur with a Transmission Trunking system), since no channel grant is required to permit transmission on the voice channel in a PTT-ID system (following, of course, the initial channel grant).
Todd
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
My two bits worth:
The option of "Message trunking" or "Transmission trunking"
is set in the controller code plug (U48), on the older 6809 controller, and I presume that Smart Zone is similar.
Message trunking is default.
One of the problems with the EDAC system, as I understand is that it is always "message trunking", slowing the thru-put.
There is an option that was mentioned in trunking school, "Ruthless preemption" that gives absolute priority to emergency transmissions.
Factory does NOT recommend this option.
It sounds as if the users have never been trained in operating their radio system.
The option of "Message trunking" or "Transmission trunking"
is set in the controller code plug (U48), on the older 6809 controller, and I presume that Smart Zone is similar.
Message trunking is default.
One of the problems with the EDAC system, as I understand is that it is always "message trunking", slowing the thru-put.
There is an option that was mentioned in trunking school, "Ruthless preemption" that gives absolute priority to emergency transmissions.
Factory does NOT recommend this option.
It sounds as if the users have never been trained in operating their radio system.
Aloha, Bernie