Note - new information below in bold, since this was initially posted.
From time to time, people ask me how to spot more beacons, or why RBN nodes don't spot more.
For many beacons, the question has a trite answer - because the nodes aren't covering and decoding the frequencies where the beacons are. The question is "why?", and the answer lies in the SkimServ.ini file used by the Skimmer Server software, and in your Skimmer Server settings. The NCDXF beacons are a special case, and we'll deal with that a bit later.
First, the easy ones. Open Skimmer Server, and select the Telnet tab. Make sure that the box "Send only CQ Spots" is unchecked. Unless you do this, you'll never send any beacon spots. Set the Validation level to "Normal", because the beacons may not be sending the keywords or the optimum number of repeats of their callsigns needed to be recognized by CW Skimmer.
Now let's fix the .ini file. The first small challenge is to find the file. In Windows XP, it is typically installed in the Afreet folder under Program Files. In Windows 7 and beyond, you'll most likely find it in C:\Users\[your logon name]\AppData\Roaming\Afreet.
Once you track it down. open it and you'll see this group of lines:
CenterFreqs48=1822750,3522750,3568250,7022750,10122750,14022750,14068250,18090750,
21022750, 21068250,24912750,28022750,28068250,50022750,50068250,50113750,50159250
CenterFreqs96=1845500,3545500,7045500,10145500,14045500,18113500,21045500,24935500,
28045500, 28136500,50045500,50136500
CenterFreqs192=1891000,3591000,7091000,10191000,14091000,18159000,21091000,24981000,
28091000,50091000
SegmentSel48=000101001
SegmentSel96=001111111
SegmentSel192=001111111
CwSegments=1800000-1840000,3500000-3590000,7000000-7090000,10100000-10130000,
14000000-14090000,18068000-18095000,21000000-21090000,24890000-24920000,
28000000-28090000,50000000-50100000
The first three rows are center frequencies for each of the three possible bandwidths. You'll note that the actual bandwidth covered by each is slightly less than its name would suggest - for example, 192 KHz actually covers 91 KHz below and 91 KHz above the center frequency, not 96. With many of the beacons you want to spot 100 and more KHz above the lower band edge, you'll want to run 192 KHz bandwidth to be sure to find them - on 10 meters, some are even above 28.182, so you may want to define a second 10-meter segment to allow your QS1R to listen higher.
The next magic trick is in the line titled "CWSegments." This is something that Alex added in order to conserve computer power by not decoding a lot of junk, like RTTY, PSK31, etc. Fortunately, the way Alex implemented it is quite flexible. You can add segments at will, simply by adhering to the format, which uses frequencies to the nearest Hz, and separating them with a comma For example, if you want to capture the NCDXF beacon frequency on 20 meters, you'll want to add a CW Segment of 14095000-14105000. To avoid all the RTTY activity on 20 meters, you might want to split the 20M segment in two - 14000000-14070000,14095000-14105000.
Incidentally, if you like to make as many contest spots as possible, you may also want to modify this line, because during CW contests people frequently operate up into and well beyond the RTTY/PSK segment. The cost of opening it up, of course, is that if the RTTY guys stick it out during the CW contest, you'll get some of the "EE5EEE" type of junk spots.
The NCDXF beacons are a special case, because they only sign their callsigns once before they begin their power step-downs, and then the next beacon takes over. As a result, CW Skimmer and Skimmer Server often don't hear enough repetitions to validate and spot a callsign.
CW Skimmer has a special function called a Watch List, which is discussed in the Help file. Put the beacon callsigns on the list, and they will be spotted the first time they are heard. Unfortunately, there is no Watch List in Skimmer Server. Alex says that there is an update in the works, and hopefully this capability will be added. Stay tuned.
So that's the story to date. Let me know if you find this useful.
73, Pete N4ZR
Tuesday, January 28, 2014
Tuesday, December 24, 2013
A New Tutorial on Using the RBN
It has been over three years since I last wrote a tutorial for users of RBN spots, and I was amazed when I read the old one to discover how much things had changed. Here's the current word.
There are two RBN Telnet servers, at telnet.reversebeacon.net port 7000 and arcluster.reversebeacon.net, port 7000. The intended use of these servers, however, is not to provide spots to end users, but rather to feed spots to AR Cluster and CC Cluster nodes worldwide for "retail" distribution.
To find a cluster node that provides what you want, go to and search by software type. Of course, geography is pretty unimportant these days, with the demise of RF clusters, but you'll want to check to be sure the node you use has Skimmer spots from the RBN as well as the filtering capabilities you want.
Both ARCluster Version 6 and CC Cluster provide a choice to users as to whether to include spots from the RBN in the spots they receive. More importantly, each has its own set of filtering capabilities, with quite different underlying philosophies. Why filter? Because even on a Monday morning, the RBN typically pumps out more than 120 spots per minute, and during a contest, the flow can be 20 per second average.
If you use a VE7CC (CC Cluster) node, he has already made some decisions for you. His nodes provide de-duped data, which all by itself will cut the volume of spots by more than 80 percent, and he has done some pre-processing to reduce busted spots.
A complete list of CC Cluster commands is at http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm. The easiest way to set filters is to use the very versatile CC User client program, available from http://www.bcdxc.org/ve7cc/default.htm#prog
Among other useful features, CC User can be used between a cluster node and a logging program, to make it easy for you to manage your filters.
A caution - CC User is usable with DX Spider, CC and AR Cluster version 4 nodes. It is not compatible with AR Cluster Version 6, which has adopted an entirely new "Boolean" filter syntax.
The AR Cluster commands are at http://ab5k.net/ArcDocsVer6/UserManual/ArcCmdSummary.htm. As you can see, the default AR Cluster posture is not to remove duplicate spots. This offers one important benefit - to use a program such as Viewprop, which relies on spots to and from your area to give you a near-real-time portrayal of propagation, you must have access to all spots of each station.
AR Cluster also has a client program, available at AB5K's web site. It provides for setting a wide variety of user-defined filters, including duplicate removal if you wish
A feature not found in CC Cluster is the inclusion of CT1BOH's "skimquality" algorithms, which flag verified spots (ones heard by more than 2 Skimmers), QSYing stations (which may occasionally be image spots), and busted spots (based on a complex statistical algorithm. Here's a sample of the output:
Note the spot of OK7FL as K7FL, about 3/4 of the way down - the algorithm not only identifies the spot as a likely bust, but also tells you what the correct call is. You can filter on any combination of these attributes - for example, so that you do not see busted spots, or QSY spots until they are verified by at least 3 Skimmers.
A beauty of the AR Cluster filtering approach is that you can create compound filter selections to store very complex filtering combinations as a single string. for example, the Hi-Q button on my N1MM Logger Telnet window above, when clicked, tells the cluster "SET DX FILTER call=n4zr OR (NOT Skimbusted and spotterstate=[MD,PA,VA,NJ,WV, NY,NJ,NC]). This lets through any spots of my station from anywhere in the world, and lets through both Skimmer and traditional spots from the states listed, deleting any that the cluster believes to be busted. Here's a sample with the filter in use:
Note that since I did not choose to block the first spot of a new station or a previously-spotted station on a new frequency, spots coded ? and Q come through immediately.
That's about the whole story. I hope this encourages more people to use Skimmer/RBN spots for CW, RTTY and BPSK.
73, Pete N4ZR
There are two RBN Telnet servers, at telnet.reversebeacon.net port 7000 and arcluster.reversebeacon.net, port 7000. The intended use of these servers, however, is not to provide spots to end users, but rather to feed spots to AR Cluster and CC Cluster nodes worldwide for "retail" distribution.
To find a cluster node that provides what you want, go to
Both ARCluster Version 6 and CC Cluster provide a choice to users as to whether to include spots from the RBN in the spots they receive. More importantly, each has its own set of filtering capabilities, with quite different underlying philosophies. Why filter? Because even on a Monday morning, the RBN typically pumps out more than 120 spots per minute, and during a contest, the flow can be 20 per second average.
If you use a VE7CC (CC Cluster) node, he has already made some decisions for you. His nodes provide de-duped data, which all by itself will cut the volume of spots by more than 80 percent, and he has done some pre-processing to reduce busted spots.
A complete list of CC Cluster commands is at http://bcdxc.org/ve7cc/ccc/CCC_Commands.htm. The easiest way to set filters is to use the very versatile CC User client program, available from http://www.bcdxc.org/ve7cc/default.htm#prog
Among other useful features, CC User can be used between a cluster node and a logging program, to make it easy for you to manage your filters.
A caution - CC User is usable with DX Spider, CC and AR Cluster version 4 nodes. It is not compatible with AR Cluster Version 6, which has adopted an entirely new "Boolean" filter syntax.
The AR Cluster commands are at http://ab5k.net/ArcDocsVer6/UserManual/ArcCmdSummary.htm. As you can see, the default AR Cluster posture is not to remove duplicate spots. This offers one important benefit - to use a program such as Viewprop, which relies on spots to and from your area to give you a near-real-time portrayal of propagation, you must have access to all spots of each station.
AR Cluster also has a client program, available at AB5K's web site. It provides for setting a wide variety of user-defined filters, including duplicate removal if you wish
A feature not found in CC Cluster is the inclusion of CT1BOH's "skimquality" algorithms, which flag verified spots (ones heard by more than 2 Skimmers), QSYing stations (which may occasionally be image spots), and busted spots (based on a complex statistical algorithm. Here's a sample of the output:
Note the spot of OK7FL as K7FL, about 3/4 of the way down - the algorithm not only identifies the spot as a likely bust, but also tells you what the correct call is. You can filter on any combination of these attributes - for example, so that you do not see busted spots, or QSY spots until they are verified by at least 3 Skimmers.
A beauty of the AR Cluster filtering approach is that you can create compound filter selections to store very complex filtering combinations as a single string. for example, the Hi-Q button on my N1MM Logger Telnet window above, when clicked, tells the cluster "SET DX FILTER call=n4zr OR (NOT Skimbusted and spotterstate=[MD,PA,VA,NJ,WV, NY,NJ,NC]). This lets through any spots of my station from anywhere in the world, and lets through both Skimmer and traditional spots from the states listed, deleting any that the cluster believes to be busted. Here's a sample with the filter in use:
Note that since I did not choose to block the first spot of a new station or a previously-spotted station on a new frequency, spots coded ? and Q come through immediately.
That's about the whole story. I hope this encourages more people to use Skimmer/RBN spots for CW, RTTY and BPSK.
73, Pete N4ZR
Friday, December 20, 2013
Finding Your Spots
Want to find spots of your callsign on a particular day, like during the 2 days of CQWWCW?
Bob, N6TV has come up with an easy .cmd script for use under windows, as well as a version for Linux. you can download them as a zipfile at http://bit.ly/GetSpots.
Use notepad to open the .cmd file, and you'll see that it specifies the filenames of .csv files from the RBN's Raw Data archive. You can change the filenames to anything you want, add more, etc. Then put the .cmd file in the same directory as the .csv files you've downloaded. Run it, specify the callsign you want extracted, and boom, it creates a .csv file in the format [call].csv. Very neat.
Bob, N6TV has come up with an easy .cmd script for use under windows, as well as a version for Linux. you can download them as a zipfile at http://bit.ly/GetSpots.
Use notepad to open the .cmd file, and you'll see that it specifies the filenames of .csv files from the RBN's Raw Data archive. You can change the filenames to anything you want, add more, etc. Then put the .cmd file in the same directory as the .csv files you've downloaded. Run it, specify the callsign you want extracted, and boom, it creates a .csv file in the format [call].csv. Very neat.
Tuesday, December 17, 2013
CQWW CW 2013 - RBN Stats by N6TV
Once again, Bob, N6TV has compiled statistics on the RBN during the 2013 CQWW CW contest. But as seems to happen a lot to us, the infrastructure isn't up to the task. In this case, it's the blogspot editor, which can't handle a file this big, so I have put the data out on Dropbox in .pdf form. You can access the file (and download it if you wish) at this Dropbox location.
73, Pete N4ZR
73, Pete N4ZR
Friday, September 27, 2013
Crunching the Numbers
One of the potential benefits of the RBN has been the use of our archive for studies of propagation, but a barrier to that has been the difficulty of importing and managing all that data. Now Stephen, WD5EAE has developed a technique for importing some 240 million RBN spots into PostgreSQL. You can read all about it at his web site.
Already doing propagation analysis with RBN data? We'd love to hear about it!
Already doing propagation analysis with RBN data? We'd love to hear about it!
Wednesday, August 21, 2013
Using the Funcube Dongle Pro+ with CW Skimmer
by Gabriel Sampol, EA6VQ
reproduced with permission of the author from
http://www.dxmaps.com/funcube.html
Editor's note: The Funcube Dongle Pro + is a tiny and relatively inexpensive receiver that plugs into a USB port and is capable of 192-KHz coverage between 150 KHz and 1.9 GHz. Because it does not blank out US cellular telephone frequencies, the DP+ is not legal for use in the United States. For interested readers elsewhere, you can read more at the maker's website.
First of all I noticed that CW skimmer was recognizing it and it was receiving if I configured it as a Softrock with a 192 kHz Sampling Rate.
However, the frequency received had nothing to do with the value of "LO Frequency, Hz". There was an offset all over the band.
I then realized that the shown frequency had to do with the last frequency set in the Funcube by another SDR program (SDRsharp) that I had used just before, so it was a matter of setting the right frequency with a program that supports the Funcube and setting that same frequency in CW Skimmer.
With this simple two-step procedure you can satisfactory use the Funcube Dongle PRO+ with CW Skimmer, and of course also use it for the Revese Beacon Network thru Aggregator.
This is an example on how to set the LO frequency to 28095 kHz, to cover the lower portion of the 10m band.
1. Download the FCHID (FCD+ Frequency Control Program) program for Funcube, place it in the CW Skimmer folder (for instance) and run it. Set the frequency to 28095.
2. Set the LO Frequency to 28095 also in CW Skimmer, as shown in the first image.
And that's it. You will be receiving the 27999 to 28191 kHz band and the frequencies shown in Skimmer will be correct.
No need to say that if you want to receive another band you will have to repeat both steps.
Well, now that I had it working I wanted to go one step further and find a way to switch bands automatically, so that I could monitor several bands sequentially. In order to it I obviously had to find a way to programmatically change the frequency in both, FCHID and CW Skimmer.
In order to change it in FCHID I developed a small program that uses Windows API calls. I called it ControlFCD and it accepts a frequency in kHz as a command line parameter (For instance "ControlFCD 28123" will change the Funcube frequency to 28123 kHz in FCHID). No need to say that FCHID must be running when executing ControlFCD.
For changing the LO Frequency in Skimmer I didn't find a better way than changing this value in the CWSkimmer.ini and restarting the program so that i takes the new configuration file. Instead of modifying the ini file I opted by creating different copies of the original file, each of which with the desired value of frequency, and copying then later over the CWSKimmer.ini.
Finally, I made a simple VBS to control the whole process of starting all the programs and automatically managing band changes at certain times. You can download this VBS as a sample and the ControlFCD program for your convenience.
Important: Download and use these programs at your own risk. They work fine for me on Windows XP, but you may need to modify the VBS for your own use and you will need some basic programming skills for this purpose. They are also likely not to work in later version of Windows, without changes. I can't provide you support about them.
Saturday, August 17, 2013
Testing Spot Quality Filters
It's
been a busy and rewarding couple of weeks. Sometimes, I'm
quite overwhelmed by the willingness of hams to invest large
amounts of time and intelligence in advancing our hobby, not
for any personal gain but simply because they care and enjoy
what they are doing.
This is one such case. The AR Cluster V6 Telnet server at the RBN has just been replaced with a beta version that provides quality scores for each RBN spot, as well as filters enabling users to apply those scores to limiting the spots they receive. Note that if you don't set any of the new filters, the node will continue to function as it always has, except for the addition of a validity code as part of the comment on each RBN spot. All existing filters will continue to work as before. The full story is at <http://www.ab5k.net/ArcDocsVer6/UserManual/ArcDx_CT1BOH.htm>.
Special thanks to CT1BOH, who did extensive analysis of RBN data and developed the innovative algorithms being used, and to AB5K, for the hard work of coding and testing the filters for incorporation in this new version of his cluster software.
During the beta period, users will see a set of new tags in the comment field of spots coming from the RBN ARC6 Telnet server. These will not be a feature of the finished version, so software that relies on a particular format in the Comment field of spots will not have to be modified. Users will see the quality tag, but in order to filter using them, the node they are connected to must be running the beta server software as well. Users can test with the RBN node at arcluster.reversebeacon.net, port 7000. Node sysops who want to try the beta are encouraged to contact AB5K.
These are the quality tags:
? - Not yet verified. The first and/or second identical spot of the same station, including erroneous spots of callers
V - Valid, meaning that at least three identical spots (call and frequency) have been posted by Skimmers worldwide
Q - QSY?, meaning that it is the first and/or second spot of a station on a new frequency, where spots of that station were previously verified. Sometimes, this will be a legitimate QSY, but the tag may also indicate an I/Q image of a good spot.
B - Bust, based on whether a new spot is enough like ones already seen and tagged Valid, except for a difference in the callsign. This is based on a really clever applied math concept called the Levenshtein distance. Google for more info.
. - Unique, meaning that there are only one or two stations currently spotting stations in a given country. Will often change to V if more stations spot it, but in the meantime you won't miss that P5 because only one RBN station heard it.
You can filter so that you get only Valid spots, or so that you can block all busted spots, or so that you get no Q spots until they are verified (so I/Q images will not come through). You can even tell the cluster node to let through spots with a "." tag, so you don't miss the really rare one who is only spotted by one or two stations. Full info and examples at the URL above.
I do not assume that this is the last word on improving RBN spot quality. Beta means beta. Please experiment, see what you think, and let me know. One particularly fruitful line of inquiry would be to compare the arrival time of unfiltered spots and spots that have been judged Valid, to note instances when an apparently legitimate spot doesn't get through or is judged to be a bust, or when a bust is not caught.
In this connection, in testing we have noticed that sometimes a Busted call will be mistakenly judged Valid, because there are more busts than good spots in a time window. Often, this seems to be due to spacing errors (RN4ZR for N4ZR), frequent omission of portable designators by ops (N4ZR instead of P5/N4ZR), and PTT cutting off the first dit (E4ZR for N4ZR)
Please send your comments/reports to me, and I'll see to their onward distribution. Do not send them to this reflector!
73, Pete N4ZR
This is one such case. The AR Cluster V6 Telnet server at the RBN has just been replaced with a beta version that provides quality scores for each RBN spot, as well as filters enabling users to apply those scores to limiting the spots they receive. Note that if you don't set any of the new filters, the node will continue to function as it always has, except for the addition of a validity code as part of the comment on each RBN spot. All existing filters will continue to work as before. The full story is at <http://www.ab5k.net/ArcDocsVer6/UserManual/ArcDx_CT1BOH.htm>.
Special thanks to CT1BOH, who did extensive analysis of RBN data and developed the innovative algorithms being used, and to AB5K, for the hard work of coding and testing the filters for incorporation in this new version of his cluster software.
During the beta period, users will see a set of new tags in the comment field of spots coming from the RBN ARC6 Telnet server. These will not be a feature of the finished version, so software that relies on a particular format in the Comment field of spots will not have to be modified. Users will see the quality tag, but in order to filter using them, the node they are connected to must be running the beta server software as well. Users can test with the RBN node at arcluster.reversebeacon.net, port 7000. Node sysops who want to try the beta are encouraged to contact AB5K.
These are the quality tags:
? - Not yet verified. The first and/or second identical spot of the same station, including erroneous spots of callers
V - Valid, meaning that at least three identical spots (call and frequency) have been posted by Skimmers worldwide
Q - QSY?, meaning that it is the first and/or second spot of a station on a new frequency, where spots of that station were previously verified. Sometimes, this will be a legitimate QSY, but the tag may also indicate an I/Q image of a good spot.
B - Bust, based on whether a new spot is enough like ones already seen and tagged Valid, except for a difference in the callsign. This is based on a really clever applied math concept called the Levenshtein distance. Google for more info.
. - Unique, meaning that there are only one or two stations currently spotting stations in a given country. Will often change to V if more stations spot it, but in the meantime you won't miss that P5 because only one RBN station heard it.
You can filter so that you get only Valid spots, or so that you can block all busted spots, or so that you get no Q spots until they are verified (so I/Q images will not come through). You can even tell the cluster node to let through spots with a "." tag, so you don't miss the really rare one who is only spotted by one or two stations. Full info and examples at the URL above.
I do not assume that this is the last word on improving RBN spot quality. Beta means beta. Please experiment, see what you think, and let me know. One particularly fruitful line of inquiry would be to compare the arrival time of unfiltered spots and spots that have been judged Valid, to note instances when an apparently legitimate spot doesn't get through or is judged to be a bust, or when a bust is not caught.
In this connection, in testing we have noticed that sometimes a Busted call will be mistakenly judged Valid, because there are more busts than good spots in a time window. Often, this seems to be due to spacing errors (RN4ZR for N4ZR), frequent omission of portable designators by ops (N4ZR instead of P5/N4ZR), and PTT cutting off the first dit (E4ZR for N4ZR)
Please send your comments/reports to me, and I'll see to their onward distribution. Do not send them to this reflector!
73, Pete N4ZR
Subscribe to:
Posts (Atom)