[RTTY] What causes RTTY with longish character spacing?

[Joe Subich, W4TV]

> > I use the microHAM interface, and my transmitted FSK tones sound 
> > nothing like these stations.
> 
> Because there is no way to echo the RTTY buffer in the 
> microHAM "Keyer Protocol"s FSK interface back to the computer, 
> some programs opted to use only a single character of the buffer.

There is no need to do that.  MMTTY's "Limiting Speed" option 
simply sends one character every 165 msec (1.5 stop bits) or 
176 msec (two stop bits).  That avoids the need to watch for 
an echo - although MMTTY will echo as sent and a programmer 
could use that with the MMTTY engine.  

> Since you have to send 5-bit Baudot instead of ASCII to the keyer,  
> there is no way for the keyer to know if a FIGS state has 
> been changed by a LTRS diddle.  As a result, there is no automatic 
> generation of a diddle by the keyer.  If you are late in delivering 
> the next character, the keyer will remain in the Mark position until 
> it can resume sending the start bit of the new character.

That's not the responsibility of the UART (microKEYER acts like a 
UART - not a code translator or "keyer").  The software should be 
generating a diddle when it has no other data but is still in 
transmit.   

73, 

   ... Joe, W4TV 
 

> -----Original Message-----
> From: rtty-bounces at contesting.com 
> [mailto:rtty-bounces at contesting.com] On Behalf Of Kok Chen
> Sent: Tuesday, September 29, 2009 7:38 PM
> To: RTTY Reflector
> Subject: Re: [RTTY] What causes RTTY with longish character spacing?
> 
> 
> On Sep 29, 2009, at 9/29    1:20 PM, Jim Reisert AD1C wrote:
> 
> > I use the microHAM interface, and my transmitted FSK tones sound 
> > nothing like these stations.
> 
> Because there is no way to echo the RTTY buffer in the 
> microHAM "Keyer  
> Protocol"s FSK interface back to the computer, some programs 
> opted to  
> use only a single character of the buffer.
> 
> I, for example, send a single character at a time to the keyer, and  
> then wait for the keyer to send me the "RTTY buffer is empty" 
> response  
> before sending the next character.  This way, I echo each 
> character to  
> the computer display just as it is being transmitted.
> 
> I have not noticed any problem with Mac OS X running on a moderately  
> current computer by buffering a character at a time.  I "wait" by  
> using the Unix select() call, so it is pretty much a kernel driven  
> event.  I suspect that a program that polls for the "RTTY buffer is  
> empty" response may not be able to react as quickly.
> 
> A slow program/computer could end up not keeping the buffer filled.   
> If that is the case, the latency in sending the next character will  
> cause the stop bit of the previous character to be extended.
> 
> Since you have to send 5-bit Baudot instead of ASCII to the keyer,  
> there is no way for the keyer to know if a FIGS state has 
> been changed  
> by a LTRS diddle.  As a result, there is no automatic 
> generation of a  
> diddle by the keyer.  If you are late in delivering the next  
> character, the keyer will remain in the Mark position until it can  
> resume sending the start bit of the new character.
> 
> (The microKeyer *can* insert automatic diddles if you attach a  
> keyboard directly to the keyer.  In that case, it knows when 
> there is  
> a need to send a FIGS shift after a diddle since it knows 
> what key you  
> have pressed.)
> 
> We could ask a microKeyer user who appears drunk to switch 
> from FSK to  
> AFSK and see if he then passes the sobriety test.
> 
> 73
> Chen, W7AY
> 
> _______________________________________________
> RTTY mailing list
> RTTY at contesting.com http://lists.contesting.com/mailman/listinfo/rtty