How Skimmer Server
Decides What to Spot – Beacons and More
Note: As
changes/additions are made, I will add them in blue text. Why
blue? Because it’s my favorite color.
I’ve just spent a couple of days in back-and forth e-mails
with Alex, VE3NEA, and decided that it would be useful to clarify how both
node-ops and station-ops wanting to spot or be spotted could maximize their
chances. I apologize for the length of this, but there’s material here you’ll
find nowhere else. If you’re not an RBN
node-op, you can skip right to number 3 below.
1.
First, for node-ops, there are a couple
of basic considerations:
·
Make sure your CW Segments (or RTTY Segments, if
you’re working with RTTY Skimsrv) are set to cover the frequencies you want,
and exclude those you don’t. That second
part is particularly important for RTTY, which is very resource-intensive. If you spend a bunch of decoders trying to
copy FT4, FT8 or other non-Baudot transmissions with RTTY Skimsrv, you can
easily swamp your PC. Just look up the
latest list of frequencies for those modes and create CW segments that exclude
them; for example, you can write CW or RTTY Segments for 14000-14072 and
14083-14100 or 14083-14105 if you also want to capture the NCDXF beacons at
14100. Do similar things on other bands,
avoiding published FT4/8 bands and capturing the frequencies you want, either
for QSOs or for beacons. There’s no
practical limit on the number of CW or RTTY Segments, but of course the
frequencies they define must be within the coverage set by the band segments in
use.
·
There is one other basic consideration if node-ops
want to copy beacons that do not send the CQ keywords (CQ and TEST) as part of
their transmissions. You must tell CW
Skimsrv, on its Telnet tab, to send all spots to the Aggregator, not just CQ
spots. There’s no reason not to do this,
because the Aggregator will sort out beacons and make sure they are
spotted. More on this below.
2.
The second important consideration, again for node-ops,
is whether the callsign of the station to be spotted is recognized by Skimsrv
as likely valid, and therefore qualified to be passed on to the Aggregator.
This recognition is based on three devices.
·
The watch list, file name watch.lst, is a
text file stored in the Skimsrv or RTTYSkimsrv folders in C:\Users\[your
username]\Appdata\Roaming\Afreet\UserData.
It is not editable from within CW or RTTY Skimsrv, but must be edited
using a simple text editor like Notepad. Note also that there is no default watch.lst - you have to create your own. You might choose to put in it callsigns like those of the NCDXF beacons
(4U1UN, etc.), to make sure they are spotted whenever they are decoded.
·
The validation level, which is set by the
node-op in CW or RTTY Skimsrv
·
The pattern file, filename patt3ch.lst, which
is stored in C:\Users\[your username]\Appdata\Roaming\Afreet\Reference. It consists of one line for each known
callsign pattern. Here’s a snippet:
+ OH2@@
+ OH2@@@
OH2@@@@
OH3###@
OH3@
+ OH3@@
+ OH3@@@
As you can see, each pattern is denoted by its first three characters,
whatever they are, plus “wildcards” for additional numbers (#) or letters (@).
For most callsign structures, the Patt3Ch.lst file includes the
patterns that have the first three characters of the call, and the rest
of the characters are replaced with the # (any digit) or @ (any letter)
symbols. For example, the pattern of the VE3NEA call is VE3@@@, and the
pattern of HA2021ITU is HA2###@@@. However, there are two exceptions.
- If the call starts with letter-digit-letter, then only the first two
characters are kept explicit, so the pattern of N4ZR is N4@@.
- If the call starts with digit-letter-letter, then 4 characters are
kept, so the pattern of 3DA0RU is 3DA0@@.
In the portable callsigns the base call and the portable prefix are
analyzed separately, and the lower of the two results is taken. The
portable prefixes are listed in the PortPref.lst file. This file does
not use the @ and # symbols, but it uses the square brackets that mean
'any of', so KP[15] means KP1 or KP5.
There’s one other important feature.
Each pattern can be shown either with or without a “+”. The “+” means that the callsign pattern is
among those more commonly seen on the air.
Listing of a pattern without the “+” means that it has been seen, but
less often. And finally, if a pattern
does not appear, that means that it has not been seen at all.
An example: Say a station, call him BY1AA has been active on the
air. His callsign pattern, BY1@@, will
be marked with a “+”. If he has not been
that active, it might not have the “+”, but it is still on the list. But now he
gets a contest call with a single-letter suffix, like BY1A. The pattern BY1@ is not on the list at all. What that means is that his call will have to
be decoded much more often before a spot is sent up to the RBN for distribution.
What does “more often” mean? CW
Skimsrv works by assigning a 50-hz wide decoder channel to each signal it
hears. It then “looks at” a constantly
updating 256-character sample from that decoder, and if the callsign is
repeated enough in that length of time, the station is spotted.
An initial patt3ch.lst file is distributed with CW and RTTY Skimsrv, and
the organizers of the RBN have published updated versions at least every year,
based on calls that have been heard in the time since the last list came
out. Sometimes, the organizers will
release an updated pattern file when some special event occurs. For example, when EA amateurs were permitted
to have single-letter suffixes, the RBN distributed a revised pattern file with
those callsign patterns. RBN node-ops
are notified whenever they start the Aggregator if the pattern file on the RBN
server is different from the one they have currently. There is an easy one-click option in the
Aggregator to quickly and easily download the new pattern file.
·
The table below will explain why you need to
know all this. The interaction of the
Watch list, the pattern file, and the validation level the node-op has chosen
(ranging from Minimal to Paranoid) determines how many times Skimsrvs must
decode a given callsign before “deciding” to accept it and send the spot on to
the RBN.
Number of Repetitions Required to be
Spotted
|
Pattern File/Validation
|
Minimal
|
Normal
|
Aggressive
|
Paranoid*
|
|
Watch list
|
1
|
1
|
2
|
2
|
|
+ in pattern file
|
2
|
2
|
4
|
-
|
|
No + but in file
|
2
|
3
|
4
|
-
|
|
Not in file
|
2
|
5
|
-
|
-
|
|
Not ITU prefix
|
-
|
-
|
-
|
-
|
3.
Now
we get to the user part, which is pretty simple. For users or beacon operators who want to
make sure their transmissions result in spots, there are several cautions:
·
For non-beacons, be sure you send one of the
keywords – TEST or CQ (FD, SS, NA and UP also work in appropriate settings) –
at least once in each transmission. Send
your callsign at least twice. When in
doubt, send it 4 times. It doesn’t
necessarily have to be all in the same transmission, because of the length of
the decoding buffer.
·
Make sure the CW is good – letter formation and
spacing, and 3:1 dot/dash
ratio. Any errors here may manifest themselves as copying
errors. Use a memory keyer or software, if feasible,
to be sure of this. Skimsrv is pretty
forgiving, but there are limits. Above all, avoid using half-spaces right before or right after your
callsign.
·
If you want to repeat a transmission right away
and have the same station spot you again – in antenna comparisons, for example
– you must QSY a half-KHz or
so before making the next transmission.
Skimsrv will not spot you on or close to the same frequency more than
once every 10 minutes.
·
When operating remotely, check to be sure your CW is clean as
transmitted – Internet latency can garble your CW.
·
For beacons, and particularly ones that are in
the normal CW parts of the bands, make sure that your call and frequency are on
one of the five most commonly-used beacon lists:
https://www.keele.ac.uk/depts/por/50.htm
https://www.keele.ac.uk/depts/por/28.htm
http://www.newsvhf.com/beacons2.html
https://mmmonvhf.de/beacon/beacon.csv
http://www.qsl.net/wj5o/bcn.htm
The Aggregator downloads these files
from the server every night and automatically updates its beacons.csv
file. It checks every spot it receives
against the file and uploads those that it receives from Skimsrv or RTTY
Skimsrv, as well as any spots with /B on the end of the callsign, regardless of
the presence or absence of keywords.
