At PJ2N, Chet, W6XK, and I ran into a problem just before the start of
the ARRL RTTY Roundup. We received numerous reports that the first few
characters of each report we were sending was garbled. we searched
frantically to find and fix the problem, but the only thing that seemed
to work was adding significant front end padding to our programmed
messages in Writelog. We started with a single CR/LF but had to add two
spaces, a CR/LF, and another space before every message before our
signal became 100% copyable.
We were running the latest versions of Writelog and MMTTY with an FT2000
and TenTec Titan II linear amp. We started out with our messages very
short in order to maximize our QSO rate. Even a few extra characters,
over the 24 hour contest period reduces the number of total QSOs in the
log. So, while we were happy to "solve" the front end garble problem,
we did add considerably to the time each QSO exchange took.
When I returned home to California I ran a bunch of experiments to see
if I could determine why the PJ2N pre-contest RTTY signal was garbling
the first several characters of each exchange.
To make a long story a bit shorter, we feel the problem was most likely
our amplifier not switching fast enough and/or we had an ALC induced
spike of some kind at the start of each transmission.
When the problem was first reported to us at PJ2N, I did suspect a
transition timing problem and tried changing the Writelog CW DELAY
parameter, but that parameter had no discernible effect. What would have
helped us is if either / both MMTTY and Writelog had a user modifiable
RTTY DELAY parameter. The idea would be that the text in the buffer
would not be sent to the transceiver until xx milliseconds after the PTT
had been asserted. This would cause the transmitter to send a steady
Mark signal for the specified delay interval before the first character
Start bit begins.
While I suspect most modern transceivers and most modern linear
amplifiers switch fast enough without unstable "spikes" of any kind,
many of us do use equipment with these problems. So, why not just pad
the front end of your messages with as many spaces and/or CR/LFs as it
takes to eliminate the front-end chopping? First, each space takes
either one or two character lengths. Two if MMTTY "transmit UOS" is
selected to send a LTRS character with every space. At PJ2N, we wanted
to start each message with one character, a CR/LF. Instead, it took
three spaces and a CR/LF, or six extra baudot characters of eight bits
(start, 5 data, 2 stop) for 8/45.45 = 8x22 ms = 176 ms per character * 6
extra padding characters = 1.06 seconds added to every exchange message
solely for the purpose of overcoming the transmitter/linear transition
instability. Doesn't sound like much? Multiply that by the 2186 QSOs
we made and you see that we "wasted" over 38 minutes as a result. That
time could generate a whole lot more QSOs in the log. Remember, I'm
talking about a contest here and the objective is to make as many QSOs
as possible during the contest period.
Another problem with simply adding extra spaces at the front of each
message is that it does not ensure that the receiving station will
synchronize quickly. If the transmitter chops off a bit or two there
will be a contiguous stream of bits from the buffer which, to the
receiving station decoding algorithm presents a problem of finding the
"true" start bit of the next character. It typically takes several
characters, at least, for the decoding algorithm to figure it out and
start decoding correctly.
By contrast, if Writelog could send a Mark Signal, i.e. assert PTT but
not send any characters, for the specified RTTY DELAY milliseconds, the
receiving station will be much more likely to detect the first occurence
of a Start bit, i.e. decode correctly beginning with the very first
transmitted character.
How long does RTTY DELAY need to be? I don't know, but I would guess
that no more than two character lengths (2*8/45.45=352 ms) at most would
be sufficient both for the transmitter and amplifier to transition to a
stable state and for the receiving station to synch up. Most likely, a
much shorter RTTY DELAY would work just fine. This is admittedly just
a wild-a** guess. But the point is that a RTTY DELAY feature in
Writelog, MMTTY, N1MM, DX Lab WinWarbler, etc.) could be a very valuable
improvement in the software. I therefore would like to humbly request
that the authors of these programs give serious consideration to the
addition of a user defined RTTY DELAY parameter. In Writelog I would
guess that it could possibly be as straightforward as extending the CW
DELAY parameter to also work in the RTTY mode.
I look forward to working you in the next RTTY contest!
Thank you and 73,
Ron N6EE
aka PJ2N
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|