On Feb 7, 2010, at 2/7 10:13 AM, Jerry Flanders wrote:
> TOOLQTR-QTR-QTR (The hyphen character is in the figs set - so shifts
> were made before and after it. Anybody see how this could have
> happened?)
Notice that the error already existed at the TOO -- that initial FIGS
shift was mis-decoded.
However, if asked for a repeat, the above should print properly. This
is *not* the case of an exchange where repeated AGN? result in never
getting a successful exchange across.
The "L" in the exchange is a mystery to me. Presumably it meant to be
a FIGS shift character (otherwise a LTRS would have been sent after
599 and a subsequent FIGS is sent after the "L"). A dash is Hamming
distance 2 away from the 'L' so it is possible that there are two
error bit hits within that 5 bits.
> 599 - 167 - 167 (With spaces each side of the hyphens. What was he
> thinking?)
Kinda silly.
(1) it is *very* slow to transmit under USOS (it forces a FIGS right
after each of the space characters above, not to mention the time to
transmit the spaces themselves),
(2) it does not help when the receiver is non-USOS user, and the
additional characters just add more probability of errors,
(3) when transmitted from a non-USOS transmitter, the above will print
QWERTY-gibberish on a USOS receiver.
If you are transmitting with USOS, why not just use something simple
like "599 001 001" and "599-OR-OR". Both USOS and non-USOS receivers
can copy those transmissions; notice the difference when transmitting
numbers or letters exchanges. Just don't transmit "599 OR OR,"
otherwise a non-USOS station will never copy you, no matter how many
times you repeat.
Keep a "599-OR-OR" macro around if you insists on using "599 OR OR"
when transmitting with USOS, for the times someone keeps asking for
repeats.
If you transmit with non-USOS, use "599-001-001" and "599 OR
OR" (again, both USOS and non-USOS receivers can copy those
transmissions). And, if you are a non-USOS transmitter, never ever
transmit "599 001 001," otherwise a USOS will never be able to copy it
no matter how many time you repeat it.
If you insists on transmitting "599 001 001" with non-USOS, keep a
"599-001-001" macro around for the times that someone asks aver and
over for a repeat.
Finally, if you have no idea if you are using USOS or non-USOS to
transmit, just use 599-001-001 and 599-OR-OR. Both USOS and non-USOS
receivers can copy them, even if you have to repeat occasionally when
the FIGS are mis-decoded.
It is really that simple.
A digression, looking at this exchange again:
> TOOLQTR-QTR-QTR
I dislike stations that don't transmitting anything before the 599. A
FIGS could easily be missed as in Jerry's example.
If the other station did not send any callsign before the 599, that is
a major mistake (in many fronts, but especially on 2-tone FSK).
Some may have noticed this before: when you copy an exchange that has
a callsign at both the beginning and at the tail, the first callsign
is the one that has a larger percentage of failure.
Selective fades has a greater chance to the first few characters out.
The reason is that the ATC has no idea at the start of a transmission
if the two tones have marked differences in strength. So, the first
few characters suffer greater percentage of decoding errors than other
characters, when the ATC has a chance to finally figure out the best
slicing level to use.
I have also noticed that very strong stations also tend to create more
errors in the first few characters. In this case, I believe the fault
is with my receiver's AGC.
The moral of the story is, with 2-tone FSK, the first few characters
are the ones that are more prone to errors.
The absolute beauty of RTTY is that 2-tone FSK survives very well
under selective fading, and we get a lot of that kind of fading on
HF. I can't think of any other modulation modes that has this
property. The "modern" MFSK modes counter selective fading by using
FEC and long interleavers, but RTTY can do it without FEC.
Just watch your crossed ellipse display. On HF, the two ovals often
do not change size at the same time. They do their independent
dances. One tone is selectively fading, then later, the other tone
selectively fades.
For the RTTY ATC to counterbalance the selective fading however, it
must first be able to measure the strengths of each tone. The ATC
mechanism needs a character or two before it achieves a reliable
reading.
That being said, there *are* demodulators that delays the signal
before it reaches the decoder by a couple of characters; this way, it
can measure selective fading just a little into the "future" first.
Time shifting like this is easy to do with DSP demodulators. But not
all demodulators will forward time shift the decoding relative to ATC
measurements, and they are not available in any hardware demodulators
(e.g., ST-8000) that I know of.
For those reasons, I wouldn't transmit any mission critical characters
at the start of a transmission. I wouldn't go as far as transmitting
a whole line of "The quick brown fox" or "RYRYRY" :-)
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|