[RTTY] Microham RTTY

[Kok Chen]

On Feb 28, 2008, at 2/28    8:50 AM, Phil Cooper wrote:

> Why is it that microham RTTY sounds odd? It is almost as if it is  
> going
> slow, or maybe the diddles aren't quite in step. There is a  
> distinct sound
> when someone uses a microham interface, and it is quite common in  
> contests.

Unless VP6DX is using a direct keyboard connection to the microKeyer,  
the FSK diddles should be generated by the software that they are  
using in the computer, and not by the box itself.

I have not noticed the effect (I only noticed the missing newlines,  
HI HI) or I would have recorded the audio for post analysis.  Does  
anyone  have a clean recording that the rest of us could use?

For FSK, there is a character buffer in the microKeyer that you send  
Baudot characters and diddles to.

The usual way to use the FSK port on the microKeyer is to  
periodically inspect a "buffer empty" byte from the microKeyer's  
status return (the microKeyer always sends a status byte to the  
computer whenever this empty state changes).  When the RTTY program  
sees this "empty" status, it is responsible for sending a LTRS to the  
microKeyer asap.

If the software that is running in the computer is too slow in  
sending a LTRS into the microHAM buffer after the "buffer empty"  
status  comes from the microKeyer, then there could be a gap between  
the diddle charcaters.

Another possibility is that the software is sending a Baudot NULL as  
diddles.

I think that most software send LTRS for diddle but I am not  
certain.  A NULL diddle (5 bits of zeros) will definitely sound  
different from a LTRS diddle character.

The disadvantage of sending LTRS as diddles is that if you are in the  
middle of a string of numbers and make a short pause, the software  
would not just need to send the LTRS, but also a FIGS when you start  
typing again, and this will slow you down a tad.  However, like  
forced-USOS, it also improves the character error rate (you won't be  
stuck in one Baudot shift for too long).  Furthermore, dow often do  
you pause in the middle of typing a string of numbers, anyway.

If you are pausing during typing, transmission rate is not your  
biggest concern anyhow, and from the robustness viewpoint, I have  
chosen LTRS as diddles in cocoaModem.  I don't know the rationale  
used by other software whether they choose LTRS or NULL.

Any non-printing Baudot character can be used for diddles as long as  
the character appears as the same Baudot byte representation in both  
LTRS and FIGS shift).  There are three that I know of.  Other than  
NULL and LTRS, the FIGS character is a third possibility.

You can also be cute and send these characters alternately when you  
are idling, i.e., <NULL>, <LTRS>, <FIGS>, <NULL>, <LTRS>, <FIGS>...   
That would generate an idle that is definitely different sounding and  
might make your signal distinctly identifiable from the other people.

Unlike PSK31's idle Varicode character (the shortest character in  
Varicode), there is really no idle character specified in RTTY,  
probably because RTTY was intended as an asynchronous stream.

As an aside, cocoaModem has an option for a "robust" transmission  
mode where it periodically generates a LTRS (and a FIGS if you are in  
FIGS state) even when it is not absolutely needed.

BTW, if VP6DX is stretching the timing during diddles, then the  
stream will also be poor when used with RTTY decoders (like RITTY in  
"flywheel" mode) that are using a pseudo-synchronous method to reduce  
QSB effects on the start bits.

For fun, I had been planning on playing with FSK (as many people  
know, I only use AFSK for RTTY work) on the microKeyer II anyway.   
This is the same box as what the VP6 guys use.  I will report if I  
see any anomaly when I get to it.  My bet is that any anomalies you  
heard is in the software VP6DX is using for RTTY, and not in the  
microKeyer itself, either not keeping up with the "buffer empty"  
flag, or sending some alternate diddle character that we are not  
accustomed to hearing.

> So what causes the "sound" to change when using a microham unit? Is  
> it due
> to the different Baud rate?

Human ears are fantastic instruments and your ears might be perfect  
pitch enough to catch the slight difference in the keying sidebands.   
It is hard to imagine you can pick up a 1/2700 difference in the FSK  
keying sidebands (not the mark and space tones themselves), but I  
have been surprised before at what good RTTY ops can hear!

Notice that anyone can easily spot an inverted signal by ear.  If you  
think about it, the only difference (if the character bits are  
random) is whether the 1.5 bit stop bit is sending the mark tone or  
whether it is sending the space tone.  On average, the difference is  
just 1 part out of 15 parts of the RTTY duty cycle.  But 1 part out  
of 15 is still a far cry from 1 part out of 2700.

BTW, you can set the FSK port of the microKeyer to generate 2 stop  
bits; it could be that the operator had done that.  But that would  
slow every character down and not just the diddles.

73
Chen, W7AY