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@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|