Wrong RBN frequency -> Wrong Spot

Hi all,

when I was activating HB/GR-012, it took a little longer than expected for the first chasers to call me. It turns out that the reason was a grossly wrong frequency in the first RBN spot:

I was calling CQ steadily on 7.0304 MHz, never changed anything on my MTR, and yet the skimmer operated by HA2KSD spotted me on 7.0158 MHz.

RBNHole then quickly took this frequency up.

Luckily, some chasers found me despite the wrong frequency, and later on @EA2LU was kind enough to post a correcting spot manually.

Strangely, there was only a single RBN spot despite calling CQ for a couple of times. My guess is that the RBN filters out new spots on a new / different frequency for a certain amount of time, and so the first wrong frequency spot blocked others with the correct frequency. Also, the long prefixed callsign HB9/DK3IT/P might be harder to receive than others.

Now, my questions:

  1. Have other experienced similar problems?
  2. Is there anything I could have done better?

73 de Martin, DK3IT

The interface between the RBN network and SOTAwatch worked perfectly. You were heard and the info for you matched against your alerts. The wrong frequency was then spotted for you. The only person who knew it was wrong at this point was you. Future spots for your call on the same frequency are ignored until some time (I think 10mins) or some frequency change (1kHz) occurs. There’s nothing to stop the errant skimmer from spotting you on the wrong frequency again.

  1. Yes, because there is no validity checking and there cannot be checking because it’s an open loop system.
  2. Don’t completely rely on automated spotting.

It’s probably worth mailing HA2KSD and tell him his spotter is sending the wrong information. Maybe mail Andrew VK3ARR @VK3ARR and ask him if HA2KSD spots can be ignored or given lower priority so if his skimmer still sends wrong spots RBNhole will prefer another skimmer.

I already notified HA2KSD of the problem. Likely, they have to recalibrate their SDR.

As for blacklisting HA2KSD in RBNhole - I would not recommend that, because then there would have been not SOTA spot at all. The only thing that would help is blacklisting or downranking HA2KSD in the RBN.

Otherwise, you have to call CQ for as long as the RBN QRG window prevents re-spotting (10 minutes).

So in case Andrew @VK3ARR reads this, please do not take any action. I hope HA2KSD will fix this.

The only thing I could have done was laying out the radials of my Up-and-outer into a different direction to get spotted by another skimmer first :wink:

73 de Martin, DK3IT

Do nothing? I can do that.


Looks like HA2KSD is (still? again?) reporting incorrect frequencies:

Thu 12:10 OK/OM4AA/P on OK/MO-020 7.0312 cw
*[RBNHole] at HB9DQM 26 WPM 7 dB SNR (Posted by RBNHOLE)

Thu 12:11 OK/OM4AA/P on OK/MO-020 7.0166 cw
*[RBNHole] at HA2KSD 26 WPM 21 dB SNR (Posted by RBNHOLE)

Thu 12:12 OK/OM4AA/P on OK/MO-020 7.031.2 cw
“RBNHole” HA2KSD always sends bad QRG pse inform! (Posted by SP9AMH)

Looking at RBN itself, HA2KSD does seem to be 14.6 kHz low on 40 metres…

HA2KSD DL6UNF/P 7017.4 CW CQ 14 dB 21 wpm 1235z 05 Jul
ON5KQ DL6UNF/P 7032.0 CW CQ 11 dB 22 wpm 1235z 05 Jul

If only someone had suggested we don’t use this skimmer until it is working correctly. Oh I did.

Tell me again why we didn’t ask Andrew to do something temporarily about this?

I sent them an email pointing out the problem on June 26 but have not gotten a reply so far.

Since it can have very nasty consequences for a CW activator if HA2KSD happens to be the first spot on RBN, I would recommend to block HA2KSD spots from being used by RBNhole.

Otherwise, it will take at least 10 more minutes for getting spotted by RBNhole, unless one of the expert chasers quickly realizes that HA2KSD spot frequencies must be converted, and subsequently issues a correct manual spot.

@VK3ARR - could you implement that?

73 de Martin, DK3IT

My bad. I had assumed it was a singular glitch and thought blocking the entire skimmer was too harsh a measure.

It should actually not be too difficult to write a script in Python or any other programming language that goes through the RBN data dumps and flags skimmers that report frequencies contradicting a majority of others at the same moment in time.


I have sent an email to the HA2KSD club (Bakony Radio Klub) at their QRZ email address, noting that frequency errors are being reported. Hopefully this will be received well and some attention will be given to it. [edit: this may have happened already - the thread was much older than I realised]


Andrew VK1DA/VK2UH

Puzzled that his has turned up in recentlly updated threads, my email may blow up in my face. Oh well, mistakes are human, to really stuff things up you need a computer…

I had two activations in a row where bad frequencies were being reported by the AC0C skimmer on 20m CW. At least once this led to me being spotted on SOTAWatch 4 kHz off my actual frequency. After reading this thread, I decided to contact AC0C before doing anything else.

I sent him an email on Thursday (2019-12-19), I heard back right away, and yesterday (2019-12-22), all the RBN reports from AC0C for VE2DDZ were spot on.


So it seems he fixed the problem right away. If I notice similar behaviour from a skimmer in the future, my first response will be to contact the skimmer operator and I advise others to do the same.
Malcolm VE2DDZ

1 Like

:+1: to you Malcolm for informing AC0C there was an issue and :+1: to AC0C for responding quickly and sorting the issue.