November 29, 2004

Loose Belt possibly tightened

Greetings,

On Saturday the first attempt was made to cure the 145.27 system (linked into the wI0OK system) of the intermittant 'loose water pump belt' sound. With careful consideration, the prime suspect was the Echolink equalizer box portion of the 145.27 controller. It was noted that the past month or two the 'canned speech' from the Echolink software was unusually 'tinny' and 'sharp' (having considerable high frequency audio energy). Perhaps the pre-emphasis circuit in the interface had a component failure and was on the edge of oscillation.

I reduced the amount of equalization tilt in the interface, which brought the Echolink status announcements into a more pleasant sounding state. While at the site, varioius audio adjustments were made (some of which later had to be undone on 11/28). Frequencies were checked and adjusted as needed, with the exception of the 52.42 receiver which (like the receiver in Empire) was found to be on 52.419.

It was noted that there's a 'ping-pong' that sets up when Echolink is connected to certain systems (the test server and WA5KUB sites had this) that appears to be related to the speed at which the COS signal from the Echolink software progresses through the linking system. When Echolink unkeys there is a slight delay before the PL decoder unkeys at the W8TVC 444.725 receiver used for the Empire-->TVC portion of the link. This slight delay is enough to trigger a transmission via Echolink to the remote node, which sometimes is mysteriously bounced back. The bounce-back from the remote site was not noted in connections to the K2TC node, which seemed to ignore the momentary echolink keyup. This problem is still under investigation.

Another Echolink problem was noted and solved. Interestingly, with the addition of the '#' command to the Empire system for use in disconnecting the W8TVC echolink node, users on 145.27 were unable to disconnect the echolink connections. A station on 145.27 would hit the '#' to disconnect, and their # would register in the Echolink computer, but their # would also propagate through the links to Empire where it would be regenerated on the 444.725 transmitter, and then decoded by the same Echolink computer and added to the other '#' that was entered. Effectively, hitting a single '#' on 145.27 would enter a '##' command on the Echolink computer. [Note that hitting '#' from 444.725 or 52.92 worked as expected, entering a '#' command on the Echolink computer.]. Because of this code conflict, the Empire repeater Echolink disconnect code was changed to a '*'. Users on 440/6m need to enter a '*' to disconnect Echolink connections from the W8TVC node. Users on 145.27 can use either a '#' or a '*' to disconnect the Echolink node.

While working on Echolink, there were two other code conflicts that were changed to eliminate potential problems. Sadly, users from 145.27 will find conflicts with entering the commands to put the Empire remote base on 146.52 or 146.76, as these would simultaneously initiate Echolink connections in addition to linking on two meters. Most all of the other commands to the Empire repeater (when entered on 145.27) would generate the begnign 'not found' response from the 145.27 Echolink computer.

FYI--- at the antenna terminal of the 145.27 duplexer the power level was measured at approximately 75 watts.
The 440.05 transmitter was measured at the transmitter output to be approximately 9 watts.

While at the Empire site it was noted that there is an irregularity in the audio system that causes random (one in every ten) audio level jumps of about 6db. These level fluctuations were not localized to any input and appeared on both outputs (unknown if simultaneously). There was nothing noted to affect the levels by physical shock or 'therapeudic touch'. Approximately 3-4db of gain was added to the 440 and 6m transmitters, as the more commonly found audio levels were below optimum by about 6db. The current adjustments 'split the difference' so that should the audio jump to the higher level, it will be 'hot' but not overtly so, and when the audio is on the more common lower level it will be lower than optimum but within reason. The repair for this will likely be time consuming and involve removing the controller to the workbench for a few days-- a project for the spring, not right now.

Additionally, the 6mtr voter appears to be having a problem voting. Perhaps a hanging chad is gumming up the works, perhaps it's detected voter fraud. Either way, it seems to not always want to vote as it should and can leave the audio of the poorer receiver switched into the system. I had not brought adequate documentation to deal with this unexpected problem with todays trip. This may or may not be resolved quickly.

