[RTTY] Microham RTTY

[Kok Chen]

On Feb 28, 2008, at 11:12 AM, Alan Burgstahler wrote:

> It has something to do with how the software program sends the
> characters to the MMTTY program, for instance, but the MMTTY program  
> sends
> each character correctly.

If you are using FSK on a microKeyer (or digi Keyer), the bit timing  
is handled by the microKeyer and not by the software on the computer.

The way the microKeyer (actually, the "Keyer Protocol" in the  
microKeyer's firmware if you want to be pedantic) handles characters  
is that there is a small buffer in the keyer that you send characters  
to.  When the microKeyer sees an available character in the buffer, it  
will send the character out at the preset baud rate (approx 22ms per  
bit).

After sending a complete 7.5 bits out to the FSK port, the microKeyer  
stays in the Mark state (stop bit) until it sees another character in  
the buffer.  If you are late in providing the next character after the  
microKeyer buffer reports that it is empty, this "stop bit" will be  
indefinitely stretch -- this will slow down the character rate.

I.e., the microKeyer is responsible for maintaining the bit rate and  
the computer is responsible for filling the microKeyer buffer so that  
the character rate is not slowed down.

Diddles are not sent automatically by the microKeyer when the  
microKeyer is in this mode (there is an option to automatically send  
diddles when you connect a keyboard directly to a microKeyer).

Phil had mentioned that he'd only noticed the odd sound when VP6DX was  
sending diddle characters, and not when VP6DX was sending a macro.   
That is why one of my suspicions is that whatever software they are  
using is late in delivering a diddle character to the microKeyer's  
buffer.  I.e., in between the diddlec haracters, the microKeyer stays  
in the Mark state for longer than it should.  If so, this is not the  
fault of the microKeyer, but of the software that is feeding  
characters to the microKeyer.

73
Chen, W7AY