Automatic SOTA spotting

In reply to KU6J:

Thanks Eric

Although I understand, and commend, your desire to avoid “forcing” users down the RBN route, I think that you are in danger of making the whole thing far too complicated. The suggested “RBNgateme” and “NoRBNgate” are rather unwieldy options, and very easily forgotten or mistyped on a cold, wet summit. If they are needed I suggest that “RBNyes” and “RBNno” are more memorable, as well as being shorter. It could even be “RBNY” and “RBNN” using the KISS principle.

However, is there a real issue here? You are already offering users who post alerts two ways of opting-out, either by use of “NoRBNgate” as a comment in the alert message, or as a blanket option if they contact you to request it. That would appear to be sufficient.

At the other extreme we have non-alerted activations who have self-spotted. Surely this means that they wish to solicit as many QSOs as possible, and can reasonably be assumed to equate to “RBNyes”.

The only uncertain case is when a non-alerted activation is spotted by a chaser. In this circumstance it appears best to assume “RBNno” unless there has been a previous self-spot. In case that sounds confusing, this is what I mean –

  1. I activate a summit without a prior alert
  2. I self-spot on 10MHz CW – this activates the “RBNyes” option
  3. I QSY to 14MHz CW, but fail to self-spot my move
  4. A chaser spots me on 14MHz CW – this would normally be an “RBNno” spot by default but my previous self-spot should retain the “RBNyes” option.

I am endeavouring to find an agreed set of options that maximises the benefits of RBN-gate, but minimises the potential complications for users as well as simplifying the coding required.

How does this sound?

73 de Les, G3VQO

In reply to G3VQO:

I am endeavouring to find an agreed set of options that maximises the
benefits of RBN-gate, but minimises the potential complications for
users as well as simplifying the coding required.

How does this sound?

Les, that sounds like a well thought out and reasoned analysis to me!

The case you describe of a non-alerted activation being spotted by a chaser wouldn’t be an issue in the implementation I was contemplating because my software wouldn’t consider such a spot to be authoritative (it is coming from a 3rd party rather than from the activator themselves). I’ve frequently seen chasers enter spots with the wrong summit reference, perhaps due to the urgency they feel for getting the spot entered quickly or possibly because they heard and copied the wrong reference. My preference would be to leave the activator solely in charge of whether RBNGate spots them or not, and which summit it spots them on.

With 3rd party spots excluded from consideration, that leaves the question of whether or not to require the activator to self-spot with a code in their comment such as “RBNYes” or “RBNY” (which are both better than the longer and more cryptic “RBNGateMe” that I proposed).

I agree that if an activator has spotted themselves, they are obviously interested in receiving many calls and are thus not in the small set of activators who wish to opt-out. The benefit of requiring a code vs. not requiring it would then just be to prevent what happened to Barry N1EU earlier this week (he self-spotted the wrong summit) and preventing what happened just yesterday.

Yesterday a NA activator entered an alert for a summit reference ending in 074. When I worked him, he gave me a reference ending in 047. I replied that his alert had said 074 and asked for confirmation. He sent me the name of his summit and it turned out that he really was on 074 (what he alerted for) and not 047 as he had sent. Perhaps these are actually rare events, but seeing two recent instances of an activator either self-spotting or sending the wrong summit reference from the summit, while having it correct in their alerts, makes me wonder.

Anyone who has activated a summmit can understand how and why such mistakes can be made: there may be many things to contend with on the summit all at the same time, such as bad weather, questions from other hikers, an intermittent rig, mast blowing over, etc. Entering an alert at home is a more relaxed process that is less subject to error.

Taking all of this into account, I could:

  1. KISS and not require any code in the activator’s self-spot. The self-spot would override their alert as well (if one exists).

  2. KISS and not require a code, but only consider the activator’s self-spot as being authoritative when they did not post an alert in advance. If an alert existed, self-spots would always be ignored.

  3. Require the code (to hopefully cause the activator to think twice and double-check what they are sending) whether the activator posted an alert or not.

  4. Require the code ONLY to override an alert that already existed. No code would be required if no alert existed (the activator forgot to enter one, is doing a spur-of-the-moment activation, etc.).

  5. Something else…

