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
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
posted by kf8kk at 1:19 AM
