It is very annoying to be spotted when simply the call has been exchanged during a s2s QSO.
That looks every time like one had stolen the activators QRG 
I thought a skimmer would produce a spot for stations calling cq only?!
What to do?
Heinz HB9BCB/P
The CWSkimmer software does pretty well but it does make mistakes, so looking directly at the RBN reports may help identify where the mistake happened (though thereâs not much you can do about it once itâs happened).
Heinz.
Unless something has gone wrong, Skimmers only report CQ or TEST calls into RBN.
Not sure which spot youâre referring to, but if its this one:
then there is NO corresponding RBN spot.
Something must have therefore gone wrong in the RBN gate algorithm.
Eric, KU6J, would be the person to look at that!
73
Pete
Thanks Rick and Pete for the contributions!
Unfortunately the comfortable operating position on HB/BE-082 did not provide gapless internet access, therefore cannot speak about details. I thought I saw 3 such improperly spots and in one of these KU6J referred to a skimmer in OE.
May be this inconvenience is the price to pay for a steadily growing number of skimmer stations. Nobody seems to be perfect from the start.
Will try to catch the details next time.
73, Heinz HB9BCB
Hi Heinz
The unreliability of the RBN skimmers, poor radio conditions, QRM and QRN of late and the levels of activity around freqs such as 7032 mean activators on CW ought to be identifying with their callsigns every few contacts to my mind, which I know you do. Its risky for chasers to rely on an RBN spot without actually hearing the activators callsign themselves. They may well log the wrong station if they do.
73 Phil
I see it that way, Phil.
Observed lately that a skimmer sent spots with a delay of up to 30 min ⊠which leads undoubtedly to confusion.
73 cu, Heinz
There were two occasions on Saturday when RBNGate posted SOTAwatch spots for you out of nowhere. You were spotted on six occasions last Saturday, as follows:
Sat 09:24 OE6JTD/P on OE/KT-148 (Posted by DJ5AV) 7.031 cw
Sat 09:21 HB9BCB/P on HB/BE-082 (Posted by OE3KAB) 7.032 cw
Sat 09:18 S5100ISONZO on S5/JA-042 (Posted by KU6J) 7.0299 cw
Sat 09:44 OE6JTD/P on OE/KT-148 (Posted by DL3HXX) 7.033,8 cw
Sat 09:44 HB9BCB/P on HB/BE-082 (Posted by HB9BCB) 14.061 cw
Sat 09:40 S5100ISONZO on S5/JA-042 (Posted by KU6J) 7.0299 cw
3) Bad RBNGate spot at 10:03
Sat 10:04 EA1LQ/P on EA1/CR-034 (Posted by EA2DT) 14.285 ssb
Sat 10:03 HB9BCB/P on HB/BE-082 (Posted by KU6J) 14.0609 cw
Sat 10:01 HB9DPR/P on HB/OW-015 (Posted by KU6J) 10.1241 cw
RBNGate claims spot was:
*"CQ CQ at 28wpm. S/N=12 dB at DJ3AK {Via RBNGate}"
There is NO corresponding RBN spot.
Sat 11:57 OK2PDT/P on OK/US-014 (Posted by OK2PDT) 7.032 cw
Sat 11:49 HB9BCB/P on HB/BE-082 (Posted by KU6J) 7.0339 cw
Sat 11:48 DB7MM/P on DM/BM-369 (Posted by DB7MM) 145.500 fm
Good RBNGate spot triggered by IK3STG RBN spot below:
IK3STG,I,EU,7033.9,40m,HB9BCB/P,HB,EU,CQ,25,2015-09-12 11:49:23,26,CW
OK1IAK,OK,EU,7033.9,40m,HB9BCB/P,HB,EU,CQ,10,2015-09-12 11:49:26,27,CW
HB9DCO,HB,EU,7033.9,40m,HB9BCBX,HB,EU,CQ,12,2015-09-12 11:49:32,26,CW
DF7GB,DL,EU,7033.9,40m,HB9BCB/P,HB,EU,CQ,26,2015-09-12 11:49:37,28,CW
5) Bad RBNGate spot at 12:15
Sat 12:18 YO/HA8LLH on YO/WC-182 (Posted by SP9AMH) 7.032 cw
Sat 12:15 HB9BCB/P on HB/BE-082 (Posted by KU6J) 7.0339 cw
Sat 12:13 OK2HIJ/P on OK/OL-006 (Posted by KU6J) 7.0337 cw
RBNGate claims spot was:
*"CQ CQ at 27wpm. S/N=13 dB at OE6TZE {Via RBNGate}"
There is NO corresponding RBN spot.
Sat 12:38 YO/HA8LLH/P on YO/WC-182 (Posted by DL3HXX) 10.118 cw
Sat 12:36 HB9BCB/P on HB/BE-082 (Posted by KU6J) 14.0609 cw
Sat 12:34 OE/S57NAD/P on OE/KT-230 (Posted by S57NAD) 145.550 fm
Good RBNGate spot triggered by SE0X RBN spot below:
SE0X,SM,EU,14060.9,20m,HB9BCB/P,HB,EU,CQ,8,2015-09-12 12:36:04,27,CW
SK3W,SM,EU,14060.9,20m,HB9BCB/P,HB,EU,CQ,22,2015-09-12 12:36:08,27,CW
(Raw RBN data from raw data download - Reverse Beacon Network )
Excellent analysis, thanks Rick!
RBN raw data never considered until now, hi.
73, Heinz
Hello all,
My experiences with this RBN tool are very good. It helped me a lot to get sufficient QSOâs in my log.
The 3 W from my KX1 into a random wire is most of the times picked up. Only when activating from EA8 I was not picked up by RBN.
I see that there is some room for improvement but I like to say here that I am pleased with this system.
73 de geert pa7zee
Yes, itâs a very useful tool, especially if your mobile phone drops off the network. If it wasnât useful then folk wouldnât bother mentioning when it went wrong.
Under poor conditions, skimmers may occasionally fail to differentiate between the station calling CQ and the call sign of the replying station i.e. skimmer(s) pairing a CQ and a call sign on the QRG even though the signals originated from two separate stations. This could trigger a RBNGate spot on SOTAwatch if both involved stations have active SOTAwatch alerts (which is usually the case for S2S contacts).
On one (known) occasion, a skimmer captured my call sign when I sent it a single time in reply to an activatorâs CQ. I was just chasing that day, so this instance did not result in a SOTAwatch spot; however, the result was even worse. That erroneous spot was quickly followed by QRM on the activatorâs frequency as an SKCC member began to persistently call for me. l stayed off the key to avoid more QRM until it became obvious the guy would not quit until I answered him. Fortunately, he copied my quick âDN 2â and followed me away from the activatorâs QRG. It was only much later that I pieced together the cause of that incident.
I learned that the SKCC op had been filtering RBN spots for call signs of other SKCC members (I am a member of that group). Looking at the reverse beacon website, I found - yes indeed - one single spot for my call sign that day . . . at exactly the time when I replied to the activatorâs CQ. That erroneous RBN spot was then compounded by the LID-ish behavior of the SKCC op who blindly called me even though he hadnât heard a peep from my station. Terrible operating practice.
On reflection, though, that situation compels me to briefly climb onto the soapbox. Doesnât the bad behavior of that SKCC op seem awfully similar to the chaser LIDS who canât stay off the key when conditions are such that they hear nothing at a SOTAwatch spot?. I know youâve heard their QRM, too . . . the ones who immediately begin sending jug handles, or SOTA?, or a 2x2 call for the activator as if he must certainly be standing by, awaiting THEIR arrival on frequency.
Gary, K9ZMD
Ridgefield, Washington
âŠbut in that case Iâd expect to see the bad skimmer reports in the raw RBN data archive. In this case, if the raw RBN data archive is complete, then there would appear to be NO corresponding RBN spots.
I guess itâs possible the raw RBN data has actually been filtered, and the offending bad skimmer spots were removed during the filtering before the raw RBN archive data was saved (but then why call the data ârawâ?).
An examination of the data RBNGate actually received and the actions it performed as a result might explain the cause of the problem, but thatâs probably something only Eric, KU6J, can investigate.
Thereâs an RBN filtering application at http://pa4n.xs4all.nl/bandmap.html which covers a fairly comprehensive range of such choicesâŠ
Here is what happened:
Iâve been running RBNGate on one primary computer and on a 2nd backup computer. This last weekend was the North America SOTA weekend, so on Friday I decided to power up a rather ancient 3rd computer to use as a 2nd backup instance. This was to assure that my North American brethren (and everyone else) could continue to be auto-spotted in the very-very unlikely event that BOTH of the other two computers failed.
HoweverâŠ
The ancient 3rd computer had been shut down for a long time (a year or so?), and when MS Windows started up, it was running very-very slowly. This very-very slow performance led to a very-very long time lag between when an RBN spot arrived via Telnet and when it was finally pulled out of the Telnet buffer and processed.
In Rickâs âBad RBNGate spotâ instances 3 and 5 above, there actually were corresponding RBN spots, itâs just that they were 21 and 18 minutes earlier respectively(!). This very-very long delay was so long that it exceeded the dupe check interval, and both of these spots were sent on to SOTAWatch. There may have been other instances of this happening as well.
Iâve now rebooted the ancient computer and it is running much faster. Why? I donât know. Perhaps it had been offline for so long that it was trying to update itself when I first booted it up, and that led to the very-very slow performance before(?). Anyway, for now Iâm going to let it continue to run a 3rd instance of RBNGate (2nd backup instance) and keep an eye on it.
Regards,
Eric KU6J
Ha, you set up another machine as backup/failover and had problems. I should have reset the SOTAcluster knowing it would be busy and I forgot and so had a 17hr outage. Iâve been meaning to make so it gets reset every 24hrs but have avoided it as that wont actually fix the bug that causes lockup, just disguise it.
Of course it runs for weeks and weeks without a problem till itâs important that it keeps workingâŠ
A system with a mean streak? 
âŠand, of course, the SOTAwatch spot time is the time the spot is received by SOTAwatch. The others all being within a minute or so of the RBN time, Iâd figured a window about ten minutes long would be plenty long enough. Oops.
Thanks for the explanation.
Eric good to know you identified the error.
Itâs a great facility and, regardless of the occasional bad press, itâs extremely timely and accurate.
In fact, Iâm always amazed at the forum traffic that arises over very minor RBNgate (usually human induced) errors!
There are far more errors made by âhuman robotâ spotters than there ever are by RBNGate!
In fact thereâs a correction on the forum right now and I donât expect there will be any follow up posts 
73
Pete
Sorry to see it like Gerhard Schurr DH2SAA (sk):
âWer aufhört besser zu werden, der hört bald auf gut zu seinâ
âIf you stop trying to be better, soon you will stop being goodâ
Hi Heinz & Pete,
Wise words from Gerhard Heinz.
We should always strive to be better at what we do, I know I do. In my case, just as I was finally getting somehwere with Morse, my job changed & I now donât have the time I used to have to play radio 
Personally, I like the RBNGate, but I donât treat what it says as being 100% correct. The RBN can sometimes get confused when one activator chases another for a S2S & all the RBN hears is a CQ & the âchasingâ activators callsign. This can lead to spots as Heinz descibes earlier that make it appear as though a second activator has jumped onto a busy QRG whereas they were only chasing the first activator for a S2S.
The RBN adds 2 + 2 together & gets 5!
I have seen this many times & to me as a âhumanâ chaser following activity on SOTAwatch & on the air it is usually pretty obvious.
Whilst erroneous spots by the RBNGate do generate discussion, human spotters also make mistakes & I have done so myself on more than one occasion. That is a fact of life & nobody (& no machine) is perfect.
I would rather have the occasional discussion about an incorrect RBNGate spot than comments from activators that they hiked up a very high mountain, stayed longer than they should have in dangerous conditions & didnât work any chasers because they didnât get spotted on SOTAwatchâŠ
RBNGate helps activators get SOTA chaser contacts more quickly when calling CQ away from the traditional SOTA centres of activity (7032, 10118 etc.). Of course, contacts are always available but when an activator is in a hurry, they may not want to ragchew.
It could be better, as could we all 
Thanks & best 73,
Mark G0VOF
âŠbut computer programs can be fixed if you know why theyâve gone wrong, so itâs worth investigating the issue, because then thereâs a good chance it wonât happen again.
Human errors, on the other handâŠ