[Skimmertalk] Skimmer Experiance: 160M and 10M
Pete Smith
n4zr at contesting.com
Mon Dec 22 20:21:59 EST 2008
There are a number of reasons why, despite paranoid validation, busted
calls can still occur. By busted calls, I'm referring here to miscopies,
not to misidentification as CQing. More on that topic in a bit.
The most significant cause, in my experience, is problems with the USB data
stream caused by contention with other programs. This can be seen as
vertical "blank" stripes in the waterfall, very narrow but enough to turn
an T into an I, for example. The fixes I have found include increasing the
priority of the Skimmer process in Task Manager, and assigning Skimmer to
sole use of a single virtual CPU in dual-core systems (also a Task Manager
function, under "Affinities").
It is true that anything that disrupts reception by Skimmer, including
receiver blocking or tuning the receiver to a different frequency range,
will cause an upset in the decoders that can take a second or so to
resolve. During that period, all decoders that have been deployed are
prone to miscopies.
It is true that Skimmer looks at each decoder in isolation, and over a very
short time interval. Typically, if a callsign is decoded twice on the same
frequency, then Skimmer assumes it is a real decoding, and proceeds to the
validation process. This can lead, particularly with weak signals, noise,
and a less-than-paranoid validation level, to a series of miscopies
occurring in a short series all on the same frequency. I'm working on a
set of rules that will approximate how a skilled operator decides what a
callsign really is under hard conditions, and would welcome suggestions.
It is NOT true that a different set of criteria is applied to spots sent
via Telnet than to those shown on the Skimmer callsign list. If you
choose paranoid, then there must be a match with the master.dta file, or
the callsign is neither displayed nor spotted via telnet. Inevitably, the
master.dta files still include a certain number of plausible but busted
calls - look up the number of variations on IS0SQH sometime.
The problem of identifying CQ-ers is a hard one, and judging by the reports
from this fall, particularly in the ARRL 160 contest, perhaps the most
troublesome one. If a callsign occurs twice on the same frequency within
fairly close proximity to a CQing key-word ("CQ" or QRZ? or "Test", for
example), then the program assumes that station is the one calling CQ. I
have been working for some time on trying to define a set of rules that
explain how a skilled operator determines, to a high degree of probability,
which station is CQing and which is answering the CQ. I'd welcome
suggestions about how to do that.
73, Pete N4ZR
At 05:03 PM 12/22/2008, k3mm at verizon.net wrote:
>This can easily happen when you are using a TX antenna on RX, you are
>using your tranciever IF for skimmer, or your TX signal effectively wipes
>out your skimmer RX input due to overload (quite understandable). This
>leads to lots of truncated calls on the front or backside.
>
>I get the impression that the reason skimmer busts so many calls, even in
>the paranoid mode is that it just looks at how many times it sees a
>particular call on a particular frequency, rather than looking at a
>percentage on a frequency. So if it sees the same bust enough times
>within x amount of time, it posts it as a legitimate call alongside the
>real one.
>
>I also am guessing that it doesnt use master.dta exclusively when
>qualifying spots for broadcast onto packet no matter what setting you use.
>
>IE, the filtering for packet spots is not as effective or selective as
>that displayed in the skimmer window.
>
>Ty K3MM
>
>
>
>Dec 22, 2008 01:14:43 AM, dean at acsnet.com wrote:
>ARRL 160M
>Skimmer was used both on a soft rock receiver
>located at my QTH and on a Flex 5000a with
>Skimmer in IF mode and WD5EAEÂs Skimmer Scheduler
>located at the contest station. Paranoid
>callsign validation was used on both instances.
>
>Skimmer wasn't useful in periods of moderate to
>high activity. There were so many erroneous
>spots that it was better to have both ops concentrating on the run frequency.
>
>It appears that Skimmer was spotting calling
>stations. This seems to happen on stations
>running with Âtest callsign callsign test and
>only with certain callers. Maybe these certain
>callers are better at matching the running
>stationÂs frequency and with the end of the CQ
>message being Âtest (CQ to CW Skimmer?) the CQ
>and callsign twice threshold is met by the end of
>the CQ and the exchange by the running
>station? Just speculation, as I didn't have
>time to investigate this during the contest.
>
>Show non-workable spots was initially turned off
>to reduce the clutter on the band map, but was
>soon turned on so that the correct call would be
>shown for spots that had decoding errors with the callsign.
>
>Skimmer showed its worth when the rates fell and
>the spotting station had time to check the few
>spots that were generated in between the running
>stationÂs CQs. Skimmer did find new stations to
>work. The remote skimmer with a shortened dipole
>at 35ft provided more spots than the local
>skimmer in IF mode (due to the running station,
>limited to 20khz and use of directional beverage antennas?).
>
>This experience was a solid improvement over CQ
>WW when skimmer was disconnected from the logging software.
>
>
>ARRL 10M
>Skimmer was used in IF mode using a Flex 5000a
>that was also the contest radio. During the
>first three quarters of the contest when signals
>were weak and gone quickly, I could see the
>signal on the Flex 5000 PanaFall display and I
>was working the station by the time CW Skimmer
>spotted the station. I also experienced a lot of
>crashes of CW Skimmer early on and then it
>somehow stabilized (I plan to send the log to
>Alex). During the short period the 2nd day when
>the band actually opened, I found skimmer to be
>pretty helpful. When I noticed a new skimmer
>spot and no one was answering my CQs I was able
>to click on the spot, be right on frequency, work
>the station and return to my run frequency if
>skimmer hadn't spotted another station to work
>(since my 20khz decoding window had changed).
>
>For the 10M contest the cluster spots weren't
>useful. Too bad the logging software doesn't
>show skimmer spots in a different color. I don't
>want to disconnect from the cluster so that I can
>see who is working what area and know when I have
>been spotted (and then be disappointed when it
>didn't really make any difference). Maybe it is
>time to expand from 2 monitors to 4 monitors so
>that CW Skimmer is visible along with the radio software and logging software?
>
>I would like to see specific support for the Flex
>radios with CW Skimmer. The main problem is that
>the IF mode is limited to 20 kHz due to filters
>of standard transceivers. With the Flex radio
>the whole 96 or 192 kHz is available to CW
>Skimmer, the center frequency is the VFO frequency.
>
>If two copies of CW Skimmer (one for each
>receiver  VFO A and VFO B) would run in a ÂFlexÂ
>mode with OmniRig reading the center/VFO
>frequency, I think it would be an almost ideal
>implementation: The operating antenna and
>skimmer antennas are the same with no concern of
>accidently transmitting in to the skimmer
>receiver and you can operate and skim two bands simultaneously.
>
>Next Contest: Stew Perry
>I plan to be active in the Stew Perry 160m
>contest next weekend as a Multi-OP-single-person
>with skimmer. It looks like cluster is
>prohibited even for Multi-Op entries, so it will
>be interesting to see skimmer-only spots on the
>band map. I will post again if I learn anything new.
>
>73,
>Dean - N0XR
>
>
>
>
>Dean R Madsen
>dean at acsnet.com ICQ:5510840
>
>_______________________________________________
>Skimmertalk mailing list
>Skimmertalk at contesting.com
>http://dayton.contesting.com/mailman/listinfo/skimmertalk
More information about the Skimmertalk
mailing list