Make Trunked Radios Work with Interop: JPS Adaptive TX Delay

Make Trunked Radios Work with Interop: JPS Adaptive TX Delay

You can successfully use a trunking radio with an interoperability gateway. JPS’ Adaptive Transmit Delay (US Patent 10630846) lets you do so without unnecessary latency, audio clipping, or outright failure. Read on to learn how.

Trunked Radios, Disparate Devices, and Interoperability Systems

Following FCC narrowbanding mandates, the use of trunked radio systems began to grow and has continued to expand. At the same time, interoperability gateways have become more necessary to interface with non-radio or disparate communications device types. This combination of factors has led to the problem of missing first syllables of audio during transmission. That’s because the trunking system controller grants channel access on a by-request basis. Channel availability is indicated by a distinct audio pattern, commonly called a talk permit tone. Radio users train themselves to wait for the tone before speaking so that they are heard.

In any interoperability system, channel acquisition from trunked radio systems doesn’t just affect radios, it also affects every other disparate communications device type patched with a radio. That’s because even though channels are often granted relatively quickly, the channel acquisition time is enough to interrupt a standard speech pattern. On top of that, the channel acquisition time will change as the load on the system changes, which makes it difficult to predict how to preserve the first few syllables of the transmitted conversation.

In response to this problem, you might try retraining your personnel on phones to change their habits, maybe wait a beat before speaking? That’s just awkward and unlikely to actually solve the problem. It could even make things worse. That’s why the JPS RSP-Z2 includes Adaptive Transmit Delay – a unique feature that uses the gateway to make the adjustment based on tone, not guesswork.

Problem: …Waiting for a Channel…

trunking radio systems require channel acquisition before TX
In a trunked system, when you press the PTT button on your mobile radio, it sends a signal to the trunking system controller requesting a channel. Then the trunking system analyzes channel availability. When it has a channel, the radio plays an audible talk permit or a channel grant tone back to you. When you hear the tone, you know you have a channel and can start talking.

wait for the tone for successful transmission

says: One five nine Main Street hears: One five nine Main Street

What happens if you start talking before you hear the talk permit tone? Pressing the PTT button sends the channel request to the trunking controller, which analyzes availability. However, if you’re talking before the channel grant tone, you don’t have a channel. If you don’t have a channel, you’re not talking to anyone. Anything said before channel acquisition is lost.
not waiting for the tone causes failure

says: ONE five nine Main Street hears: five nine Main Street

Another example of this is the difference between, “Cut the red wire,” and, “Don’t cut the red wire.” If “Don’t,” is spoken prior to the channel being acquired, the rest of the people on the radio system hear, “Cut the red wire.” Missing that first syllable of audio makes a really big difference.

Solution: Use Transmit Delay

As we’ve already established, if you commonly use radios requiring tones or absence of tones to indicate channel acquisition, you’ve trained yourself to wait for the tone before speaking. Trying to train a phone or other device user to wait – especially because they don’t even hear the tone – is fraught with problems.

So instead of asking the users to change their accustomed behaviors, the RSP-Z2 lets you train your radio resources to wait before transmitting.

  • Either, ALWAYS wait the same amount of time (Constant TX Delay)
  • Or, ONLY wait the time it takes to acquire a channel (Adaptive TX Delay) – and try again if needed

Constant TX Delay

Constant TX Delay
Using Constant TX Delay, you take your best guess at how much the maximum amount of time is that it takes to acquire a channel. Then, you configure the radio resource to always wait that amount of time before transmitting. Of course, waiting up to ten seconds for every radio transmission can add latency. It can also tempt overly optimistic users to configure a too-short delay, which can cause missing first syllables and audio clipping.

Adaptive Transmit Delay

Adaptive TX Delay for audio pattern or busy channel
Patented Adaptive TX Delay lets you train the RSP-Z2 to do what you do – wait for the correct tone and then immediately transmit without further delay. There are two types, one for trunked radio systems and one for systems that use the lack of a busy tone to indicate channel readiness.

Audio Pattern Transmit Delay

