Well, just wanted to give a quick update to this issue. Looks like from info supplied by Trident that we have to totally initialize (wipe) each and every controller first as a stand alone unit and then again connected together as a system and reprogram the master controller and wait for the data to populate along the data bus to the other controllers…which could take up to 45 minutes for a 20 channel system. Since this is only a 5 channel system we are estimating possibly 10-15 minutes. Of course not knowing if the corruption is due to hardware failure (failing) a spare controller has been ordered to have on hand. And will also be taking this opportunity to play around with this new spare controller to test the procedure that has been written up as well as learn more what the manual does not tell us. The fun will continue….updates to follow…

The other night came across a very unusual problem and behavior which was “masked” by other problems, and it was in the process of resolving these other issues that this real issue was discovered.

What started us down this path was an interference issue on Chan 4 Rptr due to a company 4 air miles away across the water from this system recently getting licensed for their Mototrbo system, a freq only 12.5 kHz away!

While monitoring the input and output rptr channels conventionally to determine the degree of interference it was discovered that at different seemingly random intervals there was a dead carrier on Chan 1 rptr.

Those familiar with LTR Passport know that when the channel is idle a “beacon” is sent out approx. every 2 secs for radios “homed” to that channel. When there is this dead air carrier there is no beacon so radios that are turned on during that period stay “Searching” because they do not see the beacon and therefore cannot register. Units that are already registered can complete calls without any issue BUT units that are homed to another rptr and their call has to be processed by Chan 1 Rptr during this dead air carrier time calls are lost but to the user there is not indication of a problem other than the person they are talking to not receiving their calls.

What we discovered is occurring once visiting the site is that when a call is processed on Chan 2 or Chan 3; Chan 1 rptr also keys during this period thus creating the dead air carrier.  It is not an RF issue but a logic issue as all LTR Passport repeaters share a data link via a “T-Net” data bus. Each rptr has its own Controller with one controller acting as the Master generating the sync, neither one of there three rptr channels are the Master.

So after serveral additional tests this data was referred to the manufacturer who currently does not believe this is occurring BUT says that if this actually occurring it is probably due to data corruption. The challenge is how best to “fix” this data corruption which unfortunately may require a total system rebuild. Thus I sit here now with the manual to get a deeper understanding to come up with the best way to approach this and correct this issue.

So anyone who is familiar with LTR Passport and has seen this behavior/phenomenon before with Trident Raider Xtreme Controllers any advise/suggestions are welcome.