• 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.

SmartNet emergency functions

Status
Not open for further replies.

ocguard

Member
Premium Subscriber
Joined
Nov 9, 2002
Messages
1,288
Location
PA/MD
I have a few questions about emergency functions and status bits regarding Smartnet II emergency.

1. Do all systems have the ability for the dispatcher, using a console, to manually place a talk group into emergency status?
2. Does a dispatcher-initiated emergency assign the talk group the same status bit as a subscriber-initiated emergency?
3. Are the emergency functions/status bits in a SmartZone system identical to those in a SmartNet II system?
4. Do SmartNetII and SMartZone systems support emergency "hot-mic-keying" where activating the radio emergency button keys up the radio's mic for a set time period?
 

ocguard

Member
Premium Subscriber
Joined
Nov 9, 2002
Messages
1,288
Location
PA/MD
Ruthless pre-emption

One additional question regarding "ruthless pre-emption" in SmartNetII/SmartZone systems.

It is my understanding that the term "ruthless pre-emption" in reference to Smartnet/SmartZone systems is as follows:

If a radio activates emergency alarm/emergency call, and there are no voice channels available for assignment (system busy), the channel being used by the lowest priority talkgroup call is cancelled, and that voice channel assigned to complete the emergency call.

I have done some research on the internet and found another interpretation of "ruthless pre-emption" where, when an emergency call is sent, and the emergency user's talkgroup is in use, the subsrciber using that talkgroup is pre-empted allowing the emergency call to occur.

I don't believe that the latter case is supported by SmartNet/SmartZone system, since Smartnet/Smartzone systems assign priority levels to talkgroups, NOT to individual subscriber radios. I'm hoping an expert can clarify.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
1. Do all systems have the ability for the dispatcher, using a console, to manually place a talk group into emergency status?
I don't know for sure, but I doubt it.


2. Does a dispatcher-initiated emergency assign the talk group the same status bit as a subscriber-initiated emergency?
It would have to.


3. Are the emergency functions/status bits in a SmartZone system identical to those in a SmartNet II system?
Yes. And a good thing too - otherwise it might be a "tall order" for Uniden to keep up. :)


4. Do SmartNetII and SMartZone systems support emergency "hot-mic-keying" where activating the radio emergency button keys up the radio's mic for a set time period?
I would've thought that that was an option in the subscriber programming.


One additional question regarding "ruthless pre-emption" in SmartNetII/SmartZone systems.

It is my understanding that the term "ruthless pre-emption" in reference to Smartnet/SmartZone systems is as follows:

If a radio activates emergency alarm/emergency call, and there are no voice channels available for assignment (system busy), the channel being used by the lowest priority talkgroup call is cancelled, and that voice channel assigned to complete the emergency call.
I've seen that definition. I have to wonder how well it would work, since the low priority subscriber is still using the inbound voice channel. How will a copper rolling in the dirt with a perp overpower that?


I have done some research on the internet and found another interpretation of "ruthless pre-emption" where, when an emergency call is sent, and the emergency user's talkgroup is in use, the subsrciber using that talkgroup is pre-empted allowing the emergency call to occur.

I don't believe that the latter case is supported by SmartNet/SmartZone system, since Smartnet/Smartzone systems assign priority levels to talkgroups, NOT to individual subscriber radios. I'm hoping an expert can clarify.
The local SmartZone system here does exactly that. The emergency user gets a voice grant on an available channel and the preempted subscriber keeps yakking on a dead input channel. The remaining group members get a disconnect and follow the new grant.
 

ocguard

Member
Premium Subscriber
Joined
Nov 9, 2002
Messages
1,288
Location
PA/MD
I've seen that definition. I have to wonder how well it would work, since the low priority subscriber is still using the inbound voice channel. How will a copper rolling in the dirt with a perp overpower that?



The local SmartZone system here does exactly that. The emergency user gets a voice grant on an available channel and the preempted subscriber keeps yakking on a dead input channel. The remaining group members get a disconnect and follow the new grant.

Wow. I'm confused now.

I may have to start a thread just for "ruthless pre-emption."

I'm reading some actual Motorola documents about ruthless pre-emption and from what I gather, the purpose is focused on granting a voice channel to an emergency call when the system is busy by cancelling a low-priority call. It does address the issue of RF contention (the user transmitting on the old "cancelled" call will not receive the system's command to go idle, and that user transmitting on the input frequency may interfere with the emergency user transmitting on the same frequency).

What slicerwizard is saying is that his local Smartnet is set up where ruthless pre-emption is more focused on an emergency activation that occurs while the emergency user's talkgroup is in use, and the process of moving the emergency user, along with all other monitoring users to another available voice channel, leaving the user transmitting the call on the talk group basically talking to nobody.

