I heared 4 or 5 times such a kind of signals from Europe
last WW.
But I remember in past when it was fast flatters on NA signals
which was came over North Pole the slow RTTY reads better than normal
Much better !
Larry
RW4WZ
-----Original Message-----
From: RTTY [mailto:rtty-bounces@contesting.com] On Behalf Of Don AA5AU
Sent: Wednesday, October 02, 2013 9:32 PM
To: RTTY Reflector
Subject: Re: [RTTY] Looking for an interface - a few simple requirements
I don't recall hearing any "slow" RTTY signals at all this weekend. Maybe
it's not as widespread as some think.
73, Don AA5AU
>________________________________
> From: Kok Chen <chen@mac.com>
>To: RTTY Reflector <rtty@contesting.com>
>Cc: "ws7ik7tj@gmail.com WS7I" <ws7ik7tj@gmail.com>
>Sent: Wednesday, October 2, 2013 12:28 PM
>Subject: Re: [RTTY] Looking for an interface - a few simple requirements
>
>
>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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|