Spots from APRS


First of all I realise that this subject was mentioned in a thread a few days ago, but on re-reading much of what was said it seems to me that the current available option for this sort of facility is a little cumbersome to use, in that it requires anyone that wishes to use such a facility to register for a PIN (via email) and having got the PIN use that to generate a unique authorisation code (on a web site) for each summit and use the correct code in the appropriate APRS message.

Whilst the other option that Martin (VA3SIE) is working on seems to have a dual aim of generating both QRP spots and SOTA spots from a single message, it occurs to me that this might not be what some potential users of such a system would want from it (esp anyone carrying out a non-QRP activation).

Therefore I have continued with creating and testing my own version that I envisage will require potential users to register with me (perhaps at a later time via a web site) but will not require any authentication code to be sent in the APRS message and will be quite flexible with APRS data format (see later).

Now I’m not really familiar with many of the APRS enabled radio’s so would like to get some idea from any potential users as to how messages that a system such as this would accept might be formatted.

From what I see if you have a system configured and sending APRS position reports the ‘destination’ of the APRS UI Frame is set to something that very much depends on the system in use (i.e. each system uses its own destination fields like: APRS, APRNMA, APN382, APNU19 etc)

So I have questions relating to this:

Would it be acceptable to SOTA activators that might use APRS to use a ‘destination’ such as ‘SOTA’ or similar when sending a message for the APRS to SOTA spots gateway ?

Would using something different (that does not start with the letters ‘AP’) be generally acceptable on the APRS system or would that cause things not to work somewhere else ?

Is it necessary or desirable to register for a unique ‘destination’ field for this purpose ?

Can these ‘portable’ APRS systems be configured to send APRS position reports using whatever ‘destination’ field they normally use and send a APRS to SOTA specific message when required (or is this too fiddly or complex to configure when out and about).

My current test code will accept messages with the destination field starting with ‘SOTA’ and requires as a minimum the following information in the UI Data frame:

The Summit Reference (i.e. GW/NW-010)
The Frequency (or band) in MHz
The Mode (same list of options as on SotaWatch)

It will also accept:

A callsign (which may be different to the APRS originators) such as ON/G0LGS/P
A comment

These must all be contained in a single UI Frame, but can be in any order and separated from each other by one (or more) of a list of separators which include any of #^!|@%,:;’" or space (others might also be possible).

Would this work ? have I forgotten or overlooked anything ?


ON/ON-010:ON/G0LGS/P;144.310!SSB,APRS Test Ignore

Stewart G0LGS

In reply to G0LGS:

Hi, Stewart.

Great job - following with interest!

I may even piggy back my qrpspots system on yours by putting an message back into APRS-IS to your system… if you don’t mind.

Here’s some feedback:

I have some suggestions for you and I can help you out with some sample perl code if required, especially around reading the published alerts and the pattern matching of the message, as I already have those bits working.

On message format:

For my own use, the message format needs to be as simple as possible and as short as possible. Time on a summit is limited.

Here’s my thoughts about format:

If you read in the published alerts on sotawatch and keep that information up to date, the frequency is the only mandatory thing which needs to be in the message. One way of doing this is to make your script multi-threaded and place s perl hash in a shared memory segment, then one thread polls sotawatch2 every hour and keeps the alerts list up to date for the other thread.

If checking sotawatch, the message can be as simple as ‘10118’.

This is a good thing because that message is very quick to send (even quicker than spotlite!).

The script should accept frequency in any format (10118, 10.118, 10118.4khz, 10118.4 kHz, 10.1184 MHz, etc). The script should not care if there is other stuff in the message as well as the frequency, and it can validate that the frequency lies within the region 1, 2 or 3 band limits (to reduce the chance that some other number in the message was misinterpreted as the frequency).

In this way you open the system up to more folks (some folks just think in kilocycles!), and don’t have to tell anyone to RTFM when their spot is not picked up :slight_smile:

