Trunk Priorty feature would be cool

[dougjgray]

I think with hardware inprvements/fast processors and Control channel trunking, I would think that having the ability to set the priorty channel to a trunking system and would be check every 2, 3 or 4 seconds would be possible and a good feature

 

[DaveIN]

You need two receivers to do trunking priority correctly. The control channel needs to be monitored for the talkgroup you have in priority, or it may never see it on a busy system.

 

[WayneH]

You need two receivers to do trunking priority correctly. The control channel needs to be monitored for the talkgroup you have in priority, or it may never see it on a busy system.

That's a negative. With Motorola the voice channel contains the active talkgroups (and which have been enabled for Priority Monitor in the SAC) in the low-speed data. Even Type I trunking sends out this info.

I'm pretty sure EDACS is the same way but I'm not familiar with the true method of conveying the TGs.

 

[DiGiTaLD]

I think he may be talking about scanning both conventional and trunking, and setting the priority channel to a trunked system control channel. Priority monitor would be a nice feature for trunked systems nevertheless.

 

[DaveIN]

That's a negative. With Motorola the voice channel contains the active talkgroups (and which have been enabled for Priority Monitor in the SAC) in the low-speed data. Even Type I trunking sends out this info.

I'm pretty sure EDACS is the same way but I'm not familiar with the true method of conveying the TGs.

Ok, so to do this with a scanner you would need a method to monitor the low speed data and the control channel and sample the data for the talkgroup you have priority set to, correct? Can this be done and still pick the talkgroup you want to keep priority on from the data?

 

[loumaag]

While the priority scan channel issue "can" be implemented in a system, it is not necessarily done and even if it is, unless you and the system administrator are thinking along the same lines, this may not do what you want. I am also not familiar enough with EDACS to know if the same applies there; I am completely in the dark about P25 (since there is no slow speed data stream) and don't know if it is included as part of the control data sent along with voice.

 

[dougjgray]

Couldnt it be done simple as instead of making a conventional channel a priorty couldnt it just check the control channel of a system for activity. if there is then switch to that system and find the voice channel and do what it needs to do, when done couldnt it just go back to scanning. I wasnt neccessarily refering to hunting for a particular Talk group in the proirty but just to check for activity on a system. Any way mostly brought it up becuase there is very little Conventional to put in priorty where I live any more except the weather channel as well as possibly give GRE some Ideas

 

[rdale]

The control channel ALWAYS has activity, so you'd lose the conventional channel briefly.

 

[dougjgray]

That is true it would have be able to interpete the control channel to check for a appropriate talk group to know if it show scan the system. Maybe in future scanners they will use like arm processors or something

 

[UPMan]

And, it takes about 1 -1.5 seconds for the control channel to send a complete "sentence" with all system activity. To decode that, the scanner has to wait for the beginning of a sentence and decode through to the end. So, your "break" in audio would be anywhere from 1 - 3 seconds.

My understanding of Low-Speed data (LSD) is that it does not contain all TG activity, but only those ID's that are flagged as priority enabled by the system admin, and some systems don't implement the feature at all. Actual Priority performance would be quite unreliable from system-to-system.

 

[troymail]

Seems the only real way to do a priority thing is to have a 2nd receiver (as was previously mentioned) so one of the two could monitor the control channel 100% of the time and hand off to the 2nd reciever....

