One of the side-effects of the RBN/CW Skimmer revolution is the dramatic increase in the sheer number of spots received. Since Skimmers at RBN sites worldwide report everyone they hear calling CQ, instead of picking and choosing, logging software is being asked to handle ten times as many spots as before. An added dimension of the problem, for those using the RBN or another aggregator of CW Skimmer spots, such as VE7CC's DX cluster or VE1DX's , is the flood of duplicate spots. It is common for the RBN to collect (and forward) 8-10 near simultaneous spots of the same station on the same frequency. These data are critical for other RBN functions, such as comparing signal strength between stations or across geography, but logging software shouldn't have to cope with all that.
Fortunately, software writers have risen to the task. In a near dead heat, VE7CC's CC User and N1MM's N1MM Logger released updates that handle the problem for different audiences.
First, CC User. I've discussed this program earlier, and advocated using it to set and adjust filters on the RBN Telnet server easily and without having to learn the command syntax. After I wrote that, I learned that it is very simple to use it as a "front end" for your logging program. That way, you can also take advantage of the new built-in de-duping capability, whatever your logging software.
If you're a user of N1MM Logger, then you don't need the added complexity of CC User between the RBN and your logging software. That's because N1MM Logger itself removes duplicate spots, and also does not retain RBN or CW Skimmer spots that are more than 20 minutes old. Before you rise up in protest, that is really a very clever adaptation to how CW Skimmer operates - if a station remains on a frequency and continues to run there, CW Skimmer will re-spot it every 12-15 minutes, so by setting this limit N1MM has ensured that all RBN and CW Skimmer spots will be pretty fresh.
Watching with interest to see what Win-Test and Writelog do with this.
73, Pete Smith N4ZR
Wednesday, December 29, 2010
Friday, December 3, 2010
Frequency Calibration and the RBN
Looking through the log of spots posted during CQWW, it appears that the consistency of calibration between RBN Skimmer stations is pretty good - most differ by no more than 100-200 Hz. Still, I thought it would be worthwhile to offer some suggestions on achieving better calibration.
Why? First and foremost, anyone who is using RBN spots may be using some sort of "de-duping" software to get rid of the duplicate spots. We want those spots in our data, since they provide a basis for signal comparisons and other RBN features, but they contribute a lot to the total flow.The most popular de-duper, WintelnetX, only removes duplicate spots that are on the same frequency (to the nearest 100 Hz), so we need to try for accuracy around half that, or 50 Hz.
Accurate calibration of the QS1R receiver (and perhaps other SDRs I haven't used) is more important as you go up in frequency. A small error at 10 MHz is magnified at 21 or 28 MHz.
One of the special characteristics of the RBN is the expectation, when you click on a spot, that you'll hear the spotted station at approximately the same beat-note each time. If your calibration is off, it means that when people click on your spots on the higher bands, the CW tone they hear from the spotted station will be off. Not good. I had calibrated my QS1R against 10-MHz WWV, and was distressed during CQWW CW to hear that my own 21 and 28-MHz spots were too high pitched, to the point where I had to tune my radio slightly before each 10-meter QSO.
Clearly this wouldn't do, so here's what I did, in tutorial form:
Download a copy of Spectran from this site and install it on your computer. Feed audio from your transceiver to it. Now tune to the highest-frequency WWV broadcast you have available, or a similar AM standard frequency station that broadcasts a continuous tone most of the time. Set your radio to the frequency the standard station is supposed to be on, and either USB or LSB. You'll see a display like this:
The audio tone is the key to the whole trick - because with the filters in our modern radios, you can't hear below 300 Hz or so on the audio output. We know that the tone is precisely 600 Hz on WWV, so all you need to do is adjust your radio's calibration until the "Peak" message at the top of the screen is as close to 600 Hz as it will go. On my K-3, that was 600.24 Hz. The next choice was 597.5 Hz, and who wants to be a whole 2.5 Hz off?
To double-check your work, switch to the opposite sideband. It's likely that the displayed frequency will be slightly different, but you should still be able to get within 2-3 Hz. We can't hear that small a difference - at least those of us without perfect pitch can't. Even if you don't want to bother with Spectran, you can still get pretty close by ear, through using this alternate sideband technique to match the beat notes.
Ok, so now your transceiver's calibration is pretty darned good. For the QS1R calibration. QSY to the highest band your transceiver supports, within the range of your SDR. In the case of the QS1R and the K-3, that's 6 meters. Set your transceiver on CW on an exact frequency, like 50,101.000 KHz, for example.
Start CW Skimmer (not Skimmer Server, yet), and tune it to that frequency. Start it running. Turn your transmitter power way down, connect it to a dummy load, or whatever you need, so that when you send dits, the Skimmer waterfall isn't flooded with spurious signals. You'll see that the trace of the dots will be, most likely, somewhat off the frequency displayed by your radio. Use the "crosshairs" in Skimmer to read out as precisely as you can what the frequency of the center of the trace is.
Now, divide the displayed frequency by the frequency your transceiver is tuned to. That will give you a number like I got, at first - 1.00000535.
Close CW Skimmer, and then use Notepad to open the CWSkimmer.ini file. In Windows XP, it will in the CW Skimmer folder of your program directory. In Windows Vista, it will be [User]\AppData\Local\VirtualStore\ProgramFiles\Afreet\CWSkimmer\, where "User" is your user account name. In Windows 7, it will be in UserData\[User])\AppData\Local\VirtualStore\ProgramFiles\Afreet\CWSkimmer. Depending on how your Windows installation is set up, these folders may be hidden - you will need to "unhide" them.
Now that's over (thanks a lot, Microsoft), scroll down until you come to the section labeled "[SdrQS]". In that section you will find a line titled "FreqCalibration=". If you have never adjusted your calibration, the value for this parameter will be 1. Edit it to the value you determined above, and save your change.
Now go back to CWSkimmer, and see where your line of dits falls this time. if you're lucky, you'll hit it the first time, and your Skimmer display will look like this:
If not, then repeat the process, adjusting the value in the ini file until you get it as close as you can. Since the CW Skimmer display is only graduated every 200 Hz, this step is the least precise of any so far, but with a few iterations, you should be able to get within 20-30 Hz. That's the sort of accuracy we're looking for.
You're almost done. Close CW Skimmer and open the SkimSrv folder. Find the SkimSrv.ini file, as above, but looking in the SkimSrv folder. The frequency calibration is the last line in this file. Replace the value with whatever value you found using CW Skimmer. And now you're done - from now on, your Skimmer Server spots will be as accurate as you can make them.
Let me know, please, what you think of this explanation. And please do try it yourself!
73, Pete N4ZR
Why? First and foremost, anyone who is using RBN spots may be using some sort of "de-duping" software to get rid of the duplicate spots. We want those spots in our data, since they provide a basis for signal comparisons and other RBN features, but they contribute a lot to the total flow.The most popular de-duper, WintelnetX, only removes duplicate spots that are on the same frequency (to the nearest 100 Hz), so we need to try for accuracy around half that, or 50 Hz.
Accurate calibration of the QS1R receiver (and perhaps other SDRs I haven't used) is more important as you go up in frequency. A small error at 10 MHz is magnified at 21 or 28 MHz.
One of the special characteristics of the RBN is the expectation, when you click on a spot, that you'll hear the spotted station at approximately the same beat-note each time. If your calibration is off, it means that when people click on your spots on the higher bands, the CW tone they hear from the spotted station will be off. Not good. I had calibrated my QS1R against 10-MHz WWV, and was distressed during CQWW CW to hear that my own 21 and 28-MHz spots were too high pitched, to the point where I had to tune my radio slightly before each 10-meter QSO.
Clearly this wouldn't do, so here's what I did, in tutorial form:
Download a copy of Spectran from
The audio tone is the key to the whole trick - because with the filters in our modern radios, you can't hear below 300 Hz or so on the audio output. We know that the tone is precisely 600 Hz on WWV, so all you need to do is adjust your radio's calibration until the "Peak" message at the top of the screen is as close to 600 Hz as it will go. On my K-3, that was 600.24 Hz. The next choice was 597.5 Hz, and who wants to be a whole 2.5 Hz off?
To double-check your work, switch to the opposite sideband. It's likely that the displayed frequency will be slightly different, but you should still be able to get within 2-3 Hz. We can't hear that small a difference - at least those of us without perfect pitch can't. Even if you don't want to bother with Spectran, you can still get pretty close by ear, through using this alternate sideband technique to match the beat notes.
Ok, so now your transceiver's calibration is pretty darned good. For the QS1R calibration. QSY to the highest band your transceiver supports, within the range of your SDR. In the case of the QS1R and the K-3, that's 6 meters. Set your transceiver on CW on an exact frequency, like 50,101.000 KHz, for example.
Start CW Skimmer (not Skimmer Server, yet), and tune it to that frequency. Start it running. Turn your transmitter power way down, connect it to a dummy load, or whatever you need, so that when you send dits, the Skimmer waterfall isn't flooded with spurious signals. You'll see that the trace of the dots will be, most likely, somewhat off the frequency displayed by your radio. Use the "crosshairs" in Skimmer to read out as precisely as you can what the frequency of the center of the trace is.
Now, divide the displayed frequency by the frequency your transceiver is tuned to. That will give you a number like I got, at first - 1.00000535.
Close CW Skimmer, and then use Notepad to open the CWSkimmer.ini file. In Windows XP, it will in the CW Skimmer folder of your program directory. In Windows Vista, it will be [User]\AppData\Local\VirtualStore\ProgramFiles\Afreet\CWSkimmer\, where "User" is your user account name. In Windows 7, it will be in UserData\[User])\AppData\Local\VirtualStore\ProgramFiles\Afreet\CWSkimmer. Depending on how your Windows installation is set up, these folders may be hidden - you will need to "unhide" them.
Now that's over (thanks a lot, Microsoft), scroll down until you come to the section labeled "[SdrQS]". In that section you will find a line titled "FreqCalibration=". If you have never adjusted your calibration, the value for this parameter will be 1. Edit it to the value you determined above, and save your change.
Now go back to CWSkimmer, and see where your line of dits falls this time. if you're lucky, you'll hit it the first time, and your Skimmer display will look like this:
If not, then repeat the process, adjusting the value in the ini file until you get it as close as you can. Since the CW Skimmer display is only graduated every 200 Hz, this step is the least precise of any so far, but with a few iterations, you should be able to get within 20-30 Hz. That's the sort of accuracy we're looking for.
You're almost done. Close CW Skimmer and open the SkimSrv folder. Find the SkimSrv.ini file, as above, but looking in the SkimSrv folder. The frequency calibration is the last line in this file. Replace the value with whatever value you found using CW Skimmer. And now you're done - from now on, your Skimmer Server spots will be as accurate as you can make them.
Let me know, please, what you think of this explanation. And please do try it yourself!
73, Pete N4ZR
But it didn't....now where do we go from here?
It stayed up, and delivered the goods.
This was thanks to a lot of hard work by PY1NB, F5VIH and a new member of the RBN team, Dave Pascoe, KM3T, as well as the donation of a temporary dedicated server by George Fremin, K5TR.
Something over 1,700,000 spots were delivered in the 48 hours of the contest, which comes out to around 10 per second worldwide. Most users said they needed pretty stringent filtering to help their logging software keep up. One favorite strategy by European users was to block US/VE spots, and vice versa.
Peak usage of the RBN server was 147 users, most of whom reported no difficulty staying connected. I suspect that actual usage of RBN spots was much more than that, because I've heard from a large number of stations who were connected to RBN Skimmers with public IP addresses (a reasonable precaution given how much trouble the RBN Telnet server had a few weeks earlier). Others connected to VE7CC or VE1DX, two clusters we know of that were rebroadcasting spots from a large subset of the whole RBN.
We have set up a new Yahoo group called RBN-OPS to facilitate cooperation among RBN users and between them and the RBN development team. You don't have to be currently active on the RBN to join the discussion - everyone is welcome.
Come be a part of a game-changing technology initiative in ham radio contesting.
This was thanks to a lot of hard work by PY1NB, F5VIH and a new member of the RBN team, Dave Pascoe, KM3T, as well as the donation of a temporary dedicated server by George Fremin, K5TR.
Something over 1,700,000 spots were delivered in the 48 hours of the contest, which comes out to around 10 per second worldwide. Most users said they needed pretty stringent filtering to help their logging software keep up. One favorite strategy by European users was to block US/VE spots, and vice versa.
Peak usage of the RBN server was 147 users, most of whom reported no difficulty staying connected. I suspect that actual usage of RBN spots was much more than that, because I've heard from a large number of stations who were connected to RBN Skimmers with public IP addresses (a reasonable precaution given how much trouble the RBN Telnet server had a few weeks earlier). Others connected to VE7CC or VE1DX, two clusters we know of that were rebroadcasting spots from a large subset of the whole RBN.
We have set up a new Yahoo group called RBN-OPS to facilitate cooperation among RBN users and between them and the RBN development team. You don't have to be currently active on the RBN to join the discussion - everyone is welcome.
Come be a part of a game-changing technology initiative in ham radio contesting.
Monday, November 22, 2010
What if.... the RBN Telnet server goes down during CQWW?
We are monitoring the RBN Telnet server closely in hopes of discovering what killed it during CW Sweepstakes, but we do not have a definitive answer yet. It is hard to be confident that we have fixed it until it gets hit with the traffic that only a major contest can provide, both in terms of the spot flow and the user numbers. Next weekend will guarantee both in spades, but our object is to provide useful information, not a toy, so we thought it was appropriate to offer suggestions on how to make your RBN spot feed somewhat fail-safe.
The most comprehensive solution is probably to use WintelnetX by K1TTT to merge the spot stream from the RBN with those from one or more of the more prolific individual RBN stations' Telnet servers that are relatively close to you. for example, I might use WZ7I plus the RBN. A downside is that the Skimmer Telnet server does not filter spots, so you must contend with everything the local server sends you and rely on your logging software to cull out the ones you do not want. Of course, you can filter the RBN Telnet server's output, as described in the previous article.
Another, much simpler solution is to configure your logging program for the RBN server and a nearby RBN station's Telnet feed, and keep an eye on the spot flow. It will be easy to tell, at >5 spots/second, when or if the RBN server goes down, and an easy matter to switch.
How do you get the IP address of your nearby RBN station? Most of them are on. We are trying to get those guys whose IPs aren't currently displayed to display them before the contest.
Again, we hope none of this is necessary. See you on the bands!
73, Pete N4ZR
The most comprehensive solution is probably to use WintelnetX by K1TTT to merge the spot stream from the RBN with those from one or more of the more prolific individual RBN stations' Telnet servers that are relatively close to you. for example, I might use WZ7I plus the RBN. A downside is that the Skimmer Telnet server does not filter spots, so you must contend with everything the local server sends you and rely on your logging software to cull out the ones you do not want. Of course, you can filter the RBN Telnet server's output, as described in the previous article.
Another, much simpler solution is to configure your logging program for the RBN server and a nearby RBN station's Telnet feed, and keep an eye on the spot flow. It will be easy to tell, at >5 spots/second, when or if the RBN server goes down, and an easy matter to switch.
How do you get the IP address of your nearby RBN station? Most of them are on
Again, we hope none of this is necessary. See you on the bands!
73, Pete N4ZR
Wednesday, November 17, 2010
What Happened During Sweepstakes?
I'm sure I'm not the only one who got burned by this during the ARRL Sweepstakes - periodically the RBN Telnet server would go down, throwing everyone off, reject connection requests for a few minutes, and then come back on - but unless your client had automatic re-connect capabilities, you might not notice until the spots stopped flowing, and then, if you tried to reconnect, you might or might not get back on..
We (mainly Felipe and Nick, F5VIH) have been studying the logs and configuration details for a few days, trying to figure out what is going on.The spot volume doesn't appear to have been to blame - only 470k spots for the busiest 24-hour day, or about 5.5 per second on average ("only", he says!). Instead, it seems to have been the number of users - we're once again victims of our own success.
There are several potential avenues for fixing this - the best would probably be to adjust the current server's parameters to increase its inbound bandwidth and other capacities very substantially, but that may not be feasible with a Virtual Private Server such as we're currently using. We could get another server, and set up a round-robin DNS so that connection requests are routed to them alternatively. Fine, except that this requires the added server to have a fixed IP address, and if either server gets overburdened and crashes, then half the users would find themselves getting rejected or thrown off until it recovers. A third possibility might be to move the whole thing to another server that we don't share with anyone, and that we can set up for high volume. A fourth, crude solution would be to set up another server with an entirely separate URL, and publicize its availability in the hope that the users themselves will redistribute among the servers.
Anyhow, we're scrambling to figure it out and solve the problem before CQWW CW in ten days' time - please stay tuned.
73, Pete N4ZR
We (mainly Felipe and Nick, F5VIH) have been studying the logs and configuration details for a few days, trying to figure out what is going on.The spot volume doesn't appear to have been to blame - only 470k spots for the busiest 24-hour day, or about 5.5 per second on average ("only", he says!). Instead, it seems to have been the number of users - we're once again victims of our own success.
There are several potential avenues for fixing this - the best would probably be to adjust the current server's parameters to increase its inbound bandwidth and other capacities very substantially, but that may not be feasible with a Virtual Private Server such as we're currently using. We could get another server, and set up a round-robin DNS so that connection requests are routed to them alternatively. Fine, except that this requires the added server to have a fixed IP address, and if either server gets overburdened and crashes, then half the users would find themselves getting rejected or thrown off until it recovers. A third possibility might be to move the whole thing to another server that we don't share with anyone, and that we can set up for high volume. A fourth, crude solution would be to set up another server with an entirely separate URL, and publicize its availability in the hope that the users themselves will redistribute among the servers.
Anyhow, we're scrambling to figure it out and solve the problem before CQWW CW in ten days' time - please stay tuned.
73, Pete N4ZR
Monday, November 1, 2010
Finally, a "DX Cluster" for Contesters - how to use the RBN in contests
As we approach the big CW contests of the season, I thought that Assisted/Unlimited contesters might appreciate a few tips on how to make the best use of the Reverse Beacon Network's Telnet feed (http://telnet.reversebeacon.net, port 7000).
As I've said before, the RBN is uniquely fitted to use by contesters, because its 40 or more stations scattered worldwide spot every running station, wherever the station is being heard. Stations are re-spotted every 10-11 minutes if they stay on the same frequency, or immediately if they change frequency more than a few hundred Hz. The result is an all-band snapshot of activity on every band, delivered in real time. Picture that on Sunday afternoon in Sweepstakes, or anytime during the CQWW DX contest. Is 10 meters open? As soon as one station calls CQ, and is heard by CW Skimmer at one or more of the Reverse Beacon Network stations, it will be spotted. You should never have to miss that rare opening again.
Now obviously, the volume of RBN spots will be tremendous, and could easily overwhelm you (or your logging program). The first thing to do, to manage this, is to filter spots at the Telnet node. K4TD, who generously hosts the node, uses DX Spider cluster software. This software lets you set filters with great precision, so that, for example, you can tell the node only to send you spots from a given continent, or country, call area, or even state. I find it most useful to limit the RBN spots I receive to those generated by stations nearby, because I can pretty much count on being able to hear everything they spot.
DX Spider's filter commands are quite different from those used by AR-Cluster. You can either learn the syntax or, as I did, download VE7CC's excellent CC User (http://www.ve7cc.net/). This software translates your wishes to commands and "tells" DX Spider what to do. You do *not* have to use CC User as an intermediate step between the telnet node and your logging program. Instead, once you've set the filters, you can shut it down, start your logging program, and you're ready to go.
Two more hints for operators using the RBN. Most contest loggers have a setting for "packet spot timeout", or something similar, that removes spots from the bandmap when they get too old. Because of RBN's unique re-spotting capability, there is no reason to have the timeout set to more than 15 minutes - if the station is still there, it will be spotted again, and your bandmap won't be clogged with obsolete spots.
And finally, if you want to make sure that you're spotted by the RBN, then once in a while, even if you're running fast, send "CQ" or "TEST" as a part of your end-of-QSO transmission. CW Skimmer isn't perfect at determining which stations are running and which are S&P - it has trouble with runners who only sign their calls at the end of each contact - but this way, you can help it "notice" you.
See you on the air.
73, Pete N4ZR
As I've said before, the RBN is uniquely fitted to use by contesters, because its 40 or more stations scattered worldwide spot every running station, wherever the station is being heard. Stations are re-spotted every 10-11 minutes if they stay on the same frequency, or immediately if they change frequency more than a few hundred Hz. The result is an all-band snapshot of activity on every band, delivered in real time. Picture that on Sunday afternoon in Sweepstakes, or anytime during the CQWW DX contest. Is 10 meters open? As soon as one station calls CQ, and is heard by CW Skimmer at one or more of the Reverse Beacon Network stations, it will be spotted. You should never have to miss that rare opening again.
Now obviously, the volume of RBN spots will be tremendous, and could easily overwhelm you (or your logging program). The first thing to do, to manage this, is to filter spots at the Telnet node. K4TD, who generously hosts the node, uses DX Spider cluster software. This software lets you set filters with great precision, so that, for example, you can tell the node only to send you spots from a given continent, or country, call area, or even state. I find it most useful to limit the RBN spots I receive to those generated by stations nearby, because I can pretty much count on being able to hear everything they spot.
DX Spider's filter commands are quite different from those used by AR-Cluster. You can either learn the syntax or, as I did, download VE7CC's excellent CC User (http://www.ve7cc.net/). This software translates your wishes to commands and "tells" DX Spider what to do. You do *not* have to use CC User as an intermediate step between the telnet node and your logging program. Instead, once you've set the filters, you can shut it down, start your logging program, and you're ready to go.
Two more hints for operators using the RBN. Most contest loggers have a setting for "packet spot timeout", or something similar, that removes spots from the bandmap when they get too old. Because of RBN's unique re-spotting capability, there is no reason to have the timeout set to more than 15 minutes - if the station is still there, it will be spotted again, and your bandmap won't be clogged with obsolete spots.
And finally, if you want to make sure that you're spotted by the RBN, then once in a while, even if you're running fast, send "CQ" or "TEST" as a part of your end-of-QSO transmission. CW Skimmer isn't perfect at determining which stations are running and which are S&P - it has trouble with runners who only sign their calls at the end of each contact - but this way, you can help it "notice" you.
See you on the air.
73, Pete N4ZR
Wednesday, July 28, 2010
27 July 2010 - CT1BOH endorses RBN - " - "The King (Packet cluster network) is dead! Long live the King (Skimmer reverse beacon network)"
When one looks at the growth of QSOs during 48 hour contests (notably
maximum QSOs in the CQWW SOAB CW category in the past decades:
50's 1277 QSOs
60's 2623 QSOs
70's 4505 QSOs
80's 5970 QSO
90's 7555 QSOs
00's 7828 QSOs
one has to wonder where have all those extra QSOs have come from.
- The operators have better resources and share more information (more
knowledgeable with propagation and openings, more skillful with SO2R
resources, ...)
- The logging software and Computer Generator CW have added extra efficiency
when working stations
- The stations (split TX signals) and low band antennas (both RX and TX)
have added extra QSO potential
but If there is one aspect that has impacted Contesting the most, for
good or for bad, in my opinion, it is:
- The development of Packet Cluster network by AK1A in the late 80's and the
enhancement it has given to contest operators to be found while CQ'ing on a
band
There was one aspect in the Packet Cluster network that was not fair. Since
most users of the packet cluster network are DX'ers they tend to spot
stations more according to their DX rareness than to their actual operating
time.
Looking at the packet spot data for 2009 CQWW CW with its almost 51.000
packet spots, listing the stations with most spots shows great differences
between them. Almost all these stations were active during the 48 hours of
the contest but still great differences exist:
For stations with most spots worldwide
HC8GR-573, LX7I-271 , EA8URL-254, JA3YBK-249, B7P-219, VK9XW-216, EE2W-211,
K3LR-206, KC1XX-206, JA5FDJ-198
For stations with most spots in the USA
K3LR-206, KC1XX-206, W3LPL- 165, K1LZ-156, K1TTT-155, NQ4I-139, W2FU-115,
NR4M-103, NR5M-99, K0RF-63
For station in the SOAB Category worldwide
V47NT-190, ZS4TX-183, A25NW-182, 8P5A-174, VE2IM-160, P49Y-146, 6W1RW-145,
EF8M-144, VQ5M-132, CR3E-127
There is not fairness in the packet cluster network. The more DX you are,
the more known you are the more spots you get, even if you have a great
signal or are QRV all the time. The K3LR verus K1LZ or V47NT versus EF8M
are good examples.
Another interesting aspect also to note is that more and more people rely on
the packet cluster network to work stations in contests.
Looking at 2009 CW Claimed results, there were 783 stations submitting logs
in the SOAB category and 1020 stations submitting logs in the SOAB Assisted
category
The fact that there is a majority of stations operating the Assisted
category versus the Non Assisted category in the SOAB class also provides
extra QSOs to those CQing stations, because in order to maximize QSOs these
Assisted stations are not only going after DX multipliers but also after
stations that are not necessarily multipliers for new QSO points.
In 2008 when VE3NEA - Alex Shovkoplyas developed CW Skimmer I sent him the
following note on Mar 2008:
"(...) you realize this is the end of CW contesting as we have known it. It
will be a very different contest in the future. (...) Also, with a script
that puts all the calls from CW Skimmer into packet, no need for "old
version packet". It's like having a requirement in the rules for self
spotting.(...)"
What I did not realize was how quickly would Skimmer reverse beacon network
achieve such a degree of coverage and overcome Packet Cluster Network in a
devastating way.
The result can be tagged as "shock and awe" to use a military jargon.
In order for you to understand the degree of band coverage Skimmer reverse
beacon network is capable of I will compare the results of packet cluster
network performance against Skimmer reverse beacon network, using the last
IARU HF Championship contest as a reference and my CR3E operation.
I took the packet cluster network data from DX Summit Search option
http://www.dxsummit.fi/Search.aspx and Skimmer reverse beacon network from
http://www.reversebeacon.net/raw_data/
CR3E was spotted 40 times in the packet cluster network. An average of one
spot every 36 minutes
CR3E was spotted 500 time in the Skimmer Reverse Beacon network. An average
of one spot every 2.9 minutes
The difference is incredible.
What is the impact of this difference? In order for all to fully understand
I will use the packet window concept.
Most Contest logging programs have a packet spot lifetime option to display
new multipliers and QSO's in the band map. Using a common 30 minute default
option, l can calculate the packet coverage of both the packet and skimmer
reverse beacon network.
Imagine CR3E started the contest on 15 meter and was QRV for 120 minutes on
that band.
Imagine there was only one packet spot during that 120 minute QRV and that
it occurred in the minute 20
CR3E will be in Assisted stations band map (if not worked) during the packet
spot lifetime window from minute 20 until minute 49 (30 minutes), when the
spots lifetime ends.
CR3E was QRV 120 minutes and there was a coverage of 30 out of 120 minutes,
i.e. 25% packet coverage for the time of QRV
So what is the difference between Packet Cluster Network (PCN) and Skimmer
Reverse Beacon Network (SRBN) for CR3E IARU operation when it comes to
packet coverage?
Looking at the 1440 minute of the IARU contest I checked how many minutes
CR3E was QRV while CQing/Running. I removed minutes with SO2R QSOs that are
not spotted because I'm replying to stations:
On 28 Mhz CR3E was QRV 68 minutes, there was a 65% PCN and 78% SRBN coverage
On 21 Mhz CR3E was QRV 485 minutes, there was a 60% PCN and 96% SRBN
coverage
On 14 Mhz CR3E was QRV 503 minutes, there was a 53% PCN and 98% SRBN
coverage
On 7 Mhz CR3E was QRV 283 minutes, there was a 33% PCN and 99% SRBN coverage
On 3.5 Mhz CRE was QRV 28 minutes, there was a 86% PCN and 96% SRBN coverage
On 1.8 CR3E did not CQ, just S&Ped.
Skimmer Reverse Beacon Network (SRBN) achieved an incredible 96% window
coverage. while CR3E was CQ/running. i.e. CR3E was spotted ALL the time of
the contest, whenever he was CQing (TEST CR3E). To put it in another way the
minute I CQ the minute a Skimmer Robot will spot me.
There was even one time Skimmer reverse beacon network spotted me before I
even logged stations.
With Skimmer reverse beacon network, spotting will rely on robots. Everybody
will be spotted about the same for same conditions. It's democracy into
packet spots.
t's no wonder stations like K3LR have implemented their won skimmer network
http://www.k3lr.com/skimmer/ in order to have all the data of active
stations on the bands, in order to gain an extra competitiveness over their
competitors. Tim K3LR told me that last ARRL they even found a new opening
never heard of, thanks to skimmer.
Assisted stations, MS, M2, MM, DXers and alike don't need systems like K3LR
to gather all this data. They can feed into the telnet aggregated output of
all currently active skimmer reverse beacon receivers in real time at
telnet.reversebeacon.net port 7000. Check
http://reversebeacon.blogspot.com/ for details.
Relying in the old Packet cluster network is the best way to loose. Relying
into Skimmer reverse beacon network is the way for Assisted station in CW
Contests.
I guess it is proper to say The King (Packet cluster network) is dead! Long
live the King (Skimmer reverse beacon network).
I have never operated in the Assisted SOAB class in my 36 CQWW Contests as a
single operator that span over 21 years non stop since 1989.
http://www.qsl.net/ct1boh/operations.htm
I do recognize the great impact packet has had in my pile-ups and
operations. I do love packet pile-ups. "It's rush after rush". Packet
spotting is certainly here to stay, no matter what.
Will the contest be a different one? Information is tilting the nature of
the contest. It will not be worse nor better. It will be just different. And
I guess change is what people fear the most.
John F. Kennedy once said "Change is the law of life. And those who look
only to the past or present are certain to miss the future."
I don't really care if the good old days are better than today but it is an
interesting coincidence that for some, the less days one has left the better
the good old days are...
73----
José Nunes
CONTEST CT1BOH - http://www.qsl.net/ct1boh
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
Friday, July 23, 2010
Spot Analysis Tool in Action
The Reverse Beacon Network's Spot Analysis Tool has been getting a good workout since the IARU contest. For those who haven't tried it yet, a small introduction.
This screen shows the basic features of the tool (click on the image for a magnified version). First, you choose a date (above the screen shown, on the left). Then select a continent, and the tool tells you which reverse beacons (or skimmers, if you prefer) were active on that day, and how many spots each made. Select a reverse beacon, and move to the bottom of the screen where a box invites you to "ADD" a callsign. Type one, click the ADD button, and any spots of the station will be plotted, band by band.
Now the best part. Add another, and the tool compares the signals of the two stations. Add more (up to 10, total), and their signal strengths are plotted on the screen.
If you want, you can zoom in on the graph and examine the individual spots more closely. You can also change reverse beacons, add or delete stations to compare, and zoom in on multiple graphs.
In the example above, I compared the signals of several WRTC stations in Europe. It looks to me that the organizers achieved their goal of equalizing signals pretty well.
73, Pete N4ZR
This screen shows the basic features of the tool (click on the image for a magnified version). First, you choose a date (above the screen shown, on the left). Then select a continent, and the tool tells you which reverse beacons (or skimmers, if you prefer) were active on that day, and how many spots each made. Select a reverse beacon, and move to the bottom of the screen where a box invites you to "ADD" a callsign. Type one, click the ADD button, and any spots of the station will be plotted, band by band.Now the best part. Add another, and the tool compares the signals of the two stations. Add more (up to 10, total), and their signal strengths are plotted on the screen.
If you want, you can zoom in on the graph and examine the individual spots more closely. You can also change reverse beacons, add or delete stations to compare, and zoom in on multiple graphs.In the example above, I compared the signals of several WRTC stations in Europe. It looks to me that the organizers achieved their goal of equalizing signals pretty well.
73, Pete N4ZR
Monday, July 12, 2010
7-9 Spots a Minute During IARU
I'm happy to report that the Reverse Beacon Network made 312,867 spots
in the 34 hours of the IARU Contest. On average, each active Reverse
Beacon was spotting 7-9 stations per minute. We are working on
extracting numbers of spots of each WRTC station during the period, and
hope to have these later today.
73, Pete N4ZR
Friday, July 9, 2010
New RBN Feature Out for Beta Test During IARU Contest
The Reverse Beacon Network team is pleased to announce that a new and (we hope) exciting feature is being released for beta testing during and after the IARU Contest.
The Spot Analysis Tool, written by Nick Sinanis, F5VIH/SV3SJ, can now be found at http://reversebeacon.net/analysis
If you select SNR, you will immediately be able to see which station opened the band to the area represented by the Reverse Beacon, which had the better signal during the middle of the opening, and which fared better in the waning hours. Select a time period and zoom in to get a close look at comparative signal strength. Selecting frequency to plot will show whether stations changed run frequencies often and which frequencies they were (or were not) able to hold, and when.
A few cautionary notes. This *is* an automated system. It only spots stations that it believes are CQing. The SNR for a given spot can be heavily influenced by QRM or QRN, so general trends are a lot more instructive than individual spots. If Slim decides to sign somebody else's call, and it's heard, it will be spotted, and the frequency calibration may vary (though we're working on that) depending on the Reverse Beacon's individual setup.
As we said, this is a beta test version. There are a few limitations right now - most important, it does not yet work with Internet Explorer, so you will need to use Firefox or Chrome to test it. While Nick is working on that problem, we'd like to get comments about the usability of the tool, reports on any bugs you encounter, and any other input you want to provide. While we're not averse to comments on CQ-Contest, you can avoid a glut there by sending your comments to us at skimmer@dxwatch.com.
We look forward to hearing from you!
73,
Nick, F5VIH/SV3SJ, Felipe PY1NB, and Pete, N4ZR
The Spot Analysis Tool, written by Nick Sinanis, F5VIH/SV3SJ, can now be found at http://reversebeacon.net/analysis
If you select SNR, you will immediately be able to see which station opened the band to the area represented by the Reverse Beacon, which had the better signal during the middle of the opening, and which fared better in the waning hours. Select a time period and zoom in to get a close look at comparative signal strength. Selecting frequency to plot will show whether stations changed run frequencies often and which frequencies they were (or were not) able to hold, and when.
A few cautionary notes. This *is* an automated system. It only spots stations that it believes are CQing. The SNR for a given spot can be heavily influenced by QRM or QRN, so general trends are a lot more instructive than individual spots. If Slim decides to sign somebody else's call, and it's heard, it will be spotted, and the frequency calibration may vary (though we're working on that) depending on the Reverse Beacon's individual setup.
As we said, this is a beta test version. There are a few limitations right now - most important, it does not yet work with Internet Explorer, so you will need to use Firefox or Chrome to test it. While Nick is working on that problem, we'd like to get comments about the usability of the tool, reports on any bugs you encounter, and any other input you want to provide. While we're not averse to comments on CQ-Contest, you can avoid a glut there by sending your comments to us at skimmer@dxwatch.com.
We look forward to hearing from you!
73,
Nick, F5VIH/SV3SJ, Felipe PY1NB, and Pete, N4ZR
Thursday, July 1, 2010
Twenty Times as Many Spots!
A very interesting talk on new technology in contesting was given last week at the Friedrichshafen hamfest in Germany by Tobi, DH1TW. It featured the Reverse Beacon Network, and contrasted the number of spots generated by RBN during the recent WPX CW contest with those delivered by the conventional spotting network. You can see it (in English) at hhttp://www.dh1tw.de/how-new-technologies-affect-the-art-of-contesting.
It's pretty breathtaking - the RBN delivered about 837,000 spots from 41 reverse beacons in 21 countries, while the conventional spotting network delivered less than 40,000. The RBN also collected two and one half times as many callsigns, and about 35 percent more total prefixes during the 48-hour contest. Not bad.
The RBN is very close to the perfect information tool for WPX, but it offers the same benefits in every contest - huge volume, no subjective "to spot or not to spot" judgments, and spot quality as high or higher than conventional DX clusters. Now, thanks to K4TD, you can even apply full filtering to the spot stream from the RBN. The Telnet server at telnet.reversebeacon.net port 7000 uses the DX Spider cluster server, and you can set it up to deliver a very high level of specificity - filtering out all spots except those from your own area, for example, or spotting only stations from Europe (WAE is coming, after all).
Stay tuned for a major announcement, coming soon - the RBN Signal Analysis Tool, developed by Nick, F5VIH/SV3SJ. It's in test now, and once a few last bugs are smoothed out, you'll see why Felipe and I are so excited about it.
73, Pete N4ZR
It's pretty breathtaking - the RBN delivered about 837,000 spots from 41 reverse beacons in 21 countries, while the conventional spotting network delivered less than 40,000. The RBN also collected two and one half times as many callsigns, and about 35 percent more total prefixes during the 48-hour contest. Not bad.
The RBN is very close to the perfect information tool for WPX, but it offers the same benefits in every contest - huge volume, no subjective "to spot or not to spot" judgments, and spot quality as high or higher than conventional DX clusters. Now, thanks to K4TD, you can even apply full filtering to the spot stream from the RBN. The Telnet server at telnet.reversebeacon.net port 7000 uses the DX Spider cluster server, and you can set it up to deliver a very high level of specificity - filtering out all spots except those from your own area, for example, or spotting only stations from Europe (WAE is coming, after all).
Stay tuned for a major announcement, coming soon - the RBN Signal Analysis Tool, developed by Nick, F5VIH/SV3SJ. It's in test now, and once a few last bugs are smoothed out, you'll see why Felipe and I are so excited about it.
73, Pete N4ZR
Monday, April 12, 2010
New RBN Aggregator Telnet Feed Available Now
The Reverse Beacon Network (http://reversebeacon.net) has now made a
Telnet feed of the aggregated output of all currently active RBN Skimmer
receivers available in real time at telnet.reversebeacon.net port 7000 (that's not a clickable link - you'll need a telnet client, though your logging software will work just fine).
Thanks to Rick, K4TD, for making the server available, and to Felipe,
PY1NB and Nick, F5VIH for the programming effort.
No big deal, you say? Well, before you blow it off, take a look at the
flow of spots, even on a normal weekday. Run them through appropriate
filters (CCUser, etc.) to remove duplicates, restrict spots to your country, continent, or call area, or whatever, and use them to populate the bandmap of your favorite contest logging software. I think you'll be amazed.
This feed offers one huge advantage for contesters, because the RBN
spots *every* station it hears, not just the ones that someone,
somewhere thinks are worthy of being spotted. It is also listening on
all bands, all the time, at world-wide sites.
ONE CAUTION -- Precisely because it spots everything, usually multiple
times, it would be disastrous if someone were to feed the RBN Telnet
server into the normal DX cluster network. If this happens, the server
may have to be shut down, so *please* don't do it.
73, Pete N4ZR
Telnet feed of the aggregated output of all currently active RBN Skimmer
receivers available in real time at telnet.reversebeacon.net port 7000 (that's not a clickable link - you'll need a telnet client, though your logging software will work just fine).
Thanks to Rick, K4TD, for making the server available, and to Felipe,
PY1NB and Nick, F5VIH for the programming effort.
No big deal, you say? Well, before you blow it off, take a look at the
flow of spots, even on a normal weekday. Run them through appropriate
filters (CCUser, etc.) to remove duplicates, restrict spots to your country, continent, or call area, or whatever, and use them to populate the bandmap of your favorite contest logging software. I think you'll be amazed.
This feed offers one huge advantage for contesters, because the RBN
spots *every* station it hears, not just the ones that someone,
somewhere thinks are worthy of being spotted. It is also listening on
all bands, all the time, at world-wide sites.
ONE CAUTION -- Precisely because it spots everything, usually multiple
times, it would be disastrous if someone were to feed the RBN Telnet
server into the normal DX cluster network. If this happens, the server
may have to be shut down, so *please* don't do it.
73, Pete N4ZR
Sunday, March 21, 2010
Load? What Load??
When I wrote the sad story of our server buckling under the load of the ARRL DX Contest, I'm sure people were curious about the quantitative story. Because of the problems that weekend, we don't have the numbers for it, but we do have them for the Russian DX Contest, which just finished.
As you can see, we went from a rate of around 50 spots per minute received at the RBN, in the time just before the contest started at 1200Z, to a peak of 600 spots per minute at 1400Z. There was a brief drop-out between 0300 and 0400Z due to problems with a backup routine, but then the flow of spots continued at a rate of 250-400 spots per minute until the end of the contest. At that point the server breathed a sigh of relief, as it dropped back to around 30 spots per minute.
For the 24 hours of the contest, the database received 545,747 spots. Our guesstimate is that a major contest such as CQWW or the ARRL DX Test, with their much larger number of participants, would yield at least twice the spot rate. The programming team has done a lot of good preliminary work, to stabilize things at the current level, but the effort continues. The next big test will be the WPXCW at the end of May.\
73, Pete Smith N4ZR
Monday, March 15, 2010
Tell us what you'd like in the database search interface.
While Felipe and Nick are doing the real work, I'm inspired to try to stimulate some interest by raising some ideas about improving the user interface for the Reverse Beacon Network database.
It might be possible for there to be a single interface for all searches. Alternatively, there may be good reasons, such as simplicity, to break it into multiple forms, depending on the purpose. What I'm trying to do here is suggest some things that it would be good to keep in mind for various fields:
For example:
DE should provide for specifying a variety of different limiters - they might include the specific callsign(s) of the spotters as well as countries and ITU zones. Multiple callsigns or countries should be accommodated.
DX should have the same range of possibilities.
Any Date field should allow for date ranges as well as single dates
The Signal Comparison Tool should, if at all possible, only offer Skimmer sites that have data relating to the comparison that is being run. As it stands now, when you specify a date, the next step in the tool gives you a list of Skimmers active on that date, but many will not have data for the stations or bands of interest for any given search. It would be great if the skimmers could be offered for selection based both on the band and on the stations to be compared, but I realize that may be too burdensome; even just the bands would be a step forward.
What would YOU like to see?
73, Pete N4ZR
It might be possible for there to be a single interface for all searches. Alternatively, there may be good reasons, such as simplicity, to break it into multiple forms, depending on the purpose. What I'm trying to do here is suggest some things that it would be good to keep in mind for various fields:
For example:
DE should provide for specifying a variety of different limiters - they might include the specific callsign(s) of the spotters as well as countries and ITU zones. Multiple callsigns or countries should be accommodated.
DX should have the same range of possibilities.
Any Date field should allow for date ranges as well as single dates
The Signal Comparison Tool should, if at all possible, only offer Skimmer sites that have data relating to the comparison that is being run. As it stands now, when you specify a date, the next step in the tool gives you a list of Skimmers active on that date, but many will not have data for the stations or bands of interest for any given search. It would be great if the skimmers could be offered for selection based both on the band and on the stations to be compared, but I realize that may be too burdensome; even just the bands would be a step forward.
What would YOU like to see?
73, Pete N4ZR
Progress Report
Since I last wrote, Felipe, PY1NB and Nick, F5VIH, have been hard at work putting together a development environment that they (hopefully joined by other contributors as well) can use to develop better software for the RBN site. Stay tuned for more details on that in the coming days, including an invitation to participate.
In the meantime, they have made some changes in the current software that should, we hope, make it better able to handle heavy loading. The Russian contest, coming up next weekend, should provide a good first test.
In the meantime, they have made some changes in the current software that should, we hope, make it better able to handle heavy loading. The Russian contest, coming up next weekend, should provide a good first test.
Saturday, February 27, 2010
Starting to Find Our Way Out
Well, in a nutshell, the thing has grown too fast. The Reverse Beacon Network website and database share a single server. We could add a second one (which we understand would need to be co-located with the first), to put the database functions on one server and the web functions on another. The trouble is, that costs real money, and Felipe is already out 49 Euros a month for the system.
In the short term, Felipe has ordered additional disk space and memory for his server from the ISP in Germany. That will be some help. But Ideally, we would go at the problem from both the hardware and software sides at once.
In the short term, Felipe has ordered additional disk space and memory for his server from the ISP in Germany. That will be some help. But Ideally, we would go at the problem from both the hardware and software sides at once.
Thursday, February 25, 2010
Victims of Our Own Success
For those of you who are currently trying to use the RBN database and experiencing erratic behavior... it broke under the strain last weekend, and Felipe is repairing it now. Unfortunately, first indications are that a lot of QSOs never made it into the database - in my case only 17,000 of 47,000 made it. We're asking Skimmer Server operators who contributed spots to the RBN last weekend to be sure and hang onto their spot logs (the spot.txt file in the SkimSrv directory) while we figure out whether we can use them to recover at least a portion of the data.
Wednesday, February 24, 2010
Nice Articles About RBN
Nice Articles about the RBN in WorldRadio Online and on QRZ.com . Unfortunately, the QRZ post elicited some misinformation about what RBN is and how it works, which prompted me [this is Pete speaking] to write the following reply:
There seem to be some misunderstandings afoot, so let me try to briefly put them to rest.
First, the RBN is not an advertisement. There are far more people using CW Skimmer than are connected to the RBN. Individuals are using it to chase DX. Others are using it as an alternative to DX clusters, for DXing or for contesting. What we have done is to make it easy for people who are already using Skimmer to report their spots to a central point for display and archiving.
There is one critical difference between the RBN and PSKReporter/WSPRNET, which is enabled by the unique combination of CW Skimmer and software-defined receivers. Skimmers report all the CW activity on a band, or up to seven bands at once, *independent of frequency*. During the ARRL DX Contest, in 48 hours the RBN archived over 300,000 spots on 160-10 meters, despite serious problems with the server throughput which suggest that as many as 2/3 of spots didn't get through.
Multi-band Skimmers were operating from Europe, North and South America, Australia and Japan. If you were on during the contest, the chances are very good that you were spotted. You can go to the RBN and ask.
We are very conscious of the fact that the RBN is having growing pains, and that it could be a much better resource for the amateur community with an expanded team working on configuration and code optimization, a more flexible query engine, and similar problems.
With this in mind, we have set up a blog at http://reversebeacon.blogspot.com and intend to use that platform to invite others' contributions. Please check it out.
73, Pete N4ZR and Felipe, PY1NB
There seem to be some misunderstandings afoot, so let me try to briefly put them to rest.
First, the RBN is not an advertisement. There are far more people using CW Skimmer than are connected to the RBN. Individuals are using it to chase DX. Others are using it as an alternative to DX clusters, for DXing or for contesting. What we have done is to make it easy for people who are already using Skimmer to report their spots to a central point for display and archiving.
There is one critical difference between the RBN and PSKReporter/WSPRNET, which is enabled by the unique combination of CW Skimmer and software-defined receivers. Skimmers report all the CW activity on a band, or up to seven bands at once, *independent of frequency*. During the ARRL DX Contest, in 48 hours the RBN archived over 300,000 spots on 160-10 meters, despite serious problems with the server throughput which suggest that as many as 2/3 of spots didn't get through.
Multi-band Skimmers were operating from Europe, North and South America, Australia and Japan. If you were on during the contest, the chances are very good that you were spotted. You can go to the RBN and ask.
We are very conscious of the fact that the RBN is having growing pains, and that it could be a much better resource for the amateur community with an expanded team working on configuration and code optimization, a more flexible query engine, and similar problems.
With this in mind, we have set up a blog at http://reversebeacon.blogspot.com and intend to use that platform to invite others' contributions. Please check it out.
73, Pete N4ZR and Felipe, PY1NB
Tuesday, February 23, 2010
Welcome to Our Blog
It's been almost two years now since we had the idea for the Reverse Beacon Network. The RBN (we'll call it that here, mostly) has prospered since then, and we have big plans for it now, but the ability to realize those big plans requires us to reach out to the wider community for help. That's the idea of this blog. Stay tuned. Much more to come.
Subscribe to:
Posts (Atom)