I will be on a hut for all of next week with unclear access to Internet for posting / updating alerts. Now, there are a least two SOTA-worthy 10-pointers with no activation so far, and it is well possible that I will be able to activate both of them in CW.
Here is my question: Will it be possible for me to set up a week-long alert (using e.g. “S+ 168” for a 168 hours validity interval) and hope for RBNhole to create a spot for me should I be heard by RBN? I could use a wildcard summit ID and give the correct REF on the air then.
I cannot predict the day nor time for the activations within those 7 days ex ante.
Since I will be with others, time on the summit will be very limited and I will be dependent on RBN / RBNhole for a successful activation.
73 de Martin, DK3IT
I had the same question before my vacation on Tenerife 3 weeks ago and asked Andrew VK3ARR.
His advice was to place an alert for the last day of the stay and to state e.g. “S-168” in the comment field.
So in your case (assuming that you stay from 15/04 until 21/04) you should set an alert for 21/04/2019, ETA e.g. 2100 UTC, place a wild card for the summit (e.g. DL/AL-XXX) and in the comment field you should state “S-168” (or perhaps better “S-178” to cover the whole first day).
The reason why you should use “last day & S-168” instead of “first day & S+168” is that the alert for the first day will no longer be visible for RBNHole after that date whereas the alert for the last day will be visible for RBNHole during your whole stay.
73, Andy DK7MG
I was rather impressed by the deep thinking behind that long alert period methodology.
I should try some deep thinking next time I’m designing some software!
It’s a lot easier to deep think about something when you have several bug reports and decent logs
But where’s the fun in that?
We need deep thinking for the heights of a summit?
That calls for a beer.
One problem we had with the KU6J version of RBNgate was that a long alert could not be removed except by Eric, himself. So if you changed plans and operated from home during that interval, you were spotted on a summit… ghost hiking. Can a back-end long alert be cancelled by the operator who posted it using RBNhole, Andrew?
Should be. IIRC Eric’s read the alert and noted how long after the alert time to keep the alert active. But once the alert had passed and dropped off SOTAwatch, then it wasn’t possible for SOTAwtatch users to tell Eric’s software the alert wasn’t needed anymore and Eric had to do it. This one works backwards and the beauty is that the alert will be visible for the whole period and the -ve delay means that RBNhole starts spotting before the alert time. The user can kill the alert at anytime and then RBNhole wont see it and wont spot it anymore. It’s a very elegant way of solving the problem we had originally.