TRLog
[Top] [All Lists]

[TRLog] TRLog in the RTTY Sprint (long)

Subject: [TRLog] TRLog in the RTTY Sprint (long)
From: ve3iay@rac.ca (Richard Ferch)
Date: Sun, 14 Oct 2001 21:53:02 -0400
Some notes on my experiences setting up and using TRLog in the RTTY Sprint
this weekend. This message is long. If you're not interested in using TRLog
for RTTY, you might as well stop reading now!

1. Why use TRLog on RTTY?

That's a good question.

There are several free sound-card RTTY programs available, including MMTTY
(www.qsl.net/mmhamsoft/mmtty/), but although they usually have some kind of
contest logging capability, it doesn't come close to TRLog's.

On the other hand, with TRLog you have to use a TNC. It may be possible to
use MMTTY in its KAM emulation mode with TRLog. I haven't tried this, but I
understand some people have made it work with WF1B RTTY.

This raises the question: why not use WF1B RTTY (available free from
www.rttyinfo.com)? WF1B RTTY has a major advantage over TRLog, and that is
that it detects call signs in the incoming data, dupe checks them, and can
transfer call signs and exchanges automatically from the input window to the
log. WF1B RTTY also knows about the exchanges and scoring for most RTTY
contests. On the other hand, I don't find it quite as easy to use as TRLog
is, particularly in the Sprint, where TRLog's automatic switching between
run and S&P modes can save you from having to think (always a good feature
in a fast-paced contest!).

