RTTY
[Top] [All Lists]

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

To: RTTY Reflector <rtty@contesting.com>
Subject: Re: [RTTY] Looking for an interface - a few simple requirements
From: Don AA5AU <aa5au@bellsouth.net>
Reply-to: Don AA5AU <aa5au@bellsouth.net>
Date: Wed, 2 Oct 2013 10:31:53 -0700 (PDT)
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
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

<Prev in Thread] Current Thread [Next in Thread>