Any other input as to which one is correct (as I suspect only one is the actual correct answer)?
 

talviar

Member
Joined
Dec 22, 2002
Messages
388
Location
Uniontown, PA
Wow. I'm confused now.

I may have to start a thread just for "ruthless pre-emption."

I'm reading some actual Motorola documents about ruthless pre-emption and from what I gather, the purpose is focused on granting a voice channel to an emergency call when the system is busy by cancelling a low-priority call. It does address the issue of RF contention (the user transmitting on the old "cancelled" call will not receive the system's command to go idle, and that user transmitting on the input frequency may interfere with the emergency user transmitting on the same frequency).

What slicerwizard is saying is that his local Smartnet is set up where ruthless pre-emption is more focused on an emergency activation that occurs while the emergency user's talkgroup is in use, and the process of moving the emergency user, along with all other monitoring users to another available voice channel, leaving the user transmitting the call on the talk group basically talking to nobody.

Any other input as to which one is correct (as I suspect only one is the actual correct answer)?

I have to go back in time with my memory. . . .
When my agency installed a Smartnet Type II System in 1995-1996 and training was conducted prior to live cutover to users being on the system, we had the opportunity to test a lot of things out.

One of those was ruthless pre-emption.

Things to keep in mind (For my example I am using a 5 channel trunking system)--This example was tested and verified. . . - - -
CH 1 in use by Control channel
CH 2-5 in use for voice calls
4 talk paths are available on a 5 channel TRS
If all 4 talk paths are in use there are 4 radios that are actively transmitting on the repeater inputs and --NOT-- monitoring the Control Channel or receiving in any way shape or form.

User hits emergency button on radio. Ruthless preemption is enabled on system and Hot Mic is enabled on radio.
Emergency Alert hit consoles but in regards to Hot Mic Nothing happens. . . Until one of the talk paths clears

Reason nothing happens is there is no available talk path on the system.
There is no way for the central controller to tell a radio to stop transmitting since the radio is not actively receiving. Due to nature of FM and strongest signal wins, turning the radio on that has declared the emergency would not positively give the radio access to the dispatcher on voice if there is no talk path available.

However, the radio is now at the top of the queue for a channel grant when it becomes available.

Further in regards to Hot Mic on Emergency. . .
If the radios are programmed and trunking controller set up for Message Trunking this method works.
If the radios and trunking controller are setup for Transmission Trunking the radio will not key up with Voice traffic if there is traffic active on the talkgroup that the emergency is declared on.

This is going back almost 15 years but definately remember what we did in testing.

Tony
 

ocguard

Member
Premium Subscriber
Joined
Nov 9, 2002
Messages
1,288
Location
PA/MD
I have to go back in time with my memory. . . .
When my agency installed a Smartnet Type II System in 1995-1996 and training was conducted prior to live cutover to users being on the system, we had the opportunity to test a lot of things out.

One of those was ruthless pre-emption.

Things to keep in mind (For my example I am using a 5 channel trunking system)--This example was tested and verified. . . - - -
CH 1 in use by Control channel
CH 2-5 in use for voice calls
4 talk paths are available on a 5 channel TRS
If all 4 talk paths are in use there are 4 radios that are actively transmitting on the repeater inputs and --NOT-- monitoring the Control Channel or receiving in any way shape or form.

User hits emergency button on radio. Ruthless preemption is enabled on system and Hot Mic is enabled on radio.
Emergency Alert hit consoles but in regards to Hot Mic Nothing happens. . . Until one of the talk paths clears

Reason nothing happens is there is no available talk path on the system.
There is no way for the central controller to tell a radio to stop transmitting since the radio is not actively receiving. Due to nature of FM and strongest signal wins, turning the radio on that has declared the emergency would not positively give the radio access to the dispatcher on voice if there is no talk path available.

However, the radio is now at the top of the queue for a channel grant when it becomes available.

Further in regards to Hot Mic on Emergency. . .
If the radios are programmed and trunking controller set up for Message Trunking this method works.
If the radios and trunking controller are setup for Transmission Trunking the radio will not key up with Voice traffic if there is traffic active on the talkgroup that the emergency is declared on.

This is going back almost 15 years but definately remember what we did in testing.

Tony
Thanks, Tony. I understand about the "FM strongest signal wins" theory. RF contention is something I've been reading alot about since I started combing the internet for information on ruthless preemption. Regardless, if ruthless preemption is enabled, and a subscriber sends an emergency call during a "system busy" moment, that subscriber will still trigger another active voice call to be preempted, and will in turn receive a channel grant. At this point, he begins to transmit (whether it be thru a hot-mic or manual PTT), and it will be a crap shoot as to which subscriber "wins" and has their audio demodulated by the receiver.

