On Feb 26, 2012, at 10:22 AM, Dave Hachadorian wrote:
> One of these days, in the not-too-distant future, someone is
> going to come up with a RTTY Skimmer, and the whole ballgame will
> change once again, at least in the assisted category.
If you look hard enough, you will find that multiple RTTY decoders already
exists.
I know of two such working systems, one has been made public soon after the
last Roundup I think, and the other remains a private effort. Both were
developed by folks who post on this reflector and during part of their
development, I was in email communications with them (separately; neither knew
I was talking to the other, and both used different demodulation schemes).
Both efforts started last year, and I am sure there are many other such
efforts. When you see an ant on the floor, you know there are many more :-).
When the CW contest managers banned the use of VE3NEA's "CW Skimmer," I thought
it was a horrible idea that would stifle technical progress and innovations. I
had expected RTTY innovators to keep such developments close to their vests to
avoid not being able to use the fruits of their own labors. If I were serious
about contesting, I would write such a thing and then keep it secret.
As such, I suspect there are many such multiple decoders floating around that
have not been made public.
The public one was published by our very own Mario; you can find the sources on
the web. Some compilation required. The non-public one has been around since
at least last July, when the author contacted me.
Both of them require some form of SDR, naturally, and I don't think they have
automatic linkages to QSY a transmitter automatically (yet). In cococaModem,
you can click on a row in the PSK31 tableview (what cocoaModem calls its PSK31
"skimmer") and the program will QSY your transmitter to the correct frequency
-- a quick QSY is an easy thing to implement.
OK, I might as well divulge an idea that I have only previously discussed with
Doug K4DSP... for DX that is working a split pileup, install a parser on his
data stream to do callsign recognition (recognizing anything that smells like a
callsign). Then in the skimmer (or whatever name you call a multiple decoder),
do an automatic search for that callsign and highlight any row in the skimmer
table where that callsign had appeared in most recently. A single keyboard
shortcut then takes your transmit VFO automatically to the most recent spot,
ready to pounce once you see the DX issue his next QRZ.
For that matter, here is another idea that I had previously discussed with Doug
on how to make working split DX even more of a "shooting fish in a barrel"
proposition. Add a macro which "stages" your callsign in your transmit buffer
but don't key the transmitter yet (i.e., like a type-ahead). Install a
"carrier detect" algorithm on the DX frequency. Once the DX's carrier drops,
the already "staged" callsign gets transmitted automatically, without any
additional keystroke or mouse click. This obviously works with contest
exchanges too; it might even shave a few magical milliseconds that contesters
seem to crave, off of each contest exchange.
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|