Monday, January 10, 2022


Where to Get RBN Spots – For Users

In the last few days, it has become apparent that there is some confusion about where users can get RBN spots.  This brief note is an attempt to clear this up. 

First, for CW and RTTY spots, which are supplied identically to DX clusters around the world, the best resource is AD1C’s website,  If you look in the “Telnet Directory” on the site, you’ll find well over 100 clusters worldwide, sorted by country, that carry RBN spots.  Each is tagged with “(+RBN)” right under the callsign.  Since CW and RTTY spots are handled identically by the RBN server, this list should be users of those modes’ “go-to” resource.

It’s also worth noting that each major cluster software package takes a different approach to RBN spots.  ARCluster nodes carry RBN CW/RTTY spots by default unless turned off.  CC and DXSpider nodes require SET/SKIMMER to turn them on

FTx (FT4 and FT8) spots are a different matter.  They are distributed separately by the RBN, and are not carried by many DX clusters.

Following is a list of those clusters we know of now that carry FTx spots.  In many cases, these nodes require a SH/FT8 command to enable FT-8 spots

W9PA-5 (FT8 on by default)

RBN spots are 99% accurate, but nowadays they also make up around 99 percent of all spots, so busted spots can be an issue.  Each of the three major DX cluster software packages employs its own sort of spot-quality filtering to get rid of busted spots.  Details are too complicated to go into here, and you’ll have to decide for yourself which works best for you. 





Tuesday, September 28, 2021

How Skimmer Server Decides What to Spot - Beacons and More

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@@@




+ 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





Watch list





+ in pattern file





No + but in file





Not in file





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:


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.

Sunday, February 28, 2021

Info from N6TV on implementing CWSL on a Red Pitaya 122-16

 Everything you need to do is explained at the bottom of the CWSL_Tee web site:

But some of the links are broken, and you have to go down one level and click Download to actually get the links to the files.   Here are some direct links:

Important additional steps  In the SkimSrv2 folder:

Rename SkimSrv.exe to SkimSrv2.exe
Rename CWSL_Tee.dll to CWSL_Tee2.dll
Rename HermesIntf_xxxx.dll to HermestIntf_FFxx.dll 

Update CWSL_Tee.cfg:

To access either receiver with HDSDR, copy Extio_CWSL.dll to the HDSDR folder, and copy Extio_CWSL.dll to Extio_CWSL2.dll to access the second receiver.

Monday, November 16, 2020

Editing the file for 16-bit Red Pitaya on a Windows Computer

 Bjorn, SM7IUN has brought my attention to a potentially important caveat in editing the file to activate two entirely separate receivers on an RP-16.

The RP-16 is a Linux device, so the file must be compatible with Linux.  However, if you edit a Linux file using Windows Notepad, the edited file will come out with <CR><LF> at the end of each line, rather than the Linux standard <LF>.  This, in turn, could result in its no longer working under Linux.  While I have not yet had this problem with my RP-16s, it's worth knowing about.

Fortunately, there is an easy solution - Notepad++.  Written by Don Ho, it is freeware, and senses whether a file selected for editing follows the Linux convention or the Windows and ends lines appropriately.  A worthwhile precaution, I'd say. 

Sunday, November 15, 2020

How to Post Two Receivers' Output to the RBN under Two Different Receiver Names

As outlined in my post a couple of weeks ago, it is not possible, using a single Aggregator, to post spots from the two receivers in an RP-16 to the RBN under separate receiver names.  Fortunately, Dick Williams, W3OA, the author of the Aggregator, has figured out a work-around.  Here's his solution:

1)  Update Aggregator to version 6.2.  Aggregator will now show the name of its executable file in the title bar at the top of its window.  This enables you to determine which Aggregator instance the window refers to.

2) Aggregator was running from C:\Ham Stuff\Aggregator. I created a new folder, C:\Ham Stuff\Aggregator2, and copied Aggregator.exe from the original folder to the new one.  Also copy BADCALLS.txt if you are using that filter.

3) Rename Aggregator.exe in the new folder to Aggregator2.exe.

4) In your first Aggregator instance go to the “Secondary Skimmers” tab, find the line which connects to the second SkimSrv instance, click the “D” button, and uncheck the “Auto Connect?” box.

5) Again in your first Aggregator instance go to the “FT#” tab and uncheck the “Use?” box for each source which receives spots from the “Rig Numbers” on the right half of the FT#StartUp window, i.e SkimSrv2.  Then click the “Apply Changes” button.

6) In your second SkimSrv instance go to the “Operator” tab and update the entries there as necessary.  The callsign should be the SSID you want to use for that Skimmer.  (I used W3OA-2.)

7) Start your second Aggregator instance and go to the “Connections” tab to set the second SkimSrv instance as the “Primary Skimmer Connection” for this Aggregator instance.  While on this tab change the “Local User Port Number” so it's not the same as in the first Aggregator instance.

8) Complete setting up the second Aggregator instance paying particular attention to the “Spot Filters”, “Patt 3Ch.lst”, and “FT#” tabs.  On the “FT#” tab add the sources you disabled in the first Aggregator instance in step 5. Then click the “Apply Changes” button.

9) Return to the first Aggregator instance, go to the “Associate Pgms” tab, and add the second Aggregator instance.  

