2011-11-06

Repeater Status Update - November 6

Your SCARS Technical Committee has not been having fun over these past few weeks.  About the end of September, the crunch monster returned to the VHF repeater.  Since then, things have become less-fun. 

There are two things going on; RF issues and controller issues. 

RF

Signals are appearing in the repeater that are unwanted.  Sometimes, these signals are retransmitted by the repeater because they act like signals that we would want repeated.  There are at least two different (at least, they seem to be different) scenarios. 

The first scenario is a mixing product getting in to the UHF link that brings the signal from the stadium receiver to the main site.  This happens when two or more transmitters' signals heterodyne together to create signals at other frequencies.  It's how a superheterodyne receiver functions!

In our case, one of the transmissions was easy to ID: it's the club's UHF repeater!  You can, at times, clearly hear either the voice ID from the CAT200 controller or the voices of club members chatting (Hi Gordon!  Hi Michael!  Hi Allan!). 

What's harder to hear -- and ID -- is the second signal.  It's there, but so far no one has been able to identify it.  It's definitely not another amateur signal and so far it has not sounded (to this 30-year scanner listener) like a public safety signal.  Perhaps a local government agency or a commercial repeater?

No idea what (fundamental) frequency it is on since we have yet to ID it, but one of the mixing products is entering the VHF repeater via the UHF link receiver and being repeated.  You can tell that's how it's getting in because the stadium link courtesy tone is sent at the end just as if a station was transmitting into the remote receiver at the stadium and being relayed through that same receiver. 

The other scenario appears to be the repeater "hearing itself".  This is more along the lines of the traditional "crunch monster" that has plagued our repeater for years (long before the recent technology refresh).  The noise usually appears while, or just after, the repeater is in use.  It sounds a little like what happens when you you key up an HT while in audio range of another HT and the audio bounces around between the two.  The difference in this case is that the transmitter and receiver make up the repeater and not a pair of HTs.  This scenario is why the hang time was dropped to zero seconds (see below).  And that actually seems to have helped a little.

One thing argues against this strictly being the repeater "hearing itself": sometimes it happens when the repeater is otherwise quiet and hasn't so much as IDed itself in some time.  We may find that the two scenarios have the same root cause. 

Root causes for either of these scenarios have yet to be definitively determined nor has a course of action been decided. 


Controller 

In order to try to make the repeater less annoying, the hang time of the repeater was set to zero by entering a control code on the controller.  Macros were created to set and unset this, but those macros do not function (and the vendor is stumped as to why).  Instead, the hang time was set to zero seconds manually. 

The hang time is the period of time from the squelch closing on the repeater's receiver (because the user unkeyed) and the repeater's transmitter dropping.  Ordinarily, this is set to about 3 or 5 seconds.  With it set to zero you hear that double chunk at the end of a transmission instead of a proper courtesy tone (no idea why there is a double chunk, but there it is).  This change has seemed to help, at least a little, with the "crunch monster" noise. 

As members have heard, somehow the macro that announces the upcoming meeting  when it's at City Hall has decided to run.  It's not being run by the Set Point, a scheduler feature that runs the macro at the top of each hour the week before a meeting, because those have all been cleared.  Possibly, it is running as a "tail message".  The tail message was never intentionally set to do this, but there it is. 

At the time of this writing (Sunday afternoon), both the tail counter (where the number of "overs" that happen before the announcement is set) and the tail timer (where the announcement runs so many minutes after the last transmission is set), have been "zeroed out".  Hopefully, this "fixes" that issue. 


So ....

We're still in the evaluation stage.  Likely, there will be a site visit in the coming week.  If the most recent changes did not effect the controller issues, we will probably replace the controller in order to bench-test it and, possibly, return it to the vendor for evaluation.  The committee is also identifying the testing equipment that it has as its disposal, which turns out to be substantial.  Before embarking on a visit to the site, a test plan will be in place.  What is done after that depends on what is discovered!

The Technical Committee wishes to again thank members for their patience!