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

Wed Oct 2 15:57:21 EDT 2013

Yes, Susan's RTTY signal has always been "distinctive" to my ears 
because of the slower pacing of the characters. But that is the only one 
I can recall specifically as an example.

73 de Bob - KØRC in MN

------------------------------------------------------------------------

On 10/2/2013 1:10 PM, Vladimir Sidarau wrote:
> 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
> _______________________________________________
> RTTY mailing list
> RTTY at contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
>