One more consideration is that spots sent by activators via APRS don’t seem to allow for a comment to be included(?) so requiring a code to be present would exclude them.

So what do you think Les (and others), which way should I go: “RBNY” required under some or all circumstances, or never required?

73,

Eric KU6J

===========================================
Free SOTA Spot Monitor Software:
http://www.ku6j.com

In reply to KU6J: ““So what do you think Les (and others), which way should
I go: “RBNY” required under some or all circumstances, or never required?””

Thanks for all this great work Eric.

APRS2SOTA does allow for comments - but since it’s a pain to enter extra text they are apparently rarely used.

I for one would like “RBNY” to never be required - I’d just like this wonderful magic to happen. I’m really looking forward to “hands-free” spotting. Very much.

Best,
Etienne, K7ATN

In reply to K7ATN:

I for one would like “RBNY” to never be required - I’d just like this
wonderful magic to happen. I’m really looking forward to “hands-free”
spotting. Very much.

Eric,
Thanks for the great piece of work on this.
I’d agree, keep it as simple as possible.
I have no control over human spotters so can’t think why I’d want control over a skimmer!
I am calling CQ after all :slight_smile:

In reply to KU6J:

Good thinking Eric.

My vote would be either for option 1, the simplest, or for option 4 which does allow the activator to add an RBNY confirmation if he/she decides to activate a summit other than that alerted.

I also agree with your suggestion of third-party spots not updating the RBN status for the very reasons you describe.

73 de Les

In reply to G3VQO:

Worked for me! I was delighted to see the auto spot for 30m when I returned home. I certainly knew I had been spotted by someone/something as suddenly my frequency was really busy :slight_smile:

I’ve been paying the bills by programming for 30 years. I’ve worked on cool stuff and I’ve worked on tediously mundane software. I’ve seen and played with cool technology but after 30 years, very little impresses me anymore.

This, however, is cool. What I like is how it unites a whole series of standalone, useful systems (SOTAwatch, CW skimmers, RBN) into one super system. It’s so easy, post an alert, climb mountain, call CQ, get a pileup. Excellent :slight_smile:

Andy
MM0FMF

Yes, it worked a treat for me yesterday. Jimmy posted Bardon Hill alerts for himself, plus me (20m CW) and John G3WGV (30m CW). Without any self-spotting, it appears that the system worked perfectly, and directed the chasers onto our frequency. I think John spent most time on 40m - so I assume this system still works even if you change to an unalerted band?

BTW, how many of you managed to work the first activation in 8 years by our esteemed President and Founder?

Tom M1EYP

In reply to M1EYP:

I assume this system still works even if you change to an
unalerted band?

Yes, it doesn’t care about the bands in the alert. As long as the RBN-spotted callsign is in the alert and the time is +/- 2hrs of the time in the alert, you will be SOTA-spotted (if you haven’t already been SOTA-spotted on the same frequency).

73,
Barry N1EU

In reply to MM0FMF:

I was impressed too, I deliberately posted an alert for my activation yesterday, whereas I normally would not.

In the event both of my chosen and alerted frequencies were in use when I was ready to call CQ, so I had to deviate down 1kHz from my intended frequency of operation.

Within seconds the pile ups began, thankfully they didn’t last long, I tried to push myself to 18wpm and my brain got a bit fried! The skip seemed a bit short to me on 20m yesterday afternoon.

I find that mobile phone coverage is becoming worse on the hills, my theory being that too many cells are ‘visible’ to the phone, due to increased infrastructure. Whatever the reason, I’m pretty convinced that phones on summits these days are pretty useless!

I really appreciate the auto-spotter - thanks to all involved - great job Eric!

73
Colin
M0CGH

In reply to KU6J:
I suspect this is a daft question, but I will ask it anyway! Do skimmers work on vhf cw? If I call cq on 144MHz cw , having alerted and met the other criteria, is there any possibility of being heard and reported on a VHF skimmer, assuming they exist.
73, Frank

In reply to M1EYP:

I missed Jimmy’s alert but came into the shack to see an RBN spot for G3WGV on Bardon Hill (a local summit for me). The call sign did not immediately ring a bell for me but a quick check on QRZ.com revealed all.

