[RTTY] Microham RTTY

[Alan Burgstahler]

My take on what was happening with the VP6DX operation was that it was 
similar to what occurred with another software program a year or so ago, and 
they found that there was something wrong with the way the program 
implemented the sending of the RTTY characters, and it was later fixed.  It 
appeared that the VP6DX characters were being sent properly (i.e., 22ms per 
pulse for the marks and spaces), but that the characters were slow in being 
sent out.  In other words, instead of sending 60 wpm (which isn't exactly 
correct), they were only sending about 45-50 wpm, but each character was 
being sent out with the proper timing within the character.  There was just 
a blank space of time between characters.  (I hope this makes sense.)  I 
still hear some people on RTTY contests sending this way, and I think NP3D 
is one of them.  He seems to send each the characters slowly, but the timing 
within the character is correct or we wouldn't be able to copy what he's 
sending.  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.

Alan - N7BF

----- Original Message ----- 
From: "Kok Chen" <chen at mac.com>
To: "RTTY Reflector" <rtty at contesting.com>
Sent: Thursday, February 28, 2008 10:46 AM
Subject: Re: [RTTY] Microham RTTY


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