Each person in your party needs to have their own account (where the username is their callsign) on the SOTAmāt web site. The web site is where each user builds a “configuration” specific to their callsign that defines the meaning of each over-the-air suffix for that callsign (ex. “KA2VYS/1234” means something different than “AB6D/1234” even though the suffixes are the same). Once you’ve defined a configuration on the web site, it gives you a “configuration blob of text” that can be loaded into the mobile app. The reason for these configuration “blobs’ is to allow you to store multiple blobs for offline use by multiple callsigns on your mobile device. You can store these blobs in any app that works offline such as the iOS “Notes” app or your Email app. When you are in the field, you can load any one of these configuration blobs (for a specific callsign) into the SOTAmāt mobile app and send messages/commands on their behalf. You can copy as many of those configuration blobs from the web site for as many people as will be in your party and have them stored on your device.

There can only be one active configuration per callsign: the server and mobile app need to be in 100% agreement on what that configuration is for that specific callsign. If you make *any* change on the web site (even changing a single letter in a defined SMS message) you must delete the old corresponding configuration blob and re-load the new blob from the server. A single letter change for one suffix can cause the meaning of all other suffixes to change (there are MD5 hashes involved in some of the internal mappings for technical reasons beyond the scope of this FAQ).

Once you’ve saved multiple configurations on your device for multiple callsigns, you just paste the appropriate blob into the mobile app for whomever wants to use it.

The simplest way is to click in the old configuration blob so you have a cursor in the middle of the existing text somewhere. Then just type in (add) any random letter and click outside the selection box. This will cause a checksum error in the configuration (it is now an illegal configuration), and the app will resolve the bad-data issue by erasing the configuration.

Now that you have an empty text box, you can easily paste in a new configuration from the clipboard. Voila!

Yes! You can play the FT8 sound from your phone speaker into the microphone of your radio. FT8 is resilient against noise and imperfect signals, but if done wrong it can cause “splatter” that interferes with other users of the band.  Learn the technique with a dummy load at home before using on-air.  All the experienced SOTAmāt users seem to use the cable-free approach even when they own cables because the workflow is easier and faster (no VOX mode to deal with, etc.).

The trick is to (1) get the best signal-to-noise ratio since there will be background noise picked up from the radio’s microphone, (2) prevent distortion from over-driving the speaker or microphone, (3) prevent under-driving the speaker gain or microphone gain to avoid internal amplifier hiss, all while (4) maximizing RF power output within the linear range of your RF amplifier.

Your background noise is likely at a fixed-ish volume level, so we want to increase the sound level of our FT8 signal from the speaker so the FT8 sound is stronger in comparison to the background noise, but not so much that it would cause speaker distortion.

There is a game you play where you increase the volume of the mobile phone’s speaker (avoiding distortion), while decreasing the radio’s microphone gain setting so that you don’t overdrive the radio into the non-linear range.

You do this by having your radio display the amount of ALC (Automatic Level Control) it is applying. Your radio’s ALC circuit attenuates signals that are about to over-drive your radio. That’s normally good, but ALC does this by applying a non-linear filter of the signal which is bad for FT8 since it causes splatter across the band that interferes with other users. Your goal is to get as high a phone-speaker-volume as possible while not having any ALC applied (by varying the radio’s input microphone gain).

On many Yaesu radios, the ALC bar graph shows actual ALC: zero-bars means zero-ALC, non-zero bars means ALC is being applied. Check your radio manual to learn how to display the ALC graph.  Your goal is to keep increasing the phone’s speaker volume and/or increase the radio mic-gain until you see a bar of ALC appear, and then back-off the mic-gain slightly until the ALC just (barely) disappears. You now have the best signal-to-noise ratio possible and the maximum linear RF power output to your antenna.

On many Elecraft radios, the ALC bar graph shows a ‘shifted’ ALC. Four-or-fewer bars on the ALC display means you are approaching ALC but have not yet engaged any ALC.  Five-or-more bars means you’ve started engaging increasing levels of ALC. So with Elecraft equipment, keep increasing phone speaker volume and/or radio-mic-gain until you have exactly 4-bars in the ALC graph. You now have the best signal-to-noise ratio possible.  In the field you can “fine tune” the ALC while transmitting by slightly moving your phone’s speaker closer-to or further-from the radio microphone.  It is VERY sensitive to even small movements.

Read the section below on “direct cable” use since it covers similar concepts for mic-gain.

Yes! Of course a master of light loads, K6ARK, asked this question. All the mobile app does is compute a callsign suffix encoding from whatever summit ID and Frequency you select. If you know the summit you plan to activate, you can use the mobile-app ahead of time and just write down the computed suffixes for a set of interesting frequencies on a piece of paper. Now you can transmit one of those messages (with suffixes) in the-field using any mode that has PSKreporter monitoring stations. That can be the RTTY or PSK31 that is built into your Elecraft radio rather than FT8 from your phone. Theoretically it can also be CW.

