Repeater Site Expedition Report - 2018-10-18

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-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.

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.