I’ve just pushed a couple of updates to RBNHole that should make things a bit better (not that it isn’t perfect already…):
Firstly, I now pull in CW spots from SOTAWatch, so if you are spotted on your QRG before RBNHole gets in on the action, RBNHole will mute itself and not spot you. It works on the same code that does frequency lockout, so the 10 minute/band change rules apply. If you change bands, RBNHole will respot you (unless you spot yourself first); if you stay on frequency more than 10 minutes, RBNHole will throw a spot up.
Secondly, I’ve added in a watchdog routine that monitors incoming spots from the RBN. If there’s a two minute window in which no spots are heard from the RBN, RBNHole will kill the existing RBN connection, and start a new one. This may take up to a minute for RBNHole to process. Incidentally, this approach is often known in the industry as STONITH. I’ve chosen two minutes as the window as I’ve never seen a situation where the RBN doesn’t have at least one spot over this timeframe (in reality, I’ve never seen a minute without an RBN spot, but I’d like a bit more certainty and to give the TCP stack a chance to time itself out and reconnect)
Neither of these features are particularly easy to test live, so I’ve basically just pushed them straight to production on the assumption if it breaks, someone will email me or post on the reflector So far, so good, it seems.
If there’s any issues, I’ll be awake for a few more hours, or will pick them up at some point in the morning. Hopefully this yields a more reliable RBNHole, particularly on weekends when the system seems to fall over during periods of high activity. At the very least, it should allow me to test the stability of the RBN relay I’m connected to.
It’s not at my end - the server is plenty beefy enough It’s the RBN end. It appears they have a tendency to drop connections without sending any TCP handshakes to finish the connection. The Hole side rightly hangs around expecting more data, until it times out. Some times reconnects work, sometimes they don’t, and RBNHole used to give up after three attempts (as a good citizen). It tends to happen on contest weekends, hence my guess it’s activity related.
Did you happen to catch my previous comment that the s+3 implied spotting window change was not working on 11/19, and it still seemed to be functioning as only s+2?
No big deal, but could you possible say why this was done? Seems like RBNHole is going to be the accurate spotter and should be allowed to over-rule any previous manual spotting. But maybe I’m missing something
Users may mistakenly spot themselves on the wrong hill. But attempting several hills on the same day and not using wildcard spotting is almost guaranteed to produce an incorrect spot from RBNHole followed by wails of indignation from people who need little motivation to wail. If seeing a spot by the user reduces the chances of incorrect spots then it’s a good thing.
This will, no doubt, produce wails of indignation from people who can multi-alert and activate. But such is life
As far as I recall, self-muting is the last feature needed to make HOLE equivalent to GATE. Both codes include S+ and S-, and that requires the activator to pay attention during the involved time period. Hard to undo your extension if you change your mind.
I did, but I couldn’t dig deep into that. I’ve seen a few lately where it’s started as “the window isn’t working”, but really it’s “NA just came off DST and I forgot what time it is in UTC, so my alert was wrong” I can see the window is -1/+3 in the database of alerts. Another change I pushed which isn’t relevant to most people is that I added more debugging so I get a better sense of why someone wasn’t spotted.
As Elliott mentioned, it was basically done for feature parity with RBNGate. However, the reason Eric did it, and from my own experience, is that your frequency in the RBN is very much dependent on skimmers’ and your own sidetone settings, and invariably, you’ll get heard by only one skimmer, which assumes a 700Hz (or 500Hz) sidetone, but you’re on 600Hz, and BOOMSHAKALAKA, you’re spotted on the wrong frequency, and there’s no other RBN skimmers to correct us.
The immediate effect of that is you get people calling you below your frequency (happened to me in DM - I was on 7060, RBNHole spotted me on 7059.9). Hence a self-spot (or someone else spotting you) gets them back onto your frequency without the RBNHole erroneous spot. Remember, the point of the RBN is to answer the question, “Where am I being heard?”, not “On what frequency am I being heard?”, the latter being something you’re expected to know when you transmit
Andy’s points around multi-summit days are also true. The other benefit, for those who hate RBNHole spots, is that if someone’s already spotted you, you don’t pollute SOTAWatch with additional RBN spots.
So this white horse goes into a bar and says to the barman “Pint of bitter and a bag of Cheese & Onion crisps please.”
Barman: “That’s amazing!”
White Horse: “What a talking horse? No there’s lots of us about.”
Barman: “No, no, we’ve had a talking horse in here before.”
White Horse: “Oh the Cheese & Onion crisps, well they’re vegetrarian you see.”
Barman: No, it’s just we have a whisky that’s named after you."
White Horse: “Really?”
Barman: “Yes. It’s really quite popular and surprisingly named after you.”
White Horse: “What… Eric?”
(FX) Ba-dum-tish <(/FX)
Looks like some posts were withdrawn by Rob and I missed part of the thread. Looking to change the name?
The reasons for the name has been explained a few times. As the software gets better, the distinction between “nice and neat” RBNGate and “ragged gap in the fence” RBNHole is narrowing - if not already closed. In any case, I felt keeping the name was important, as a suggestion that no matter how the software improved, it’d never achieve the ‘ultimate perfection’ of Eric’s code. Kind of like Donald Knuth and the versioning for TeX and Metafont, that adds a digit to get closer to, but never reach, pi or e (depending on the software).
If enough people feel passionately about the name needing to change, I’ll put up another poll with a few suggestions. I like Andy’s suggestion of “Eric” as a tribute. Or we can reutilise Eric’s old account KU6J for posting the spots (instead of the RBNHOLE account). We could call it “A Randy Wren” (an anagram of my name), or “Enjuicer” (you can work that out). Or we can choose a new name that has no connection to anyone. Or we can do nothing. All are valid (if slightly different in appropriateness) options.
The name doesn’t matter if we just look into the features!
It’s a big big help for guys who would like to hike in some remote regions where there are no GSM available.
Saying so, I agree that the “Hole” is not fair name for that piece of software, for you or for Eric’s memory.
But that’s up to you!
As a Aussie you have enough sense of humor and amateur radio spirit to decide what to do: A poll, rename it or call it something else.
From my side, I just have to thank you again and again for it.
Well, not saying it is a problem. But during the two CW Activations that I have done since this change was made, I did not get any automatic RBNHole Spots on any frequency that I used during either of them. I had pre-posted a Single Summit Alert (just as I have always done) for 1645 UTC today. At 1700 UTC, whenever I was finally setup, I called CQ for a minute or so to trigger an initial automatic RBNHole Spot. However, I did not get any automatic RBNHole Spot. Whenever I changed bands at 1730 UTC, I did that 1 minute CQ again. I did not get any automatic RBNHole Spot there either. I did not post any Self-Spot prior to my sending the first CQ out on each band for any of these instances. And I see that I was reported 50 times on the RBN Network today, consistent with my operating times. And it seemed like I was well within the Alert Window.
During previous CW Activations (prior to this change), where I had put in the same pre-posted Single Summit Alert, whenever I was setup and called CQ for a minute or so, I always got an automatic RBNHole Spot. Usually within that minute. Whenever I switched bands, doing that 1 minute CQ again there got me an automatic RBNHole Spot there also. It was smooth, and painless.
While what I am seeing does not seem consistent with the description of the change, maybe I don’t fully understand it. I can only say that I liked it a lot better the way that it was. It was 22F (-5.5C) whenever I was out there today, and having to stop and fuss with my cell phone (that did not seem to like the cold any more than I did) to type in a Self Spot with my cold fingers was quite difficult.
I can see that the RBN saw you, and that RBNHole tried to spot you, other than during times of spot lockout. Which points the finger at the spot lockout mechanism, which actually didn’t change here (only the source of spots which might cause lockout). A longer dig into this found a bug which suggests this has NEVER worked properly.
So, I’m not making it back the way it was. I’ve fixed the underlying problem. There may be other implications that I’ll need to examine, but your issue was specifically a wrong function being called in the database, yielding a large lockout window, which caught previous RBNHole spots as being within the window.
Incidentally, with the new watchdog/monitoring scheme, RBNHole has been up 99.6% of the time, which I’ll take. It’s not five 9s, but it’s never out for more than a few minutes now.
Andrew - I’m glad that my story led you to that bug. Sounds like that fix will get me back to “the way it was behavior” that I was hoping for. It is early in the day, but I see an automatic RBNHole Spot for N0SA on 40 meters and then another one for him on 20 meters. So, it is looking real good.
Software is never finished. I found a bug that was in some software that I had written that was running in a small business for 8 years. It took that long for the right obscure situation to occur and expose it.
Thank you for all of your efforts in creating and maintaining this fine software for us.
So far, so good, it seems.
It’s the RBN end. It appears they have a tendency to drop connections without sending any TCP handshakes to finish the connection. The Hole side rightly hangs around expecting more data, until it times out. Some times reconnects work, sometimes they don’t, and RBNHole used to give up after three attempts (as a good citizen). It tends to happen on contest weekends, hence my guess it’s activity related.
I can see the window is -1/+3 in the database of alerts. Another change I pushed which isn’t relevant to most people is that I added more debugging so I get a better sense of why someone wasn’t spotted.
