[RTTY] Looking for an interface - a few simple requirements

Wed Oct 2 14:10:01 EDT 2013

K5DU was a sound (oh, what a sound it was...) example.

73,

Vlad VE3IAE

--

----- Original Message ----- 
From: "Don AA5AU" <aa5au at bellsouth.net>
To: "RTTY Reflector" <rtty at contesting.com>
Sent: Wednesday, October 02, 2013 1:31 PM
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 at mac.com>
>To: RTTY Reflector <rtty at contesting.com>
>Cc: "ws7ik7tj at gmail.com WS7I" <ws7ik7tj at 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 at contesting.com
>http://lists.contesting.com/mailman/listinfo/rtty
>
>
>
_______________________________________________
RTTY mailing list
RTTY at contesting.com
http://lists.contesting.com/mailman/listinfo/rtty 