Motorola 0x90 TSBKO 0x0A & LCO 0x0A - Emergency Alarm Activation Message

[DSheirer]

I've been trying to figure out Moto TSBK Opcode 0x0A message that I'm seeing infrequently on both the control channel and also in Link Control messaging on traffic channels. The following sequence seems to indicate it's an Emergency Alarm Activation notification message. It's also interesting that on activation the network issues two group voice channel grants to the radio for separate talkgroups on separate traffic channels, one encrypted and one not encrypted. I'm guessing the radio is capable of (simultaneous) dual-channel operations?

 

[boatbod]

If it's any help, Moto subscriber radios can be programmed to switch to a different tgid after activation of the emergency button. That's how our county has our fire radios set up. PITA really because the IC doesn't know a mayday has been declared until Dispatch notifies them.

 

[GTR8000]

I'm guessing the radio is capable of (simultaneous) dual-channel operations?

Highly unlikely. If it's a Motorola subscriber, they do not make dual-tuner radios. Best you could do is have a dual-deck mobile setup, however it wouldn't make much sense to program both with the same SID or to have each deck transmitting on different talkgroups after an emergency activation.

TG 161 could be the emergency revert talkgroup, so if the subscriber was on TG 39 and hit the emergency button, the radio can be setup to transmit on TG 161 without user intervention.

 

[Unitrunker2]

Normally when a radio starts talking on a channel - it is a sane assumption they're done talking on the previous channel. In this case clearly the radio is talking on both channels at the same time.

Not efficient. It would be more efficient to patch the two groups together.

Other trunking protocols have an inefficient form of multi-select calling that behaves this way. The two talkgroups can't hear each other's replies. Normally this is a dispatcher radio that exhibits this behavior but dispatchers don't normally generate "E" button alarms.

@DSheirer This is a weird one.

 

[boatbod]

Normally when a radio starts talking on a channel - it is a sane assumption they're done talking on the previous channel. In this case clearly the radio is talking on both channels at the same time.

Not efficient. It would be more efficient to patch the two groups together.

Other trunking protocols have an inefficient form of multi-select calling that behaves this way. The two talkgroups can't hear each other's replies. Normally this is a dispatcher radio that exhibits this behavior but dispatchers don't normally generate "E" button alarms.

@DSheirer This is a weird one.

On the assumption that this is an OSP being monitored, is there any particular reason that a SU emergency button activation might not result in the voice being sent on two separate tgids when the RFSS rebroadcast it? Seems like it's not necessarily the SU sending on two tgids at the same time, more of a RFSS ability (albeit normally coded as a regroup)

 

[tadsmith]

TSBK Opcode 0x0A message th

If I'm reading the timestamps correctly, there's also almost 4.5 seconds between the emergency alarm acknowledgement (1712566858576) and the first group voice channel grant (1712566862924). Wouldn't be impossible for there to have been some human intervention.

 

[Unitrunker2]

Seems like it's not necessarily the SU sending on two tgids at the same time, more of a RFSS ability (albeit normally coded as a regroup)

That's how multi-select works (or rather, this crappy form of MS). To be clear - no, I'm not suggesting the radio is transmitting on two repeater inputs at once. My guess is the split into two repeater outputs happens at the controller.

Normally multi-select is initiated from a dispatcher - either on a proper console (like you'd see inside a 911 call center) or as just another subscriber unit (as a backup when the main call center is down for maintenance or for departments running on a tight budget).

Let me back up a bit. @boatbod, @GTR8000 and @DSheirer I think are very familiar but I want to state a few things so others can follow along. Setting aside telephone patching or ISSI linking, we have three kinds of patches.

1. The normal patch where all radios joined/affiliated on subordinated groups talk to and listen on the supergroup until the patch goes away.
2. The mutli-select patch. All radios joined/affiliated on subordinated groups listen on the supergroup but continue to talk on their respective subordinate groups. This allows the dispatcher to talk to multiple groups at once but also allows the members of each group to talk among themselves.
3. Last is the crappy form of multi-select. The key trait is multiple simultaneous calls with the same speaker but differing audiences.

The snippet shared by @DSheirer above appears to be an example of #3. The only advantage I can imagine is #3 may be faster to set up compared to #1 or #2 on some consoles. That said, I've never seen an ordinary subscriber initiate #3. Either this is a dispatcher radio / console or someone found and enabled a very obscure feature inside the RFSS.

It will be fun to see where this goes.

If you want to give someone nightmares - imagine a combination 1+3 or 2+3 above.

 

[Unitrunker2]

Here's an example of different calls being transmitted on clear and encrypted talkgroups at the same time.
On the top is "Henry Riverside" 3C7 (enc) and 3DC (clear) - both with the same radio ID. In the history below you can see similar pairs of calls with the same radio ID - one is a "4" and the other is a "P4".


I'm guessing the talkgroups are being migrated over to encryption. They need side-by-side enc / clear TGs working until all subscriber units are reprogrammed or upgraded. Edit: the forums down-sample the image. That's a 10 point font shrunk to about a 7.

 

[DSheirer]

To followup, I found the bitstream recordings from each of the two traffic channels that were spun-up from the radio emergency. The first one was encrypted/emergency to TG 161 and it started with the 911 dispatcher talking:



and then the emergency radio responding ... it sounded like "um, sorry I accidentally hit the emergency button", but it was mostly encrypted so I can't be sure



The second group channel grant, unencrypted to TG 39 looks like an empty call, although there were 2x sync losses, conveniently right after the HDU where the first LDU voice frames would have been, but the total bit loss doesn't amount to much, so I don't think any voice was transmitted on that traffic channel. Seems like it was just an unnecessary traffic channel spin-up.



Thanks for the responses from everyone.

cheers,
Denny