My test in EA3 worked great, by using your Android app!
As we know, there is lack of pre- and postfixes, but the spotting from a summit with the smartphone speaker to the microphone worked without problems and that’s what I was mainly interested in!
For time synchronization I used the slightly outdated Smart Time Synch Android app using the GPS time base, which did its job. Any other recommended solution, or do you plan to automate the time difference into the app?
I created a video, that once I’m home (and have time) will make a practical YouTube video.
@HB9EAJ As for time sync here are my opinions and experiences. Since I am supporting multiple platforms (iPhone, iPad, Android phone/tablet, Windows, Mac OS, Kindle, etc.) and since I am doing this in my spare time (I have a day job), I try to do things in a way that works the same across all platforms and doesn’t require platform specific code. The mobile code is written in C# with multi-platform Xamarin.Forms. Unfortunately Apple API’s do not allow me to directly access the raw GPS time data, nor control how/when the time syncs: it is all automatic and hidden by iOS. Other platforms do. Hence the current neutral design.
In my experience I’ve found:
monitoring stations are forgiving and allow a several second mis-timing in either direction.
most mobile phones time sync automatically when they have network
most mobile phones will hold their time sync within a +/- 2 second window for a few days (backpack trip)
when I operate cable free (speaker to microphone), before I hit the radio PTT button for an FT8 cycle, I first tell my mobile app to transmit at the same time that I am listening to the over-the-air FT8 stations. I can tell my timing relative to the other stations by hearing my phone’s audio vs. the audio from the radio. I then count in my head “one-onethousand, two-onethousand, etc.” to determine if I’m fast or slow and by how much relative to other FT8 stations. I then use that in the “Settings” tab to apply a time correction offset on the SOTAmat time slider. And since I only need to be +/- 1 second, it is easy to do.
The advantage is you can be totally off grid, no internet, no cell, and no GPS required.
As I continue on my backpacking trip after a manual sync, I find that the manual sync will hold for a day or so.
The SOTAmat app time offset slider (on the “Settings” tab) only allows you a range from -0.75 to +0.75 seconds since it doesn’t actually care about the absolute time and only cares about alignment with the FT8 15 second window.
You are correct that Android has a lot more options. There are apps that not only will grab precise GPS time, but will also help you set your system clock to the correct time, meaning you’ll never have to use SOTAmat’s time offset.
I hope that helps in the field. For people who use a direct connect cable, you can do the same thing before you connect the cable, use VOX mode settings, etc.
And for other people just joining the conversation: I’ll reiterate that going “cable free” with the speaker to microphone approach requires proper calibration of your phone and radio settings to avoid splatter on the band. Please read the FAQ on the SOTAmat web site before attempting so that you don’t splatter others on the band. [And cable free is what I do because it works and has a much easier workflow once dialed-in].
Ed, thanks for the pointer.
Unfortunately, I couldn’t find the ClockSync app, neither on the play store or F-Droid. On play I found SyncClock, but this seems something different.
Could you please paste the URL with the package name (the id-parameter) in it?
73 Stephan
@HB9EAJ I want to help you (and others) decode some of the information that is in your posted screen shot from the SOTAmat activity page:
You were heard by 3 different monitoring stations (skimmers). That’s good as you want some redundancy in your area. Remember that only skimmers running SparkSDR will work (or if you didn’t know that, watch the very long 1 hour YouTube video I posted on the homepage to see why only SparkSDR). Note that I have a volunteer software developer (possibly 2) who are looking to add SOTAmat compatibility to other SDR software on the market. That would be fabulous and I’ll support any developer who wants to.
SOTAmat’s server recognized that either multiple stations heard the same transmission, or you transmitted the same message multiple times, or both. It executes the first one it sees, and then marks the others as duplicates and does not execute the duplicates. A message is considered a duplicate if it has identical content (callsign + suffix are identical) AND the latest message is within 15 minutes of the last message heard with that callsign/suffix pair. So after 15 minutes if you want to respot yourself on the same peak with the same mode and frequency, you can do it after 15+ minutes since your last transmission.
If you want to change frequencies on the same peak, you don’t need to wait 15 minutes, since self-spotting with a different frequency will generate a different callsign suffix, and thus the messages won’t be identical and SOTAmat will execute the novel callsign/suffix combination immediately.
I can tell that you transmitted the same message multiple times (and you should) by looking at the frequency heard by skimmers. In the default mode SOTAmat will send the same FT8 message up to 4 times, but each time it will shift the audio frequency by 51 Hz as an attempt to not constantly transmit/interfere with the same person if someone else happens to be on that frequency too. I can see your first two reception reports (the bottom two) have essentially the same frequency, but the top report is 100 Hz different. That means 2 stations heard your first transmission, no stations heard your second transmission, 1 station heard your 3rd transmission, and 0 stations heard your 4th transmission. That’s why I recommend sending 4 times, and if that fails to generate Chasers, 4 times on a different band (20m + 40m for example)
You had a nice strong signal (-8 snr) into DL3EL but he only heard one of your transmissions. QSB?? Interference? Don’t know. This happens a lot, and is another reason I suggest people transmit multiple times.
SparkSDR skimmers tend to have frequency stability to about +/- 12 Hz if they run continuously since the software automatically watches the radio’s drift against an internet atomic clock over several days and based on long term drift modeling it auto-corrects it to about +/- 12 Hz. But only radios that run continuously have that accuracy (like the skimmer my wife runs).
The default SOTAmat audio frequency is chosen to be in the “sweet spot” for most mobile phone speakers and radio microphones. It is also chosen with a strange value of 1,543 Hz that is less likely to be used by others. Most people pick a frequency that is a nice round number like 1500 Hz.
Once you send your FT8 message it is received instantly (speed of light!) by the skimmers, but it takes up to 6 minutes before the spot posts. This is because skimmers are only allowed to upload reception reports to PSKreporter at 5 minute intervals. Once received SOTAmat only adds a few seconds of processing (mostly negotiating OAuth credentials for the SOTA API), and then once posted to SOTA Watch the Chaser’s apps poll about once a minute. Hence a worst-case of 6 minute delay. If multiple skimmers hear you, their 5-minute timers are NOT sync’ed and thus statistically if you are heard by 2 skimmers the response time should be 2.5 minutes + 1 minute = 3.5 minutes delay.
Anyway, I know you know most of this already, it was just an opportunity to use your screen shot to explain to everyone.
A bug affecting Garmin inReach users outside of the USA was found by New Zealand operator @ZL4NVW and has been fixed with his help. If you had issues with Garmin inReach before, give it another try. If you find new issues, please let me know! Now that I have examples from several countries I think I’ve got Garmin’s API figured out internationally.
It was good Matt tested at home before an excursion!
I played with ClockSync, but it seems, it only supports NTP as time source.
Since I need a network independent time source, I stick for now with what I already have:
BTW: For security reasons, Android doesn’t allow an app to change the system time, unless you have a rooted device, of course. No problem, since one needs only to know the delta and only to the start of the 15 second FT8 window. And according @AB6D, the FT8 monitoring stations are more relaxed concerning mis-timing.
To be safe, I’d shoot for +/- about 1.25 seconds or better. Given that window I find I can just use my ears and listen to my tones relative to receiving many FT8 stations over the air. Just by listening and manual correction I think you can often do better than +/- 0.5 seconds.
@DJ2TG You can’t just search for “SOTAmat” in the Apple App Store. Apple’s search algorithm doesn’t work well for low volume apps. While software developers provide “search keywords” when listing in the App Store, Apple simply ignores them for new low-volume apps! Developers have to do their own marketing initially. There is a post above saying you have to do one of two things:
That funny “ā” symbol would be familiar to most kiwis (and probably other pacific nations) as a macron. The trouble is it’s pronuncuation would be somewhat different here to your expectations, approximately:
Sotama’at
At least it’s not rude! The joys of naming for an international audience!
Each to his own but when you need to give pronunciation advice for your product then to be honest, you’re on a losing run from the start. It’s like the Tom Hanks 1996 film “That thing you do” where the pop group was called “The Oneders” and people didn’t realise it was pronounced “wonders” and called them “The On-ee-ders.” It wasn’t long before the record company changed it to “The Wonders” which is what it should have been from the start.
YMMV, but I think it’s great app with a poor name.
Agreed. In my “About” and “FAQ” pages, I talk about how the name was a mistake from the start. When I started it was just an experiment for my own use and then evolved. It wasn’t “planned” per se.
On the FT891 it seems to be a major pain to change sideband to the other one on the fly, and digital does not use the microphone.
Perhaps the ability to send reversed tones for LSB would be useful?
Does anyone else also have a problem with LSB?
I don’t own a FT-891, but since it has two VFOs, I recommend to save the USB FT8 frequency in one VFO and the working frequency in the other VFO. Like that you can just toggle between them.
Since you use USB instead of digital mode, you can simply use the microphone, but make sure you have the correct audio level. Strive for a slightly lower output power, just before the ALC kicks in.
That’s how I tested it successfully on a summit about a week ago.
To me, using SOTAmat with this procedure was faster and less cumbersome than using APRS with a Yaesu HT.
Once the pre- and suffix can be configured, it will be my preferred backup spotting solution.
I made a video where I showed it in action that I will edit when I have some time.
@HB9EAJ Regarding the need for spots posted by SOTAmat to have an option for callsign prefixes and suffixes added when operating outside your home country, I can give you two options:
Options:
Do a quick hack to the current system using the current database schema. I do this by using the existing “My Notes” field/column in the “Frequencies and Modes” tables. We define some special syntax that lets the system know that the notes are encoding a prefix and/or suffix rather than just a message to the user. For example: Hello these are my notes /Prefix=VE,/Suffix=P
…or… /Prefix=VE,/Suffix=P
…or… /Prefix=VE
etc. The advantage is that this can be implemented quickly. The disadvantage is that it isn’t as elegant or as easy to learn as having specific columns in the user interface Table Editor for “prefix” and “suffix” (and dedicated columns in the database schema).
This approach allows for future additional features to be added easily. For example, I’ve had people who want to be able to have their own comment posted to the spot. For example: These are notes to myself /PostComment='Thanks chasers' /Prefix=VE /Suffix=P
Do it the more elegant way by adding two new columns to the database schema for Prefix and Suffix and update the Table Editor UI, etc. The advantage is that it is easier on the user to understand. The disadvantage is that all of the code from the front end to the back end to the processing daemons would need to be updated, taking more time to implement and possibly introducing bugs. I’m starting a new day job and thus have less time. Implementing this version will take me longer. Starting with version #1 and then later changing to #2 would be even worse because people would have configurations using two methods.
Since I will likely not use this feature myself, I am asking you and the community what you prefer. Option #1 or #2? If option #1 I think I can do it soon. If #2 I don’t know when I’ll get the time.