However there are issues. I’ve found that the software used on CW monitoring stations modifies many of the callsign suffixes transmitted. For example, if I use CW to transmit “CQ CQ DE AB6D/2345” what will actually get reported to PSKreporter is “AB6D/2”. This will cause SOTAmāt to fail. Some suffixes work while others don’t. [I would love to work with an RBN “Elmer” who knows how RBN’s internals work! If I had data on which suffixes RBN would mess-with, I could program SOTAmāt to avoid them. Email me with info!]

Unlike with CW, modes like FT8, RTTY, and PSK31 have monitoring station software that reports the callsign suffix faithfully to PSKreporter. Since RTTY and PSK31 are built-into the Elecraft radios, it seems we could leave the cell phone at home and lighten K6ARK’s load! Unfortunately there are fewer and fewer RTTY and PSK31 monitoring stations across the bands and you run a much higher risk of not being heard. As of this writing I only see 2 PSK31 monitoring stations on the 20 meter band, and zero RTTY monitors. Yikes! It is quite hard to be heard when there are zero stations listening. I love FT8 but wish it hadn’t blown all other modes away.

This is the reason that I recommend FT8 and carrying a mobile phone with you. As of this writing there are 1,163 FT8 monitors on 20 meters.  Of those (a total guess) is that 1 to 2% of them is a SparkSDR monitoring station compatible with SOTAmāt.

Often not (when using low power/QRP)! There are a variety of reasons for a Signalink type device, and some of those reasons don’t apply at low power when you are careful with your configuration.

One main issue is that the microphone input of your radio is designed for the very low voltages produced by microphones (weak signals), while the output from your phone is designed to push a bigger speaker with higher voltages (and higher power). You don’t want to connect a high voltage source (your phone’s speaker output) to a delicate microphone input (expecting a low voltage in). One thing an audio interface box (ex. Signalink) can do is attenuate the output voltage level to the expected microphone input voltage level.

However, most phones I’ve tried don’t really have huge voltage outputs since they are only meant to drive personal headphones, and not a home theater sound system! While even a mobile phone output voltage is much higher than the radio microphone input expects, the worst I’ve seen is distortion of the radio’s microphone input amplifier. I haven’t seen enough output voltage to actually damage the radio’s electronics (distortion does not equal damage – it means you are saturating an amplifier transistor).  However, this is not a guarantee of your situation or equipment: damage may be possible.

We don’t want distortion since that interferes with our signal and with other people using the band (it causes “splatter”). So the question is: can your phone’s output volume (voltage) be reduced enough and can your radio’s microphone input-gain level (how much the radio amplifies the signal received at the microphone input) be reduced enough such that you find a compatible level where neither is distorted? And I’ve found the answer is YES with many (most?) devices!

There is some one-time calibration you should do in order to get the best results for your equipment. As we’ve said, you want to get your phone’s output volume low so it doesn’t over-drive the mic input, but you don’t want the phone’s volume too low. This is because the phone’s speaker amplifier has background “hiss” noise that is likely at a constant (but low) volume. If you reduce the volume of the FT8 signal, that hiss noise becomes loud in comparison. So we want as strong a signal-to-noise ratio (FT8-volume to hiss-volume ratio) that we can get away with while simultaneously not over-driving the radio mic-input.

Similarly we don’t want to set the radio’s mic-gain so low that the radio’s internal hiss noise is loud in comparison to the incoming signal. So we want the radio mic-gain to be as high as possible while simultaneously avoiding distortion and avoid engaging the radio’s ALC.

Before calibrating, set your radio to transmit zero-watts (or use a “dummy load” virtual antenna) so that you aren’t transmitting anything while calibrating. Read the FAQ section above on operation without direct-connect cables where it talks about calibrating for zero-ALC.  Getting your radio’s mic-gain setting right is a similar process for both cable-free microphone input and for hard-wired direct connect cables.

