Once upon a time, I was part of a team that wrote a program that could
identify CW signals by taking a variety of measurements - things like
code speed, weight, word and character spacing, transmitter spectrum,
signal strength, and variance of measurements over time (measuring
things like chirp and drift). Such metrics were stored in a file as a
"signature database" of previously-heard stations. An operator could
add more information about a station as well - op's name, location,
callsign, rig, etc. When a signal was being received, its metrics were
compared against the database, and if there was a close enough match,
you knew what station was being received even without it ever even
sending a callsign. The software could tell you how confident it was of
a match. With a high confidence, it was virtually always correct.
This software modelled what a good operator could do - recognizing
familiar signals based on what the "fist" sounded like, even from just a
few seconds of code.
Even with today's largely machine-sent code, you can still usually
recognize the signals of people you work a lot. The computer is just
better at remembering what different ops/stations sound like.
So, IMHO you don't need to decode callsigns to identify dupes. In fact,
since the data for a signature in the database probably includes the
callsign, you could display the likely callsign by simply pulling it
from the database entry for that signature - without ever decoding it at
all.
BTW the software was written in 1975 or thereabouts, so it should be
pretty easy to make today's computers do similar stuff.
The software doesn't have to decode CW or present characters to the
operator at all in order to detect dupes, new multipliers, etc., and
prefill a potential log entry with callsign, section, name et al.
What our 1975 program would do is scan from a lower to an upper
frequency, stop on each CW signal, listen for a few seconds, and put the
probable callsign if the station onto a bandmap, with an indication of
how confident it was of the identification. Might be a nice feature to
have in a contesting program.
Whether such software is legal or not is of course debatable. But it
doesn't "decode CW".
73,
/Jack de K3FIV
On Sat, 2011-01-01 at 07:43 -0700, Steve London wrote:
> Tor,
>
> When a new station shows up, please explain how your program knows if it is a
> dupe without decoding CW ?
>
> 73 and HNY,
> Steve, N2IC
>
> On 12/31/2010 09:45 PM, RT Clay wrote:
> > I'm releasing a new contest logging program I've been working on for the
> > last
> > year. Its name is so2sdr, and the general idea is to explore uses of SDR
> > technology for unassisted SO2R cw contesting. By unassisted, I mean that the
> > program DOES NOT DECODE any cw. It is freely available at:
> >
> > http://code.google.com/p/so2sdr/
> >
> > At this point although I have operated a while using the program, it is
> > still
> > a work in progress, so expect to find bugs and things that are not complete.
> >
> > so2sdr features:
> >
> > -it is dual-platform, running under both Windows and Linux
> >
> > -a SDR panadapter is integrated into the bandmap for showing dupes/new
> > calls:
> >
> > Dupe qso's are marked on the bandmap in a different color. By actually
> > marking the signal traces, it becomes easy to see potential new stations on
> > a
> > band---they stand out immediately (see screenshot at above web page). There
> > is no need to tune across a band sequentially, just jump around to new
> > signals.
> >
> > -logging interface is somewhat like trlog
> >
> >
> > Hardware (and specific contest) support is somewhat limited right now:
> >
> > -radios: Elecraft K3 and K2 -cw generation only via Winkey -SDR: soundcard
> > based SDR connected to rig IF (Softrock, LP-PAN, etc). 96 KHz stereo
> > sampling
> > needed. One is needed for each radio. -parallel port for headphone/radio
> > switching
> >
> >
> >
> > have fun& HNY! You can send bug reports to so2sdr (at) gmail.com
> >
> > Tor N4OGW/5
> >
> > _______________________________________________ CQ-Contest mailing list
> > CQ-Contest@contesting.com
> > http://lists.contesting.com/mailman/listinfo/cq-contest
> >
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|