So - how does Motorola do it? I know we have the ability to scan on our Motorola mobile units. The radio is apparently programmed to always jump to either the channel/talk-group that is on the display or the dispatch channel (I can't remember at the moment) if/when a conversation occurs on that TG... Do they have two receivers? (yes, I realize there is a big difference between a $500 scanner thats designed to be able to be programmed easily to listen to multiple systems and a Motorola mobile radio...):lol:

 

[loumaag]

Seems the only real way to do a priority thing is to have a 2nd receiver (as was previously mentioned) so one of the two could monitor the control channel 100% of the time and hand off to the 2nd reciever....:

Well yes and no, if a second receiver were included then the next request would be to be able to scan normally and monitor two (or three or four...) separate TRS' for priority traffic. This situation is why most of us have multiple scanners.

So - how does Motorola do it? I know we have the ability to scan on our Motorola mobile units. The radio is apparently programmed to always jump to either the channel/talk-group that is on the display or the dispatch channel (I can't remember at the moment) if/when a conversation occurs on that TG... Do they have two receivers? (yes, I realize there is a big difference between a $500 scanner thats designed to be able to be programmed easily to listen to multiple systems and a Motorola mobile radio...):lol:

Once again, the Moto systems can be programmed, as explained by Wayne above, to do exactly what you describe; but this is system and system administrator dependent.

 

[n4jri]

It seems to me that you can't expect to have a true priority function on a trunked system if you interrupt your reception of the CC in favor of scanning elsewhere. If your radio doesn't leave the CC, then prioritizing a TG should probably be practical. It seems like a simple choice for the user to make.

(And I agree 100% with the comment about how we already solve this by using more than one scanner)

As for Moto users getting priority TG's, why not? Their radios DO continuously monitor the control channel.

I will say that I think it would be great to be able to have an assignable receiver to monitor a CC while scanning elsewhere, but that's a lot of RF-generating stuff to put into such close quarters.

And--from what we've seen posted on this radio sight-unseen--would be be satisfied even with THAT!

So many breathtaking features have been described for this radio, that I just hope it comes out soon--and with an easier learning curve than the Uniden 396/996.

73/Allen (N4JRI)

 

[wlmr]

Couldnt it be done simple as instead of making a conventional channel a priorty couldnt it just check the control channel of a system for activity. if there is then switch to that system and find the voice channel and do what it needs to do, when done couldnt it just go back to scanning. I wasnt neccessarily refering to hunting for a particular Talk group in the proirty but just to check for activity on a system. Any way mostly brought it up becuase there is very little Conventional to put in priorty where I live any more except the weather channel as well as possibly give GRE some Ideas

Unfortunately the example you've given wouldn't work on a system where there's always someone talking. With the exception of afterhours some systems have sites that are rarely quiet.

As far as P25, yes there is low speed data on the voice channels anytime a priority talkgroup is active. Even so, scanning multi-site and even worse multi-zone and multi-site systems is fraught with headaches and pitfalls for the radio users and system administrators.

 

[WayneH]

As for Moto users getting priority TG's, why not? Their radios DO continuously monitor the control channel.

Let me put this myth to bed once and for all. Motorola radios operating in trunked mode do not use two receivers (for anything) nor do they continously decode the CC even while receiving a voice call. Once the radio trunks out to the voice channel it has lost all ability to receive the control channel. Never does it leave the voice channel, or retune in any way, until the conversation has ended. This is the purpose of sending sysadmin defined TGs over the low-speed data of the voice channel.

Even when all TGs are disabled for Priority Scanning the low-speed will still send out TG data. It is just $001 continuously. You can even see low-speed in the system keups on idle channels of a SmartZone system. You need a PRO-96 or 2096 to decode them though.

 

[SCPD]

Wayne;

Is it true that the talkgroup IDs sent over the voice channel as low speed data are truncated? I read somewhere that only 10 or 11 of the 12 bits are sent.

-rick

 

[WayneH]

Wayne;

Is it true that the talkgroup IDs sent over the voice channel as low speed data are truncated? I read somewhere that only 10 or 11 of the 12 bits are sent.

The last bit, or LSB, is left off (and assumed to be one). This is normally why analog talkgroups are in increments of 32 (in scanner form) or odd numbered in hex form.

I've never heard a definitive answer as to why.

 

[mdulrich]

This is normally why analog talkgroups are in increments of 32 (in scanner form)

Wouldn't that be increments of 16?

Mike

 

[loumaag]

Wouldn't that be increments of 16?

Mike

No, actually they are normally in increments of 32, just divisible by 16. If you look at a typical Moto Type II system you will see they start at TG 16 and the next one is 48, then 80, 112, 144, etc.

 

[DonS]

No, actually they are normally in increments of 32, just divisible by 16. If you look at a typical Moto Type II system you will see they start at TG 16 and the next one is 48, then 80, 112, 144, etc.

Yep. Since the lsb of the 12-bit ID is assumed to be a 1, you get the odd-numbered multiples of 16 (which are, of course, increments of 32 starting at 16).