Then there are the Windows contest logging programs, Writelog and N1MM
Logger. I have used Writelog, but somehow it has never quite clicked with me
(sort of like CT - I'll use it if I have to, but given my druthers,
I'druther use TRLog). And the free N1MM Logger software is still in
development. Reading the messages on the reflector for this new program
makes me uneasy about trusting it in a contest, but with several more RTTY
contests this fall, I'll probably try it out in one of them.

Let's just say that I wanted to give TRLog a try on RTTY, and the RTTY
Sprint seemed like the ideal place.

2. How do you set TRLog up for RTTY?

Let's assume you already have a TNC or TU hooked up to a serial port, so the
question really is: how do you set up LOGCFG.DAT to use the TNC?

I started out from my LOGCFG.DAT file for the CW Sprint. First, you need to
add the following two lines:

DIGITAL MODE ENABLE = TRUE
RTTY PORT = SERIAL 1

assuming your TNC is connected to COM1. As far as I can tell, the RTTY port
in TRLog is fixed at 4800 baud, so you may have to reprogram your TNC's data
rate to match (unless it has an autobaud feature).

You should probably add:

BAND MAP ENABLE = FALSE
VISIBLE DUPESHEET = FALSE

as the TNC incoming and outgoing data uses up the space where either of
these would appear. It may be possible to have two of these windows active
in the same LOGCFG.DAT file, but my guess is that you would have on-screen
interference between the visible dupesheet and the TNC window. In a
multi-mode contest like Field Day, you might want to use the band map in CW
and SSB, and only have the TNC window active in RTTY, but this may be one of
those "rough edges" that only sort of works.

Add:

LEADING ZEROS = 3
LEADING ZERO CHARACTER = 0
SHORT INTEGERS = FALSE

so your serial number exchanges come out as expected (cut numbers or short
integers like ATN for 109 don't make any sense in RTTY). Three-digit serial
numbers take marginally longer than shorter ones, but they are more
predictable and stand out better in noisy conditions.

The next set of changes applies only to the RTTY Sprint, not to other RTTY
contests. This is because you are allowed to work dupes in this contest,
provided there are at least three intervening QSOs in both logs (what I did
during the contest was check whether the call sign was visible in TRLog's
on-screen log window, figuring that if it was, we were too close - that beat
figuring out whether there were 2, 3 or 4 intervening QSOs).

AUTO DUPE ENABLE CQ = FALSE
AUTO DUPE ENABLE S AND P = FALSE
SPACE BAR DUPE CHECK ENABLE = FALSE
DUPE SHEET ENABLE = FALSE

There will also be changes needed to the various memories and messages, but
I'll leave that for the moment. First, we need to make sure that the
hardware setup will work.

3. Checking out the hardware

For various reasons, I run TRLog in a DOS box under Windows 98. I'm not sure
why this is, but many DOS programs (including TRLog and WF1B RTTY) don't
seem to be able to see the serial ports on my machine unless I
"precondition" the ports by running yet another DOS program, Hyperlog,
first. If I don't run Hyperlog first, TRLog will freeze on startup when it
fails to find the radio interface. Sometimes Hyperlog fails on the first
try, too, but somehow a second try with Hyperlog always works, where a
second try with the other programs does not - don't ask me why, ask
Microsoft. If I run a Windows program that uses the com port in question,
then I will have to repeat the preconditioning step before running TRLog.
For all I know, I'm the only person in the world with this particular
problem, but anyway...

Use Alt-M to change modes until you are in digital mode. That switches my
TS-850 into FSK mode. I don't know whether TRLog can support AFSK. (Tree:
would it be possible to implement an option that would put the radio into
either USB or LSB when TRLog is in digital mode, for thsoe who want to use
AFSK?). By the way, for some reason the band up and band down commands
(Alt-B and Alt-V) don't work in digital mode. You can either do your
bandswitching on the radio, or change to CW or SSB to switch bands, then
change back to digital.

If you've got the serial ports working, when you switch the TNC on you
should see something, even if it's only rubbish, in the TNC window. When you
press F10 when TRLog is in digital mode (as distinct from CW or SSB),
anything you type after that is sent to the TNC. This includes the Enter
key, which does not terminate keyboard input (unlike CW). This is a good
thing, because you will probably need to be able to send a carriage return
to the TNC without terminating the keyboard input. The only way to terminate
keyboard input is to press the Esc key (F10 doesn't take you out of keyboard
input).

With my MFJ-1278, after pressing F10 and turning the TNC on, I have to press
Enter a few times to get the TNC to recognize the baud rate. I then enter
the commands needed to put it into the correct configuration: MODE HB, 45 to
select RTTY, RADIO 2 to select the HF radio, and K to take the TNC out of
its command mode, before pressing Esc. Other types of TNC or TU will have
commands with similar functions, as appropriate. You may have to specify the
RTTY SEND STRING and RTTY RECEIVE STRING parameters appropriate to your TNC
as well. The defaults work with the MFJ.

If all this works, you should be able to tune to an RTTY signal and see it
in the TNC window. One very nice feature in TRLog is a small window at the
bottom that shows the same incoming characters in the other figures/letters
mode. This will translate all those annoying TOO PPQ exchanges that happen
when the sent FIGS character is hit by noise into 599 001 and so on.

To transmit, you can just hit F10 and start to type. Press Esc to go back to
receive mode.

4. Programming TRLog's memories

There are two aspects of RTTY that are different from CW and affect how you
program the memories.

The first is that when there is no signal, the other guy's TNC will probably
convert random noise into random characters, or "garble". To separate your
message clearly from the garble, it's a good idea to start and end your
messages with a space or two, or even a carriage return. TRLog ends its
messages with a carriage return, but the RTTYer's habit of ending all
messages with a space and one or two K's is probably not a bad idea either,
in case the CR gets hit by a noise burst. It's also a good idea not to make
your messages too short, or they will be lost in the garble.

The second is that there is no way to identify who sent a message from the
sound alone, as there often is in CW. This suggests that more messages
should include your call sign than would be the case in CW.

In CW, you can begin and end messages with _ to force TRLog to insert a
space. Unfortunately, this doesn't work in RTTY; the _ is passed through to
the TNC, which will probably ignore it (there is no such character in the
Baudot character set). Some of the other special characters used in CW
messages don't work either ( ^, +, <, =, ! and &). The control characters in
Table 3 of the manual seem to work, but the ones to control speed, weight
and various length dits and dahs do not work. They are passed on unchanged
to the TNC, and may have undesired effects, so it is best to remove them
from the programmed messages.

You can insert special characters in CQ MEMORIES F1-F9 and EX MEMORIES F3-F9
by using the <xx> syntax. I have found <20> (space) and <0D> (carriage
return) to be useful. However, these do not work in the "Other" messages
(Alt-P-O menu); they get passed through to the TNC, except for the > which
zeros your radio's RIT.

Some useful messages from my RTTY Sprint config file:

CQ EXCHANGE = DE \ # name state K
(in some software, the DE tags the following word as a call sign, which can
speed up the other guy's response, and the trailing K separates your
exchange from garble. TRLog automatically sends the other station's call
sign and a space before this message.)
S&P EXCHANGE = @ NR # name state DE \ K
QSL MESSAGE = @ QSL DE \ QSY K
(unlike CW, where a simple EE or R or TU will do the job, in the RTTY Sprint
most stations were using some variant on the above QSL message. In a
non-Sprint contest, you would put QRZ? in place of the QSY).
CQ MEMORY F3 = <20>) NR # # name name state state DE \ K
EX MEMORY F3 = <20>@ NR # # name name state state DE \ K

