Wednesday, August 21, 2013

Using the Funcube Dongle Pro+ with CW Skimmer

by Gabriel Sampol, EA6VQ

reproduced with permission of the author from  

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.


I got a Funcube Dongle PRO+ with the idea of setting up a secondary Reverse Beacon receiver for 28 and 70 MHz bands.  To my disappointment the current version of CW Skimmer (1.8) does not support this device so I have spent some time investigating how to make it work.

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

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