RTTY
[Top] [All Lists]

Re: [RTTY] Strange XE Contest exchanges

To: RTTY Reflector <rtty@contesting.com>
Subject: Re: [RTTY] Strange XE Contest exchanges
From: Kok Chen <chen@mac.com>
Date: Sun, 07 Feb 2010 12:09:48 -0800
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
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

<Prev in Thread] Current Thread [Next in Thread>