This all sounds complicated if you’re new to it, but it is actually very easy. The radio’s bar graphs give you the feedback you need. Your configuration will be specific to your devices (even with the same manufacturer I’ve seen differences between devices), but here is my configuration using direct-connection cables:

  • iPhone
    • iOS system-wide output volume: set at 100% (using the physical buttons on the side of the device) to make it easy to always get a consistent setting.
    • HOTPAW FT8 app-specific output volume: set at 10%. This setting is not visible on the home page, click the “Configure Tx/Audio” button to find the “Tx Vol %” setting. At 10% on my device it gives enough signal-to-noise ratio without blowing out the radio’s inputs.
    • I use the Lightning-to-headset adapter that came from Apple (with the phone). This has a female TRRS 3.5mm socket. Internally it has both an analog-to-digital input and a digital-to-analog output sound card built into the cable which talks digitally to the phone over the Lightning port. It is this cable that defines what 100% and 10% audio levels mean. Hence a 3rd-party adapter can be quite different regarding calibration then my Apple adapter.
  • Elecraft KX2 radio
    • Mic-gain: set to 20 or 21 (based on watching the ALC graph and shooting for 4-bars)
  • Elecraft KX3 radio
    • Mic-gain: set to 10 or 11 (based on watching the ALC graph and shooting for 4-bars)

Nope. Most SMS-to-SOTA gateways figure out your callsign by using the inbound phone number that the SMS originates from. Since there is only one phone number for SOTAmāt (+1-601-SOTA-MAT) serving multiple users, the SMS-to-SOTA gateways could only work for a single person.

A feature request has been made to allow spot comments to be predefined and then matched to a given spot in the mobile app. It is a good idea and on the list. Note however that there is a cost for this: it will consume many of the limited suffix combinations from additional combinations of suffix-ID’s times Frequencies times comments. Each new comment divides the suffix space leaving less room for summit ID’s and frequencies.

When operating in remote locations without cell service, there is no way to know for sure, unless chasers show up on the radio!  The whole purpose of SOTAmāt it to help get spotted (or send messages) when you are off-the-grid.

However, when you are on-the-grid at home testing SOTAmāt (often by instructing SOTAmāt to send you a test SMS message) how long should you wait before trying again? 

When you transmit your SOTAmāt message (ex. via FT8), it is instantly heard by in-range monitoring stations (after all, radio travels at the speed of light!).  However, the PSKreporter guidelines require monitoring stations to cache all reception reports for 5 minutes before transmitting a package of them to the PSKreporter database.  While FT8 messages are clock synchronized between all senders and receivers, the 5-minute cache timings between monitoring stations and PSKreporter are not clock synchronized.  Thus, the more monitoring stations that hear your message, the (statistically) shorter time you’d expect to wait before one of the stations sends its reception reports to PSKreporter.  In other words, 5 minutes is the maximum time, and you’d expect it to be much less on average.

Once received by PSKreporter, reception reports are forwarded to SOTAmāt a few seconds later.  SOTAmāt caches the raw reports and analyzes them within about 3 seconds.  When a report is deemed “actionable” (a valid user, a valid configuration, a valid command) and not a duplicate, it is processed according to the suffix.  Some processing (such as spotting to SOTA Watch) takes up to 3 seconds, and other commands (like sending SMS messages) takes about 3 to 12 seconds depending on cell phone carrier.

In summary your message may take up to 5 or 6 minutes to fully “execute” in the worst case, and often 2 or 3 minutes (or better) in the average case.  If you send yourself a test SMS message via SOTAmāt, don’t expect a result for 5 minutes, give or take.

When doing a real activation in-the-field (in the snow and wind) the stakes are much higher.  Make sure to read the section on “duplicate” messages, as you’ll want to send your message a few times to ensure delivery.

Yes, the system handles duplicates intelligently.  In fact, even when you only transmit your SOTAmāt signal once, it is very likely to be picked up by multiple monitoring stations and each will report individually multiple duplicate reception reports to PSKreporter.

Thus SOTAmāt has built-in de-duplication.  You can safely transmit an identical SOTAmāt message as many times as you want within a 15-minute window and all duplicates received will be ignored, while the first will be executed. 

Since SOTAmāt is a one-way system (without the ability to get a return acknowledgement of receipt), it makes sense to send your message 3 (or so) times to ensure being heard (but don’t go overboard and tie up spectrum).

Today the system relies on your messages being heard by a monitoring station running the SparkSDR software: it is the only software that can pull out a callsign + suffix in an FT8 13-character “free text” message.  Since there are only hundreds of these SparkSDR stations running worldwide at a given moment, it helps to transmit a few FT8 duplicates to increase chances of being heard.

A future version of SOTAmāt might support FT8 “C58” coding which will greatly increase the number of monitoring stations compatible with the service (beyond just SparkSDR software).  However, it is unclear if WSJT-X software reports on non-CQ C58 messages.  Testing is required…

