There has been some discussion about this on the NASOTA group and the beta version is now online.
Eric KU6J is running a reverse beacon network gateway for SOTA stations. RBN is a system using a piece of software called a CW skimmer. Depending on the radio this monitors part of the CW band or all of the CW bands and decodes CW stations heard. You get a callsign and signal strength. The reports are then posted on the net. There are web sites were you can see real time decodes of who is on the CW bands.
Eric’s extension is to check to see which stations have been heard sending CQ SOTA and grab the frequency and call from the RBN. Now the magic bit… if the station heard on RBN has posted and activation alert and the alert time is within 2hrs of decode time, then Eric’s system will automatically spot the station. There is a lot of code in the system that tries to minimise spurious spots.
So if you post an alert and call CQ SOTA on the key then if you are heard by the RBN you will be automatically spotted onto SOTAwatch. Something which is really rather useful I think.
It’s still beta and you can see some RBN spots currently on SOTAwatch posted under Eric’s call KU6J.
In reply to MM0FMF:
Yes, this really is absolutely fantastic! Among other things, it means you don’t have to worry when there’s no SMS coverage on the summit (as long as you’re operating cw).
In the USA, I’m seeing multiple instances per day, on average, of activations with no alert. Is there a way to help those operators, who appear to be excluded from an otherwise transforming system?
.
Elliott, K6ILM
Troublemaker
Elliott, I didn’t write the code but I think the answer is no. The alerts form a fundamental basis of the error checking/reliability of Eric’s reverse beacon gateway. PLUS, the reverse beacon system does NOT report the presence of “SOTA” as in “CQ SOTA” in any given spot. Also, the shear volume of reverse beacon spots necessitates using the Alerts to narrow it down to a manageable group of potential spots to filter for SOTAwatch.
With the increasing number of spots (and alerts) SOTAwatch is going to
need some filtering options some day soon, though…
An improved version of Sotawatch is already being tested, it will probably replace the current version when a further improvement has been installed and tested.
I guess it will use the alerted ref. So that’s a problem but enough
sending the correct ref. should get a chaser to spot the correct ref.
That’s correct Andy, the software will always use the summit reference from the alert since summit information isn’t included in the spot it received from RBN. This would be a GIGO (garbage in, garbage out) instance where the software dutifully outputs bad data as a a result of bad data being fed into it (the wrong reference in the alert). Here are some other instances where things could go wrong:
Activator enters an alert, wakes up the next day to bad weather, and elects to stay home and work some DX instead. If they call CQ DX within two hours of their alert time, the software will spot them as if they are on the summit. The solution is for the activator to delete their alert when they decide to cancel the activation (the software currently re-downloads the alerts every 15 minutes but could be set to use a shorter interval if necessary).
Activator plans a multi-summit day and enters an alert for each activation. However, they find themselves running quite late. If the time of their CQ SOTA from summit #1 is actually closer to their alert time for summit #2, they will incorrectly be spotted on summit #2. This could potentially happen for all their summits that day. The solution is for the activator to update their alert times when they realize that their day will be running significantly behind schedule.
The new version of Sotawatch changes the format of the alert page HTML, spot feed via Twitter or the RSS spot feed such that my software can no longer parse some or all of the data correctly. In the worst case, the software would never find duplicate spots on Sotawatch so it would send a spot of the station every X minutes, where X is the interval that new RBN spots are considered dupes (by checking them against themselves). Currently I have X set to 60 minutes. The solution to this would be for someone to kindly inform me prior to the new version of Sotawatch going live, so I can shutdown my software until it can be re-tested against the new Sotawatch.
FYI, the software appeared reliable enough for me to allow it to run unattended overnight (local time in California). I can see in its logs that it considered posting 4 different spots for F5UKL on EA2/NV-104. However, each time it found an earlier spot on Sotawatch for the same frequency (from F5UKL via APRS) and refrained from sending it. This is a good outcome!
73,
Eric KU6J
===========================================
Free SOTA Spot Monitor Software: http://www.ku6j.com
In reply to KU6J:
Excellent work Eric. Thanks. Can you just clarify one thing for me…
Does the reporting skimmer have to decode “CQ SOTA” (per the description at the top of the thread) or does it look for a general “CQ” from a DX station (as it would for any skimmed callers) that also appears as an alert in the 2 hour window?
The reverse beacon network doesn’t care what is added after a CQ (if anything), and doesn’t report any information about that. The station could be calling CQ, CQ DX, CQ SOTA or CQ MARS and all of those would be reported identically as a “CQ” spot. My software would thus consider any of those as a possible activation spot if it arrives within 2 hours of an alert for the spotted station.
RBN also listens for stations calling TEST DE G0AZS. These are reported as “TEST” spots and my software filters those out.
73,
Eric KU6J
===========================================
Free SOTA Spot Monitor Software: http://www.ku6j.com
In reply to KU6J:
Thanks Eric… that’s clear. I wondered if the CQ call should be
“formatted” in a particular way… but obviously not.
Marc, to increase the chance that your CQ will be heard, here is a tip that I found on the RBN blog:
Tip (from N6TV): The best way to get spotted by a Skimmer is to send “CQ” or “TEST” and your callsign (twice), with everything sent at the same speed. Sending “TEST” faster than your callsign, or sending the exchange faster than everything else, will make CW Skimmer much less likely to properly decode your call. CW Skimmer must detect your CW speed before it can decode any letters successfully. Varying your CW speed constantly will make it much harder for CW Skimmer to spot you.
N4ZR adds: Also, you must send TEST or CQ, or you will not be spotted. These are keywords that Skimmer uses to identify running stations. No keyword, no spot.
73,
Eric KU6J
===========================================
Free SOTA Spot Monitor Software: http://www.ku6j.com
If the activator goes up a different summit to the ‘Alerted’ one the automatic system will spot the wrong place e.g Barry N1EU today he’s alerted GC-109 but he’s up GC-013
Mon 14:40 N1EU on W2/GC-109 7.04 cw
*CQ CQ CQ at 24 wpm… S/N=9 dB at KQ8M {Via RBNGate}(Posted by KU6J)
Mon 14:38 N1EU on W2/GC-109 7.035 cw
*CQ CQ CQ at 23 wpm… S/N=20 dB at KQ8M {Via RBNGate}(Posted by KU6J)
Mon 14:38 N1EU on W2/GC-013 7.038 cw
219/QSB - band is bad today - thanks Barry!(Posted by KK1W)
Mon 14:27 N1EU/P on W2/GC-013 7.038 other
*Spot[N1EU]: (Posted by SMS_NA)
We seem to be getting multiple spots or is this because Barry has changed frequency.
I was just watching the spots and observed the same thing! LOL, Barry is going to have some explaining to do when he gets home, as he knows how my software works: it will spot the summit based on the summit reference in the alert that he entered. It appears that he changed his mind this morning (vs. his alerts) and went to W2/GC-013 first instead of going to W2/GC-109 first as his alerts specify.
I see that he self-spotted himself on W2/GC-013 prior to going on the air. I’m going to try and add an algorithm to the software that will look for recent self-spots from activators, and use the summit reference from those self-spots to override the summit reference in their alerts. This would thus allow the activator to correct things “on the fly” if they are in a situation where they are able to send spots but unable to edit their alerts.
The spots that my software posted were OK in terms of dupe checking vs. Sotawatch. In each case he had changed frequency by more than 1 kHz, so my software didn’t consider the spot to be a duplicate vs. earlier spots of him on the same band. Several other spots were considered but not posted because they would have been duplicates with existing Sotawatch spots.
73,
Eric KU6J
===========================================
Free SOTA Spot Monitor Software: http://www.ku6j.com
