About
Resources
- Changelog / Release notes found here
- Frequently Asked Questions (FAQ) found here
- Getting started instructions found here
- Service Health Status found here
- Privacy policy found here
Support
Need help? Found a bug? Have a suggestion? Please send a message to:
support@SOTAmat.com
Trivia
Why call this “SOTAmāt” (pronounced ‘sota-mate’)? A few reasons:
- The SMS messages originate from the reserved phone number +1-601-SOTA–MAT (+1-601-768-2628), so it is easy to remember. It was the best phone number available at the time that had “SOTA” in it.
- It is your friend in the field, like a “mate“
- It automates sending spots and messages
- It uses FT8
History
SOTAmāt started out of frustration after a few nearly busted activations where I had no cell service, I forgot to pack my APRS programming instructions, and I had limited time to call “CQ SOTA” all afternoon in the wind on a cold mountain. On a later trip APRS was successful in self-spotting, but it was cumbersome trying to type out all those special characters on the radio keypad one-at-a-very-slow-time. I later purchased a Garmin InReach Mini satellite messaging device, but had trouble in getting it properly configured to self-spot with the official SOTA SMS gateway (in fact I never got it working as I couldn’t figure out how to remove the GPS telemetry data that breaks the SMS gateway from working, and when I did figure it out I didn’t want to remove the telemetry data that might be needed to save a life back-country). Instead I had to use the Garmin InReach Mini to send a message to my wife back home and have her spot me (which doesn’t work when she is unavailable). It was an expensive tool when you add in subscription fees for the mid-and-upper tier plans (but a value at the low-tier plans and welcome in an emergency!).
I became interested in KM4ACK’s YouTube videos on using a Raspberry Pi “headless” in the field for WSJT-X, JS8-Call, and more. “Headless” simply means using the Pi without a physical display and instead use your iPad or iPhone as a remote-desktop “screen+keyboard+mouse” to the Raspberry Pi’s desktop (using the VNC software). While it worked, it was complex and cumbersome given the need to split the battery output between the Pi, the radio, and the iPhone, the need for voltage regulators for the Pi, the need to add a GPS dongle to the Pi to get accurate time, lots of cables, lots of configuration, etc. The Pi based JS8-Call showed promise with an announced SOTA gateway, but in practice there are fewer monitoring stations. Oh, and the Pi would often have configuration issues with audio settings and such. It made for a great hobby since there was always something to fix, but it didn’t help get more SOTA points on the board!
At a radio club meeting a fellow member mentioned he had been porting the FT8 code to an iPhone, and I was lucky enough to Beta-test the software. [He has a bit of fame as his signature is found etched inside the plastic molds for the cases of both the original Macintosh computer and the Amiga!] I hooked his FT8 iOS software it to my portable Elecraft (directly hard wired, without any SignaLink type device needed) and had a very portable digital operation with a radio, cell phone, and a single cable. Wow.
To test out the iPhone FT8 I started sending FT8 messages to myself, and it dawned on me that I could encode information into a suffix of self-addressed messages. For example, “AB6D AB6D/3” could tell an automated monitoring system to execute a pre-registered “command #3”, such as a self-spot from a particular Peak ID.
I started watching my messages be received by the PSKReporter network of monitoring stations and discovered that while FT8 message payloads are NOT collected or recorded, the sender’s callsign suffix is recorded if the monitoring software supports extraction! Later I learned that WSJT-X based monitoring stations only report callsigns to PSKreporter when found in “CQ” messages, and normal FT8 messages don’t allow for callsign suffixes other than ‘/P’. However, I found there are several 3rd party monitoring software solutions (in particular SparkSDR) that do indeed report to PSKreporter my self-addressed messages with 4-character suffixes when embedded inside FT8 free-text messages. What this means is that you can use a specially addressed message with a callsign suffix to reliably get a message to PSKreporter. From there SOTAmāt interfaces with PSKreporter to watch for these special messages and when found, expands the suffix into a set of actions (spotting, sending SMS messages, etc.).
Encoding
The next question was how much information can we encode into the FT8 message? It turns out quite a bit, and while in hindsight these methods seem obvious to you they did take quite some time to realize the options:
- The suffix itself is rather complicated since callsigns can be encoded in FT8 several ways. It turns out an FT8 “free text message” is what we started with, which allows for 11 characters total of callsign + “/” + suffix. Since callsigns are often as long as 6 characters (ex. “KA2VYS”) that leaves 4 characters for a suffix. FT8 free text messages must be 13 characters or less, so if you have a 4-letter suffix plus a 6 character callsign plus the ‘/’, you have two remaining characters (and for SparkSDR, there needs to be another “word” and a space preceeding the callsign).
The suffix can be composed of the symbols 0 through 9, and A through Z for 36 combinations. But in some cases we can have a 37th symbol of a “space”. This means we have more than 1.7 million combinations available for messages:- (36 * 36 * 36 * 36), plus
- <space> (36 * 36 * 36), plus
- <space> <space> (36 * 36), plus
- <space> <space> <space> (36)
= a grand total of 1,727,604 combinations, or about 20.72 bits of data
- From that “master” suffix space of 1.7M combinations, we have to subtract disallowed suffixes. About 700,000 suffixes are not used by SOTAmāt::
- FCC suffix rules don’t allow suffixes that conflict with country prefixes, So we can’t use “AB6D/I” or “AB6D/IA” because those imply a USA operator operating in Italy. In fact there are huge numbers of suffixes that aren’t allowed since the ITU has carved out most letters of the alphabet!
- The FCC has reserved suffixes. For example we can’t use “/AE” since that implies someone operating with Amateur Extra privileges. There are a handfull of these special suffixes like “/BCN” for beacons.
- We don’t want an encoded suffix to look like a message. For example, “AB6D/SOS” or “AB6D/HELP” would be bad, so SOTAmāt doesn’t use any word found on Google’s list of international swear words nor in an open source dictionary of the English language.
- The receivers record the frequency offset the message is received on. This is a combination of the radio frequency plus the audio frequency offset. I discovered through testing that some FT8 decoding software has very accurate frequency stabilization through software statistical feedback methods. In other words, we can gather several bits of data based on not just the suffix of the FT8 callsign, but also the audio frequency offset it is sent on. I have a bunch of math on this.
This works out to about 100 buckets or 6.64 bits of data - The time when the message is sent. For example, the FT8 “even” or “odd” time slot can communicate a bit of information. But we can to further than even/odd frames and do larger modulo time slots.
This works out to either 2 or 4 combinations for either 1 or 2 bits. - etc. etc.
The result was that I could encode 21 bits easily, and around 28 bits of data with some complexity in an FT8 message, and possibly a few more (268 million possible messages).
Decoding
The next question was how to use all these 28 bits of possible message combinations to relay meaning. For this I did a bunch of analysis on the SOTAdata web site as to how many bits are needed to encode all the summits, or a subset of the summits, the probability distribution of different modes and bands, etc. The result was that I could allocate different bits to different goals and that there was no perfect one-size-fits-all way to fit inside 21 (easy) or 28 bits (more complex) of allocation.
Hence the idea for the SOTAmāt web site, where users can pre-register what they care about when activating. Most activators only care about summits in a few regions at a time and don’t need 24 hour access to worldwide regions. Once you register (on the “PREPARATION” menu of this site), the service directly connects to PSKreporter to monitor for your callsign and matches encoded suffixes it hears to your pre-configuration to decode them into your personal callsign actions.
Next was working with PSKreporter and the API’s available, which were not built for the purpose of SOTA activations. Working directly with the founder of PSKreporter, he developed a special service that enabled SOTAmat to get what it needs. I have huge gratitude for the time, effort, and support he provided as it is the source of everything SOTAmāte does. Thank-you!
I hope it helps you activate!
73 de AB6D, Brian
P.S. you can find my personal SOTA site here. I haven’t had time to list all my trip reports, but that is where they will go when I get to it.