Hey all,
It’s been a while since I’ve used the feature, but does it still work to put “s+48” (for example) in the comments field of an extend the window for when the RBN will listen for you and still post your spot when it hears you?
I know there’s some new rbn interface, so if anything has changed, please let me know.
Thanks,
Tim
K6TW
Second question on this this week, first on nasota, now here 
Yes, the S+ / S- features work.
There’s a full list at: RBNHole
Thanks- posted twice to be sure to get a response before I leave on my trip in a couple hours.
OK, I tried this feature this past weekend and am not sure it worked. After a lengthy hike and climb to 11,700’, I called CQ for 20 minutes before I started getting contacts. I see RBN first spotted me at 2216 and there was never a corresponding rbnhole spot posted on sotawatch. I only started getting contacts after N4EX manually spotted me at 2235. I did include “s+54” in my comments. Any idea why rbnhole didn’t spot me using one of the many spots that appeared on rbnetwork between 2216 and 2236? RBN - Reverse Beacon Network
Thanks,
Tim
K6TW
I need to check, but I think it is because S+54 is a fairly large extension of the window, enough that your alert is no longer displayed on SOTAwatch, so it vanishes from RBNhole’s regularly updated list of alerts.
That’s a bug, so I will try fix it in the next few days
Thanks for fixing this. For us backpackers who stay out for extended periods of time, this will be very helpful. I try to spend a week each year on the trail and I know there are others who might stay out for three weeks at a time, to do the JMT, for example.
OK, this is a harder problem to fix than it seems at first.
As a summary, I keep a record of all alerts on SOTAwatch in a database, pulled down every 10 or 15 minutes (I can’t remember exactly, but it’s not that important so I won’t look it up 
). My current approach is to remove all alerts from the table, and repopulate with the alerts currently listed on SOTAwatch. Thus, the table is a direct copy of the SOTAwatch alerts page, in a format RBNHole can handle, minus excluded alerts and operators that have opted out.
The S+/S- is implemented using a start/end time window calculated from the SOTAwatch alert time and any S+/- bits in the comment string. The obvious solution is to not remove all the alerts from the table at the beginning, simply remove those alerts for whom the end time is earlier than now. Easy. Looks like one case to handle, which is to not insert alerts into the table that are already there (avoid duplicates).
This is relatively easy, except for the fact you also have to handle the fact that people can modify alerts. This increases the cases we need to handle. And there’s a few tricky ones.
Case 1: Alert time the same, operator the same, new summit code. Straightforward, update the summit code, continue.
Case 2: Alert time the same, operator the same, comment changed. Straightforward, check the comment for “S+/S-” and update start/end times accordingly.
Case 3: Alert time the same, operator the same, comment now contains “NoRBNHole” etc. Now we need to delete the alert from the table. Still relatively straightforward, but some extra handling required as usually alerts don’t make it down to this point if they’ve been excluded. Nothing insurmountable, but we’re now up to about 5 times the code we initially thought we needed.
Case 4: Operator changes alert time. Now we run headlong into the first brick wall. Let’s assume I’ve posted an alert for 1 Jan 2017 for summit VK3/VC-030 at 0000 hrs. I’ve also got an alert for 1 Dec 2016 for the same summit. Got to maximise those points! I suddenly realise I won’t make it on 1 Jan because I’m going away, so I change to 2 Jan 2017. How do I identify this alert change? My table contains an alert with my original time. I could look for same operator, same summit, but there’s two alerts for that summit. Which was changed? Oh, I can check to see if either of those is duplicated already, but now I’m not processing row-by-row, I’m getting into deeper SQL query territory. Lots more complexity now.
Of course, on SOTAwatch (and in my DB) the primary key is a separate alert ID, which isn’t available to RBN Hole to identify modified alerts by. I can talk to Jon about that.
Case 5: Operator deletes an alert. Now I’m seriously screwed. The alert is gone, and I have no idea it’s gone. But, I have eternal faith in the power of computers to fix problems. I’ve got this. I can go through and scan my list of alerts for any that are in the database but aren’t in the list and assume they’re deleted. Which, if you’re still following, is functionally the same as (and 10x more complex than) deleting the entire table and repopulating - my current approach.
The real kicker is you have to delete alerts; it’s a non-negotiable, as someone will get spotted if they abort due to weather, stay home, call CQ and get picked up by the RBN. What follows is much irate (and I guess justifiable) complaining on the reflector.
Case 6: Alert disappears from SOTAwatch after 36 hours: this is the original problem. This is functionally equivalent to Case 5. The alert disappears. Did an operator delete it, or did SOTAwatch hide it? I don’t know, and by now that bottle of scotch is looking tempting.
In short, I’m reverting any changes I’ve made here and will go back to the existing approach for now. Longer term, I’ll work with Jon on getting the SOTAwatch API to the point where I can pull alerts with an identifying string/ID and maintain a proper set of alerts.
In the interim, you can invert your logic, and rather than do a S+54, do an S-54 and alert later, or alert each day you intend to be out at 1200hrs and the intended summits you are going to approach with a S+12/S-12.
Putting up at least one alert for each potential day makes a lot of sense from a chaser’s point of view, too…
I was out again this past Saturday (8/27) for an activation and based on the length of time it took chasers to reply, I’m guessing the rbnhole feature didn’t work again. I did as you suggested and set the alert time for 1200utc with a s+12 and s-12 in the comments. I was spotted on RBN at 1940utc. However, my first hf contact wasn’t until almost 30 minutes later. I suspect the rbnhole feature didn’t work because I started getting contacts within a few minutes after doing an aprs self spot, which was around 2000utc.
I looked at sotawatch to try and see what happened and if rbnhole ever picked me up, but its been past 72 hours and the data is no longer there. Can you tell me if rbnhole worked?
Thank you for your time and effort on this.
Sat 20:10 WO6B on W6/CT-039 - (Posted by KM6CEM) 146.520 fm
Sat 20:01 K6TW on W6/SS-299 - (Posted by APRS2SOTA) 14.064 cw
Sat 19:52 KX0R on W0C/SP-101 - (Posted by RBNHOLE) 18.0929 cw
Nothing from RBNHOLE.
Maybe you could alert using multiple alerts. First one for 0000 W6/SS-??? S+12 then 1200 W6/SS-??? S+12 and repeat for each day you expect to be active. I don’t know if that would fix the problem.
And here in lay the bug. For some reason lost to the mists of time, I didn’t check for lower case ‘s’. That then uncovered a second bug that would only stretch time if you had both S+ and S- set (this didn’t affect you, but did another alert coming up).
Fixed now.
Great, thanks! Does this mean we can now add s+48 (anything longer than 12)? Or are we still limited to a max of 12 hours, plus or minus?
The 12 hour limit is because of SOTAwatch, not RBNhole. You should be able to do S-48, but S+48 will fall foul of the alert disappearing off SW and out of RBNhole’s knowledge
Just came off the John Muir Trail and called CQ for 2 hours to get my 4 contacts while on a previously unactivated peak. I had to go back to this thread to find out why my S+120 instruction in the alert comments didn’t work. I’m guessing the + time window is still limited to 12 hours? Is there a limit on the - window? Could I have done S-120?
Thanks,
Tim
Read the thread you started on nasota the other day with 4 responses all telling you the answers to this question.
tl;dr S-120 will work. As would S-1048576 should you try walking from Vladivostok to Cape Town.
Thanks, didn’t realize there were 4 responses as only one has come through via email so far. I appreciate you confirming and thanks again for your efforts with this immensely helpful software!