Brett,
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.
On Tue, 30 Jul 2002 23:29:31 +0000 you said:
>
> Did the Russian RTTY contest off & on the past weekend...
>
> 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.
>
> But it's once a minute. How can you stare at the screen for hours & hours
> over the weekend & not notice something like that? Especially when it
> invariably clears off some previous copy of a station you're trying to
piece
> together the call from knowing which bits on the screen printed when the
> signal sounded like the TNC had a chance of copying correctly?
>
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.
> 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.
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.
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.
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.
Hope to meet you on RTTY some day.
> 73, BW2/VR2BrettGraham
>
73,
Rich VE3IAY
|