I just got my 800Mhz Astro Saber 3 back from Motorola and it has the latest firmware Host R07.70.00 DSP N08.03.03 and the digital id works fine but on an analog talkgroups the user id sticks. For example when user 45100 keys up the mic the id will pop up and then when user 45360 keys the mic to reply the id never changes to the new users id 45102. It will display the ids fine if there is a 4 second pause between each time someone transmits. Has anyone else had this problem or know what may be causing this to happen? Thanks
-Jeff
Analog ID Question
Moderator: Queue Moderator
-
N4DES
- was KS4VT
- Posts: 1234
- Joined: Thu Dec 25, 2003 7:59 am
- What radios do you own?: APX,XTS2500,XTL2500,XTL1500
It could be a number of things, one is if the users that are on the system are not programmed for PTT ID which instructs the radio to transmit the ID each and every time the PTT is pressed.
The other item to note is to how the talk-group is set up (message vs transmission trunking). Most of the TG's on my system are transmission trunking and the id's show up each time for every user. Of the 3 cities that are connected to the controller, some are message trunking and the id's don't rotate from one user to the next until the carrier drops.
From what you are seeing I highly doubt that the problem is on your end.
The other item to note is to how the talk-group is set up (message vs transmission trunking). Most of the TG's on my system are transmission trunking and the id's show up each time for every user. Of the 3 cities that are connected to the controller, some are message trunking and the id's don't rotate from one user to the next until the carrier drops.
From what you are seeing I highly doubt that the problem is on your end.
Last edited by N4DES on Sun Jan 14, 2007 7:36 am, edited 1 time in total.
The 4-second delay he mentions is no doubt the hang-time of the trunking repeater.
I think KS4VT is right on with his diagnosis - your system is set up for message trunking instead of transmission trunking.
The difference being:
In message trunking, the radio ID of the unit that initiates the conversation is displayed. If another user (i.e. different radio) replies BEFORE the repeater hang-time runs out (and disconnect tone is sent), the system just uses the ID of the radio that initiated the conversation, and not the ID of any responding radios. You could have a 15 minute conversation occuring on the talkgroup, and as long as the hang timer doesn't run out causing disconnect tone to be sent, you're only going to see the ID of the radio that started the conversation. It seems that message trunking was intended for things like SMR's and the like, in that there is generally no dispatch console and no need for ID display, therefore updating the ID's wasn't critical - the ID was just used to authenticate the radio to the system upon initiating a call.
In transmission trunking, the radio ID of ANY transmitting portable is updated to the central controller each time the user presses the PTT. This will result in each radio's ID being displayed on your portable in real-time, as the radios are keying up. Transmission trunking is intended for public-safety type applications, where there is a legitimate dispatch console attached to the system, and ID's need to be updated on-the-fly so that dispatchers and field units know who is transmitting at any given time.
Hope this helps. KS4VT is correct, the problem is not on your end. The only way to fix the problem is to reconfigure the system as transmission trunking, and reprogram *all* of the subscriber units. Not an easy task.
I think KS4VT is right on with his diagnosis - your system is set up for message trunking instead of transmission trunking.
The difference being:
In message trunking, the radio ID of the unit that initiates the conversation is displayed. If another user (i.e. different radio) replies BEFORE the repeater hang-time runs out (and disconnect tone is sent), the system just uses the ID of the radio that initiated the conversation, and not the ID of any responding radios. You could have a 15 minute conversation occuring on the talkgroup, and as long as the hang timer doesn't run out causing disconnect tone to be sent, you're only going to see the ID of the radio that started the conversation. It seems that message trunking was intended for things like SMR's and the like, in that there is generally no dispatch console and no need for ID display, therefore updating the ID's wasn't critical - the ID was just used to authenticate the radio to the system upon initiating a call.
In transmission trunking, the radio ID of ANY transmitting portable is updated to the central controller each time the user presses the PTT. This will result in each radio's ID being displayed on your portable in real-time, as the radios are keying up. Transmission trunking is intended for public-safety type applications, where there is a legitimate dispatch console attached to the system, and ID's need to be updated on-the-fly so that dispatchers and field units know who is transmitting at any given time.
Hope this helps. KS4VT is correct, the problem is not on your end. The only way to fix the problem is to reconfigure the system as transmission trunking, and reprogram *all* of the subscriber units. Not an easy task.
By default, 'transmission trunking' simply means no repeater hang time, thus the need for the field units to require a channel grant from the controller every time. I wouldn't call it 'public safety' grade, as most PS agencies require a hang time to ensure uninterrupted communications once the talk permit is given. Thus, "PTT-ID" trunking was developed, which gives the best of both worlds...repeater hang time for smoother conversations, and PTT-ID sent to the controller on every transmission to ensure field units & consoles get the updated IDs.d119 wrote: In transmission trunking, the radio ID of ANY transmitting portable is updated to the central controller each time the user presses the PTT. This will result in each radio's ID being displayed on your portable in real-time, as the radios are keying up. Transmission trunking is intended for public-safety type applications, where there is a legitimate dispatch console attached to the system, and ID's need to be updated on-the-fly so that dispatchers and field units know who is transmitting at any given time.
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.