The reason for the last two is that the F2 exchange memory does not work in
TRLog's RTTY mode. That means there is no way to send the REPEAT S&P
EXCHANGE. My solution to this problem was to program it into the F3 memories
as above.

I also programmed short messages to resend the exchange elements into EX
MEMORIES F4-F6, and queries asking for repeats of the same elements into CQ
MEMORIES F4-F6. That took care of most requirements for fills, and you can
take care of the rest (questions in EX mode and fills in CQ mode) with
ALTF4-ALTF6. As usual, in both EX and CQ I used F9 as a general repeat
request.

The default CQ messages in CQ MEMORIES F1 and F2 needed a bit of work. The
Alt-A and Alt-B don't do any harm (they're there for SO2R), but the Alt-F
and Alt-S should be removed, and the ^ changed to a full space.

5. During the Contest

I changed the font in the DOS window to a size that left a bit of room on my
screen (6x10), and substituted single-prescription reading glasses for my
normal varifocals so I could read the computer screen better. Then I opened
up MMTTY and sized its window to fit beside the TRLog window. That gave me
some additional tuning aids, as well as two different decoders working on
the same received signal. Most of the time, if one of them garbled the
incoming signal, the other one supplied the missing information, and if not,
well, that's when you ask for fills.

Overall, I'm pretty happy with the way the computer setup worked (how the
rest of my station works in the Sprint is a different story!), except that I
wish the F2 function key in exchange mode worked the way it does in CW. I'll
probably use this setup again in other RTTY contests where TRLog can handle
the scoring. If there are any with unusual scoring (ANARTS springs to mind),
well, I still have a copy of WF1B RTTY, and I can try to set that up to work
as similarly as possible to TRLog.

6. After the Contest

I had
LOG FREQUENCY ENABLE = TRUE
and
SHOW SEARCH AND POUNCE = TRUE
in my config file, as I find the information they add useful for analysis.

To remove the effects of the first one, I ran POST /L/C and renumbered the
QSOs. I then renamed the original LOG.DAT to LOGFREQ.DAT, and the new
LALLBOTH.DAT to LOG.DAT. Then I ran POST /C to produce the Cabrillo file
LOG.CBR . One tiny fixup: the CONTEST: line in the Cabrillo file produced by
POST read NA-SPRINT-RY. There is no name specified for this contest in the
official Cabrillo spec, but the WT4I Cabrillo tools software uses
NA-SPRINT-RTTY, as does some of my own log processing software, so I edited
the file to make this change.

To get my contest log into my general station log, I used two more programs.
CBRFRFIX puts the frequency information from LOGFREQ.DAT back into the
Cabrillo file, and CBR2ADIF converts the Cabrillo file into ADIF, while
adding a few fields that aren't in the Cabrillo file. These programs are at
http://www.storm.ca/~ve3iay/cbr2adif.html, if anyone is interested. The
version of CBR2ADIF that was at that site before this morning doesn't handle
the received name properly in the RTTY NA Sprint, but that bug has now been
fixed.

If you're still reading, I hope you found some interesting tidbits in this
message.

73,
Rich VE3IAY



--
FAQ on WWW:               http://www.contesting.com/FAQ/trlog
Submissions:              trlog@contesting.com
Administrative requests:  trlog-REQUEST@contesting.com
Problems:                 owner-trlog@contesting.com
Feature Wishlist:         http://web.jzap.com/n6tr/trwish.html


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