When you use Audio Pattern delay, you train the RSP-Z2 to listen for the unique talk permit tone for your radio. The RSP-Z2 will store and buffer the transmit audio until the RSP-Z2 hears the talk permit tone – in half a second, in 3 seconds, or in 10 seconds, however long it takes – then it immediately releases the stored audio to the host radio which initiates the transmit of the audio. If the trunked controller determines all channels are busy and the radio does not play a talk permit tone, the RSP-Z2 detects that it has not received the tone, and it can try again.

Busy Channel Transmit Delay

This is also a patented Adaptive Transmit Delay type because, like Audio Pattern, it reacts and adapts to the signals coming from the radio system. However, Busy Channel is used more commonly on conventional radio systems that require the user to wait for the absence of a busy tone before speaking. As soon as the RSP-Z2 detects the absence of the busy tone – in half a second, in 3 seconds, or in 10 seconds, however long it takes – it starts to transmit the audio. If the busy tone does not go away (because the channel is busy), the RSP-Z2 detects it and can re-key the radio to try again.

Reasons to Use Adaptive TX Delay

While it certainly may seem like it would be “easier” to just set a Constant Transmit Delay, choosing an Adaptive Transmit Delay will:

  • Reduce latency because channel acquisition times vary due to traffic and system loading conditions. Setting an overly long constant delay is often not necessary.
  • Prevent audio clipping because the channel will be acquired. You won’t be tempted to set a too-short constant delay to reduce latency.
  • Significantly reduce or prevent outright failure because the RSP-Z2 can re-key the radio and try again if a channel isn’t acquired the first time.

The patented Adaptive Transmit Delay feature set ensures complete audio: no additional delay, no missing first syllables of audio, and with the capability to try again.

Real-World Example – A Volunteer Fire Department with Radio to PoC App

A volunteer fire department uses their RSP-Z2 to patch a Push-to-Talk over Cellular (PoC) talkgroup with a radio channel that requires channel acquisition. They’ve noticed something they don’t understand. When a radio user speaks, everyone on the radio channel or who is in the PoC talkgroup hears the whole message.
field radio user waits so successful to PoC and radios

However, when one of the PoC talkgroup members speaks, the other talkgroup members get the whole message, but the radio users miss the first syllables of audio. And sometimes there is no transmission at all!
PoC user does not know to wait so radio users miss message

Here’s what’s happening: They’re not using any form of Transmit Delay

When a radio user speaks, they PTT the radio to send the channel request and they wait while the trunking controller ascertains channel availability. Once the channel is acquired, the radio emits the talk permit tone. The radio user starts talking and the audio is transmitted to all the other radio users as normal – that includes to the donor radio and its radio resource on the RSP-Z2. The radio resource receives the audio and the RSP-Z2 sends it straight through to the PoC resource.
net on RSP-Z2 where radio audio shared with PoC talkgroup

However, when a user on the PoC group speaks, they simply start talking. Other PoC users in the talkgroup – including the PoC resource on the RSP-Z2 – hear or receive the message. The PoC resource shares the audio with the radio resource in the same net, but this is where the problem occurs. The donor radio connected to the RSP-Z2 has not yet acquired a channel to transmit on, and it must PTT to request one from the trunking controller. During that variable of time from request to acquisition, there is no channel. Therefore, there is no audio transmission to the radio system until the channel is acquired. The result is missing first syllables of audio.
net on RSP-Z2 where PoC audio shared with radio users but without any TX delay

Here’s how an Adaptive TX Delay fixes the problem

The volunteer fire department determined they were using a trunked radio system, and their problem was related to the inherent delay caused by channel acquisition. So, they went into the radio resource’s settings on the RSP-Z2 and looked at the Transmit Delay group of advanced settings. There, they selected Audio Pattern transmit delay and clicked the Train Now button.
Audio Pattern TX Delay settings for radio resource

  • Train Now keys the donor radio attached to the RSP-Z2, which sends the channel request to the trunking controller.
  • When a channel is acquired and the radio emits the talk permit tone, the RSP-Z2 hears and learns it.
  • Now, just like a human, the RSP-Z2 will transmit after it hears the tone – not before, and not with an overly long delay before transmitting.
  • And if the channel isn’t obtained, the RSP-Z2 can rekey the radio to try again.

Adaptive TX Delay allows all users to receive the full message

If you’d like to learn more about Adaptive Transmit Delay or any of the other unique features built into the RSP-Z2 or the Z-Series Controller, please:

SHARE IT:

Related Posts