RBNGate seems to insist I’m on a summit today despite there being no alerts for me as well as a “NoRBNGate” directive in a spot I made to try and remedy the situation.
Today is the Flight of the BumbleBees QRP event and I’m operating from home because of forecast of thunderstorms and that’s why I’ve called a few cq’s in the neighborhood of 14.060 - sorry guys, but no SOTA points for working me today.
73, Barry N1EU
Barry,
Another N1EU spot at 1920 UTC. If you’re not on that mountain, someone or … something… must be.
Ha! There’s a spot on SOTAwatch, so it must be true 
It’s just been me from home, all along.
Yes indeed Rich…as you wrote… 
I have a fuzzy memory about RBNGate not updating its internal knowledge of alerts if they’d contained extended window instructions (like “S-5” or “S+7”)…
Yes, that’s my memory as well and not sure why that needs to be the case.
I discussed unintended spots with KU6J three days before this happened to N1EU. If one extends his/her alert with S+, then the alert is cached by the RBNGate machine and can not be countermanded by the posting station using any technique whatsoever. One climber used S+192 for an eight day hike, and he was locked in for the full eight days. Another guy accidentally used S+ in listing alternate frequencies in his alert, and the machine locked him in. The ordinary non-extended three hour alerts are downloaded to the machine every five minutes, not cached, so one who returns home before the expiration of the standard three hours can cancel his alert, wait five minutes for the machine to refresh, and call CQ with impunity.
I don’t know if there was an alert for W2/GC-002 using a call similar to N1EU and a weak skimmer misinterpreted what it heard, but EU has nothing logged in June or July. He has been on that peak more than once, though. One time I posted an alert with the wrong year. When it didn’t appear, I posted it again. A year later, the bad alert dutifully showed up and I didn’t show up… bad. Maybe someone on the MT can look at the alerts for N1EU last Sunday, if any. Then this mystery will go away.
Elliott, K6EL
[quote=“K6ILM, post:8, topic:11283”]If one extends his/her alert with S+, then the alert is cached by the RBNGate machine and can not be countermanded by the posting station using any technique whatsoever.[/quote]Right… That’d be one very good reason for not using the S+/- directives, then… Thanks for the warning.
I had an alert for W2/GC-002 (s+4) but deleted it two days prior to activation date due to wx forecast. I happened to be actively calling CQ from home during the originally alerted time slot and RBNGate went to town.
[quote=“N1EU, post:10, topic:11283”]I had an alert for W2/GC-002 (s+4) but deleted it[/quote]I guess that explains the event; RBNGate still retained its cached copy, and acted on it when it saw your calls from home. If RBNGate has to cache alerts, then it would be nice if it delayed that caching until the latest possible moment, if only to give folk a chance to fix mistakes before the alerted window starts…
That’s an interesting definition of caching you have there Rick! 
That cache needs a little laundering.
It was the word Elliot used for what the RBNGate does, and I didn’t feel like being pedantic…
Tee hee! Dealing with time in any programing issue is like trying to fill a sack with weasels and not get bitten!
I wonder if a new alert for a different summit would fix the issue. i.e. you have a pending S+12 running and you alert you will be on a different summit in 10mins. Spot yourself on that summit with a “Test ignore” comment(*) then update the alert with RBNN. The second alert should override what is happening, the spot should shutup RBNgate spots and then it should read the updated alert.
Might work.
EDIT: Forgot this bit
(*) Of course lots of people wont read the comment and will call on the freq. anyway. Some will log the QSO that didn’t happen too!
Yeah, and it might be a totally confusing disaster.
BTW, this didn’t work at all for me:
Spot yourself to Sotawatch and include either of the following anywhere in your spot’s comment (without the quotes, case-insensitive): “RBNN” or “NoRBNGate”. This will disable spotting based on any of your current Sotawatch alerts or prior self-spots.
Those tools do not work if your alert was extended by S+n. That type of alert locks you in no matter what. Also, if your extension is followed by another number, such as “S+4 5 of us on peak, work us all”, then there is a chance your extension will be 45 hours from the alerted ETA, not 4 hours, ruining for nearly two days your option of going home and calling CQ. Go bowling, instead.
Elliott, K6EL
I don’t think I’ll ever use one of those “s” directives again in the future. I’ll just use multiple non-“s” alerts for the same summit, time spaced. It will confuse the chasers but waddyagonnado?
Barry N1EU
Ah, this must explain why, even though I cancelled my alert for W6/NC-180 and replaced it with an alert for W6/NC-423, that I was spotted at W6/NC-180.
Still not clear why, at later summits, my CQs that were being picked up by the RBN weren’t being repeated on sotawatch.
Will use s+n with caution on all future activations.
73
NF1R