RTTY
[Top] [All Lists]

Re: [RTTY] CQWW exchange

To: RTTY Reflector <rtty@contesting.com>
Subject: Re: [RTTY] CQWW exchange
From: Kok Chen <chen@mac.com>
Date: Tue, 30 Sep 2008 16:23:36 -0700
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
On Sep 30, 2008, at 3:25 PM, Bill, W6WRT wrote:

> 1. Propagation knowledge. What band to work and when, and perhaps more
> importantly, when to give up and change bands.

Already automated today -- although some of guys on this reflector had  
complained about the automated PSK beacons, instead of making use of  
the information.

It is better than human skills since it gathers the data in real time,  
with no guesswork that is based on "experience" :-) :-).

> 2. Macros. Getting the "perfect" macro is half the fun, to me anyway.
> It's like a contest within a contest.

You are easily entertained, Bill :-).

> 3. Timing. When to call, when  not to call.

Why do you think a computer algorithm cannot do better?  You can  
probably train a Bayes algorithm (like the junk email filters) which  
will beat a human after a couple of contests.  In fact, a computer  
algorithm is never distracted (unless you hit a blue screen) and react  
to a carrier drop from the other station much faster than a human can.

Hmmmm... I just thought of an interesting function to add to cocoaModem:

Today, we have transmit/receive button or buttons in software modems,  
right?

What if we add an "auto transmit" button -- hit that, and the modem  
program waits for carrier detect to drop (i.e., the other station  
stops transmitting) and then starts transmitting the queued exchange  
right after it sees carrier detect drop.  It should be very trivial to  
implement in any contest program.  The op will not have to react to a  
carrier drop by ear before and then clicking transmit.  It might gain  
you half a second per exchange.  Some contesters actually care about  
1/2 a second :-).

> 4. Radio control. Using RIT, bandwidth selection, spectrum display and
> all the other bells and whistles.

The automated software is controlling all that for you, and  
optimally.  You don't need to lift a finger. There is no need to play  
with bandwidth seletcion since a good radio has a decent dynamic range  
across a wide bandwidth and the signal detector uses the optimal  
bandwidth for the given condition (Mark Only and Space Only are  
automated by using a soft decision on the output bits from M/S, MO and  
SO demodulators -- 3 demodulators, odd number = good :-).

Or you can spawn multiple demodulators, each having a different  
bandwidth and the soft decision maker picks the best signal from all  
of them.  (cocoaModem already have multiple demodulator for a single  
RTTY signal -- I don't use it to decide on filter bandwidths, but use  
them to compensate for different fading parameters in the ATC  
implementation -- but there is no reason where the soft decoder is  
based on more demodulators, including ones with different bandwidths --

i.e., instead of switching a demodulator between a bank of filters,  
you just implement a bunch of demodulators each with its own filter  
(this is effortless in object oriented programming by the way - you  
just program one demodulator and then "instantiate" multiple copies  
giving each copy a different bandwidth parameter) -- and you run all  
the demodulators concurrently.   Remember when we used to run two  
modems at the same time and watch the print from both?  Sometimes one  
prints a character that the other does not print -- that is pretty  
much what cocoaModem does, except there are today 9 demodulators, not  
two.  We can add more demodulators with other parameters such as  
filter bandwidth, and run 30 demodulators all looking at the same  
signal.

With machine decoding modes like RTTY, there is really no need in this  
age where your computer is mostly idle otherwise, to depend on the op  
to switch filters when band conditions require it.  Sure, it lets any  
idiot run RTTY -- but that was my original argument, remember?  That  
software can do much of what we regard as operator skills.

> 5. And finally, developing one's radio "instincts". I can't define it,
> but all good operators know it when they see it. Some folks become
> almost like a part of the radio and other folks never get it at all.

A good software heuristics might beat ad-hoc instincts.  And the  
computer does not need a potty break.

73
Chen, W7AY

_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

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