I'm not sure if my whole quest to fully understand ruthless preemption, it's purposes, and it's benefits and shortfalls is even worth it. A well-designed system will have very few "system busies" and the likelihood of an emergency call occurring during a busy is extremely low.

Also, thanks for the info on hot-mic-ing. I wasn't sure if Smartnet/Smartzone systems every supported it.
 

kf8yk

Member
Joined
May 3, 2003
Messages
713
1. Do all systems have the ability for the dispatcher, using a console, to manually place a talk group into emergency status?

Yes, if the console has the emergency functions/buttons assigned to the trunking resource. This is assuming a 'real' console connected to the infrastructure, not one running behind control stations.

4. Do SmartNetII and SMartZone systems support emergency "hot-mic-keying" where activating the radio emergency button keys up the radio's mic for a set time period?

Subscriber dependent feature, some subs can hot mic automatically after the emergency button is pressed. A remote monitor feature is also available on some subs.

As to emergency preemption, the system can be set up for 'ruthless' or 'top of queue'. In ruthless preemption the system will (in an all channels busy state) assign an emergency call on top of an existing low priority user. Of course this will result in two units 'doubling' with each other with the hope that the emergency user will win the capture effect battle.

Top of queue places the emergency user 'next in line' for a free repeater and is the more common configuration. As soon as the next user on the system dekeys the repeater they were using will be reassigned to the emergency call.

A well designed system should have a low occurrence of system busies and an average busy queue time of a few seconds.
 

ocguard

Member
Premium Subscriber
Joined
Nov 9, 2002
Messages
1,288
Location
PA/MD
This is all great info. Thanks everyone for your responses.

I was reading a Motorola research document regarding the issue of ruthless preemption and RF contention between the user transmitting the original call and the user initiating the emergency call.

The study grasped the problem and offered this solution:
The system would "compare" the receive signal strength of the low priority user whose call is slated for preemption on the voice channel to the receive signal strength of the emergency call user's emergency alarm data packet received on the control channel. If the emergency call user had the better signal, preemption would occur assuming that the emergency caller would be captured by the receiver over the original caller. If the emergency caller's signal was less than the original caller's, the system would compare the emergency caller's signal strength with the NEXT lowest priority call the same way, and so on and so forth. Nice in theory, but it seems that in the time it would take for a system to do all of this, another call has likely ended, and top-of-queue method would have been just as effective.

If anyone is interested in reading the document, you can find it here, go to the bottom right and click "Download this Document" to read the whole thing. It's free, and virus-free. I scanned it already. Pretty dry reading unless you're a loser like me.
 

WA4MJF

Member
Joined
Jan 15, 2007
Messages
509
My understanding on how it works on our VIPER system, here in NC, is hit button, mic open for 10 seconds, dispatcher gets alarm, radio goes to EMERGENCY TG (last TG in every zone). All this happens simultaneously, at the same time. We've never had to use it, thankfully, but that is the explanation.
 

ocguard

Member
Premium Subscriber
Joined
Nov 9, 2002
Messages
1,288
Location
PA/MD
My understanding on how it works on our VIPER system, here in NC, is hit button, mic open for 10 seconds, dispatcher gets alarm, radio goes to EMERGENCY TG (last TG in every zone). All this happens simultaneously, at the same time. We've never had to use it, thankfully, but that is the explanation.

Ahh, yes. You add another option into the equation: emergency revert. I can see the advantages of this too.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
What slicerwizard is saying is that his local Smartnet is set up where ruthless pre-emption is more focused on an emergency activation that occurs while the emergency user's talkgroup is in use, and the process of moving the emergency user, along with all other monitoring users to another available voice channel, leaving the user transmitting the call on the talk group basically talking to nobody.
No, I said that I have seen a local SmartZone system do that. I didn't say it was an example of ruthless preemption.

IMO, enabling ruthless preemption on systems with ~10+ talk paths is probably a bad idea. On large-ish sites, ATB conditions are generally quite short and a voice channel for high priority emergency traffic will become available within a few seconds. Better to have the user wait a bit for a clear talk path. I could see ruthless preemption kicking in if no channel frees up after a set time period (like 2-3 seconds), but it looks like Motorola doesn't offer this intelligent option.


Nice in theory, but it seems that in the time it would take for a system to do all of this, another call has likely ended, and top-of-queue method would have been just as effective.
For some reason, you assume that the system would have to start polling the voice channels for RSSI readings. This is information that would already be available (it's one variable used to determine when a call has ended). How long does it take a computer to compare a few dozen numbers?
 
Status
Not open for further replies.
Top