[TRLog] RTTY

[VR2BrettGraham]

Rich:

>I just got back home from a trip (had to miss the NAQP CW, unfortunately)
>and saw your message. I wonder whether you and I are the only ones using
>TRLog for RTTY? Of course, there are several alternatives (WF1B RTTY, N1MM
>Logger, Writelog, MixW, MMTTY, etc.), but if you're already comfortable with
>TRLog for CW contesting, it's nice not to have to switch to a different user
>interface for RTTY contests.
>
>Anyway, I think I have a solution for the most serious of the problems you
>mentioned, but complete resolution of the others may require some effort to
>fix the program.
>
> > Dunno why this didn't occur to me earlier, but at the top of each 
> minute, the
> > terminal window clears itself.  At first, I thought it was because of some
> > non-printing character coming from the TNC or that since the TNC doesn't
> > pay attention to line length & maybe it was TR just doing what it had 
> to do.
>
>This has never happened to me, and your message had me puzzled. Then it
>suddenly dawned on me: I'll bet you had the band map enabled. I tried a
>config file with both band map and digital modes enabled, and found that the
>band map refreshes itself at the top of every minute, wiping out the
>terminal window in the process. This happens even if the band map is empty.
>
>If my conjecture is correct, the solution is simple. Set BAND MAP ENABLE =
>FALSE in your config file and the problem should disappear. Unfortunately,
>that would mean you can't use TRLog's band map feature in RTTY contests.

My habit is to put everything into a single .cfg file for a contest & often 
start a
new contest by copying a .cfg file as a starting point.  That's why BAND MAP
ENABLE is in there.  Thanks for finding that.

Unfortunately, band map & RTTY are mutually exclusive in TR, due to the
terminal window occupying what should be the band map window.  It would be
really neat to have a band map in RTTY, I must admit.

> > After some time playing around, it's this bug, plus EX MENU not displaying
> > (when program switches from CQ to exchange mode as you're running
> > stations) & lack of a CALL OKAY NOW-like function that I would think, if
> > corrected, would make RTTY support in TR good enough for some serious
> > operating.
>
>Yes, for some reason the menu display seems to stick on CQ MENU while you
>are in exchange mode during a run. The function keys themselves switch, it's
>just the menu that doesn't, even though EX MENU works fine in S&P mode.
>Probably a simple bug to fix. In the meantime, programming the exchange keys
>to have similar functions to the run keys, with the exception of F1 and F2,
>is probably the safest bet to avoid confusion, although it is somewhat
>limiting.

That's been my workaround, though I've tried to push it & often goof up.

I suspect there may be more to getting EX MENU to display as the program 
switches
to S&P mode from CQ mode than we imagine - note how we don't get to CQ with the
<enter> key.

>As for the CALL OK NOW function, some of the automatic messages do not work
>in RTTY. In particular, neither the CALL OK NOW message nor the REPEAT S&P
>EXCHANGE message seems to work. Also, the @ and \ special characters are not
>translated in the QSO BEFORE message, even though they are handled OK in
>function key messages. Some other special characters, among them _, { and },
>are simply passed through to the TNC in RTTY, and do not perform the special
>functions that they are used for in CW messages. There may be a few other
>oddities like this. I would guess that the RTTY code in TRLog is pretty much
>a copy of the CW code with any features that were not absolutely essential
>left out. If that is the case, there may be some code from the CW interface
>that could be copied bodily into the RTTY part of the program to fix some of
>these anomalies without too much effort.
>
>However, even using the current version of the program there are some
>workarounds available. For example, what I do to take the place of CALL OK
>NOW is just to include the @ special character at the beginning of the QSL
>MESSAGE. That way, if you do correct his call sign before you log the QSO,
>the corrected version gets sent at least once. This is not as good as CALL
>OK NOW, but it's better than nothing...
>
>You can also dedicate a function key to use as a manual CALL OK NOW key.
>However, you have to remember to use @ instead of { or } in the function-key
>message.

That's a good workaround for CALL OK NOW, sticking @ into QSL MESSAGE.
Luckily, my typical rates on RTTY don't make lengthening QSL MESSAGE a problem.

>I have one more (optional) feature that I would add to your wish list for
>serious RTTY operating, and that would be the ability to recognize and
>highlight a call sign in the incoming data stream (perhaps by recognizing a
>preceding "DE ") and then to offer some controllable way to transfer it to
>the call sign window (by pressing a special key such as the Insert key,
>perhaps?). However, this would require some more significant programming and
>testing effort.

Somebody have a TNC we can send to Ron?  ;^)

>Regardless of whether the RTTY support in TRLog is improved or not, there is
>one other trick I have used for some RTTY contests which you may find
>useful. This is dual receive (TNC and sound card), which only requires the
>ability to run TRLog in a DOS window that doesn't cover the entire screen
>(in Windows you can use Alt-Enter to switch a DOS window from full-screen
>display to a smaller window), plus a patch cord from your receiver's audio
>output to your sound card's line input jack.
>
>I open up MMTTY and move the MMTTY window so that the tuning display will be
>visible to the right of the TRLog window, the transmit pane will be off the
>bottom of the screen, and the bottom part of MMTTY's receive pane will be
>visible below the TRLog window. I then set TRLog up in a DOS window in the
>top left corner of the screen, and change the DOS window font to a choice
>that will leave as much of the screen uncovered as possible while still
>being readable.
>
>This setup uses TRLog to transmit through the TNC, but has the advantage of
>receiving on both the TNC and MMTTY simultaneously. MMTTY seems to work
>better than my TNC on average, but there are plenty of times when the TNC
>gets a character or two that MMTTY doesn't. This setup also gives me the
>MMTTY tuning display, which I much prefer to the LED bar on my TNC.

TNC diversity - cool.

One thing I want to try this season is a second TNC on a second rig or 
sub-rx of
the main rig - I feel I need to do more S&P, but can't seem to give up 
running (which
is so much better now w/TR than TR/YAPP/DESQview one-armed wallpaper hanger
approach previously adopted ;^).

73, VR2BrettGraham