TRLog
[Top] [All Lists]

[TRLog] TR and MMTTY

Subject: [TRLog] TR and MMTTY
From: ve3iay@rac.ca (Richard Ferch)
Date: Wed, 4 Sep 2002 22:20:15 -0400
On Tue, 3 Sep 2002 at 19:03:42 -0500, "Jimmy Floyd" <nq4u@bellsouth.net>
said:

> Has anyone found a way to use some of the sound card digital programs such
> as MMTTY or Hamscope with TR?

Hello Jimmy,

First: someone is bound to ask, why do this at all? Anyone who thinks it's a
waste of time is welcome to stop reading now, but just in case someone else
is interested: MMTTY's contest features are pretty rudimentary (macro
buttons and basic dupe checking), HamScope's are even less, and besides,
some of us who love TRLog REALLY love it and would rather do what it takes
to make it work than switch to some other contesting program. For some
folks, making things work is as much fun as operating. If you are not in
this group, you might take a look at the N1MM contest logger. I haven't been
able to get it to work with my TNC, but it works fine with MMTTY. It isn't
TRLog, though.

Next, a disclaimer: I haven't made this work myself, these are just some
ideas on how I would go about trying to do it. I have done something which
is about halfway there. In recent RTTY contests I have been using TRLog with
an MFJ TNC, with MMTTY set up in a separate window on the same computer and
used as a receive-only decoder (same audio signal as the TNC). I use the
information from both receive windows to decide what to type in the TRLog
callsign and exchange windows. Sometimes MMTTY works better, sometimes the
TNC, but the combination is better than either one alone.

OK, enough of that, let's get on with it. MMTTY has been used successfully
with WF1B RTTY, which is a DOS-based contesting program for TNCs (no longer
supported, but still available), so once that has been achieved, it would
seem to be possible to use TRLog instead of WF1B. I'll describe the WF1B
setup first, then go on to discuss some of the issues with using TRLog
instead of WF1B. BTW, the link given in the MMTTY help file for the WF1B
software is broken. If you're looking for it, try www.rttyinfo.net instead.

If you look in the MMTTY help file under "Use MMTTY as a Modem", you'll find
that MMTTY can be set up to emulate a KAM TNC. If you have two computers
available, you can set up one computer with MMTTY, using one or two COM
ports, one for the TNC output, the other optional one for PTT and FSK
keying. The other computer would run WF1B, again with two COM ports, one for
TNC input, the other for rig control. The two TNC ports are connected with a
null modem cable.

Alternatively, you can do it all in one computer, with up to four COM ports.
Two are absolutely necessary, connected using a null modem cable for the
TNC-to-WF1B connection. A third recommended one is for rig control, and the
fourth optional one is for PTT and possibly FSK keying. This latter
single-computer setup is described not only in the MMTTY help file (by KX2A
and W5YG), but also by GU0SUP at
http://www.guernsey.net/~pcooper/emulate.html . GU0SUP uses the fourth COM
port for a DX-Cluster connection. He doesn't say how he controls the radio's
T/R switching. He also describes using two monitors, one for each program,
but you can do it with only one monitor. MMTTY will still work even if its
window is partly covered.

Let's assume all of this works, but you want to use TRLog, not WF1B. What
are the issues?

First, TRLog is set up for an MFJ-1278 TNC, not a KAM. If you have access to
a KAM, you can try to eliminate some of the variables by getting it and
TRLog to work with each other, then transferring the KAM settings to the
MMTTY KAM emulator. If not, charge ahead anyway. What have you got to lose?
Your time, but as long as you're having fun that doesn't count as a loss.

You will have to change the RTTY SEND STRING and RTTY RECEIVE STRING to the
proper values for the KAM. I believe these are <CTRL-C>T and <CTRL-C>R, but
I'm not sure whether that's the correct syntax for the TRLog config file. It
may be <03>T for transmit and <03>R for receive (TRLog manual p.80). You
will also have to set the RTTY PORT to the COM port you are connecting the
null modem cable to.

You also have to make sure the two COM ports for the TNC are set to the same
settings in both MMTTY (or the KAM) and TRLog. TRLog does not give you
direct control over the RTTY port's settings. I believe they are fixed at
4800 baud, 8, none, 1, but I might be wrong, and you might have to play with
these at the MMTTY end to get things to work. You might also have to play
with the flow control. The examples I quoted above use XON/XOFF, but it
looks from the documentation as though you can either leave flow control
off, or else set MMTTY to CTS and then jumper CTS and RTS together on the
MMTTY end of the null cable (GU0SUP's recommended null modem cable has these
jumpered as suggested). TRLog doesn't use flow control, so it shouldn't
care.

In fact, you may want to try using CTS on the TRLog RTTY COM port as the PTT
control line (set KEYER OUTPUT PORT to the same COM port as RTTY PORT, and
instead of wiring pins 7 and 8 together on the TRLog end of the null modem
cable, bring pin 7 out to a keying transistor to control the radio's PTT). I
am not completely sure whether this will work. If not, you can try using a
second COM port from MMTTY as the PTT control port, or maybe a parallel port
from TRLog instead. Or, if you are using AFSK, maybe VOX will work for you
(it does on some radios, but not on others). Lots of room for
experimentation here.

Finally, TRLog reads the mode from the radio, and it may expect the radio to
be in FSK mode for digital contests. If you can transmit using FSK with
MMTTY, that shouldn't be a problem, but if you use AFSK, there might be
trouble. If worst comes to worst, you might have to turn off TRLog's rig
control. Since you can't use the bandmap feature in RTTY mode with TRLog,
all you will lose is the ability to log the exact frequency and, more
importantly, the assurance that TRLog will log all of your contacts on the
correct band. If you change the band on the radio and not the software, or
vice versa, you could end up out of sync, which you might discover only when
the dupe checking screws up as a result.

Why haven't I tried this yet? Inertia, I guess. What I've got already works
fine, so why change? Nevertheless, one of these weekends maybe I'll bring a
second computer into the shack and see if I can make this work myself. If I
ever do, I'll let you know how it pans out, and I'll look forward to hearing
from you if you get it to work.

73,
Rich VE3IAY



<Prev in Thread] Current Thread [Next in Thread>