--=====================_106741646==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
I see no reason to use TRLOG on an RTTY contest. The capabilities of
WriteLog to integrate MMTTY AND the DXTELNET spots into the program make it
a huge advantage over TRLOG.
In fact for any contest that has a contest module available fro WriteLog it
seems the winner today, in all respects.
In SSB it is not even a close race. You can do a SSB contest without ever
speaking a word.
For CW, well for CW TRLOG MAY still be the best?
Besides, I am sick of DOS.
At 21:53 10/14/2001, Richard Ferch wrote:
>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
Gil Baron http://members.home.com/gbaron
W0MN 44.08208 N 92.51263 W 1055'
"Baila como nadie te ve"
--=====================_106741646==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
I see no reason to use TRLOG on an RTTY contest. The capabilities of
WriteLog to integrate MMTTY AND the DXTELNET spots into the program make
it a huge advantage over TRLOG.<br><br>
In fact for any contest that has a contest module available fro WriteLog
it seems the winner today, in all respects. <br><br>
In SSB it is not even a close race. You can do a SSB contest without ever
speaking a word.<br>
For CW, well for CW TRLOG MAY still be the best?<br><br>
<br><br>
Besides, I am sick of DOS.<br><br>
At 21:53 10/14/2001, Richard Ferch wrote:<br><br>
<blockquote type=cite class=cite cite>Some notes on my experiences
setting up and using TRLog in the RTTY Sprint<br>
this weekend. This message is long. If you're not interested in using
TRLog<br>
for RTTY, you might as well stop reading now!<br><br>
1. Why use TRLog on RTTY?<br><br>
That's a good question.<br><br>
There are several free sound-card RTTY programs available, including
MMTTY<br>
(<a href="http://www.qsl.net/mmhamsoft/mmtty/";
eudora="autourl">www.qsl.net/mmhamsoft/mmtty/</a>),
but although they usually have some kind of<br>
contest logging capability, it doesn't come close to TRLog's.<br><br>
On the other hand, with TRLog you have to use a TNC. It may be possible
to<br>
use MMTTY in its KAM emulation mode with TRLog. I haven't tried this, but
I<br>
understand some people have made it work with WF1B RTTY.<br><br>
This raises the question: why not use WF1B RTTY (available free
from<br>
<a href="http://www.rttyinfo.com/"; eudora="autourl">www.rttyinfo.com</a>)?
WF1B RTTY has a major advantage over TRLog, and that is<br>
that it detects call signs in the incoming data, dupe checks them, and
can<br>
transfer call signs and exchanges automatically from the input window to
the<br>
log. WF1B RTTY also knows about the exchanges and scoring for most
RTTY<br>
contests. On the other hand, I don't find it quite as easy to use as
TRLog<br>
is, particularly in the Sprint, where TRLog's automatic switching
between<br>
run and S&P modes can save you from having to think (always a good
feature<br>
in a fast-paced contest!).<br><br>
Then there are the Windows contest logging programs, Writelog and
N1MM<br>
Logger. I have used Writelog, but somehow it has never quite clicked with
me<br>
(sort of like CT - I'll use it if I have to, but given my druthers,<br>
I'druther use TRLog). And the free N1MM Logger software is still in<br>
development. Reading the messages on the reflector for this new
program<br>
makes me uneasy about trusting it in a contest, but with several more
RTTY<br>
contests this fall, I'll probably try it out in one of them.<br><br>
Let's just say that I wanted to give TRLog a try on RTTY, and the
RTTY<br>
Sprint seemed like the ideal place.<br><br>
2. How do you set TRLog up for RTTY?<br><br>
Let's assume you already have a TNC or TU hooked up to a serial port, so
the<br>
question really is: how do you set up LOGCFG.DAT to use the
TNC?<br><br>
I started out from my LOGCFG.DAT file for the CW Sprint. First, you need
to<br>
add the following two lines:<br><br>
DIGITAL MODE ENABLE = TRUE<br>
RTTY PORT = SERIAL 1<br><br>
assuming your TNC is connected to COM1. As far as I can tell, the RTTY
port<br>
in TRLog is fixed at 4800 baud, so you may have to reprogram your TNC's
data<br>
rate to match (unless it has an autobaud feature).<br><br>
You should probably add:<br><br>
BAND MAP ENABLE = FALSE<br>
VISIBLE DUPESHEET = FALSE<br><br>
as the TNC incoming and outgoing data uses up the space where either
of<br>
these would appear. It may be possible to have two of these windows
active<br>
in the same LOGCFG.DAT file, but my guess is that you would have
on-screen<br>
interference between the visible dupesheet and the TNC window. In a<br>
multi-mode contest like Field Day, you might want to use the band map in
CW<br>
and SSB, and only have the TNC window active in RTTY, but this may be one
of<br>
those "rough edges" that only sort of works.<br><br>
Add:<br><br>
LEADING ZEROS = 3<br>
LEADING ZERO CHARACTER = 0<br>
SHORT INTEGERS = FALSE<br>
<br>
so your serial number exchanges come out as expected (cut numbers or
short<br>
integers like ATN for 109 don't make any sense in RTTY). Three-digit
serial<br>
numbers take marginally longer than shorter ones, but they are more<br>
predictable and stand out better in noisy conditions.<br><br>
The next set of changes applies only to the RTTY Sprint, not to other
RTTY<br>
contests. This is because you are allowed to work dupes in this
contest,<br>
provided there are at least three intervening QSOs in both logs (what I
did<br>
during the contest was check whether the call sign was visible in
TRLog's<br>
on-screen log window, figuring that if it was, we were too close - that
beat<br>
figuring out whether there were 2, 3 or 4 intervening QSOs).<br><br>
AUTO DUPE ENABLE CQ = FALSE<br>
AUTO DUPE ENABLE S AND P = FALSE<br>
SPACE BAR DUPE CHECK ENABLE = FALSE<br>
DUPE SHEET ENABLE = FALSE<br><br>
There will also be changes needed to the various memories and messages,
but<br>
I'll leave that for the moment. First, we need to make sure that
the<br>
hardware setup will work.<br><br>
3. Checking out the hardware<br><br>
For various reasons, I run TRLog in a DOS box under Windows 98. I'm not
sure<br>
why this is, but many DOS programs (including TRLog and WF1B RTTY)
don't<br>
seem to be able to see the serial ports on my machine unless I<br>
"precondition" the ports by running yet another DOS program,
Hyperlog,<br>
first. If I don't run Hyperlog first, TRLog will freeze on startup when
it<br>
fails to find the radio interface. Sometimes Hyperlog fails on the
first<br>
try, too, but somehow a second try with Hyperlog always works, where
a<br>
second try with the other programs does not - don't ask me why, ask<br>
Microsoft. If I run a Windows program that uses the com port in
question,<br>
then I will have to repeat the preconditioning step before running
TRLog.<br>
For all I know, I'm the only person in the world with this
particular<br>
problem, but anyway...<br><br>
Use Alt-M to change modes until you are in digital mode. That switches
my<br>
TS-850 into FSK mode. I don't know whether TRLog can support AFSK.
(Tree:<br>
would it be possible to implement an option that would put the radio
into<br>
either USB or LSB when TRLog is in digital mode, for thsoe who want to
use<br>
AFSK?). By the way, for some reason the band up and band down
commands<br>
(Alt-B and Alt-V) don't work in digital mode. You can either do
your<br>
bandswitching on the radio, or change to CW or SSB to switch bands,
then<br>
change back to digital.<br><br>
If you've got the serial ports working, when you switch the TNC on
you<br>
should see something, even if it's only rubbish, in the TNC window. When
you<br>
press F10 when TRLog is in digital mode (as distinct from CW or
SSB),<br>
anything you type after that is sent to the TNC. This includes the
Enter<br>
key, which does not terminate keyboard input (unlike CW). This is a
good<br>
thing, because you will probably need to be able to send a carriage
return<br>
to the TNC without terminating the keyboard input. The only way to
terminate<br>
keyboard input is to press the Esc key (F10 doesn't take you out of
keyboard<br>
input).<br><br>
With my MFJ-1278, after pressing F10 and turning the TNC on, I have to
press<br>
Enter a few times to get the TNC to recognize the baud rate. I then
enter<br>
the commands needed to put it into the correct configuration: MODE HB, 45
to<br>
select RTTY, RADIO 2 to select the HF radio, and K to take the TNC out
of<br>
its command mode, before pressing Esc. Other types of TNC or TU will
have<br>
commands with similar functions, as appropriate. You may have to specify
the<br>
RTTY SEND STRING and RTTY RECEIVE STRING parameters appropriate to your
TNC<br>
as well. The defaults work with the MFJ.<br><br>
If all this works, you should be able to tune to an RTTY signal and see
it<br>
in the TNC window. One very nice feature in TRLog is a small window at
the<br>
bottom that shows the same incoming characters in the other
figures/letters<br>
mode. This will translate all those annoying TOO PPQ exchanges that
happen<br>
when the sent FIGS character is hit by noise into 599 001 and so
on.<br><br>
To transmit, you can just hit F10 and start to type. Press Esc to go back
to<br>
receive mode.<br><br>
4. Programming TRLog's memories<br><br>
There are two aspects of RTTY that are different from CW and affect how
you<br>
program the memories.<br><br>
The first is that when there is no signal, the other guy's TNC will
probably<br>
convert random noise into random characters, or "garble". To
separate your<br>
message clearly from the garble, it's a good idea to start and end
your<br>
messages with a space or two, or even a carriage return. TRLog ends
its<br>
messages with a carriage return, but the RTTYer's habit of ending
all<br>
messages with a space and one or two K's is probably not a bad idea
either,<br>
in case the CR gets hit by a noise burst. It's also a good idea not to
make<br>
your messages too short, or they will be lost in the garble.<br><br>
The second is that there is no way to identify who sent a message from
the<br>
sound alone, as there often is in CW. This suggests that more
messages<br>
should include your call sign than would be the case in CW.<br><br>
In CW, you can begin and end messages with _ to force TRLog to insert
a<br>
space. Unfortunately, this doesn't work in RTTY; the _ is passed through
to<br>
the TNC, which will probably ignore it (there is no such character in
the<br>
Baudot character set). Some of the other special characters used in
CW<br>
messages don't work either ( ^, +, <, =, ! and &). The control
characters in<br>
Table 3 of the manual seem to work, but the ones to control speed,
weight<br>
and various length dits and dahs do not work. They are passed on
unchanged<br>
to the TNC, and may have undesired effects, so it is best to remove
them<br>
from the programmed messages.<br><br>
You can insert special characters in CQ MEMORIES F1-F9 and EX MEMORIES
F3-F9<br>
by using the <xx> syntax. I have found <20> (space) and
<0D> (carriage<br>
return) to be useful. However, these do not work in the "Other"
messages<br>
(Alt-P-O menu); they get passed through to the TNC, except for the >
which<br>
zeros your radio's RIT.<br><br>
Some useful messages from my RTTY Sprint config file:<br><br>
CQ EXCHANGE = DE \ # name state K<br>
(in some software, the DE tags the following word as a call sign, which
can<br>
speed up the other guy's response, and the trailing K separates
your<br>
exchange from garble. TRLog automatically sends the other station's
call<br>
sign and a space before this message.)<br>
S&P EXCHANGE = @ NR # name state DE \ K<br>
QSL MESSAGE = @ QSL DE \ QSY K<br>
(unlike CW, where a simple EE or R or TU will do the job, in the RTTY
Sprint<br>
most stations were using some variant on the above QSL message. In
a<br>
non-Sprint contest, you would put QRZ? in place of the QSY).<br>
CQ MEMORY F3 = <20>) NR # # name name state state DE \ K<br>
EX MEMORY F3 = <20>@ NR # # name name state state DE \ K<br><br>
The reason for the last two is that the F2 exchange memory does not work
in<br>
TRLog's RTTY mode. That means there is no way to send the REPEAT
S&P<br>
EXCHANGE. My solution to this problem was to program it into the F3
memories<br>
as above.<br><br>
I also programmed short messages to resend the exchange elements into
EX<br>
MEMORIES F4-F6, and queries asking for repeats of the same elements into
CQ<br>
MEMORIES F4-F6. That took care of most requirements for fills, and you
can<br>
take care of the rest (questions in EX mode and fills in CQ mode)
with<br>
ALTF4-ALTF6. As usual, in both EX and CQ I used F9 as a general
repeat<br>
request.<br><br>
The default CQ messages in CQ MEMORIES F1 and F2 needed a bit of work.
The<br>
Alt-A and Alt-B don't do any harm (they're there for SO2R), but the
Alt-F<br>
and Alt-S should be removed, and the ^ changed to a full space.<br><br>
5. During the Contest<br><br>
I changed the font in the DOS window to a size that left a bit of room on
my<br>
screen (6x10), and substituted single-prescription reading glasses for
my<br>
normal varifocals so I could read the computer screen better. Then I
opened<br>
up MMTTY and sized its window to fit beside the TRLog window. That gave
me<br>
some additional tuning aids, as well as two different decoders working
on<br>
the same received signal. Most of the time, if one of them garbled
the<br>
incoming signal, the other one supplied the missing information, and if
not,<br>
well, that's when you ask for fills.<br><br>
Overall, I'm pretty happy with the way the computer setup worked (how
the<br>
rest of my station works in the Sprint is a different story!), except
that I<br>
wish the F2 function key in exchange mode worked the way it does in CW.
I'll<br>
probably use this setup again in other RTTY contests where TRLog can
handle<br>
the scoring. If there are any with unusual scoring (ANARTS springs to
mind),<br>
well, I still have a copy of WF1B RTTY, and I can try to set that up to
work<br>
as similarly as possible to TRLog.<br><br>
6. After the Contest<br><br>
I had<br>
LOG FREQUENCY ENABLE = TRUE<br>
and<br>
SHOW SEARCH AND POUNCE = TRUE<br>
in my config file, as I find the information they add useful for
analysis.<br><br>
To remove the effects of the first one, I ran POST /L/C and renumbered
the<br>
QSOs. I then renamed the original LOG.DAT to LOGFREQ.DAT, and the
new<br>
LALLBOTH.DAT to LOG.DAT. Then I ran POST /C to produce the Cabrillo
file<br>
LOG.CBR . One tiny fixup: the CONTEST: line in the Cabrillo file produced
by<br>
POST read NA-SPRINT-RY. There is no name specified for this contest in
the<br>
official Cabrillo spec, but the WT4I Cabrillo tools software uses<br>
NA-SPRINT-RTTY, as does some of my own log processing software, so I
edited<br>
the file to make this change.<br><br>
To get my contest log into my general station log, I used two more
programs.<br>
CBRFRFIX puts the frequency information from LOGFREQ.DAT back into
the<br>
Cabrillo file, and CBR2ADIF converts the Cabrillo file into ADIF,
while<br>
adding a few fields that aren't in the Cabrillo file. These programs are
at<br>
<a href="http://www.storm.ca/~ve3iay/cbr2adif.html";
eudora="autourl">http://www.storm.ca/~ve3iay/cbr2adif.html</a>,
if anyone is interested. The<br>
version of CBR2ADIF that was at that site before this morning doesn't
handle<br>
the received name properly in the RTTY NA Sprint, but that bug has now
been<br>
fixed.<br><br>
If you're still reading, I hope you found some interesting tidbits in
this<br>
message.<br><br>
73,<br>
Rich VE3IAY<br><br>
<br><br>
--<br>
FAQ on
WWW:
<a href="http://www.contesting.com/FAQ/trlog";
eudora="autourl">http://www.contesting.com/FAQ/trlog</a><br>
Submissions:
trlog@contesting.com<br>
Administrative requests: trlog-REQUEST@contesting.com<br>
Problems:
owner-trlog@contesting.com<br>
Feature
Wishlist:<x-tab> </x-tab>
<a href="http://web.jzap.com/n6tr/trwish.html";
eudora="autourl">http://web.jzap.com/n6tr/trwish.html</a></blockquote>
<x-sigsep><p></x-sigsep>
<font face="Courier New, Courier">Gil Baron
<a href="http://members.home.com/gbaron";
eudora="autourl">http://members.home.com/gbaron</a><br>
W0MN 44.08208 N 92.51263 W 1055'<br>
"Baila como nadie te ve" <br>
</font></html>
--=====================_106741646==_.ALT--
--
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
|