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.
