Thanks again to all on the reflector who have continued to work with me and
offered numerous suggestions. None of them worked, I'm afraid, at least out
of those I have picked up so far, but nevertheless I did get some
interesting and useful information.
The solution turns out to be not terribly obscure, once you start thinking
like a programmer (at least in regards to things technical). When the KAM
is first powered on, it can come up in one of several different states. The
initial character string it sends to the serial port, and the commands it
will accept back, depend on what that initial state is. In what I think of
as the "normal" command state, which is referred to in the manual as the
Terminal state, it starts off by giving a copyright notice for the firmware,
then the command prompt "cmd:". At that point, the software would simply
issue the string "IN HOST" in order to place it into Host mode. What I
discovered, though, is that is not what RTTYrite is expecting. It seems to
work only if the KAM is in RTTY mode when it comes up. There, the initial
string displayed is something like "-RTTY 45-" and the firmware will look
for "CTL-C X" on the line before it will accept a command--like the "IN
HOST" command I mentioned above. It can also come up in several other
states. I haven't bothered trying, but I'll bet RTTYrite can't handle them
either. To be really bulletproof, the software would have to look for any
of these states, take it back to the Terminal state if necessary, then put
it into Host mode. But that's not the way it is. So if you ever hear
somebody else having this problem, the only solution is to grab a dumb
terminal and set the TNC into RTTY mode before turning it over to RTTYrite.
Problem solved...now on to the next one.
73,
Bruce, ZF2NT
|