Of course, but you’ll need to swap the speaker-out and microphone-in plugs at the radio when sending FT8 from your phone.  In one of my tutorial videos (here) I demonstrate three different cable options.  If you hate having to swap the microphone-in and speaker-out plugs when doing FT8 from your iPhone, and then swap back when operating SSB with a headset (as shown in the tutorial video), then see the other FAQ about building a custom cable.  The reason for the swap is that both the radio and the mobile phone are both “hosts” and expect a “client” headset to be plugged in (rather than a host-to-host).  We don’t want the phone’s speaker connected to the radio’s speaker, rather we want the phone’s speaker to connect to the radio’s  microphone input.  Here are some off-the-shelf cables you can buy:

1) An Apple Lightning-to-Headset adapter (works for audio output and input).  One of these cables came with your iPhone.  There are 3rd party adapters that might work fine for speaker output, but may not implement microphone input since they are sold as headphone adapters rather than headset adapters.  The genuine Apple adapter is sold as a “headphone” adapter but is actually a fully functional two-way (A/D and D/A) headset adapter (go figure).

2) A TRRS-male to TRRS-male adapter.  Or if you want to carry more weight and have a longer run from your phone to your radio you can use this TRRS-male to TRRS-male cable instead.

3) A TRRS-female to TRS-speaker-out and TRS-microphone-in splitter adapter

If you have an Android phone, you don’t need #1 (of course!)

NOTE: you will likely need to change your radio’s settings if it expects the microphone jack to control PTT (push-to-talk).  This is because you may be plugging a TRS plug into a TRRS socket (where the extra ring is used for PTT).  On Elecraft Radios you will need to change the menu setting for “MICBTN” to “Off” (and possibly “MICBIAS” to “Off”) so that it ignores the missing TRRS input.

Yes there is, but you have to build your own cable.  You have to be comfortable cutting wires, stripping them, soldering and using shrink tubing.  This tutorial video (here) shows how the custom cable works (but doesn’t show how to build it).  The parts you need are identical to the “off-the-shelf” option (see the other FAQ), but you swap the wires for speaker and microphone by cutting the TRRS-to-TRRS cable open, and soldering the flipped arrangement.

The swap has one confusing issue:  there are two “speaker” outputs for the Left-ear and Right-ear since TRRS is a stereo output, but mono-mic-input.  When you swap the phone/mic wires in the cable, which stereo channel should be used to go to the microphone line?  And should you connect both stereo output lines together to the microphone? 

The answer is NO, do not connect the left and right output wires together since that can harm the phone’s output amplifier (the left channel trying to force one voltage while the right channel is trying to force a different voltage but they are wired together). 

Here is the wiring diagram.  It doesn’t matter which end you choose to have as the “A” and and which is the “B” end, just be consistent!

  • [A-side Tip]  connects to [B-side Sleeve]
  • [A-side Ring-next-to-Tip] connect to nothing [The B-side-ring-next-to-tip is also not connected to anything]
  • [A-side Ring-next-to-Sleeve] straight-thru unchanged connected to [B-side Ring-next-to-Sleeve]
  • [A-side Sleeve] connects to [B-side Tip]

If you want me to build one for you, drop me an email with the desired length and we’ll figure something out.  Don’t expect fast turn-around (this is a hobby, not a job!).

NOTE: you will likely need to change your radio’s settings if it expects the microphone jack to control PTT (push-to-talk).  This is because you may be plugging a TRS plug into a TRRS socket (where the extra ring is used for PTT).  On Elecraft Radios you will need to change the menu setting for “MICBTN” to “Off” (and possibly “MICBIAS” to “Off”) so that it ignores the missing TRRS input.

Yup, I agree with your sentiment!  It is explained more fully on the “About” page, but it comes down to a few (not very good) reasons:

  • When I was looking to purchase a phone number for the SMS functionality, the best available (at the time) phone number with ‘SOTA’ in the number was +1-601-SOTA-MAT (+1-601-768-2628).
  • The purpose of SOTAmāt was to automate various ham radio activities.
  • It is your helpful friend, as in “g’day mate“.
  • It uses FT8 (which is an “m-ate” sound and not a “m-at” sound).

Thus it made sense to pronounce it “sota-mate” rather than “sota-mat” (as in “automate” vs. “automatic”).  But due to the phone number, there was no way to get SOTA-MATE.  The (dumb in hindsight) solution was to use the long-“ā” symbol to give a hint about pronunciation.  Thankfully Google search works just as well with SOTAmat as with SOTAmāt.  I’m about the only person who needs to type the silly “ā” all the time to keep this up.

Want to type it yourself?  On Windows, hold down the “WINDOWS” key and type a “.” (period) to bring up the emoji selector.  Then click on the 5th tab (the special symbols tab), and select the ā symbol. After you do it one time, it will keep that symbol in the “recently used” list for easier access.  Yes it is a pain.  Yes there are other keyboard shortcuts to do it, but I don’t like any of them.  On the Mac just copy and paste the “ā” in this post.