Today, Mark, N5HZR, and Peter, N5UWY, again visited their vacation home, the repeater site.
New firmware was installed in the Arcom controller and a new, known config was loaded. The voice tracks that had been in the repeater controller previously may be there now, but it's not clear from the documentation how those are loaded using the current firmware and programming software so mark it as "maybe". Users may hear some testing to determin if those really did get loaded. If those voice tracks are there, expect to hear the repeater announce things like meeting reminders in the future. If not, there will have to be Yet Another visit to the site.
The ERROR ERROR message should be gone. The hang time after mobile stations unkey should be at 3 seconds. As always, the repeater time-out is set to 180 seconds (3 minutes) so remember to let the courtesy tone sound after the other station stops transmitting to ensure that the time-out timer gets reset.
2018-10-12
2018-10-11 - Serial is OURS!
(Special Correspondant, Mark, N5HZR reports ... )
After a couple more calls and emails to ARCOM’s guru Ken, we learned a couple of things.
First, to test the data connection without using the software provided by ARCOM, we can use PUTTY, or Hyperterm to send characters to the serial port. If we connect to the controller in a terminal mode, we can supply 'codes' as if we were DTMF'ing them into the repeater. To test from a PUTTY or similar session, we can type 11111, and the response should be a +.
If the controller understands the function, a + is returned.
If the controller doesn't understand the function, a - is returned.
Second, and more importantly, the serial transmission default information changed as of ARCOM version 7.60. The default was 9600,8,1,N. However, with the version that we received in our controller, 7.60 and following Ken changed the default to 57600,8,1,N. Ken said there was a nasty bug in the 7.60 software, and it was pulled from production and replaced with 7.61. He also said that the desktop shortcut issues that we found with 7.61 were a known issue, and he fixed that in the most current 7.67 version. Ken said that the software should automatically select 57600 baud, but from our previous visits, we knew that the computers were using 19200 baud.
So, what this means is that we’ve been using 19200 baud for a couple of months when the controller was expecting 57600 baud.
Thunderstorms, bad weather, and Hurricanes Florence and Michael slowed down the next trip to the repeater, but Mark, N5HZR, found a beautiful weather day on 10/11/2018 and stopped by the repeater site on the way into town at 9:28 am. He connected the computer and the USB Serial cable. The USB serial connector showed up on COM7 and changed the baud rate from 19200 to 57600. This connection still did not work. Mark opened the controller, flipped the TX/RX connector around, and opened the program one more time.
This time the software was able to download the information. Mark saved the .dat file and the .log file that detailed the errors in this configuration. For good luck, this process was repeated and create a second set of files. One push of the button set the clock in the controller to the computer’s time. Mark put the cover back on the controller, unhooked the computer, verified that the APRS repeater, the UHF repeater, and the VHF repeater all worked. A quick 15-minute visit and the serial data has now produced a good .dat file.
After dropping off the key, and driving down the road, the controller ID’d properly. At 10:00, the controller came on and said “error error 10:00”, which meant the clock reset worked.
Later in the day, Mark emailed the .dat and the .log files to Peter, N5UWY, for him to review, and readjust. His initial reply was that the macros didn’t update properly and a couple of wav files got ‘lost’ during the update. Peter has copies of the wav files. Since Peter now has a ‘current state’ document, he’ll try to do some tweaking over the air to remove the “error error” macro. When Peter reworks the controller, we’ll load in the new config.
2018-08-09
8/8 Update
It's the 30th anniversary of the first night game in the Friendly Confines of Wrigley Field in Chicago. The game was called due to rain and was replayed on 8/9. Many remember the "8/8/88" thing but forget that it was a rain-out.
The SCARS Tech Committee was almost rained out, or more accurately, lightning-ed out on their trip to the repeater site today. However, the electrically charged clouds moved out and even the rain clouds were largely gone before the task force arrived at the site.
Unfortunately, the changes we made a couple months ago had no effect on the interference we've been suffering on the VHF system (147.06 MHz). So today, the loaner duplexers (thanks to N5MS) were removed and replaced by the club's WACOM duplexer. While there, the NORMAN APRS digipeater was also placed back in service.
We had also removed the Arcom RC-210 repeater controller (the device that gives us the auxiliary functions) as part of the diagnostic process. While it was out, we had it updated by the vendor with their now-standard more capable CPU. Embedded CPUs in this type of situation have built-in RAM and the new unit has a lot more of that (I don't have numbers) meaning more possible functions - the software author had run out of space in the old CPU's memory. The real-time clock module was also "flashed" (new firmware) which hopefully means that the clock (and therefore the scheduling features) will work correctly now - the clock was a poor time-keeper in the past which is why it had been shut off.
Unfortunately, we were unable to communicate with the controller over its serial console which means we couldn't pull the config that's in there (to make sure it was correct and as we expected) nor could we properly set the clock - you'll probably note that we've moved to the Pacific Time Zone. We'll get back out there in the near future and see if we can't beat it into submission.
In the meantime, the interference is still a problem.
The SCARS Tech Committee was almost rained out, or more accurately, lightning-ed out on their trip to the repeater site today. However, the electrically charged clouds moved out and even the rain clouds were largely gone before the task force arrived at the site.
Unfortunately, the changes we made a couple months ago had no effect on the interference we've been suffering on the VHF system (147.06 MHz). So today, the loaner duplexers (thanks to N5MS) were removed and replaced by the club's WACOM duplexer. While there, the NORMAN APRS digipeater was also placed back in service.
We had also removed the Arcom RC-210 repeater controller (the device that gives us the auxiliary functions) as part of the diagnostic process. While it was out, we had it updated by the vendor with their now-standard more capable CPU. Embedded CPUs in this type of situation have built-in RAM and the new unit has a lot more of that (I don't have numbers) meaning more possible functions - the software author had run out of space in the old CPU's memory. The real-time clock module was also "flashed" (new firmware) which hopefully means that the clock (and therefore the scheduling features) will work correctly now - the clock was a poor time-keeper in the past which is why it had been shut off.
Unfortunately, we were unable to communicate with the controller over its serial console which means we couldn't pull the config that's in there (to make sure it was correct and as we expected) nor could we properly set the clock - you'll probably note that we've moved to the Pacific Time Zone. We'll get back out there in the near future and see if we can't beat it into submission.
In the meantime, the interference is still a problem.
2018-05-03
Still Fighting ...
But is it a good fight? Ahhh ...
The fight with VHF repeater continues. On April 11, 2018, the RC-210 controller was removed from the repeater (that's why there is no courtesy tone). There are actually two auxiliary receivers connected to that controller and while it was unlikely that this was injecting the interfering signal into the system, it was easy enough to remove it to test. Removing the controller was not expected to magically fix everything, and it didn't, but it did give us some more data - in the interval between a mobile unit unkeying and the repeater's transmitter dropping, the "other" signal was apparent. That's the good news. The bad news is that the signal is probably the repeater's transmitter on 147.0600 MHz.
The duplexer (not diplexer) is the filter that is supposed to keep the repeater's receiver from hearing its own transmitter. This is no small trick given that there is a 25-W signal on 147.0600 MHz and the repeater is trying to listen for signals 600 kHz away (147.6600 MHz) that are in the microvolt range ... at the same time ... on the same feedline and antenna.
Miraculously (or maybe not if you know N5MS), Mike had a duplexer "in stock". The unit was tuned up on "66/06" (that's how hams 40 years ago described a repeater - input/output) and placed in service today by N5HZR and N5UWY. If this "cures" the problem then the next steps are pretty clear. Note that in the repeater rehabilitation work that the Technical Committee has done over the past several years, the duplexer was the only component not replaced.
Unfortunately, in order to install the temporary duplexer, the NORMAN digipeater (on the APRS frequency of 144.3900 MHz) was removed from service. The digipeater shares the VHF repeater's antenna and feedline by use of a multi-coupler (similar to a duplexer - a tight filter that keeps 147.0600 MHz RF away from 144.3900 MHz). This is unfortunate for a couple reasons - 1) APRS users are deprived of a high-site digipeater and 2) it's possible that the digipeater itself was an issue (it's not at all clear that it was).
Time will tell if this is the "cure."
The fight with VHF repeater continues. On April 11, 2018, the RC-210 controller was removed from the repeater (that's why there is no courtesy tone). There are actually two auxiliary receivers connected to that controller and while it was unlikely that this was injecting the interfering signal into the system, it was easy enough to remove it to test. Removing the controller was not expected to magically fix everything, and it didn't, but it did give us some more data - in the interval between a mobile unit unkeying and the repeater's transmitter dropping, the "other" signal was apparent. That's the good news. The bad news is that the signal is probably the repeater's transmitter on 147.0600 MHz.
The duplexer (not diplexer) is the filter that is supposed to keep the repeater's receiver from hearing its own transmitter. This is no small trick given that there is a 25-W signal on 147.0600 MHz and the repeater is trying to listen for signals 600 kHz away (147.6600 MHz) that are in the microvolt range ... at the same time ... on the same feedline and antenna.
Miraculously (or maybe not if you know N5MS), Mike had a duplexer "in stock". The unit was tuned up on "66/06" (that's how hams 40 years ago described a repeater - input/output) and placed in service today by N5HZR and N5UWY. If this "cures" the problem then the next steps are pretty clear. Note that in the repeater rehabilitation work that the Technical Committee has done over the past several years, the duplexer was the only component not replaced.
Unfortunately, in order to install the temporary duplexer, the NORMAN digipeater (on the APRS frequency of 144.3900 MHz) was removed from service. The digipeater shares the VHF repeater's antenna and feedline by use of a multi-coupler (similar to a duplexer - a tight filter that keeps 147.0600 MHz RF away from 144.3900 MHz). This is unfortunate for a couple reasons - 1) APRS users are deprived of a high-site digipeater and 2) it's possible that the digipeater itself was an issue (it's not at all clear that it was).
Time will tell if this is the "cure."
2018-01-27
Repeater Site Expedition Report - 2018-01-27
A number of us visited the county yard on Friday the 26th (N5UWY, KD5UGO, N5HZR, W5HLG, WE5Z, WB5ULK, AG5DB, AG5LB, KB5LSB). We looked only at the VHF system and not the UHF system.
A couple of numbers for posterity:
KD5UGO provided several tons of test equipment and knowledge to operate it. We looked at the parameters quantified above.
We listened to the input frequency through the duplexers as well as straight from the antenna and we were looking at it on the spectrum analyzer at the same time; No unusual signals were heard or seen, only the signal of the HT (or the service monitor) we were using to key the repeater.
We "swept" the Bp (Tx) and Br (Rx) sides of the duplexer and found no anomalies. Yes, we wiggled wires and tapped on connectors while watching signals, none of which had any effect. We checked their tuning and were able to coerce another 2 dB of rejection from the receive side (I do not have the initial or resulting values, only the 2 dB difference). We saw no evidence that the transmitter on 147.06 was being heard by the receiver on 147.66 via the antenna system.
Bottom line: No Trouble Found.
Clearly, there is a signal from somewhere mixing with the signal being received from stations trying to use the repeater. None of the tests we did yesterday revealed the source of that signal. In fact, we saw no evidence of another signal. But it's there because we heard it on repeated stations within an hour of our visit. It's real, we just have yet to find it.
A couple of numbers for posterity:
- Squelch opens at 0.2 μV.
- Full quieting is reached at 1.0 μV
- Modulation bandwidth is 9 kHz
- Deviation of repeated stations is 3.5-4 kHz
- Transmitter frequency error +30 Hz
- Power output is 20 W
- 70 dB reject on transmit.
KD5UGO provided several tons of test equipment and knowledge to operate it. We looked at the parameters quantified above.
We listened to the input frequency through the duplexers as well as straight from the antenna and we were looking at it on the spectrum analyzer at the same time; No unusual signals were heard or seen, only the signal of the HT (or the service monitor) we were using to key the repeater.
We "swept" the Bp (Tx) and Br (Rx) sides of the duplexer and found no anomalies. Yes, we wiggled wires and tapped on connectors while watching signals, none of which had any effect. We checked their tuning and were able to coerce another 2 dB of rejection from the receive side (I do not have the initial or resulting values, only the 2 dB difference). We saw no evidence that the transmitter on 147.06 was being heard by the receiver on 147.66 via the antenna system.
Bottom line: No Trouble Found.
Clearly, there is a signal from somewhere mixing with the signal being received from stations trying to use the repeater. None of the tests we did yesterday revealed the source of that signal. In fact, we saw no evidence of another signal. But it's there because we heard it on repeated stations within an hour of our visit. It's real, we just have yet to find it.
Subscribe to:
Posts (Atom)
