Skimmer fault ?!

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 :grimacing:

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

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!


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:

  1. Spot by OE3KAB at 09:21

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

  1. Self-spot at 09:44

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.

  1. Good RBNGate spot at 11:49

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.

  1. Good RBNGate spot at 12:36

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

1 Like

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


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.


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? :wink:

…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. :wink:

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 :stuck_out_tongue_winking_eye:


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 :frowning:

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 :wink:

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… :wink: