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