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.
Good find . No, it’s not quite the same - close, but not quite. I will at some point need to push my local repository up. The github version needs to be sanitised to make sure I don’t inadvertently include password files and the like.
I think the spotting window extension might not be working. I alerted for 1400Z today and I got no RBNHole spots after 1600Z despite 9 RBN spots 1604-1619Z.
RBN hole picks me up sometimes and sometimes not. I send “CQ CQ Sota” then my call sign twice for a few times. Is this the best way to be heard by RBN Hole? Thx. Scott kw4jm
It’s the reverse beacon network of receiving stations that hears your signal. After the RBN receiver logs your cq on their website, rbnhole scans the station list and compares it with the Alerts on sotawatch. If calllsigns and bands match, rbnhole creates a spot for you on the frequency your were heard on calling CQ.
With a few steps to work correctly there are a few ways to miss out. But the first is the rf path to one of the rbn monitoring stations. With short skip temporarily out of action, that is often not happening.
A test is to look at the rbn database online and see if on of the monitors has logged your CQ.
And then there is your alert. Is that up and does it have your approximate time and frequency in the specified format?
Tnx Andrew. I am usually quite accurate on my Alerts. You also mentioned rf path. I use home made wire antennas, usually a vertical or a long wire with counterpoise, which are pretty omni directional, so I dont think I have much control over the path, or do you think there is something I can do there? Tnx agn,
Scott kw4jm
I just re read Andrew’s reply, where he mentioned frequency in the Alert. I often say something like “14-cw, 10-cw, 7-cw.” I think you are telling me I have to be precise about freq. Is that correct? Thx agn,
Scott
Hi Scott,
I was trying to describe the complete path from your alert to the generated spot. As your initial post mentioned “rbnhole picks me up” there was a faint chance that the complete path was not apparent to you. Ie.
Alert > RF transmitted by activator> RF received by a RBN network receiver > RBN spot posted > RBNHOLE system compares RBN spot with sota alert using time constraints, default or specific > RBNhole posts SOTA spot.
I think at present the RF path is likely to be the most unreliable bit.
Re the frequency precision of the alert, I don’t know. I have generally tried to alert a little closer to my likely frequency eg 7.03.
Andrew VK3ARR has provided further suggestions. He’s the guru on rbnhole so I know you are in good hands. I sometimes think I can save him some work by replying with what I know.
Does RBNHole accept wildcard alerts, e.g. w6/nc-??? or w6/nc-xxx?
I was on a summit with @N0MAP last week without cell service. We both had alerts, but mine was for the actual summit and his was with a wildcard. We were transmitting well within the window where RBNHole listens. We both got spotted on RBN, but only mine were translated into spots by RBNHole. Luckily, he was able to find a spot where a cell tower could hear him and put out a spot that way.
And that was after my Garmin InReach spot failed to work @MM0FMF. Garmin must have changed something again. The SOTA gods were not smiling on me apparently.
I’m losing the will to live with Garmin at present.
Try the following
turn off “include a link to my location” in both your account and if you are using a phone app via Bluetooth
type the spot and keep the comment short
after the spot type “inr.ch” without the quotes but with the dot
One of the latest changes makes the map link very long and the message can spill into 2 messages which the spotter cannot handle. I need a better way of handling the device but don’t know what yet.
. No, it’s not quite the same - close, but not quite. I will at some point need to push my local repository up. The github version needs to be sanitised to make sure I don’t inadvertently include password files and the like.