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.