Finally, the command to initiate an Echolink connection to the WA8ZWJ 442.85 repeater has been put in the system with the Echolink node of '9999' setup temporarily. This will allow for connections to the test server until ZWJ's repeater is equipped with Echolink.

More news as it's available.

73
KF8KK



November 25, 2004

Firmware 4.29G -- 220 audio

Greetings!

Today a new version of the firmware [program code 4.29G] for the RC210 was installed. This version includes a fix for the audio muting problem on the remote base port when it decodes a DTMF tone.

Additionally, the audio and PL levels for the 220 transmitter were set to be as near 'optimum' as possible at the moment.

Sadly, it appears that the weather receiver audio isn't making it through the system when it should. The weather alert alarm function appears to be working, and there is audio coming out of the receiver itself. It could be either a relay contact in the receivers audio path (yes, there's a relay in there) or an error in the program code for the repeater controller (just as possible). I didn't have the proper tools to diagnose this at the time and it will have to wait for my next trip to the site-- whenever that may be. Since the alarm function is still functional, that's the important part (most modern mobile transceivers have weather radio reception capabilities), it's less important to actually be able to rebroadcast the weather on the repeater as it is to alert users that bad weather is on the way.

With any luck, this hopefully will be the last repeater maintenance at the Empire site for this year. We'll see...

73
John KF8KK

November 23, 2004

220 link repaired

Today I found that the PL encoder on the Icom IC37A 220 transceiver had apparently ceased to encode tones. While I would have preferred to repair the internal encoder in the transceiver, it was a more timely and quick repair to insert a ComSpec TS32 encoder inside the unit. The unit is now working, but in operational testing after leaving the site the audio on the transmitter is a bit too 'hot'. I'll get back to the site and turn that down soon.

Sadly, during a qso, it appeared that the COS from 220 worked as it should but for that one transmission the audio crosspoint never opened up the audio-- dead carrier with PL on 444.725 and 52.92. Harumph.

In related news, on Sunday 11/21, Keith WA8ZWJ was given the 'repeater tour' and we also upgraded the RC210 controller to the latest firmware 4.29E.

73 KF8KK

November 12, 2004

Winter Maintenance Update

Greetings!

Today was a fairly cold day and so I decided to take Johnny KG8CU's Motorola service monitor to the site and check and adjust the frequency settings to put the system in 'winter' mode. FYI-- both the 444.725 and 52.92 transmitters drift DOWN the band with heat. They both were adjusted a half kHz high at rest so that as the rptrs get used they should slowly drift through the correct frequency. No major surprises were found in the tests/adjustments (they were incredibly close to where they should be which was a small surprise). Sadly, the 52.42 receiver crystal needs to have the trim cap in the channel element changed as it's about 1khz low with the adjustments max'd out. CTCSS encode levels were also checked and found to be within tolerance.

I also uploaded the latest RC210 firmware 4.29A and did some minor housekeeping on the programming.

Included with the programming was commands to initiate Echolink connections to the WA5KUB and K2TC (Memphis and New York City) repeaters via the W8TVC Echolink node. These two commands (and the requisite disconnect command) was tested and worked great.

Within the few days before this update the backup battery was fully charged up.

This evening Mike N7LMJ was given the full 'repeater tour' and markings were placed on the cabling involved in switching the system to the backup controller to make it easier to switch controllers.

On Thursday, 11/11, an odd unstable audio oscillation was heard on signals coming in on the link from the W8TVC site. This oscillation appeared to be steady when it appeared, and change pitch on unkeying, but it was not present when I was at the site to look into it. When the oscillation was heard it was the first cold day of the season, though the evening when I was at the site doing mtce was yet colder. It's been a few days since the tone was heard and it has not reappeared.

Today the documentation was updated and backup CD's were created.

73
KF8KK