RBN Hole - What just happened?

Activation Reports Issues/Errors
1

RBN Hole just squirted out a spot for WD6TED. We all arrived on his freq. to hear him having an SKCC QSO. I thought, OK that’s weird but it is a pretty slow SOTA day so he might as well spend some quality time on the QSOs =)

So I waited until he finished up with KA3LOC and then called him. Long pause. He calls me back and I give him the standard SOTA QSO treatment, knowing there are lots of other chasers waiting their turn. I sign off with him and I hear the pileup calling him… no response.

Thinking, hrrm something is not right here I go and look at SOTAWatch again… I see that his spot was posted by RBN Hole but I DO NOT see any alert for Today. I do see an alert for Monday 16 October 2919 =)

So, why did RBN Hole throw a spot? Is the code only looking at the last 2 digits (gasp!)? Isn’t that how we got in to the whole Y2K mess? :laughing:

Sorry, did I mention it’s a slow SOTA day? Guess I should get back to work now…

73,

-Josh

2

I’m stupid, but not that stupid :slight_smile:

Having said that, I can’t see why it would spit out a spot. I blame sun spots.

3

Can you make it spit out sun spots?

1 Like
4

2919 is a wild card and matches any date. :wink:

(Edit: this was ironic, not intended to be taken seriously… should have added the appropriate emoticon. )

5

So any time that WD6TED gets picked up by RBN Hole, there will be a spot? Pretty cool undocumented feature!! :beers:

Is it specifically 2919, or is there a threshold time beyond which it gets treated as a wildcard?

I like the sun spot idea Andy - maybe if we hook RBN Hole up to the flux capacitor and hit it with 1.21 gigawatts?

-Josh

6

It will be something where (typically) a US format date squeezed through an EU format date route produces a daft date. This daft date when retrieved produces a date that aliases with a real date causing a spot to be produced when it shouldn’t. i.e. 16-10-2919 under/overflows back to 17-12-2019

7

So what you are saying is that if we would just stop using our idiotic date format (mm/dd/yyyy) and conform with the rest of the world (dd/mm/yyyy), everything would be OK? :rofl:

Is it possible to tell where that alert came from (i.e. SOTAWatch 2 / 3, some phone app, SOTL.AS, etc)? Just curious if that info gets captured.

I really love that SOTL.as auto-fills in the current date (in the correct format!) for you when you start a new alert or spot posting. It also allows you to enter times in local or UTC - very nice!

-Josh

2 Likes
8

No, he’s been spotted by RBN a few times recently and not been spotted, so it’s something peculiar. All dates are stored as 64-bit Unix epochs, so it’s not a date format thing (I can see the dates are stored correctly). My next thought was a 32-bit wraparound, but that doesn’t compute.

As to where the mistake came from, it’s clearly a fat finger problem, although the comment on the alert might give a clue too

9

….“So any time that WD6TED gets picked up by RBN Hole, there will be a spots?”

Reminds me of the first RBNGate beta, Josh, which compared RBN spots to a list of known activators, whether they were on a peak or not. Gulp.

Elliott, K6EL

1 Like