I have not got a 10mhz antenna at the moment but figured that it must be the RSGB convention team on their way home so turned on the 2m rig expecting to find Jimmy coming up. Sure enough, up came Jimmy 2E0EYP so after having worked him and spotting him, I noticed a RBN spot for M1EYP on 20m so being within ground wave range worked him. An RBN spot then came up for G3WGV on 7mhz, so thinking there may be some brownie points in it worked him as well just to say that I had worked all the stations in the activation.

I would imagine that this summit is a rare one as I cannot remember any activations other than VHF/UHF in the time that I have been chasing and then made even more rare by a once in eight year activation by G3WGV.

Thanks for the activation and brightening up anotherwise dull SOTA afternoon.

73 de Ken G3XQE

In reply to G3RMD:

Hi Frank,

Here is a link to the list of worldwide RBN skimmers, the list includes the bands being monitored. http://www.reversebeacon.net/skimmers/detail.php

It might answer your question.

73

Robert
G0PEB

As you see from the RBN website, many of the skimmers monitor only a few of the CW bands and many respond only if a transmission includes the term CQ. Here in NA, it’s quite possible for an activator to be on a band where no skimmer hears him/her due to poor conditions and remote QTH. More importantly, we have daily no-alert operations here, where there are less than a dozen regular chasers. Thus, one or two of us over here are just now experimenting with a volunteer posting of alerts when one of those folks is heard. Bingo…Eric’s RBNgate springs into action and spots them with every QSY.
.
Two days ago, a group of us activators from California went to breakfast and exchanged phone numbers. Within hours, a couple of us used those numbers to get help posting alerts for climbs later the same day… Don’t be a no-alert orphan. Make a cell call, even if en route to the trailhead.
.
Elliott, K6ILM
Older & Wiser

In reply to MM0FMF:

I’ve been paying the bills by programming for 30 years. I’ve worked on
cool stuff and I’ve worked on tediously mundane software. I’ve seen
and played with cool technology but after 30 years, very little
impresses me anymore.

This, however, is cool. What I like is how it unites a whole series of
standalone, useful systems (SOTAwatch, CW skimmers, RBN) into one
super system. It’s so easy, post an alert, climb mountain, call CQ,
get a pileup. Excellent :slight_smile:

I had a similar thought yesterday Andy, as it was my first activation since getting the software running. Everyone should keep in mind that the real magic is happening in Alex VE3NEA’s CW Skimmer software. If Nobel Prizes were awarded for the field of amateur radio, then Alex would most certainly win it.

Yesterday I alerted for my usual 20m and 40m frequencies with my 20m frequency being the standard 14.061 MHz. Our chasers have learned that I invariably start on that 20m frequency or as close to it as I can. Once on the summit, I decided to mix things up a bit and start on 17m, where I thought that no NA chaser would be looking for me or any other activator. I had Internet on the summit and the Sotawatch spots page loaded on my iPhone’s web browser.

When the Sotawatch page auto-refreshed for the first time after I had started calling CQ, I saw my RBNGate spot at the top of the list. I literally dropped my keyer paddles, stood straight up and extended my arms skyward, then yelled “Oh my gosh it really works!!” at the top of my lungs. Fortunately this was a remote summit with no one else around for miles. I recovered my composure and quickly worked a small pile of chasers that appeared on frequency moments later. :slight_smile:

I tried several bands and it spotted me on each one. I even tried 80m where I didn’t expect any skimmer to be in range since it was the middle of the day. I’d forgotten about N7TR’s skimmer in Reno, NV (only about 30 miles away) and it spotted me immediately. I had no takers on that band, but it was nice to know that someone in range could have worked me if they wanted to.

I ended up with my highest activation QSO total ever: 33 QSOs. That is a small total compared to activations on your side of the pond, but it is a decent amount for a North American activation. I made those QSOs in less time than it would have taken me to do half as many in the past. It was a really-really fun day. :slight_smile:

73,

Eric KU6J

===========================================
Free SOTA Spot Monitor Software:
http://www.ku6j.com

