From my testing, it appears that it does not. I created an alert, then generated RBN spots on 144.1 MHz with call sign and time matching the alert. The spots, confirmed on reversebeacon.net, were not relayed to SOTAWatch.
If it doesn’t, can it be made to do so? If it already does, what might I be missing?
I’ve set up a skimmer at my QTH to support the small but enthusiastic band of 2 m CW activators and chasers that have cropped up this year in north/central W4V.
In any event, thanks, @VK3ARR, for the fantastic usefulness of RBNHole.
No reason it shouldn’t work. Send me more details and I’ll dig into it (times/callsigns/etc).
(Usual suspects for no spots are the alert must exactly match the RBN spot on reversebeacon.net and no spot will be posted if a spot already exists for you in the past 10 minutes on a frequency +/- 2.5khz)
As a sanity check, I moved my skimmer to 1.8 MHz, 50 MHz and back again to 144 MHz. On each band, I generated an RBN spot matching the same alert tested above and within it’s default -1/+3 hr window. The respective RBN spots were at 1550, 1614 and 1710 UTC, 16 APR.
RBNHole worked on 1.8 MHz and 50 MHz, relaying the spots to SOTAWatch. As before, it did not work on 144 MHz.
Refer to the source code, I wrote the comment past midnight without checking and it’s been several options over the years. I can’t honestly remember the exact amount, the point is there’s a frequency lockout as well
RBNHole pulls spots direct from the telnet feed RBN provides. Here’s two spots one for 20m and one for 2m (minus a # that causes the formatting to turn into a comment):
DX de K1RA-4-: 14068.10 WG0Y CW 15 dB 19 WPM CQ 0013Z
DX de HA1VHF-:144433.60 9A0BVH CW 23 dB 13 WPM DX 0013Z
RBNHole tokenises that string into its various components and then analyses whether a spot is necessary. The issue here is that for (some) >100MHz spots, there’s no space between the colon and the frequency value, so it will get tokenized into a single token, and this will cause the line to be ignored (it has not enough fields).
The fix is probably easy enough (just insert a space after the colon before tokenising the string), but I haven’t tested RBNHole in years, so I need to work out/remember how to set up my test environment again before I push it live!
Thank you! I just tested it and RBNHole correctly spots me on 144 MHz.
However, RBNHole is a little trigger-happy. It spots me even if I just send my call sign without doing so as part of a CQ message.
I suspect this is only happening on VHF, where the RBN spots any call sign heard, not just the call signs of stations calling CQ, as on HF.
There’s so little VHF CW activity, practically speaking, you could probably get away with leaving the behavior as is.
However, if you wish to prevent non-CQ spots from getting through, perhaps you can do so by checking the type field of the spot, which appears to be the next to last token in your example Telnet output above.
Type = CQ: station is calling CQ. Type = DX: station is not calling CQ.
There are two other values for the type field which represent beacons: BCN and NCDXF. Beacon spots are found on the high HF bands as well as VHF. Spots of type DX are only on VHF.
When I initially set it up, I found that field to be pretty unreliable so we ignore it. You should only be spotted once per ten minutes unless you change your frequency by more than 1.25khz. I guess that’s more likely with a drifty VHF rig compared with HF, but still, there’s supposed to be barriers blocking extra spotting.
The issue with passing type=DX spots isn’t that RBNHole would spot a station too often. It’s that it would potentially spot a caller on another station’s CQ frequency.
This would arise if I were answering another station’s CQ while I were on an activation for which I had an alert up. As it currently is, I’d be spotted to SOTAWatch on the other person’s CQ frequency.
But, as I said, I think it will be fine, practically speaking.
There’s so little VHF CW activity, and such sparse skimmer coverage on VHF, this won’t arise very often. And, if it does, the mis-spotted caller would be re-spotted on the correct frequency when he starts calling CQ himself, provided he does so more than 1.25 kHz away from the station he just called.