> Two if MMTTY "transmit UOS" is selected to send a LTRS character with
> every space.
Incorrect ... MMTTY does not transmit "Letters" with every space in
strings of spaces. "Letters" (or unshift) is transmitted before the
first space in a string.
> 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.
Three spaces and CR/LF is six characters because the string is:
"<LTR> <SPACE> <SPACE> <SPACE> <CR> <LF>" - CR and LF are separate
characters in Baudot and MMTTY does not transmit LTR before every
space as can be determined by measuring the time necessary to send a
macro containing 100 space characters *in AFSK*.
> Multiply that by the 2186 QSOs we made and you see that we "wasted"
> over 38 minutes as a result.
The time was wasted because your transmitter was operating improperly.
With a malfunctioning transmitter you would have "wasted" that time
waiting for the transmitter to stabilize whether you used character
padding or just a mark tone.
> 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.
Again, not true. The decoding algorithms need a STOP bit followed by
a START BIT - more specifically 165 ms between 1.5 bit length STOP
bits to synchronize. Absent a leading stop bit (or long mark) an
isolated start (space) bit is indistinguishable for any other space
in the noise.
> 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.
It makes absolutely no difference if the padding is a single mark,
diddle (letters) or spaces. The decoding will behave identically
in the face of what appears to be a *fading* signal. In practice
there may even be an advantage to letters or space characters as
any automatic threshold correction logic will not be skewed to
"mark only" as it would be by a long mark.
> 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.
Obviously is wasn't for you at PJ2N ... if two characters had been
enough you could have used "<space> CR/LF" which would have actually
been only 300 ms longer than a normal macro with the leading CR/LF.
Again, there is no reason for Writelog, N1MM Logger, Win-Test,
MMTTY, MMVARI, MixW, etc. to add a "data delay" parameter. If
your transceiver is not working properly add the necessary number
of space characters to the start of your macros (before CR/LF).
> 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.
Quite simply, such a parameter is not necessary. It only creates one
more potential problem and solves nothing.
73,
... Joe, W4TV
On 1/22/2012 6:38 PM, Ron Lodewyck wrote:
> 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/
>
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|