Other SOTA sites: SOTAwatch | SOTA Home | Database | Video | Photos | Shop | Mapping | FAQs | Facebook | Contact SOTA

Wrong RBN frequency -> Wrong Spot


#1

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


#2

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.


#3

Hi,
thanks!
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


#4

Do nothing? I can do that.


#5

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


#6

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?


#7

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


#8

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.

Martin