Wrong ref in RBN spots

After returning from my little tour today, I saw that the RBN-spots gave a
wrong reference for my activity from DL/AL-169.
Obviously I made a mistake in the alert :frowning:

Sorry for the confusion:
I was on DL/AL-169 (and later for a few QSOs on DL/AL-179)

TNX for the hint, Rich!
vy 73 Martin df3mc

In reply to DF3MC:

The same problem today with OK1AU/p - from RBN spots indicate a different reference than where it actually is Standa.
(US-006/US-009)

In reply to OK1HCG:
Hi, I have experienced this many times before.
The RBN spots give the reference from the last
alert or spot. If the activator moves to another
reference without prior notice, the RBN gives the
previous activation. So if you intend to change
the reference be sure to make an alert in advance.

73’s Dan / OK1DIG

In reply to OK1DIG:
Hi Dan
The inaccuracy of RBN spots is another reason why SOTA Activators (especially on CW) should identify with their callsign and reference more regularly than some do. Also when two operators are taking the key in turns from the same summit this is of more importance. It’s very risky relying on SOTAWatch to confirm who you have just worked.

73 Phil

In reply to G4OBK:

What I do now when I activate more than 1 summit is to ensure that either I self-spot from the summit so that chasers can see where I think I am or I ask the 1st chaser who works me on the 2nd (3rd…) summit to spot me and ensure they have the reference. That gets a real location into SOTAwatch.

Yes it can be a problem, the convenience of autospot has a cost and this is it. So it falls on the activator to ensure that they give sufficient information and for the chaser to ensure they have heard a ref being sent. Chasers who blindly assume that spots are always valid will find they have more and more unconfirmed QSOs in their log.

It’s very risky relying on SOTAWatch to confirm who you have just worked.

Worse Phil are those who see a spot but cannot hear the activator yet still send their call. They hear what the pileup is doing and know when to send, but mainly they cause QRM. As an activator you hear someone call and you try to have a QSO but they cannot hear you, yet they call and call and call. It’s poor operating and it QRMs the activator and slows down the activation. If you cannot hear the activator then don’t TX.

Andy
MM0FMF

In reply to MM0FMF:

summit to spot me and ensure they have the reference. That gets a real
location into SOTAwatch.

RBN sometimes spots the change in location, and other times sticks to its guns and spots the wrong one. Something to do with it only believing self-spots, I think…

73, Rick M0LEP

In reply to M0LEP:

No. It’s based on the information it retrieved from the alerts and the time windows, default or included in the alerts. There may be bugs. I’m going to shock you, there are bugs in the code I’ve written. There, all your illusions shattered! So there may well be bugs in RBNgate.

But I’ll bet you that the spots sent are entirely causal in that you can see the alerts that were read and the knowledge it gained from them and how it was used to trigger a spot when that station’s call was spotted via RBN and the skimmers.

Andy
MM0FMF

In reply to MM0FMF:
Sometimes it seems to be working from alerts us normal users can’t see any more. :wink:

Oh, and I knew there was something different about self-spots; see this from the RBN FAQ:

I was really late in getting to my first summit, and RBNGate spotted me
on my planned 2nd summit of the day instead of the one I was actually on.
Two chasers quickly spotted me on the correct summit. Why did RBNGate
continue to spot me on the incorrect summit?

For the purpose of overriding information in Sotawatch alerts, RBNGate
ignores spots made by anyone other than the activator.

(Ref RBNGate by KU6J - Automatic SOTA Spotting )

73, Rick M0LEP