MOTOTRBO - IPSC, Capacity Plus, Linked Capacity Plus - Audio Holes

[Mars]

Hi everyone

First, this is NOT a bug report, nor is there anything wrong with Motorola's current firmware or products. What I am about to describe is the result of a codeplug misconfiguration and how it can have a severe, negative impact on your networked communications. The result is audio holes across the network.

In the repeater (XPR or MTR) codeplug, there's a setting in the NETWORKED digital channel setting called "RSSI Threshold (dBm)". The CPS description of this feature really doesn't explain it too well, other than:

This feature allows the user to set the RSSI (Received Signal Strength Indication) Threshold for multisite. The RSSI threshold is used for FCC Type 1 compliance. This is a channel-wide feature.

In Canada and elsewhere, we don't have FCC Type 1 compliance. So the terminology isn't something we'd be familiar with. I wrongly assumed this set the incoming RSSI threshold for a digital signal to be repeated. That assumption was grossly incorrect.

FCC Type 1 compliance means the repeater will monitor BOTH the TRANSMIT and RECEIVE frequencies (as defined in the channel configuration, CPS) to determine if there are other nearby signals active which are STRONGER than the defined value. If it detects signals matching or exceeding this value, it will inhibit the transmit operation from passing networked traffic. (i.e. incoming audio/data from another repeater on your IPSC/CP/LCP system).

For a very detailed description, please watch Wayne Holmes' (Motorola Germany) YouTube video: (Fast-forward to 11:20)

Through my misunderstanding of this setting, I had set my repeaters up for a value of -122dBm, so they would repeat signals exceeding this value. Again, this is NOT the purpose of the setting and my understanding (to this point) was wrong.

As a result of my incorrect configuration, users on our networked repeaters reported occasional audio holes, involving inbound signals from networked repeaters on the network. This was because there was a noise floor higher (stronger) than -122dBm, causing the FCC Type 1 Compliance feature to get triggered.

The RSSI Threshold can be triggered by a high noise floor at a site, spurious emission(s) from various devices such as plasma TVs, computers or other electronic devices. Splatter from nearby signals can also affect the noise floor, causing the RSSI Threshold to be triggered when it sees a value stronger than what is defined in CPS.

The resolution is to set the RSSI Threshold to -40dBm (strongest setting possible) to avoid triggering the FCC Type 1 Compliance feature. This resolves the audio holes.



I'm wondering how many other networked repeater operators may be experiencing this same issue, due to misconfiguration of the setting. I know it has been a major problem for my sites and I'm glad to have it resolved. I highly recommend all international DMR techs review this codeplug setting as you may not be familiar with "FCC Type 1 Compliance"; I know I wasn't.

Self-depreciating confession:

In July, I had installed a UHF XPR8400 at a site where there's about 72kW ERP of UHF ATSC (digital TV) transmitters broadcasting from. I had major issues which affected inbound data/voice from our remote sites. (The XPR at this site was not keying up and relaying networked comms.)

Through troubleshooting, I found the XPR functioned correctly if I removed the BNC cable from the RX port on the repeater. I had assumed strong RF from the ATSC transmitters was getting into the repeater and affecting the ethernet functionality. I assumed this as the issue was resolved by adding a high-Q UHF passband cavity inline with the RX port. In hindsight, all I had done was knocked down the noise-floor to the point where the RSSI Threshold wasn't being triggered! (I will visit the site soon to remove this cavity, and gain some much-needed sensitivity back!)

Hopefully this report/confession helps someone. It is 100% not Motorola's fault.

 

[com501]

Most of our systems are licensed for exclusive territory, so I had set our values at -40, but good catch. You are correct, the description is less than helpful unless you delve deeply into the planning manual and help files.. This value CAN be helpful, as it will show up in your stats in Genisys and I believe in the new RDAC reports as well, showing potential site interference.

 

[PSEhub]

Glad you got that once mysterious TV tx site figured out.

 

[Magnus]

Just FYI, it appears someone from Motorola read this thread, they changed the help description.

This threshold defines a level at which the repeater will not transmit due to interference. For a multi-repeater trunked system this threshold also determines the level at which a repeater will temporarily remove itself from the system due to interference. IP Site Connect Systems The threshold should be set according to any license restrictions (for example FCC), increasing the level will make the repeater increasingly impolite to other systems. Capacity Plus Systems and Linked Capacity Plus Trunked Systems When this threshold is exceeded by an unwanted RF signal then the repeater will be temporarily removed from the system. When the interference falls below this threshold the repeater will return. This happens very rapidly. Dealers should estimate the level of interference and set this level accordingly; setting the level too high will result in wanted signals not being received when interference is present, whereas setting the level too low will result in a loss of channel capacity. This is a channel-wide feature.

 

[Mars]

Nice to see them clarifying this. Hopefully it resolves many issues and headaches down the road.

 

[Bill_G]

We've been bit by this too. You were not the only one to mis-apply the setting.