The system caused a bit of confusion this morning following this alert:

10:00 HB9HST on HB/BE-138 7.032-cw,10.118-cw

The alert didn’t include the “/P”, and the 11 RBNGate spots aren’t unreasonable under the circumstances:

Thu 12:06 HB9HST on HB/BE-138 7.009 cw
Thu 12:02 HB9HST on HB/BE-138 10.1191 cw
Thu 11:07 HB9HST on HB/BE-138 10.115 cw
Thu 11:02 HB9HST/P on HB/BE-138 7.032 cw
Thu 10:51 HB9HST/P on HB/BE-138 7.033 cw
Thu 10:34 HB9HST on HB/BE-138 10.12 cw
Thu 10:33 HB9HST on HB/BE-138 10.123 cw
Thu 10:05 HB9HST/P on HB/BE-138 7.0321 cw
Thu 09:44 HB9HST on HB/BE-138 21.0178 cw
Thu 09:16 HB9HST on HB/BE-138 7.014 cw
Thu 08:01 HB9HST on HB/BE-138 7.027 cw

They’re all but one on alerted bands, and it’s the ones with “/P” that match the alert less well, though they match SOTA expectations better. It’s tricky to know what an automatic system could have done differently under the circumstances (which are at least somewhat unusual), but it probably bears some more thinking about…

73, Rick M0LEP

In reply to M0LEP:

I don’t see how “/P” had any bearing on this at all. RBNgate is correctly reporting a new skimmer spot of HB9HST on a frequency at least 1khz removed from the last spot.

The only “match” that needs to be made is “HB9HST” - there is no frequency matching with the alert involved.

I don’t see a problem with any of those 11 spots.

73,
Barry N1EU

In reply to M0LEP:

Hi Rick,

RBNGate ignores portable designators such as “/P” in both the alert and the spot when doing a callsign comparison between alerts and spots. In all of the cases you listed, the callsign was treated as “HB9HST” for the comparison and for duplicate spot checking, but he was spotted using whatever RBN heard him send with his CQ.

In each of the cases you listed, HB9HST either changed bands or changed frequency by more than 1 kHz, so RBNGate sent the spot in to Sotawatch. I see numerous cases in my software log where an RBN spot of him was rejected and not sent because it would have been a dupe to a spot already in Sotawatch.

All of the spots were within 2 hours of his 1000z alert time. However, not long after the first RBNGate spot of him at 0801z, HB9CGA sent in a spot of him at 0808z with this comment: “no SOTA, says later”.

In response to an NA activator’s request for the spot window to extend to 3 hours after the alert time rather than 2 hours, I have since modified the software to allow the time window before and after the alert time to be independently configured. It might be better for me to reduce the before-alert-time window from 2 hours to 1 hour (or even shorter), especially if HB9HST was indeed not yet on the summit at 0801z.

As always, opinions and suggestions for improvement are welcomed!

73,

Eric KU6J

===========================================
Free SOTA Spot Monitor Software:
http://www.ku6j.com

In reply to KU6J:

Correction: I forgot that I had actually changed the after-alert-time window to 3 hours in response to the request from an NA activator, so his 1202z and 1206z were within that 3-hour window rather than the 2-hour window I mentioned (the before-alert-time window was still set to the original 2 hours when he was spotted at 0801z).

73,

Eric KU6J

===========================================
Free SOTA Spot Monitor Software:
http://www.ku6j.com

Eric, I kept track of alerted time vs first spot, starting in January of this year. There is only one instance of an early start exceeding one hour. If I see that again, I plan to re-alert him/her as a volunteer. There were only two instances of a late start exceeding three hours, both by my friend in Utah. I’ll likewise re-alert in that situation…all to assist RBNGate. Fair enough??
.
Elliott, K6ILM

In reply to KU6J:

RBNGate ignores portable designators such as “/P”

This is what caused the problem today. The callsign without the /P was the expedition BASECAMP and was not a SOTA station. The SOTA operation was conducted by the station calling with the /P suffix.

It’s worth noting that the SOTA MT recommend that activators always use a /P suffix (or at least they used to, I can’t find the reference atm).

Colin G8TMV