I’ve had a bit of discussion lately about the RBNHole spotting window, which is currently set to between 2 hours before and 2 hours after the spotted alert time. The original RBNGate used a -1/+3 window. The difference is largely because the ‘temporary’ RBNHole was a quick hack and +/- 2 hour was easier to deal with. Once it became permanent, I didn’t adjust it because I felt people were used to the +/- 2 hour window.
Now, I’m not wedded to either window size. But I do care about democracy, no matter what risks that seems to pose to the stability of the world order. So, here’s a poll to determine what the window should be:
2 hours before, 2 hours after (same as current RBNHole)
1 hour before, 3 hours after (same as original RBNGate)
3 hours before, 1 hour after (original RBNGate reversed, because more options is good, right?)
The RBNHole service should no longer participate in the European Common Market mechanism (RBNHolexit)
Barry, I’ve pinned the topic for a week. The poll will stay at the top of everyone’s topic list until they unpin it (click the pin). When they unpin it will drop down their topic list.
For the very reason that ask which is spooted is the reason why you don’t want to do this.
You could use the window commands to specify when you will be on a summit. But there will plenty of reasons why this will fail meaning you are on a different summit than you expect to be on when the alert is valid resulting in RBNhole doing exactly what it was asked to do and spotting you on the wrong summit.
If you intend to do several summits, alert yourself with a wildcard and extend the spotting window to cover when you will be out.
My system is a bit rough and ready, but tends to work. If I am out on a multi-summit day, I try to update alert times when I reach parking spots or mobile data coverage mid-ascent. If I notice that spots are erroneous in the activation, a self-spot is issued which clears things up.
Failing all that, I am still sending the correct reference during my activation, and chasers are reasonably expected to listen to what I send rather than merely trusting what they read.
Given the way older alerts drop out of circulation, it can make sense (for longer windows, anyway) to lengthen the alert window before the alerted time (so that the alert remains visible) rather than after (and risking the alert dropping off into the forgotten past)…
Does RBNHole recognise spots matching the callsign/summit mask combination when it’s deciding whether or not to issue a new spot?
My understanding is that it reads the alert, without processing anything.
So, I alert that G4AZS/P will be on G/WB-002 at 12:00
and G4AZS/P will be on G/WB-003 at 14:00
If an RBN skimmer receives a CQ SOTA from G4AZS/P at 12:30, RBNHole will notice that, and associate it with the closest alert, which puts me on G/WB-002, and that’s what it will spot.
If I am ahead of schedule, and actually on G/WB-003, that is my problem!
If I accidentally use callsign GW4AZS/P, it will, I think, ignore me because it doesn’t match the alert.
Sorry if I’m mistaken, in which case I’ll get me coat…
The skimmers notice “CQ” calls, but there’s no indication in the information that gets through to RBNHole to say whether they’re plain “CQ” or “CQ SOTA” or “CQ TEST” or anything else. RBNHole has has to work out whether a call is a SOTA one from the alerts and spots it knows about.
There are a couple of related behaviours I’m not entirely clear on:
The first is the tricky matter of matching of callsigns. RBNGate had some way it recognised self-spots (rather than any other kinds of spots) and used information from the self-spot in preference to information from an alert. I’m not sure whether RBNHole also does this. I remember discussions about whether slashed prefixes and suffixes should be honoured or ignored.
The second is the matter of duplicate spots. I think the idea (with both systems) is that spots only appear if they are providing new information one way or another. Spots don’t get posted if there’s an existing spot on that frequency (+/- a small window) for the same summit and callsign within a certain time window. The catch comes if the alert has used a non-specific summit reference like “GM/SS-???” or even “GM/??-???” (and I’ve seen characters other than “?” used for wildcards, too, I think). Is the wildcard applied when doing the checks?
The short answer is it isn’t remotely reliable to assume the RBN will pass on a CQ SOTA call. RBNHole makes no assumptions about the type of CQ that arrives, as there’s no real guarantee what type it is anyway.
I wasn’t around when those debates were happening, but RBNHole essentially is a direct callsign match. I suppose it’d be easy enough to add in checks for /P stations as well via another query against the RBN spots. RBNGate used to scrape the SOTA twitter feed to get the latest spots, and used those spots as a lockout for any RBNGate spots. If there was an existing spot for an RBN activator on the same band, then RBNGate would not place a spot. I feel dirty enough screen-scraping the alerts page, I’m willing to wait for the SOTA API to pull in Spot details before I implement such a feature. The main advantage of that is dealing with skimmers that use a different offset to you and spot you 100Hz above or below.
You’re making an assumption here that is false: that the RBN knows anything about summits and can therefore pass it to RBNHole/RBNGate. The only way of determining summits is by checking which alert is within the window. This means if you’re late to the summit, sometimes you’ll get misspotted, and sometimes, if you stay too long and enter the window for your next summit, you’ll get misspotted. So, no, the wildcard isn’t applied, as RBNHole isn’t psychic. It will actually post a summit ID with the wildcard in place - GM/SS-??? or G/WB-XXX or whatever you’ve chosen. If SOTAWatch accepts it, it appears on the main screen; if not, it disappears.
Regarding the duplicate spot handling, RBNHole will not repost for a period of approximately 10 minutes, unless there’s a band change or a frequency change of more than a certain amount of kHz. I think it’s +/- 1kHz, but there was some discussion early on. It might be 2.5kHz. I could look at the code, but that would be being diligent, so I prefer to guess from memory.
Fundamentally, RBNHole and RBNGate are both fairly dumb translators of the RBN feed into some semblance of divination regarding what’s actually happening on the summits. If there’s an RBN spot within the window of an existing alert that matches on callsign only, then a spot will placed on SOTAWatch for the closest alerted time, unless we’ve already spotted in the past 10 minutes within X kHz of the existing frequency.
[quote=“VK3ARR, post:17, topic:14171”]You’re making an assumption here that is false[/quote]I think you might have misinterpreted my speculation, as I made it clear right up top that I knew RBN passes nothing other than the fact that it’s heard a CQ call through. You have, however, explained just how much of the information that could be gleaned from SOTAWatch is being used by RBNHole, and that answers all my queries about how it works at the moment.
