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

[Phil Sussman]

Chen,

Your explanation of 'slow-RTTY' is clear and welcome as a source.

In the 'good-ole-days' such instances were rare (unless something was broken).

Personally I believe that more detail was spent meeting a set of  
specifications,
rather than playing with hardware and software shortcuts to minimize cost.

The advent of soundcards was an technological advance, but in which direction?

Certainly there are ways to do things correctly, but as Edison observed, there
are thousands of ways 'not to build a light bulb.'

Chen is right! Open sourcing multiplies problems and can degrade the overall
public perception of the product itself. This was pointed out to me years ago
by SCS (PACTOR) whose initial PACTOR-1 implementation was destroyed by work
arounds and shortcuts taken by various manufacturers who deviated from the
original specifications in the name of cost cutting. Today PACTOR-2 thru
PACTOR-4 are closed systems without an open source code. The technical results
are superior performance. That's not to say that I agree with closed  
systems on
the Ham Bands; however, you can't argue with the results.

Certainly soundcard technology and open source codes on the Ham Bands do keep
the price down. But, they also introduce those situations outlined by Chen.

73 de Phil - N8PS



Quoting Kok Chen <chen at mac.com>:

> 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
>