In reply to G8ADD:
I don’t know what it was like then, but it’s wide open now!
Well, in that case there should have been no need for any spots!
73,
Walt (G3NYY)
In reply to G3NYY:
Is there ever?
73
Brian G8ADD
In reply to G8ADD:
is there ever?
No. It is very easy to qualify a sota activation on most of the bands and mainstream modes these days.
Yes. I like to let my friends, and the dedicated chasers know there is a sota point available. Especially if it might also be a less commonly activated hill and/or have som 12m Challenge credit.
Tom M1EYP
Friend or foe
It’s definitely my friend, when I got back into CW it was a godsend, it allowed me to concentrate on identifying the activator and the summit, instead of trawling through the bands looking for contacts. On occasion I have stumbled across a pile up, and have spent ages waiting to hear the callsign, only to find it’s not a SOTA activation at all.
I’m pretty sure the CW bigshots have got it all figured out, but for novices like myself and those thinking of having a go at CW it’s a huge help. And as for the wrong summit ref now and again, no problem, just ask the activator!
And while I am at the keyboard, I always thought of CW as a gentleman’s way of operating. Not so, a CW pile up is just as cut and thrust as any SSB pile up, and he who shout loudest and the longest usually wins, the behaviour and tactics of some operators is not up to the standards one expects from more experienced amateurs, if that’s the example set, don’t moan when those new to the hobby copy it.
73 John M6BLV
In reply to G3NYY:
In reply to OE5EEP:
I sometime wish we would have a text string when put in the body of
an
alert causes the spots to apear either 5 min delayed or spoting only
the band, not the exact frequency…Your thoughts?
I quite agree, Heinz. It has been said that RBNgate is not the problem
… “it is the behaviour of the chasers who respond to the spots”.
However, RBNgate is the catalyst which has given rise to this bad
behaviour.
I’ve no experience of CW pile-ups Walt, but I’ve plenty on SSB. I’ve only thrown my teddy out of my cot twice during all of my activations. My very stern “Standby gentlemen …PLEASE” works a treat for me. In this respect, there’s a lot to be said for working SSB.
73 Mike
2E0YYY
In reply to 2E0YYY:
What makes you think you can’t do that in cw?
Tom M1EYP
In reply to M1EYP:
In reply to 2E0YYY:
What makes you think you can’t do that in cw?
You may well be able to do it in CW. However, unlike when I work SSB, it appears the cw Chasers take no notice, otherwise we wouldn’t be having this debate…
73 Mike
2E0YYY
I know from reports that this issue exists in both modes. I activate in both modes on hf and don’t really experience any difficulties in controlling my qrg in either mode.
Tom
In reply to M1EYP:
Except, of course, for the ones that can’t actually hear you!
73
Brian G8ADD
In reply to G8ADD:
No trouble Brian. I have described elsewhere my process for dealing with them. The situation has improved much.
Tom M1EYP
In general reply: I would echo an earlier comment that it is usefull to be able to see the activator’s cw speed. This lets me see (hear?) if it is worth listening to work out the op’s procedure, or whether the whole thing is too fast for me.
I note from RBNgate that cw speed reports can be a bit variable. For instance this morning OK1DIG/P is on OK/LI-038. On 12M, his speed is reported as 22wpm via 5B4AGN, but on 30M, it is 27wpm via DQ8Z. Is his speed really that variable, ir is this an indication of the system’s accuracy?
Regards, Dave, G6DTN
In reply to M0DFA:
Is his speed really that variable
The more experienced CW ops do seem to manage a wide range of speeds just fine, so it’s possible. However, different skimmers may report different values for speed and frequency. I find it’s worth checking directly on RBN, because then you’ll (hopefully) see what several skimmers are reporting, and have a better idea of what’s actually going on. Usually they’re close on CW speed and not tha tfar apart on frequency, but just occasionally you’ll find a skimmer that’s consistently off, particularly on frequency. I also find the reported signal strengths useful if they’re from skimmers relatively nearby…
73, Rick M0LEP
In reply to G4ISJ:
As I have mentioned before, RBNgate has also given rise to a lot of
confusion by generating spots with the wrong summit reference.
I think this is propaganda broadcast by the anti-RBN brigade.
Oh really? There is another one reported today by OK2QA/P. (See nearby thread).
73,
Walt (G3NYY)
In reply to G3NYY:
Except the alert is for ZL-028 which is what was spotted.
Andy
MM0FMF
In reply to MM0FMF:
Except the alert is for ZL-028 which is what was spotted.
The alert now says OK/OL-028 so presumably it was corrected at some point?
How good is RBNgate at spotting corrections in alerts? Did it miss this one, or did the correction happen after the spot was posted?
Please could RBNgate use a distinct RBNgate account (so that its spots would be marked “Posted by RBN”) rather than tagging along on its author’s one?
73, Rick M0LEP
In reply to M0LEP:
RBNGate downloads a new set of alerts from SOTAWatch every five minutes. This means that it could take up to 4 minutes and 59 seconds for an alert correction to be recognized.
The period of time between alert downloads is a configurable setting and could be made shorter. Making it shorter would have the downside of RBNGate putting more loading on the SOTAWatch server, so 5 minutes was chosen as a reasonable balance between having current (vs. stale) data and loading the SOTAWatch server unnecessarily.
The one exception is when an activator specifies a custom alert window via the S- and S+ codes. When RBNGate first sees one of these alerts, it is immediately written to a local file for caching. This is to allow an extended alert to remain active after it has been dropped from the SOTAWatch listing due to age. Because alerts don’t have unique IDs associated with them (or at least none is provided in the SOTAWatch HTML) RBNGate can’t distinguish between an edited alert and a new alert. This means that two different alerts can be active at the same time: the original one and the corrected one.
A 100% solution to that last corner-case issue would require that a unique ID be added to the alerts in the SOTAWatch listing (perhaps via a hidden HTML tag). I’ve been hesitant to ask for such a change because it would require effort on the part of the SOTAWatch administrator, and these instances are rare enough that it may not be worth the effort to prevent them. Activators can avoid this situation entirely by:
- Entering the alert without the S+ or S- codes.
- Verifying that what they entered is correct.
- Editing the alert and adding the S+ or S- codes as a final step.
Or, they could choose to always use an “at large” summit reference such as W6/SN-??? with their extended alerts. The actual reference can then be passed over the air, and chasers will invariably spot the actual reference shortly after receiving it.
73,
Eric KU6J
===========================================
Free SOTA Spot Monitor Software + RBNGate FAQ:
http://www.ku6j.com
Thanks, Eric. A useful insight into the workings.
I guess the cached alerts might also account for cases where alerts were deleted but spots continued to appear?
(I suspect the cached alerts may be behind most of the confusion for which RBNgate is being blamed?)
73, Rick M0LEP
In reply to M0LEP:
It’s possible Rick, but caching only happens for the small set of alerts that contain an S+ and/or S- code. Normal alerts are refreshed every 5 minutes. By “refreshed” I mean that all current alerts are discarded and the newly downloaded alerts are used instead. If an activator were to delete an active alert, it might take RBNGate up to 4 minutes and 59 seconds to recognize that the alert was deleted (just like the case of updated alerts). They would continue to be spotted during that interval.
The software maintains a number of log files and I can usually go back through them to determine exactly what happened for a particular spot with an incorrect summit reference. I used to do this routinely whenever I saw one, but it eventually became apparent that the root cause of all such cases was incorrect data provided by the activator. The most common instances of this are:
-
Activator intends to activate more than one summit in a day, gets behind or ahead of schedule, so the spots are for one of their earlier or later summits.
-
Activator intends to activate summit A but for whatever reason activates summit B instead. They either forget to, or are unable to, update their alert or send in a self-spot to correct the summit reference.
-
Activator spots themselves on the wrong summit because they actually didn’t know the correct reference (see all the ‘sorry I sent wrong reference’ threads).
-
Activator tried to spot themselves on the correct summit, but made an error while entering the spot. The itty-bitty keypads on mobile devices are tough to operate when your hands are cold, gloved, or the mobile device insists on “auto-corecting” what you type, which is more often “auto-screwing-up” in my experience. Hopefully your mobile devices work better than mine!
A less common instance that still does happen occasionally is what I described before: an activator enters an alert containing S+ and/or S- codes, later corrects or changes the summit reference, and we end up with two (or more) alerts for them that are all active at the same time.
73,
Eric KU6J
===========================================
Free SOTA Spot Monitor Software + RBNGate FAQ:
http://www.ku6j.com
In reply to KU6J:
Maybe the solution is to always spot the summit as ??/??-??? when there are multiple summits alerted for the same day. The activator gets spotted and it’s up to the chasers to get the details.
Andy
MM0FMF
Tuesday dawned dry and sunny, although a little breezy, so it seemed a good idea to combine some SOTA activity with a planned visit to Eastbourne. Before I departed I read Eric’s post above regarding alerts and had a little “play” with his suggested style of entry, before deciding to delete my work and switch off. How glad I was to be to see that RBNgate worked exactly as described!
My first summit was G/SE-010 Firle Beacon. As always I sent an SMS self-spot, then proceeded to call CQ on 10 MHz. Unknown to me, the SMS spotting system was broken, so it was just RBNgate that told the world that I was QRV. A couple of early callers queried the summit reference, but I thought they were just being super-cautious. In fact, they were clarifying the G/SE-??? reference on SOTAwatch. Conditions were excellent, with some really big signals, so there was just a solid wall of sound at times, but, with sensible behaviour by the chasers, I was able to work twenty-six stations before silence reigned, and I was on my way.
A couple of hours later I was on G/SE-011 Wilmington Hill. Once again my SMS self-spot failed, but RBNgate again came to the rescue. This time the wall of sound seemed bigger than ever but, catching partial callsigns and well-timed calls, I eventually gathered thirty-two stations into the log.
My thanks to the callers, the vast majority of whom were extremely well-behaved.
HOWEVER … two stations did not make it into my log.
The first was a high-profile chaser who has been deeply implicated in the “Phantom QSO” scandal. I could see no point in actually having a QSO with him as he will probably claim the points anyway!
The second culprit was a station who insisted on sending his callsign appended with /QRP. As many will know, this is a habit that I find extremely annoying! Nevertheless, he would still have managed a QSO if his behaviour had been better. Unfortunately he seems to think that QRP callers can disregard the accepted norms of etiquette, and he continued to call relentlessly whilst I was working other chasers, and when I called specifically for partial callsigns with completely different letter combinations. Yes, I heard him; no, he’s not in my log!
So, thanks to RBNgate for being a safety net after the SMS system failed.
73 de Les, G3VQO
edited to add that the /QRP station has claimed a chase in the database anyway!