+1 for the any solution allowing spot comments. Needed those this week to add the park & island ref to a sota spot - which is a common need for those of us who activate multiple award programmes at same time.
1 Like
I donât work the way you are suggesting so Iâm open to suggestions and trying to understand.
Iâm sure you know SOTAmat can post to both POTA and SOTA on their respective spotting sites with their respective Park / Peak IDâs. Sequentially, not at the same time. Does just a single SOTA spot Comment field work well enough compared to spotting on POTA and SOTA? If you do IOTA then I get it.
Since SOTAmat requires pre-configuration, is it still useful if you canât change the comment when in the field? SOTAmat was designed for âconfigure once, use many many times, no internetâ. If your comment needs to change before each activation (using internet), you might find the current UI a little cumbersome and you might rather have an internet based way to get the configuration from the web server to the mobile app (ex. button click to sync or automatic sync). The current âconfiguration blobâ approach might become cumbersome. How often would you be changing these comments in your configuration?
Thoughts?
If thatâs what you want and the workflow makes sense I can easily add a /comment='xxxxx' approach (in fact it already works that way for the special Mode of âAlert-CWâ so that the comments can be sent to RBNhole such as âS+12â).
-B
I spotted on 40m yesterday on Coosa Bald using my truSDX and SOTAMAT only. It was a success on the first try!
Great job AB6D!
Steve
1 Like
Fantastic work Brian. Used it on my last two activations. 100% xmit hit rate. Also msg my wife letting here know when I was leaving the summit. Just Great! Thank you.
1 Like
The issue is that the FT891 has âSSBâ mode not USB/LSB, and autoselects sideband, unless you go into the deep settings menus and change it. A different VFO has the same default sideband. The solution is probably to use memories.
1 Like
My vote is for option 1. It may not be elegant but seems to allow for future additional functions without the complete code base having to be updated.
My 2-penneth
73 Ed DD5LP
1 Like
Sorry - Iâm not thinking it through. It would need a user-defined comment per summit or park, which, as you say, is not how things work. So ignore the suggestion. Iâll just have to spot twice, once for park and once for summit.
==
As I mentioned in a private mail, the one BIG thing that is missing from SOTAmat is WWFF. WWFF predates POTA by many years, and claims to have more activity in more countries. Judging by spots, in VK for instance WWFF activations would outnumber SOTA and POTA combined by a large factor. And likewise it appears to be the default parks scheme for much of Europe.
I realise mirroring the parks list for another award scheme and hooking up to another spotting API is probably a big bit of work for you. But Iâd strongly recommend putting it âon the listâ if you want SOTAmat to be a global tool.
1 Like
Hi Brian,
Thanks a lot for the feedback and the open discussion!
I was thinking about both solutions and their side effects.
To me, solution #2 is the cleanest and most flexible implementation for the long run, especially when I wear my âdeveloper hutâ, explanation:
Compared to solution #1, data does not have to be entered redundantly (e.g. for every mode and frequency block combination). So if I go tomorrow for an activation to DL, I would have to enter for all my six mode/frequency block combinations this information (including the /P postfix, which would always stay there). Next day, if I stay in HB) or go to FL, I would to change this configuration again six times.
A conflict could manifest when activating along a border. For example, last summer I activated along the French/Spanish border, where one summit was in Spain and the next one in France. Since at the summit there was a barbed wire for the cattle, I could not activate the French summit from the Spanish side, which in this case would have solved this dilemma. I know, this example is rare, and Iâm a bit special, because I live at the corner of three countries. I just wanted to highlight some special cases and I guess there are more I didnât think about.
In case you would go for solution #2, the addition of a third attribute that is the comment field could make sense as well.
When I swap the hut for the project manager, I would go for solution #1, because itâs a fast(er) solution that doesnât need a new database scheme and form fields, both for the configuration and the app. The effort for the new calculation for both solutions would be probably about the same and the parsing of the #1 special meanings seems easy to me.
Well, if there are two kind of configurations that overlap, one of them would win over the other (probably #2). So going first for #1 and then later for #2 doesnât seem a show stopper to me. The user just has to be aware of the precedence.
My conclusion:
I would prefer #2, but I see your implications. You can estimate your spare time and the involved work much better than me. Both approaches solve the problem.
Your idea with SOTAmat is really great. It works reliably and solves a common off-the-grid spotting problem for the phone operator in an elegant and easy way.
73 Stephan
1 Like
Hi Simon,
OK, I seeâŚ
Yes, this could be another viable solution. At least keep all wanted FT8 frequencies on USB in the memories and toggle between memory and VFO.
73 Stephan
1 Like
@HB9EAJ Thanks for the input. Originally I was thinking that option #1 and #2 are essentially the same where you specify a prefix and/or suffix for each Frequency/Mode row in the table. The only difference was where you specified the prefix/suffix data: in #1 you specify it in the âMy Notesâ, vs. #2 the table has new dedicated columns. Originally I was thinking that in either case you would need to have lots of redundant rows. For example, one redundant row for the âVEâ prefix, and one for âHBâ:
M=SSB F=14.227 StepHz=1000 Steps=100 N="These are my notes" Prefix=VE Suffix=P
M=SSB F=14.227 StepHz=1000 Steps=100 N="These are my notes" Prefix=HB Suffix=P
In other words, originally I thought you wanted to be able to select a prefix and/or suffix combination independent of your operating location: hence the use of the Freq/Mode table. Freq/Mode selection is independent of your peak selection. That would take up a lot of code combinations (and you only have 1 million) since the Frequency/Mode entries are multiplied by the summits IDs to generate codes.
But now Iâm thinking that your Prefixâs and Suffixâs are not independent of the peak location: they are based on the country you are activating in. So wouldnât it work better if we defined (just one time, with no duplicate rows) a prefix and suffix you want to use for each of the Regions in your Region table?
In other words, if you live in Switzerland (HB) but are operating in Germany (DM) in the German Baden-WĂźrttemberg Region (region ID = âBWâ), shouldnât we define your callsign prefix/suffix in the SOTAmat Regions table for the DM/BW row? For example:
RegionCode="DM/BW" MyNotes="These are notes to myself" Prefix="DM" Suffix="P"
And then if you activate DM/BW-471 you would get spotted as:
DM/HB9EAJ/P DM/BW-471 14.229 SSB
If the choice of your prefix/suffix is always the same for a given region, then this would not add any code combinations and would be very efficient. To understand how SOTAmat computes codes, there is a picture that helps in this video: https://youtu.be/FG6hO5LgByI?t=2613 Youâll see that if we assign a fixed (static) prefix/suffix to all the summits in a region, the total number of combinations stays the same since it isnât an independent variable.
If that is how you would use it (always using the same prefix/suffix for a given region) then that would be option #3 and I think by far the most code efficient. It would also be easier to code than #2 (but more work than #1) because the integer to FT8 suffix coding could stay the same.
Does option #3 work?
-Brian
1 Like
Hi Brian,
the one situation that may be a problem is in SOTA where a summit is on the border (there are some between Germany and Austria for example) - You may be activating a âGerman Summitâ from the Austrian side of the border and hence the Summit reference would be DL however the callsign prefix (presuming you are not an Austrian operator- where no prefix would be needed) would be OE.
This is an exception situation however and to take extra work to handle this is probably not worth the time.
So I would say option #3 sounds now like the best of the three to me.
73 Ed DD5LP.
1 Like
Brian,
Your proposed solution #3 is indeed very comfortable and code efficient as well. Very clever, I like it!
And as @DD5LP mentioned, the case where one activates a border summit on the other country exists, but is rare and therefore can be ignored IMHO.
FYI (just for correctness): The prefix would be DL instead of DM, because this is the official prefix to be used in Germany, e.g.:
DL/HB9EAJ/P DM/BW-471 14.229 SSB
But since the prefix could be specified per region, this should work like that:
⌠Prefix="DL" âŚ
About the /P suffix: Like many European activators, I always use /P, Independent of the location. But there may be some restrictions and specialties with prefixes in some countries/regions. Therefore, to me the region looks like a good place for the suffix as well, but Iâm not sure if this works for all cases. Input is definitely welcome!
73 Stephan
1 Like
How do you intend to handle the UK callsign and how it varies as UK hams move about the UK?
2 Likes
I have no experience with adding a callsign prefix / suffix in the UK or working outside of a home country. I donât know the UK rules, or rules for other countries. Hence I need help designing this correctly for the community. Any guidance as to how people want it to work is appreciated.
@MM0FMF when you move about the UK, does the way you use your prefix/suffix depend on the Region inside the UK that you are activating in, or is your prefix/suffix independent of the region? If it is Region dependent (meaning you will always use the same prefix/suffix for all summits within a Region) then that is fabulous. If the prefix/suffix is independent of the summits in a Region, then that is problematic and will require us to overload the Frequency/Mode table and use up valuable code combinations.
Keep in mind that the solution has to define the meaning of the callsign suffix-code ahead of time. Nothing can be edited or changed on-mountain. Adding fields/variables to an existing item (such as a Region or a Frequency/Mode pair) doesnât increase the number of code combinations, but adding a new field/variable that is independent of the existing schema will quickly deplete the 1 million available code combinations (I only have about 19 bits of data to work with, which is why I pre-define what those 19 bits mean). [If this paragraph is confusing, the pictures in the video link above explain how it works better than words.]
-Brian
1 Like
| Country | SummitRef | My Callsign |
|---|---|---|
| England | G/xx-xxx | M0FMF/P |
| Scotland | GM/xx-xxx | MM0FMF/P |
| Wales | GW/xx-xxx | MW0FMF/P |
| N.Ireland | GI/xx-xxx | MI0FMF/P |
| I.O.M | GD/xx-xxx | MD0FMF/P |
| Jersey | GJ/xx-xxx | MJ0FMF/P |
| Guernsey | GU/xx-xxx | MU0FMF/P |
1 Like
@MM0FMF Oh wow. Iâm glad you asked. So in the UK it isnât just a prefix changing, but the base callsign changes.
It appears that for a given Association/Region pair, there is a nearly (or exactly) 1:1 mapping between the Region and the âPrefix/Callsign/Suffixâ that should be used for that Region. So am I correct that if in the current SOTAmat Region Table, if I added a new table column with a string for âPrefix/Callsign/Suffixâ that could work? If the user leaves the âPrefix/Callsign/Suffixâ column blank SOTAmat will work as it does today. If you have a non-blank, SOTAmat could post the spot using that string for all the summits in that Region. In other words, I wouldnât have a separate table columns for âprefixâ and âsuffixâ and instead would have just one new table column for a combined string value of âPrefix/Callsign/Suffixâ.
@HB9EAJ and @dd5LP and @MM0FMF would you all agree that this would serve your needs? It certainly would be efficient with code combinations (it wouldnât require any new combinations from today).
-Brian
1 Like
Not if they are using a club callsign (and club calls do get used on SOTA activations!)
| Country | SummitRef | Club Callsign |
|---|---|---|
| England | G/xx-xxx | GX3HAM/P |
| Scotland | GM/xx-xxx | GS3HAM/P |
| Wales | GW/xx-xxx | GC3HAM/P |
| N.Ireland | GI/xx-xxx | GN3HAM/P |
| I.O.M | GD/xx-xxx | GT3HAM/P |
| Jersey | GJ/xx-xxx | GH3HAM/P |
| Guernsey | GU/xx-xxx | GP3HAM/P |
Itâs fabulous isnât it? 
I think the column holding the value âthis is the call I want you to postâ will work.
1 Like
And of course the âMy callsignâ callsigns can start with G, M or 2 - with the second character being the regional letter (country or dependency within the UK) indicator, except for the case of England where it is dropped ⌠EXCEPT with the Intermediate(General) class â2xABCâ licence where it is included! Are you following this Brian? Itâs certainly a âdifferentâ solution than that used in many other countries (e.g. the US or Australia).
Another âGotchaâ outside of the UKâs complexities is that rather than needing a prefix to the home call sign when moving into another country under the CEPT rules, when separate reciprocal arrangements are in place between the destination and home country, the visited country code can actually be a suffix rather than a prefix (this is rare but does still exist in arrangements with some South American and SE Asian countries - possibly also some others as well).
So the bottom line is that with all of these variables I would not try to automate the code with it linked to the summitâs association code rather the user needs to state what they want to use as âcallsign-codeâ i.e. including Regional Letter, prefix or suffix as needed for their upcoming trip out of their country. They will need to then re-generate the code table prior to their trip and load it into the App and on return home, or when travelling to a different country change it and regenerate again.
So I think using your option of having an extra, optional, column for the combined string value of âPrefix/Callsign/Suffixâ would be better than having any automation based on the association code, or ⌠make the existing call sign field accept these customisations - perhaps it can already do that? Is this more a process and documentation change than a code change?
73 Ed.
1 Like
This definitely serves my needs.
Thank you Brian!
73 Stephan
2 Likes
Could you, please, also consider making SOTAMAT available on the F-Droid store?
I happen to have a de-Googled phone.
2 Likes