you are making my points for me. I thought it was you that was
bemoaning the lack of the human touch in contesting. :-)
73, Bill W6WRT
------------ ORIGINAL MESSAGE ------------
On Tue, 30 Sep 2008 16:23:36 -0700, Kok Chen <chen@mac.com> wrote:
>
>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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|