Communications Support Forums
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:
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.
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:
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.