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
|