The mode (if not in the message) can be guessed from the frequency as per the bandplan.

As a side effect of cross-checking the originating APRS callsign with the alerts on SOTAWatch, you will (a) know the spot is legit and (b) get the summit reference.

As far as I can tell in the system you describe there is no facility in there for preventing abuse or blacklisting certain callsigns. You might find people sending malicious spots.

On that note, you haven’t mentioned (in this message) duplicate detection. This is important because in the APRS-IS stream you will often see your message appear more than once, sometimes minutes later. Especially if the APRS message is sent atop a mountain and lots of digis & igates see it.

The easiest way to deal with this is keep a copy of every message which is for your script and make sure you have not already processed it. A hash like that will grow and grow though, so another consideration is to prune this hash from time to time. For example, add timestamps to the saved messages and then before dupe-checking a new one, remove all the messages older than 15 minutes from the dupe checking hash.

(Again I can provide you with sample perl for this).

If you do get the mode and summit ref from the published alerts, still look for them in the message. Thus they can be over-ridden should the user choose to add them in the message.

I wouldn’t require or expect separators (or list them when describing the system), you’re looking for frequency, callsign, mode, summit ref and since those have distinctive patterns, so it doesn’t matter if there are extraneous commas, spaces, colons, whatever in there t oerl it’s all just ‘.*’ :slight_smile:

Simple spaces (as in Zoli’s system) would work just as well.

The only question arises is what if you find two or more of the above items (2 callsigns, 2 summit refs, 2 modes, 2 frequencies) in the message? In this case I would just say that the 1st is taken and 2nd is ignored.

On ‘destination’:

‘Destination’ is often fixed by the radio or software originating the spot. VX-8r for example allows you to enter only the message and the callsign. The VX-8r uses a destination of ‘APY008’ for all messages.

Would using something different (that does not start with the letters ‘AP’) be generally acceptable on the APRS system or would that cause things not to work somewhere else ?

No. Some IGATES / DIGIs do forward them but they certainly don’t have to. I would suggest not forcing the user to use a particular destination. The callsign is what tells your script that it should be acting on it.

So for example this message would be sent from a VX-8R:


But your script could just look for the callsign == ‘SOTA’. (or SOTASP is SOTA is already in use).

Don’t forget to strip the ack field from the end as well.

So when you’re looking for a message, you just look for a message to the appropriate callsign (in this case SOTA), the destination can be whatever.

Also be aware that some radios will require the callsign to be 6 characters or less (The VX-8r does this), so while SOTASP is good, SOTASPOT is not.

The Summit Reference (i.e. GW/NW-010)
The Frequency (or band) in MHz
The Mode (same list of options as on SotaWatch)

