On Sep 28, 2009, at 9/28 6:50 AM, Bill, W6WRT wrote:
> If QRN or QRM wipes
> out the FIGS shift just before the 599, either of the above will
> print as
> TOOAWTAWT.
As I have mentioned this more than once already, Bill, if a symbol
error (what you refer to as QRN or QRM) can wipe out the FIGS that you
mentioned, it can also wipe out the extra FIGS that USOS inserts after
your space delimiter. I know my English is deficient and I can't get
this through clearly to you.
I.e., if a symbol error causes the FIGS that USOS sends after the
space, you will see things ranging from "599 WWT" to "599 TWT" or "599
RWT", which could be interpreted as 225, 525 and 425. Whereas the
case that you mentioned above can only be interpreted as "599-25", no
matter what the FIGS is changed into.
You are selectively harping on the first FIGS being smashed and not
addressing the issue of the extra second FIGS from being smashed.
What is so special about the FIGS which USOS inserts that makes it so
special that it won't get smashed? Nature doesn't work that way.
The FIGS in the two cases (dash delimiter or space delimiter) have
equal probability of being smashed -- unless you can present a
mathematical basis of why a space character before a FIGS somehow
makes that FIGS more immune to a symbol error (I can't think of one;
but you are a more experienced RTTY op that I am.)
(Neither are you addressing the basic fact that the more characters
there are, the higher the probability of an error (thus confusion)
event.)
When there is an error hit, the FIGS does not just disappear unless it
gets converted to another non-printing Baudot character; the FIGS gets
converted into another printing character.
When a FIGS at the start of the dashed exchange is smashed, you print
"xTOOAWT" on the screen. When the extra FIGS gets smashed, you print
"599 xWT" on the screen, where x represents the character that the
FIGS is changed to.
So, which is less confusing if the FIGS is converted into a W, which
is a Hamming distance of one away from a FIGS character? I prefer
something like WTOOAWT to something like 599 WWT, especially when the
exchange involves a QSO number. WWT can be mistaken for a "225"
exchange.
You might prefer WWT to something like AWT, in which case I agree that
using a space character is better for you.
Notice that no matter what the FIGS get converted to, a dash delimited
exchange always prints as AWT (-25), even if there are multi-bit
errors in the FIGS.
If the FIGS after a space delimiter is smashed into another printable
character, you can print a large number of things; WWT (225) and more
bizarre exchanges, such as JWT and ZWT when there is a one bit error.
When there are multi-bit errors, the extra FIGS when you use the space
delimiter can now print even more confusing exchanges. For a Hamming
distance of two, what gets printed includes TWT (525), RWT (425), UWT
(725), etc.
Heck, you could even get lucky and the <space><FIGS>25 in the space
delimiter case comes out as " AWT" ("A" is Hamming distance of 2 away
from FIGS.)
If the start bit of the FIGS gets smash, then the question is moot
since most decoders don't do predictive synchronization by looking
ahead at successive start bits. Those that do will have a lag of a
few characters, so you probably would want to turn the function off
during a contest anyway because of the delay. When a start bit is
smashed, you loose quite a few characters and in either case a repeat
of the exchange is needed.
I have wasted enough of everybody's time on this already and will not
continue this thread unless there is a specific question that someone
addresses to me. I apologize for repeating myself and have nothing
newer to offer. I just wanted to dispel the pronouncement that a
space delimiter used in conjunction with USOS is a "must" for
everybody to adopt. I have already earlier mentioned that a dash
works equally well whether you use USOS, and its use is completely
USOS-neutral, working equally well between folks who use USOS and
folks that do not, while the space delimiter produces "miss shifts"
between USOS and non-USOS systems that cannot be resolved even after
an indefinite number of exchange repeats.
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|