Motorola Radios on Repeater Randomly bricked themselves

[sammyg512]

I've recently been working at an event, using Motorola DP4400 Series radios, connected to a few repeaters around the site, suddenly radios using Channel 1 stopped working and completely bricked themselves. None of the other channels seem to have been affected, connected to the same repeater, until they are changed to channel 1 Then they stop working, and wont turn back on.

It seems when the issue originally started, an unknown radio was used on Channel 1, after this unknown radio was used, that's when the issues started.

We also noticed, that before channel 1 failed, we had a gold notification star icon on the screen, after channel 1 failed the gold star icon disappeared, with no notifications in the list.

I've worked with Motorola Radios for years, and our hire company have over 30 years in the business, and neither of us have ever heard of this happening before.

More just for my own interest, but has anyone experienced this before or know what the cause may be?

 

[K2NEC]

Radios dont just randomly inhibit themselves. It almost sounds like someone with a DP4600 or similar radio was sitting on channel 1 and disabling radio IDs. It's something that can be done by default in the radio front menu. Radios will also by default acknowledge and respond to the disable command.

 

[sammyg512]

Radios dont just randomly inhibit themselves. It almost sounds like someone with a DP4600 or similar radio was sitting on channel 1 and disabling radio IDs. It's something that can be done by default in the radio front menu. Radios will also by default acknowledge and respond to the disable command.

That would make sense, as its only radios that were on channel 1, and radios that

Radios dont just randomly inhibit themselves. It almost sounds like someone with a DP4600 or similar radio was sitting on channel 1 and disabling radio IDs. It's something that can be done by default in the radio front menu. Radios will also by default acknowledge and respond to the disable command.

Is it likely that someone has used a radio scanner to connect to the repeater, and been able to disable all radios on a channel using a scanner? Just our radio hire company, has said that they have disabled the inhibit function on individual radios. The radios are turning on, showing the motrbo logo, then the screen is going black and the radio is just turning off.

 

[kb5udf]

Scanner radios don't transmit, and so that can't "connect" to the repeater, another radio or anything else. In short, "a scanner" can't disable a two radio radio since the scanner can not transmit any commands or anything else.

 

[RFI-EMI-GUY]

Is there some political reason someone might do this?

 

[Firebuff880]

If I were guessing. I would say that someone set up a Stun/Kill, and that the Radios being affected are not acknowledging the instruction, so it is still actively running in the infrastructure hosting it. Merrily disabling your fleet.

Since this is a DP subscriber, is it safe to assume you are in the EMEA region? Another off-the-wall guess is that Channel One is shared and is also in use on another nearby system, and that system is sending Stuns/Kills. If you were in NA, I would say check the FCC databases, but in the EMEA region, that's easier said than done, as I understand it.

 

[sammyg512]

Is there some political reason someone might do this?

Hopefully not, its a music festival for families. It just seems a little strange, radios are getting bricked only when transmitting on Channel 1, to the point they wont even turn back on.

If I were guessing. I would say that someone set up a Stun/Kill, and that the Radios being affected are not acknowledging the instruction, so it is still actively running in the infrastructure hosting it. Merrily disabling your fleet.

Since this is a DP subscriber, is it safe to assume you are in the EMEA region? Another off-the-wall guess is that Channel One is shared and is also in use on another nearby system, and that system is sending Stuns/Kills. If you were in NA, I would say check the FCC databases, but in the EMEA region, that's easier said than done, as I understand it.

That would make sense, when Channel 1 was working, we intermittently had an issue where radios would say channel busy, even if no one was transmitting. There are other events going on in the area, so if another event is using the same frequency, could it have been possible, they issued the kill/stun request if they were having the same issue?

 

[K2NEC]

If I were guessing. I would say that someone set up a Stun/Kill, and that the Radios being affected are not acknowledging the instruction, so it is still actively running in the infrastructure hosting it. Merrily disabling your fleet.

But they are acknowledging it because they are being disabled. Your explanation doesn't make any sense because it can't just run on the infrastructure like you say it can

That would make sense, when Channel 1 was working, we intermittently had an issue where radios would say channel busy, even if no one was transmitting. There are other events going on in the area, so if another event is using the same frequency, could it have been possible, they issued the kill/stun request if they were having the same issue?

If the radios are saying channel busy, your admit criteria needs to be changed. Any interference on the system will cause the radios to be denied. Horrible programming feature honestly.

You need to reprogram your radios to not follow inhibit commands and probably implement some security like RAS and Enhanced Privacy

 

[speedway_navigator]

I've worked with Motorola Radios for years, and our hire company have over 30 years in the business, and neither of us have ever heard of this happening before.

Did you bid against another hire company that might be taking revenge? I had this happen to me at least 2 times.

 

[sammyg512]

Did you bid against another hire company that might be taking revenge? I had this happen to me at least 2 times.

ahaha, nope, the hire company used it the preferred supplier, and the only supplier used by the event management company! That's the first i've heard of that happening... Radio Wars!

 

[Firebuff880]

But they are acknowledging it because they are being disabled. Your explanation doesn't make any sense because it can't just run on the infrastructure like you say it can

No, the Stun/Kill can process in the subscriber, without the Ack making it back to the originating requestor (Control station/MNIS) application.

 

[K2NEC]

No, the Stun/Kill can process in the subscriber, without the Ack making it back to the originating requestor (Control station/MNIS) application.

I see what you are saying now. I meant that the subscriber is acknowledging the request

 

[sammyg512]

No, the Stun/Kill can process in the subscriber, without the Ack making it back to the originating requestor (Control station/MNIS) application.

Will the Stun / Kill request cause the radio to completely brick it's self, causing it not to turn on at all? I take it, it would need to be manually connected to CPS to remove the Stun / Kill command?

 

[K2NEC]

Will the Stun / Kill request cause the radio to completely brick it's self, causing it not to turn on at all? I take it, it would need to be manually connected to CPS to remove the Stun / Kill command?

A radio sends the Radio Disable command to a specific RID. That RID will receive the request and process it. If it's programmed to ignore that request, then the sending radio will be notified that their disable request was denied. Otherwise the receiving radio will process that request and immediately power off. If tried to power on, it will display the Motorola logo and then power off.

Yes the radio needs to by physically connected to a PC and it doesn't "remove" the command, it just writes over it.

I forget exactly how it works with TRBO, but if you know the RID, you should be able to enable the radio with the Radio Enable menu option as long as you know the RID.

 

[sammyg512]

A radio sends the Radio Disable command to a specific RID. That RID will receive the request and process it. If it's programmed to ignore that request, then the sending radio will be notified that their disable request was denied. Otherwise the receiving radio will process that request and immediately power off. If tried to power on, it will display the Motorola logo and then power off.

Yes the radio needs to by physically connected to a PC and it doesn't "remove" the command, it just writes over it.

I forget exactly how it works with TRBO, but if you know the RID, you should be able to enable the radio with the Radio Enable menu option as long as you know the RID.

Makes sense, this describes the exact symptoms we had on our radios. There was another event happening around 10 miles away, just seems to be a coincident that the other event had the same issues as we were facing, with the channel busy. Seems to be like both radio networks were using the same frequency, but different color codes. Seems like they could've inhibited radios they didn't recognize if our radios inadvertently connected to their repeater. Sounds to me, like the hire companies didn't configure the radios properly!

 

[K2NEC]

With the channel busy, if the radio sees any activity, whether its from the repeater or interference from something else, the radio won't TX. You need to set your admit criteria to "Always" to defeat this.

Maybe both events were causing interference to one another and that's why you both saw channel busy. But it's hard to say without knowing specifics.