> The third happens all the time with FSK (and rare with AFSK) and the
> majority of people don't even know it -- 2Tone has an indicator for
> the stop bit duration, otherwise in the past you will need to plot
> out the decoded waveform to see it.
>
> I think it happens because the "next" character is not sent to the
> UART fast enough, thereby stretching the stop bit. This happens more
> often than you think: stop bits would stretch between 22 ms to
> perhaps 60 ms (not as long as the K3/paddle case, though).
This condition can be created easily with MMTTY and direct keyboard
entry. Simply increase the "Diddle wait" slider on the TX Tab in
MMTTY Set-up (or at the right side of the transmit menu of the main
display) along with the "Char. Wait".
Character Wait controls the (added) wait time (mark extension) between
characters whilst Diddle Wait controls the amount of time without a
character "ready" before MMTTY will switch to sending (inserting)
Diddles in the data stream.
If Character Wait is longer than diddle wait, diddles will be inserted
into the (uneven) data stream during keyboard operation. If diddle
wait is longer than character wait, one will get the "variable length
Mark".
With many (slow) manual typists the data is often - character, LTRS,
character, LTRS, etc.
73,
... Joe, W4TV
On 10/2/2013 1:28 PM, Kok Chen wrote:
On Oct 2, 2013, at 8:26 AM, Jay WS7I wrote:
In fact I had it once using MMTTY at a place where I contest on
occasion.
Could the recent spate in Slow RTTY be caused by the open sourcing of
MMTTY, and people unknowingly modifying the code and thus inserting
latencies to the characters?
There are three kinds of "slow RTTY," some are more obvious than the
others.
The first kind "sounds" normal, with correct character rate and bit
rate, except extra diddles are inserted when they need not be, as if
it were a slow typist. The ones with extraneous diddles also tend
to come with a lot of V characters from these stations under severe
multipath conditions (the V are simply LTRS shift characters -- the
diddles -- that has the start bit smearing into the LSB of the Baudot
character. So, lots of diddles = lots of V.
The second is the K3/paddle guys -- you can spot these signals a mile
away. While the baud rate is constant (otherwise, Baudot decoders
would not be able to copy them), the character rate is not
consistent. They sound weird, but prints correctly. The stop bit
stretches wildly from 33 milliseconds to hundreds of milliseconds.
This kind of "slow RTTY" is caused by the firmware in the K3 not
issuing a diddle when it is needed, and leaving the FSK state in the
Mark condition while waiting for the paddling to finish. Those of
you with a K3 can easily hear this on the monitor by sending
somethings like WA0AOI. The zero and the O will likely suffer from
stretched stop bits unless you can paddle *really* fast -- way, way
faster than 60 WPM, since the "PARIS" Morse speed measures average
speed, not when the Morse character has lots of dah elements. Since
few people can paddle beyond 80 WPM, it is the norm to get this (the
K3 will not send FSK with a hand key, just through a pa ddle, by the
way).
If you think this is rare, you should see the email I get from K3
users who actually uses this :-). Many are teetaletolers in RTTY or
they are just having fun while operating their K3 portably. If a
rare DX pops up and you don't have a laptop with you, you can still
work the DX -- the decoded Baudot appears on the VFO display of the
K3. It is hard to discourage them from the practice, since ham radio
is all about having fun, and these guys are probably having more fun
than people using function keys. But Elecraft really should fix
their firmware.
The third happens all the time with FSK (and rare with AFSK) and the
majority of people don't even know it -- 2Tone has an indicator for
the stop bit duration, otherwise in the past you will need to plot
out the decoded waveform to see it.
I think it happens because the "next" character is not sent to the
UART fast enough, thereby stretching the stop bit. This happens more
often than you think: stop bits would stretch between 22 ms to
perhaps 60 ms (not as long as the K3/paddle case, though). Proper
software should not allow this to happen even through
misconfiguration (and with AFSK, it really can't happen unless the
software is pretty broken).
The most common cause is that the software is controlling the
character timing, and using the UART only to control the bit timing.
(nd in the K3 case, the operator is causing the character latency
:-).
I have even seen this type of stretched stop bit with MicroHAM
devices when the software misuses the character buffer in the
interface -- even though the interface has a buffer of more than one
character, the software still only uses it as a one character buffer.
It is not a hardware problem, and with proper algorithms on the
computer end, they do not happen -- all that needs to happen is to
keep at least two characters the MicroHAM interface (or any UART
based interface that has a buffer, for that matter), and let the
firmware in the interface perform the character timing.
(The "usual" argument for only using a single character UART buffer
is so that you can quickly flush an exchange. But that should not be
a problem with macro-driven contest exchanges, and delaying a flush
by 180 ms won't really hurt much, and only on the occasions when you
decide to stop a macro mid-stream.)
Since 2Tone has a stop bit duration indicator, you have a tool today
to monitor your own signal to see if this is happening with your own
transmissions with whatever UART interface that you are using. Try
it. I think a lot of people who use FSK are going to be surprised by
what they see reported back by 2Tone.
This will, as time goes by, is not just a nuisance, but become more
important as modems start adopting "pseudo-synch" techniques to get
through flutter conditions better.
Folks who have used the "numerical flywheel" in RITTY will know what
I mean. With these techniques, you are using the start-stop
information from more than a single character to derive the character
frames.
Start-stop errors contribute to about 3 times more errors than errors
in data bits because a character synch/frame error will propagate
until the decoder finally finds the true start bit again. If you can
use even just two character's worth of start-stop information, the
print errors drop dramatically. By the time you use four characters
worth, the start-stop errors are pretty much out of the picture and
you only have to deal with random errors.
Naturally, techniques like RITTY's numerical flywheel requires very
accurate character (thus stop bit) timing (or the technique includes
some magic to account for changing stop bit durations -- yeah, I have
been looking into that too and can tell you that it is a real pain
when stop bits jitters :-).
With the techniques that tries to make start-stop RTTY behave more
like synchronous FSK (Amtor FEC is synchronous FSK, by the way, and
it is quite robust), the baud rate has to be rather precise (one
percent baud rate error over 30 bits becomes a large error), and also
be constant (it is hard to track character clock when the bit clock
itself jitters). In the future, it is possible that if you run the
wrong baud rate or generates too much jitter (for example by using
EXTFSK), your transmission may not be able to take advantage of these
techniques.
Buy up the FSKits while they are still around since they provide FSK
with good timing, HI HI. (Or modify a SignalLink to include the
FSKit chip per the QST article earlier this year.)
With FSKit, you are using AFSK timing, so the jitter is moderately
low all the way to 75 baud.
A little birdie tells me that it is developing another AVR design
which might become publicly available to convert FSK from the
computer to FSK for the transmitter. I am told it reclocks the data
to 45.45 baud, and cleans up EXTFSK jitters :-).
73 Chen, W7AY
_______________________________________________ RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|