About QRPSPOTS at Twitter and qrpspots.com

Hi,

Many of you already know this :slight_smile: … but for those who do not, I thought a small reminder would be okay.

Just as you can receive SOTAWatch spots on your cell phone by following SOTAWatch on twitter, you can also receive QRP Spots by following QRPSPOTS on twitter.

(http://twitter.com/qrpspots)

QRPSPOTS was originally developed by Guy N7UN for QRP operators to find each other more easily on the air, but it is becoming more and more popular with NA Activators, since they are often running QRP or near QRP power levels.

You can of course follow both SOTAWatch and QRPSPOTS twitter accounts :slight_smile:

So how does QRPSPOTS work?

You can post QRP Spots in the field either by sending a twitter direct message to QRPSPOTS -or- by sending an APRS message to callsign ‘QRPSPT’.

Note that it does take a couple of days from when you start using QRPSPOTS before the system fully recognizes you (there is a manual step involved).

The format of the message is not critical. If your twitter ID is a callsign, or you’re coming in on APRS, you can leave out the callsign if you are self spotting.

Other than that it should have the callsign and frequency (khz/mhz doesn’t matter). It can have other information in there too like SOTA summit.

Sample:

“VA3SIE/P at 14061khz on SOTA Summit VE2/OU-001”

Just as there is a SOTA Spots web page at SOTAWatch2 there is also a web page where you can view and post QRP Spots. It is here:

http://qrpspots.com/

The twitter account and the web page are linked together. When you enter a spot on the web page, it shows up on twitter (and those in the field following QRPSPOTS on twitter will get it).

When spots are sent to QRPSPOTS on twitter (either as a direct message via SMS or a twitter app, or as an APRS message to callsign QRPSPT), these show up on the web page.

In both cases all the field stations following twitter on their mobile device get the spot.

Personally I find it useful to follow both SOTAWatch and QRPSPOTS when I’m out on an activation. Often a station is only spotted on QRPSPOTS or only on SOTAWatch, and may only show up on the other web page if there’s someone at home who notices the spot and copies it over. I try to do that when I am at home.

The future of QRPSPOTS for Twitter:

Currently one can send a spot to SOTAWatch in the field either using spotlite (Summits on the Air) or as an international SMS message (SpotSMS/SpotAPRS Gateway Log) or one can send a QRP Spot as described above, but I cannot send a spot to both places at once, and all that cellphone fiddling takes time :slight_smile:

So I am developing a SOTA feature for the QRPSPOTS system so that - in future - QRP Spots for a callsign which has an active alert on SOTAWatch2 will also generate a SOTA Spot.

I will post once that is working & stable.

Cheers!
Martin.
VA3SIE.

In reply to VA3SIE:

Currently one can send a spot to SOTAWatch in the field either using spotlite >(Summits on the Air) or as an international SMS message >(SpotSMS/SpotAPRS Gateway Log)

Don’t forget you can send a spot using my SMS server too which currently has 76 registered users.

Andy
MM0FMF

In reply to VA3SIE:

You can post QRP Spots in the field either by sending a twitter direct
message to QRPSPOTS -or- by sending an APRS message to callsign
‘QRPSPT’.

An APRS feed into SOTAwatch… now there’s an idea…

I sort of like the idea of a APRS -> SotaWatch gateway and have been thinking about it and playing with ideas on this for a little while this evening.

Getting the informatiuon from the APRS system should be easy enough and presenting it to SotaWatch is not going to be too difficult (I even started writing a Perl script to do some of this - having done some APRS stuff using a script before).

There are however a few things that need to be thought about before any such system could be implemented, these include:

Defining a suitable (easy to remember) format for the relevant information in the APRS data (i.e. Summit Ref/ Freq / Mode / Comment) that fits within APRS specification limits.

Whilst the activators callsign would probably be the same as the APRS callsign it might not be (so one person could spot another).

A method of providing some sort of control over who (by callsign) such a system accepts APRS spot data from to reduce potential for abuse.

Some sort of restriction on how often a APRS ‘spot’ from a given callsign can be gateway’d to SotaWatch (again to reduce potential abuse / eliminate duplicates etc).

Anyone got any thoughts as to if such a feature would be useful or anything else that needs to be thought about as part of an overall design of such a system ?

Stewart G0LGS

In reply to G0LGS:

Hi, Stewart.

I’ll be interested in feedback your post generates because I am already developing such a system as an extension of the QRPSPOTS system.

My solution does address your concerns. Like everything there are some limitations. But I did strive for:

o Simple/easy to remember message format (actually no defined format!)
o One callsign can spot another or can self-spot.
o Protection from abuse.
o Prevent flooding of the SOTAWatch spots.

In my system, the activator must post an alert on SOTAWatch2 beforehand. Once that has been posted there is no need to add the summit number to the APRS message (the activator is assumed to be at the summit for which they posted the alert). If the summit is in the message, the one in the message over-rides the one in the alert.

There is also no need to post the mode since the bandplan is well known. Again, though, if there is a mode in the message, it overrides the default behaviour of the bandplan.

Finally, the frequency must be present in the message.

In my system, these pieces of information can appear anywhere in the message, so there is no “message format” to remember.

Finally, I already have some anti-abuse features built into the QRPSPOTS script (which is perl too by the way) as follows:

  • A spot for the same callsign on the same frequency as a previous spot in the last 5 minutes is discarded (since everyone already knows what frequency the activator is on).
  • No more than 15 spots will be accepted in any 15 minutes and no more than 50 spots in any 12 hour period.
  • There is a special APRS message I can sent to the script which kills it.

The SOTA module has these additional safeguards:

  • The spotted callsign must have posted an alert on SOTAWatch, and spots will only be accepted from 1 hour before the posted activation time to midnight on the day of the activation.

Here are some examples of legal APRS messages:

  1. From VA3SIE, Message: 10118

Generates spot:

Spotter: VA3SIE
Activating Callsign: VA3SIE
Summit Ref: as per active alert.
Frequency: 10.118
Mode: CW
Comments: (APRS) 10118

  1. From VA3SIE/P, Message: N7UN 14342.5 CW

Spotter: VA3SIE/P
Activating Callsign: N7UN
Summit Ref: as per active alert.
Frequency: 14.3425
Mode: CW
Comments: (APRS) N7UN 14342.5 CW

  1. From VA3SIE/P, Message: KI6NN/P on W6/CC-001 14342.5 QRT Soon, Go get him

Spotter: VA3SIE/P
Activating Callsign: KI6NN/P
Summit Ref: W6/CC-001
Frequency: 14.3425
Mode: USB
Comments: (APRS) KI6NN/P on W6/CC-001 14342.5 QRT Soon, Go get him

This is still under development and borrows heavily on the scripts which link QRPSPOTS website with APRS & twitter.

Comments?

  • Martin.
    VA3SIE.

In reply to VA3SIE:

Wow! Already way beyond what I was thinking…

My idea is that the SOTAwatch ALERT form could have an APRS box added, so activators could (optionally) add their APRS callsign, then changes in their beacon text (when “in service”, maybe “en route”) would auto-gen a self-spot

For example, when SOTAing, I routinely set my beacon text as follows (example from a recent hill):

Status: In service
Beacon: G/SC-007 144.290 SSB

Use of the beacon text, rather than a message, has the advantage that it is a broadcast not a 1-2-1…

Obviously, beaconing only works for self-spots.

An enhancement is that “En route” could update the ALERT to add “[en route]”, a change to “In Service” could then update it to “[QRV]” and a change to “Returning” updates to “[QRT]”.

For those doing multi-activations, a change from “In service” to “En route” shows current hill as “[QRT]” and updates the next alert as “[En route]” etc

Thoughts
Andrew

In reply to G0LGS:

Whilst the activators callsign would probably be the same as the APRS
callsign it might not be (so one person could spot another).

With APRS you have (obviously) the issue of the SSID to contend with too

Andrew

In reply to VA3SIE:

  1. Create a special user for your APRS system to post to SOTAwatch. Then if it goes wrong and you can’t stop it, it can be stopped at the other end. Don’t use your own callsign for the user. That keeps you and the robot separate.

  2. You’ll need to filter the callsigns to support the barred calls. Due to abuse in the past some callsigns are banned. You’ll need to ensure those callsigns can’t source messages into SOTAwatch through you.

  3. Check the reflector archives to make sure you aware of all the history about spots not being actual “someone is on the summit activating right now” spots so you don’t create something some users will complain about.

  4. [Obvious] Check the MT approve of your intended use.

Andy
MM0FMF

Andy,

If you look at the spots from late last night you will see that is exactly what I did (create an account) to post a spot (actually posted manually).

My Perl code is not developed enough to do all the things Martin mentions, but most of the things he mentions do seem to be acceptable to me.

Martin,

Not sure it is necessary to post everything from the APRS as a comment, but only posting previously alerted events will certainly reduce the potential for abuse and meet the requirement NOT to post barred calls.

I was thinking that the data format for APRS could be something flexible:

  Callsign,Sota Ref,QRG(MHz),Mode,Comment
  Sota Ref;Callsign;QRG(MHz);Mode;Comment
  QRG(MHz):Mode:Sota Ref:Comment

So allowing for leaving out the Callsign (for self spots) and accepting the same list of modes as the web site allows, it should be possible to actually allow the values in any order, with several possible seperators (with some expression matching code to work out which bits are which).

Whilst adding the appropriate Country Prefix and suffix is desirable (i.e ON/G0LGS/P) it is not essential.

Andrew,

The SSID (-1 to -15 and even -A to -Z in some cases) can easily be ignored.

Stewart G0LGS

In reply to G0LGS:

The SSID (-1 to -15 and even -A to -Z in some cases) can easily be
ignored.

Doh! Of course… I was still thinking beacon-text not message. Sorry!

Andrew,

When connected to the Internet APRS servers (like the various APRS programs can do) a program/script can set all sorts of filters to control what traffic it gets.

I suspect that the best way of dealing with this is for the script to tell the Server that it only wants UI Frames sent to ‘SOTA’ (or something similar), so the script does not have to process all the other UI Frames (sent to APRS, QRP, WX etc).

This would just require users to set the Beacon destination to match (with appropriate RELAY path to have the best chance or it actually getting to the Internet).

When the data from your beacon arrives via the APRS Servers it will be a single line looking something like:

M6ADB-2>SOTA,TCPIP*,MB7UC:G/CE-001,144.320,SSB,Calling Now

That can very easily be split up to get just ‘M6ADB’ as the callsign and all the other parts, it is then a process of checking the information and passing it to Sotawatch.

Stewart G0LGS

In reply to G0LGS:

M6ADB is pondering whether he should QRT back to bed… clearly his brain hasn’t woken up yet

:frowning:

In reply to VA3SIE:

  • The spotted callsign must have posted an alert on SOTAWatch, and spots will
    only be accepted from 1 hour before the posted activation time to midnight on > the day of the activation.

The restriction around midnight might be a problem when the alerted time is close to that anyway, so perhaps a 4 hour window around the alerted time might be a better approach.

Stewart G0LGS

In reply to VA3SIE:

dear friends,
by looking for a new aprs-sota-gateway please have in mind the existing sota-gatway from ha5cqz / Zoli

It makes sense to use the same convention:

Selfspot: sota OK/KA-004 7032 cq %ABCDE

%ABCDE is the spot-code for validation und sent to SOTAwatch. The spot-code must be always the last word of the field.

See: SpotSMS/SpotAPRS Gateway Log
and here on the reflector:
http://www.sotawatch.org/reflector.php?topic=3070#24916

greetings
stephan, DD6DO

Stephan,

As an occasional activator I was not aware of the existance of the APRS gateway, and it would seem that applies to Andrew and Martin too.

Thanks for pointing out the previous mention of it in the Reflector.

At least the talk of having one got me to have a play around with some Perl code that I might find useful for another purpose some day.

Stewart G0LGS

In reply to G0LGS:

Hi, All.

Wow lots of ideas and feedback circulating :slight_smile: … Good job!

I have looked at ha5cqz / Zoli’s gateway before (excellent system!) but I find personally that having to obtain a code and append it is a little cumbersome (for me anyway).

I also don’t want to put the summit ref in the APRS message - I have an VX-8r and it takes forever to type an APRS message. I’d probably end up leaving my code at home :slight_smile:

As far as format goes, the more complex the format the harder it is to use and the less useful it will be, so like Zoli I shy away from requiring semi-colons, colons, commas, keywords like ‘ALERT’ and these types of thing in the message. Spaces are good enough?

If there’s a “format” or a “separator” or a “validation code” or anything like that, then it’s going to cost me too much time and brain power when I’m activating a summit.

Actually, on that note, in the last activation I found that it wasn’t very long before folks were spotting me on both qrpspots.com and SOTAWatch, so this system we are developing and describing here in this thread won’t always be very useful thanks to those chasers taking the time to spot the activator!

On that note, I want also want my 1 APRS message to generate a spot on both qrpspots.com and SOTAWatch. Yet more time-saving :slight_smile:

The summit ref and the ‘validity’ of the spot and everything else is addressed by the fact that only alerted spots are passed through from my script.

Plus it forces me to alert all my activations which is also a good thing. So there is no need to pre-register a code or to include the summit in the APRS message. The presence of an alert is enough.

Maybe I am missing something though, I guess it could be abused by someone posting a bogus alert…

Good point about midnight, but there don’t seem to be too many activations near 0000Z so I think it’s an okay limitation for now… Zoli addresses this by having the activator choose the duration of validity of the spot. I was trying to use just the information from the alert (for simplicity’s sake).

Some interesting comments around APRS-IS in this thread. I’ve been there, done that and got the T-shirt :wink: on another project. Filtering the stream to only get the data you are interested in is just the first part of the problem. Then you have to deal with the fact that the message can reach APRS-IS via multiple RF paths, so you will likely see the same message more than once over a 10-15 minute period (some digis even store and forward the message minutes later). The packet can also get corrupted so you need to compare the messages you do get and figure out which is the uncorrupted version.

This ends up being a sliding window dupe-checker with fuzzy matching of the message contents and voting to determine the uncorrupted message if there are a few similair messages. The dupe checking is combined with the abuse filtering and traffic reduction for when you get a lot of spots for the same callsign.

Once you have dealt with multiple copies of the message, getting the information out of the message is just a matter of pattern matching which perl does really well (even if the regular expressions dealing with prefixes and postfixes get horribly complex). If you think you have a frequency, you can compare it to the bandplan as another level of validation. If it’s not the frequency, look for more numbers. Maybe you found a date or a time.

Anyway… much of the perl code to do this is already written in my QRPSPOTS system so when I have time I will see what I can come up with.

In the meantime thanks for pointing out Zoli’s system, I can always type two APRS messages in the meantime :slight_smile:

73!
Martin.
VA3SIE.