Ethernet/Internet requirements for 2-receiver Red Pitaya

 Ash KF5EYY/3V8 just reminded me of an additional requirement for running both receivers on an RP-16, to cover 8 bands each.  Each receiver requires about 75 Mbps of Ethernet bandwidth between the receiver and your PC, and it adds up.  This means that your PC must have a gigabit Ethernet port in order to receive two receivers worth of 8-band x 192 KHz data.

My PC has such a port, but like many it was already committed to my Internet router.  Fortunately, Netgear makes a very nice unmanaged Ethernet switch, the GS 308 which retails for under US$20 plus shipping.  All I had to do was plug my receiver, my PC, my KPA-1500 amp and my router into the switch, and it was up and running.  Whew!    

Monday, September 21, 2020

Part 2 - Using the Two Receivers in Your Red Pitaya

The RP-16 has a hidden, bonus capability – it can run a second, 8 bands x 192 KHz receiver alongside but independent of the first.  This capability has a lot of potential uses – I often use it for comparing two antennas.  I have also used it to run RTTY Skimmer Server along with CW Skimmer Server on a single antenna,  without having to resort to CWSL_Tee to share the output from a single receiver .  Many operators use it to expand coverage on CW or RTTY to as many as 11 or 12 bands at once, or to add FT4 or FT8 capability.

One caution, to be mentioned first for emphasis– if you run two Skimmer Servers on the two receivers of the RP-16, do not try to send spots from both to the Reverse Beacon Network.  You would think that by identifying the Skimsrv operator by two different callsigns, like W8QZR and W8QZR/3, for example, they would appear separately on the server.  The problem is that the RBN Aggregator is only capable of reporting one operator callsign to the RBN server, so each spot will be attributed to one call, and any stations that both receivers spot will appear twice.    This is a function of how the Aggregators communicate with the server and, at least for the moment, cannot be changed. 

Of course, this caution does not apply to running CW Skimmer Server on one receiver and RTTY Skimmer Server on the other, since their modes are different.  It also obviously does not apply to using one receiver on one set of bands, and the other on different ones, as you might do to optimize receiving or covering 6 meters along with HF. 

There are two options for the second receiver – it can either share the antenna with the first receiver, or it can use the second input on the RP-16 to connect a separate antenna.  

When you boot up the RP-16, it starts two separate receivers and connects them to two different IP addresses.  From there on, it’s up to you – you can connect a separate instance of Skimmer Server (see below), or any SDR that can use the Hermes_intf.dll.  The only one I have tested this with is HPSDR. 

To use a separate antenna on the second receiver, put the RP-16’s SD card in your reader and bring up the file for the hpsdr-compatible receiver in your text editor.  It is pretty short and simple, and will look like this: 


source $apps_dir/

cat $apps_dir/sdr_receiver_hpsdr/sdr_receiver_hpsdr.bit > /dev/xdevcfg

address=`awk -F : '$5="FF"' OFS=: /sys/class/net/eth0/address`

ip link add mvl0 link eth0 address $address type macvlan mode passthru

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter

$apps_dir/sdr_receiver_hpsdr/sdr-receiver-hpsdr eth0 1 1 1 1 1 1 1 1 &

$apps_dir/sdr_receiver_hpsdr/sdr-receiver-hpsdr mvl0 1 1 1 1 1 1 1 1 & 

All we are concerned with is the last line, and to activate the second receiver on its own antenna all we need to do is change each of the “1”s in that line to a “2”, So it reads "$apps_dir/sdr_receiver_hpsdr/sdr-receiver-hpsdr mvl0 2 2 2 2 2 2 2 2 &”.  Save the file to your SD card, and the second receiver is ready to go, on its own antenna. 

In order to run Skimmer Server on the second receiver, you’ll need to create a separate instance of Skimmer Server in your computer, with a different name, and also rename the executable.  What I did was to install it under the program folder name “Skimsrv 2”, and rename the executable from Skimsrv.exe to Skimsrv2.exe. 

There’s one final thing to be done before you start the two simultaneous receivers.  In the first Skimmer Server program folder, find the Hermes_Intf.DLL.  Rename it to explicitly recognize the first receiver.  The MAC address of that receiver is printed on top of its Ethernet connector.  You need to copy the right-most four characters of the MAC address, and then use them to rename the Hermes_Intf.dll file.  In my case, it became HermesIntf_7c93.dll.  Don’t forget the “_”. 

Now go into your second Skimmer Server directory and rename its HermesIntf.dll, in this case replacing the first two characters of the MAC address with “ff”.  Rename the HermesIntf.dll as you did above for the first.  In my case it became HermesIntf_ff93.dll. 

And now, finally, it’s ready to go.  Start CW Skimserv on the first receiver.  Go to its Skimmer tab and verify that it has the correct address, like this:


Now start the second instance of Skimmer Server and verify the same thing:



Now you can connect a second antenna to the second SMA input connector on the RP-16 (next to the first one), and you’re off and running. You can get data from either receiver using a Telnet program like Putty – be sure they have different Telnet addresses on the Telnet tab in Skimserv.  You can also use the Aggregator’s Skimmer Traffic tab to follow what each is spotting, but if you do that, be sure that you check the “don’t send spots to RBN server” box on the Connections tab (far left side) and set up the Secondary Skimmers tab with the right (different) Telnet port number to connect to the second instance of Skimsrv.