I have been looking for a app to log my SOTA activations. Being a bit of a FLOSS zealot I had the following requirements:
The app should be Free/Libre/Open Source Software
Since I use /e/ OS without Google Play Services the app should be available somewhere outside Google’s Playstore.
The app should not do any kind of input validation because when I’m in the middle of an activation, I don’t want an app telling me that a field should not be empty or that an entry is not complete yes - that’s the main feature I like about logging on paper. I’ll deal with those later.
The only thing I found was TOTALOG on F-Droid which is a general purpose logging app in its early stages - I’m not even sure whether it’s still maintained. It is under MIT license which allowed me to fork the project and adapt it for SOTA. So that’s how became tSotaLog to be (I basically added an ‘S’ to the original name and changed the capitalization. )
The result is an app that is totally geared towards how I work. So I don’t expect it to be useful for anyone who already settled for other means of digital logging. I’ll post it here anyhow, even though the intersection of FLOSS and Ham Radio people seems to be quite small. Maybe it is useful to someone else anyway. If you don’t like it, that’s absolutely fine. It’s also still very rough around the edges.
Features
Log activation QSO’s including s2s (with a bit of a quirk even logging of chaser logs is possible)
Archive and export to SotaData CSV
For now it’s only available as an apk from the Codeberg repo release page. I hope that I’ll eventually get it into F-Droid but I have yet to get to terms with their build system which has yet produce anything usable.
(Disclaimer: Don’t be fooled by the fact that there are no issues yet. It’s under MIT license, so there is no guarantee that it won’t eat you coax cables or melt that beautiful beam on your roof… )
Being a Linuxer/Unixer and all I still hang on to that pre-historic Unix philosophy according to which a tool should do one thing and do it well. So that might not be something I’ll add very soon since I’m still working on the “do it well” part of logging.
Warning If anyone used this app at all, I changed the data layout, the upgrade will destroy your data. Make sure you export to Sotadata before installing the upgrade.
Notable changes:
It also allows to record chaser logs.
It keeps a cache of call signs and Name/Comments entered and fills in the previous name/comment automatically if you log a call sign for the second time.
As with the last version: There is absolutely no guarantee that this app in any way behaves the way you expect it to.
Feel free to report issues on Codeberg or here if you prefer.
You don’t say, but I assume it can export in ADIF format as well as SOTA CSV which I need to merge my SOTA logs with my main station logs and for upload to LotW and Clublog.
Thanks, but on thinking about it I find I disagree with your unix/linux philosophy in this case.
I’m a retired Linux dev and usually agree that doing a single thing well is best, but on a small device with a less than optimal UI which is basically the definition of a mobile phone I think optimising things to reduce the user work load is more important, especially so when doing a SOTA activation. In my view this means a single application which does all the off-radio tasks is needed; logging, spotting and checking recent spots head that list.
I was only half serious when mentioning unix philosophy here. I’m honestly not convinced it can be applied to anything but cli applications you can pipe from and to or into file descriptors and so on. Even in desktop applications it can make to combine multiple functions in one application.
In the case of tSotaLog it’s just a lame excuse for just doing what covers my needs and not having more time to put into this little project.
I’m absolutely not against to having handling spots integrated in this app, it’s just not something I have the urge and time to implement. Anyhow, it’s all open source and I’m not at all opposed to include this feature should someone find the time to implement it and send a pull request my way. I guess I would even enjoy the feature and use it myself.
I’m most likely my only user but happily used the app throughout the summer - and went on way to many activations to find time to improve the app. In November, with to little snow to ski but too much to go hiking, I found the time to add a few improvements, so I’ll post a follow-up anyway: I added a pre-release of 0.3.0. The notable changes are listed in the changelog.
One notable absence of a change is the still lacking support of ADIF export. I tried to add ADIF support but could not figure out what fields a SOTA ADIF file should include. I tried to figure it out using ON6ZQ | SOTA to ADIF log converter but could not tell how to distinguish between chaser, activator and s2s logs. If someone could provide a example file with one log each this would be much appreciated.
Those are the SOTA specific ones. Everything else is “standard” QSO stuff
<SOTA_REF:9>SV/MC-028
<MY_SOTA_REF:9>OE/SB-420
You don’t need to seperate that.
As activator or chaser uploads ADIF to the SOTA database the system will figure that out depending on the used SOTA_REF and MY_SOTA_REF.
If there is a
MY_SOTA_REF = Activation
If there is
SOTA_REF = Chase
if both = Summit 2 Summit
For csv it is not that trivial I guess as there are separate upload functions. So make a option on “starting” the app if one activates or chases. Because it can only be the one or other.
Btw. if you include the SOTA spots via the SOTA API to have spots available like in VK-Port-A-Log and transfer the info to the entry fields I am sure you will have a lot of new users. Swagger UI
Thanks a lot! So MY_SOTA_REF is equivalent to the third column in the CSV and SOTA_REF is equivalent to the 9th column in the CSV. Then it’s easier than I thought
Btw. if you include the SOTA spots via the SOTA API to have spots available like in VK-Port-A-Log and transfer the info to the entry fields I am sure you will have a lot of new users.
For now that’s not on my list because I’ve got spotting covered using sotl.as, APRS2SOTA and SMS Spotting and I’m doing this mainly for myself. Basically all I wanted was an open source logging app, but couldn’t find one. Who knows, maybe eventually I’ll find the time to implement this or someone else does…
(Maybe I also have to start over eventually because I’m not sure I enjoy using Ionic…)
Hey Joe, I totally missed that part of your post, hence the late reply. Yes, it is as trivial with the CSV. You just put the your summit into the third column, the summit of the other station in the 9th column. That way you can have chaser, s2s and activator logs in the same CSV.
In the UI I solved this by allowing you to choose whether a log should be a activator, summit2summit or chaser log. Of course you get a second summit field in the case of s2s…
EDIT: I also didn’t read you suggestions of supporting sports as precise as I should have…
Btw. if you include the SOTA spots via the SOTA API to have spots available like in VK-Port-A-Log and transfer the info to the entry fields I am sure you will have a lot of new users.
I thought you suggested that the app should support sending sports. Now that I reread this I thing I get what you mean. It would be useful to have spots to choose from if you have a s2s contact so you don’t have to fill in the fields… I’ll add a issue on my repo, that’s actually a good idea.
I made the v0.3.0_RC2 version the final v0.3.0 release because I already tested it on one activation (where I found and fixed some bugs ) and mainly because I’m almost done implementing accessing and copying the spots of the last 30 minutes and want to get this out soonish - mainly to use it myself when fishing for s2s QSOs.
Had some time at hand today and created a release candidate for 0.4.0 adding ADIF export and downloading of the spots of the last 30 minutes (hard-coded, up for discussion) to copy them to the QSO form.
It turned out that the listing of only one spot was a bug. It only ever displayed one spot. Addidionally there was an annoying bug in the ADIF export which made ADIF exports mainly useless. (Some fields hat the specified length of undefined rather than the actual number of caracters).
Version 0.5.0 was released which includes one major change: To export a CSV or an ADIF you are asked where you want to save the file rather than just picking a default location. This helps if you want to save the file to a folder which is synchronised using a cloud file sync app like Nextcloud (or one of the more famous proprietary ones… ). You find the release and a link to the changelog here:
Congrats, you app is really great! I like to history load /archive mecanism ! this is very good!
I would like to suggest a few things:
archive name field can comes pre-populated with current date time so at the end of my sota activation I can archive it quickly without having to fill by myself a value for that field, why not also with the latest (or the most reprepsentative) summit ref, it would be super easy to archive based on summit in history.
the toast (notification) comes on top of the bottom bar, so you have to wait the toast to fade out before being able to click on the bottom bar icon.
of course self spoting would be a must, it can also be using APRS2SOTA (so you post via TCPIP on APRS!) instead of SOTA API wich can be sometimes hard to impelement with the authentication process, or you can generated an SMS ready to be sent, up to you, but … yes self spotting would be awsome
this is more personnal so really subject to debate one thing that I do for every QSO is to populate MY_GRIDLOCATOR/MY_LAT/MY_LON from position or SUMMIT INFO from API or CSV also…
GRIDLOCATOR/LAT/LON in case of S2S, same data can be lookup.
(I do my own Java post processing to achieve it). Would be a must to do it automatically. but again it is more personal.
I’m still a bit reluctant to implement spotting because I initially wanted to leave out features that depend on proprietary APIs. However, I already broke with this when I implemented spots downloading.
I’d rather use the SOTA API which should not be too hard to implement, as far as I can tell it’s a standard Keycloak/OAUTH2. The main question is whether they allow public clients and long lived tokens needed by an app not backed by its own backend service. I heard that this might not be the case… Correct me if I’m wrong.
If they don’t APRS might be an option to work around the fact that I don’t want to implement my own backend. I rather shy away from generating SMS to spot becase someone has to pay for the SMS sent - usually the person running the gateway - and I don’t want to put additional pressure on their purse.
Anyhow, spotting is definitely not my top priority. Of course any merge requests are welcome…
)