As mentioned previously I recommend that the summit ref not be mandatory (its long to type) and the frequency be allowed to be in many different formats (mhz or khz, with or without fractional portion, with or without the text ‘khz’ and ‘mhz’ and those may actually be the next character following the frequency such as “3560.25kHz”.

Again I can help with perl code for this.

Hope that helps, please do not hesitate to send me an email if you would like to enlist my help with perl or APRS-IS, my email address is


(Good luck!)


Did you make any progress on this? It would be very neat to be able to self-spot over APRS.

Something else that looks potentially interesting: there’s a “CQ Server” on the APRS-IS network. Basically you send a message to a named group (e.g. “SOTA”, “WOTA”, or the very general “CQ”), and then anyone else who has sent a message to that group in the past 12 hours gets your message.

Seems to me like this could be useful for finding out about opportunities for S2S contacts – you arrive at your summit, send a message to the “SOTA” group with something like “W1/AM-001 QRV 10118”, and your message automatically gets bounced out to the whole group.

-chris N2YYZ

In reply to N2YYZ:

Did you make any progress on this? It would be very neat to be able
to self-spot over APRS.

I don’t know about Stewart, but I’m working on a beacon parser that will SelfSpot on changes of status text and/or MIC-E status

It’ll run as a page on my website to start with, and potentially link into SOTA later. I’m not sure how scalable it would be though!


I have not done anything with my code since posting my last message in this thread.

It does seem to work, using my test message format, however I am still not sure what format the messages from users should be (see previous messages in this thread).

Stewart G0LGS

In reply to G0LGS:

I am still not sure what format the messages from users should be

Make the format the same as my SMSBOT. Gives a consistency of interface.


! GM WS001 145.5 FM qrv now
MM0FMF GM WS001 145.5 FM qrv now

Spaces are used to break up fields and the only field that can contain spaces is the comment field which is last on the line.

The ! is used to mean “me”. I have a list of valid phone numbers and matching owner’s callsign. I match the phone number with its owner’s callsign and then apply secondary locator rules to that found callsign, append a /P for free and insert a - if there isn’t one in the summit reference.

That means an owner (like me) is registered as MM0FMF but when I’m in Wales then my callsign is mapped to MW0FMF etc. etc. for all UK secondary locators.

In your case you can map ! to the callsign that originated the APRS packet.

Might not be the best, but it seems to work and I don’t get too many complaints from the, now 96, registered users of the service.



My present code will accept a similar format, but as I’m allowing the fields to be in any order and allow a range of seperators the Ref has to be like ‘GM/WS001’ or ‘GM/WS-001’ etc (it doesn’t need ! and callsign is optional as it uses the one from APRS packet header).

The other thing that I’m not sure about is the exact format that the APRS information will be when sent by the different radio’s that people use.

Does it have to use the Format for APRS MESSAGES, BULLETINS and ANNOUNCEMENTS (as Martin suggested) which would make the ARPS traffic from the Internet servers look something like:

G0LGS-1>APRS,TCPIP*:SOTA_____:G0LGS G/CE001 145.5 FM qrv now{001

(These would normally require an acknowledgement and when generated by APRS software would be repeated until acknowledged or cancelled by the originator, but my code does not send Acks).

Can it simply be like:

G0LGS-1>SOTA,TCPIP*:G0LGS G/CE001 145.5 FM qrv now

(i.e. Beacon Text generated by non-APRS aware system).

or will some systems use some other format that I need to cater for.

Stewart G0LGS

In reply to G0LGS:

Hi, Stewart.

(I have not gotten any farther with adding SOTAWatch to my QRPSPOTS script by the way… too busy with other things…)


Speaking for the Yeasu VX-8r (not the ‘DR’/‘GR’), the APRS firmware is quite limited/rigid. The only way to get a custom string out of it into APRS is:

  1. As a beacon status message.
  2. As a directed message/bulletin.

In the case of a status message, the radio will sent it repeatedly at a fixed beacon rate. Unless you wanted each beacon to generate a SOTAWatch posting, the script would need to handle that (for example, compare each status to the previous one and only re-send to SOTAWatch if it changes).

In the case of a message, the message has to be sent to a “callsign” which cannot be more than 6 characters and an SSID. The destination field is also not customizable. The VX-8r will append an ack request and will re-send a few times if an ack is not received. This behavior is not customizable.

So - each re-sent unacked message will be seen by your script and likely more than once if more than one IGATE picks it up from the lcoal digis.

Your script can send an acknowledgment back to the originating callsign, but unless there is an IGATE configured to gate from APRS-IS to RF in the area (and these are rare!) it will not be seen by the VX-8r which sent the message.

So - I deal with this in my script by maintaining a sliding window of received messages. I create a ‘signature’ of the incoming message consisting of the originating callsign and message content (excluding the path and ack field) and I add this to a hash lookup table. I delete older entries from the hash as I add new ones based on the window size (this makes it a sliding window). Finally, if I discover that the same signature is already in the hash then I just discard it.

I can provide sample perl code for anyone interested.

  • Martin, VA3SIE.


I have made a couple of small changes to my test code I wrote several weeks ago and it now seems to accept messages in the format shown in the APRS Protocol Specification (V1.0.1 Chap 14) as ‘MESSAGES BULLETINS AND ANNOUNCEMENTS’ an example from the Internet APRS Servers looks like:

G0LGS-2>APRS,TCPIP*,qAS,G0LGS::SOTA :ON/ON-010,ON/G0LGS/P,144310,SSB,APRS Test Ignore{003

(i.e. a message directed to ‘SOTA’).

It also accepts a simple AX25 ‘Beacon Text’ (if you can get it thru a I-Gate), which might look like:

M3WDS-2>APRS,TCPIP*,qAS,M3WDS:G/WB-019,M3WDS,144320khz,Test (APRS) - Ignore,SSB

Operating Frequency with or without units (entered as KHz or MHz), Mode and Summit Reference are required, the callsign and comments are optional.

Parameters may appear in any order, text that is NOT recognised as a Callsign, Mode, Frequency or Summit Ref should be treated as part of a comment.

Parameters may be seperated by any of the following:

’ " ` ^ # @ ! % , : ; or space

The code keeps a log of what is sent to SotaWatch and should not resend an identical report when received within 10 minutes.

If anyone would like to try out the system for a real activation then contact me by email (sota dot aprs at g0lgs dot co dot uk) and I will allow your callsign to be picked up from the APRS servers and spotted by the system.

It should accept UK calls with any regional variation( G,GW,GM etc) but may not spot with the correct regional variation unless that is part of the APRS message.

Stewart G0LGS

Update (06/10/2010):

My APRS gateway code should now accept UK calls with any regional variation (G,GW,GM, M,MU,MW, 2E,2W,2M etc) and deal with putting in the correct regional callsign variation to match the given Summit reference.

It will add /P (unless another suffix such as /M is given with the callsign in the APRS info).

For non-UK operators in the UK or UK operators in another Country it will try to add the Country Prefix (i.e. ON/G0LGS/P or MW/F6ENO/P etc) when necessary (unless another one is given with the APRS info).

Anyone watching the spots closely may have seen me post some test spots earlier (spots from my code will show as posted by SOTAPRS).

Stewart G0LGS

In reply to G0LGS:

You could also have a look at

(scroll down)

It scans EU+US traffic.


And i can say, it works very well because i used it today.
I spot myself with APRS.
Bravo and thanks

In reply to F5LKW:

Did you send 5 spots out? Just wondering if some of the spots are real and some were loops/repeats etc?


In reply to MM0FMF:

Here is the log

The repetitions within 15 minutes are silently ignored. They don’t show up in the log.


In reply to HA5CQZ:

You could also have a look at
SpotSMS/SpotAPRS Gateway Log
(scroll down)

It scans EU+US traffic.

That one was posted before, but I feel that it is too complicated with the requirement to register and get various codes etc.

Stewart G0LGS

In reply to MM0FMF:
Andy !
Yes i sent 5 msg from APRS to SOTAWatch but “/p” lost anywhere …
73 QRO

In reply to G0LGS:
Stewart !
It’s not so complicated as you think. If i succeed it, everyone can do it easily ;-))
73 QRO

In reply to N2YYZ:
Hi Chris
just reading through the old sotawatch messages.
I have a CQ Server running on my T2England server part of the APRS-IS network.
the cq servername is UKSRVR,it can be renamed if needed.
to access it via Aprs just send a message TO UKSRVR
create a group of your choice first: ie cq sotausa (make as many groups as you like)
once the group/s has been made it stays active for 48 hrs then it is automaticily removed by the server,(default in the program)then you can start to send messages.
to send your sota message,you can send the same format as the sotawatch2 website
ie:CQ SOTAUSA Callsign/P on G/SP-015 144.315 SSB
or any other oneliner message.
the server will only send a copy of the message to those in your group
each member of the group can then reply to any message received.

if you fancy trying it from your end and see if you like the results.

73 de Ken
g7vja - mb7ufo