[RTTY] CQWW exchange

Bill, W6WRT dezrat1242 at yahoo.com
Tue Sep 30 20:19:05 EDT 2008


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 at 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 at contesting.com
>http://lists.contesting.com/mailman/listinfo/rtty


More information about the RTTY mailing list