Activation Report for OE/TI-361 Sagtalerspitze (10 Points)

Activation Reports
1

Hi all,
I have been pretty busy in the past months, so my progress towards the magic 1000 points is slower than I’d hope it to be. Anyway, last weekend, I tried to activate OE/TI-361 Sagtalerspitze (also called Standkopf) in the Alpach valley in Tirol, Austria.

This was the first Winter activation, and the fourth activation in general, with the last one before back in 2015.

The summit is 2.241m in altitude and has a very nice alpine shape.

IMG_0941
IMG_09413024×4032 1.92 MB

We ascended on skis from the parking at the end of the Greiter Graben valley at an altitude of 1.071m. For a detailed description of the route, see e.g. https://www.tourenwelt.at/skitour/97-sagtalerspitze-standkopf.html.

For the final ascent to the actual summit, I took the direct way through the steep (>40 degrees) North-West face. It was a bit icy, but not dangerous from an avalanche perspective, just slippery.

The actual activation was not very successful: Despite having set an alert in Sotawatch

10
10826×152 94.6 KB

and being spotted by RBN pretty quickly,

26
261602×1082 502 KB

no spot came up in Sotawatch and no chasers accordingly.

Only by chance, @9A6CW came to my rescue with a nice S2S QSO from 9A/DH-006. After 20 minutes, I had to pack up and descent, because it was very chilly and my friends could not stand the wind on the summit any longer.

I am happy to have a valid activation, but of course I miss the 10+3 = 3 points a lot, having put quite some sweat into the 1.100 meters of ascent :wink: .

I do not really understand why RBNhole was unable to create a spot based on my alert and the RBN spots. It seems that instead of writing

S-4 S+6

I may have written

S-4 S+6

so maybe RBNhole could not parse that. The alert was set for 13:00Z, while I was actually QRV at 11:34Z. But I should have been within the 4 hours interval set by “S-4”.

If anybody can explain this to me, I would be very glad. Maybe I just mistyped the time-frame specification and RBNhole discards time-frame specs if they are incomplete or partially incorrect.

Any hint will be much appreciated!

73 de Martin, DK3IT

3 Likes
2

Martin,
Your post had me looking very closely at your two identical versions of the alert comment. But the alert you quoted earlier in the screenshot contained “s-4 s 6” and it appears that the missing sign between s and 6 has confused the system. Just a guess.
Andrew VK1DA/VK2UH

3

Thanks Andrew! That is also what I assumed: That I had accidentally used a space instead of a plus sign for the end of the spotting interval. Still, I think it would be better if RBNGate would accept a partially valid spotting interval spec, i.e. such that if only the beginning or the specified end of the spotting interval can be parsed from the comment string, that one will be used and the default for the other remains active.

73 de Martin, DK3IT

4

I have to admit I rarely use those parameters to guide rbnhole. I am not often early but often late to activate, but the rbnhole’s default tolerances are usually adequate for me.

Andrew @vk3arr would be more competent to comment on the impact of the faulty time spec. But he is a very busy person…

5

Perhaps a pull request on https://github.com/vk3arr/rbnhole/blob/master/fetch_alerts_db.php would be appreciated? :wink:

73, Manuel HB9DQM

6

:slight_smile:
Unfortunately, my PHP skills are very limited, but you are right that both S- AND S+ must be present in order to overrule the defaults:

if (strpos($comment, "S-") !== FALSE && strpos($comment, "S+") !== FALSE)

And since I was 2h20+ early, I was outside the default window :frowning:

Lesson learned :wink:

73 de Martin, DK3IT

7

Hello Martin,

Sorry to hear about a pointless but at least logable activation. WX also looks nice so not a total failure.
Did you consider adding additional spotting options? I know phone coverage for data might not be available on remote mountain in OE/TI but getting an SMS out could work.
Or add an APRS capable handheld and use APRS2SOTA?
I personally like to have more options available. Of course if sotawatch is having troubles like just now things are more complicated.

73 Joe

8

As Manuel says, patches welcome :slight_smile:

9

For your benefit Martin, regexes are normally better for this kind of parsing/matching.

10

It does uses regexes eventually, but testing if a string is in another string or not is orders of magnitude faster with strpos. For examining inside with pattern matching, regexes win.

11

I guess what would have saved Martin’s alert from failing the syntax would be to default the + spec to be ignored if the syntax is incorrect, but still accept the negative spec. Tricky but this is a very handy and neat bit of functionality which would be even neater with some added flexibility in the syntax.

It would possibly be achieved by treating the rbnhole direction/request as two independent requests, one for negative and one for positive, and that would allow you to specify s-2 only, or s+2 only, simply modifying the standard flexibility on one side of the alert time. Is it feasible to split the logic to modify the negative and positive sides of the alert time independently?

An alternative approach is to provide for a block expansion of the times, like an IF width control, which would indicate I could be x hours out from my alert time, so accept +/- x hours. This gets tricky with multiple alerts and could completely trash the identification of the correct summit, I know.

Not much worse than specifying an alert at 0800 and another at 0930, with a spec of s+2 on the first alert, which can already occur.

Excuse the musings.

73 Andrew VK1DA/VK2UH

12

How about just getting it correct?

1 Like
13

Probably adjusting that from binary && to binary || should resolve the issue quickly, the rest of the code appears fairly robust in terms of handling missing items.

1 Like
14

Hi Martin

Your signal was 599 !! on 9A/DH-006
Unfortunately I didn’t notice you need spot…
Thanks for S2S ! CU

Ivica / 9a6cw

15

I now know the unfortunate reason for that (almost :wink: failed activation: The app I am using for creating alerts (SOTA Goat on IOS) seems to remove the plus sign (+) from comments, at least in “S+x”. Tonight, I tried to submit an alert for a planned activation tomorrow on DL/AL-109 (6+3 points btw ;-)) and this time, I am 100% sure that I type “S-5 S+8”, but the comment in SOTAwatch turned out to be “…S-5 S 8”.

Lesson learned: Log in to SOTAwatch directly, even from a smartphone.

73 de Martin, DK3IT

1 Like
16

It’s almost certainly not HTML escaping the character prior to submitting it (probably to Spotlite). Add it to the list of things that need fixing on the software