SatNOGS Ground Stations consist of several software components like the underlying Operation System, satnogs-flowgraphs and satnogs-client. Usually an update of the whole station can be performed by simply running the Update in the satnogs-setup configuration tool. In the past even dist-upgrades where made possible, specifically the Upgrade from Debian stretch to buster.
For the dist-upgrade from Debian buster to bullseye there has been no migration script thought, so this upgrade required re-flashing with the latest image as noted in the very-last paragraph of the SatNOGS Image 2022-09-10 Release Announcement. Re-flashing requires physical access to the Station and restoring the configuration will take additional time. Due to these complications the adoption of the latest version of the SatNOGS Ground Station Software might have been impacted.
To quantify this impact, we can use the SatNOGS Network API together with the scheduling-bazaar tools by @danwhite to create a local database of the SatNOGS Observations Metadata (thank you @danwhite for providing me with the database reaching back to 2016!). This local database can be queried to extract the reported satnogs-client version for all observations sampled on day in each month. We can get a first overview of the data by looking at the total number of “active” stations over time. I consider a station “active” in a given month if there has been at least one “good” observation on the 4th day of this month.
This plot looks similar to plots created earlier by other methods, so it confirms the validity of the method of sampling all observations of one day per month.
Next, we can plot the number of active stations again, but this time separately for a set of reported satnogs-client versions. In total 145 different satnogs-client versions have been seen by SatNOGS Network, so in order to get a meaningful graph I ordered all versions by popularity and selected the top 85%. All other versions are summed in the category “Others”. Those are mostly versions of locally modified clients or released versions where a bug-fix release happened quickly in succession.
We can see that there have been ~10 major releases in the history of satnogs-client and around when stations have been updated or replaced by new stations with the newer version. The second to last major update happened in the second half of 2021 from version 1.4 to 1.6. The current transition from 1.6 to 1.8.1 can be seen to have started in the second half of 2022.
Another way to visualize this data is to plot the relative adoption as stacked graphs. We finish the analysis of the historic data by doing so with a focus on the time since 2018 when we start to see multiple versions reported at the same time.
In this diagram it’s easy to see how version some releases did never see much adoption, especially 1.7 which despite being the latest version for at least 8 months was not even adopted by more than 10% of the active stations. This was caused by this version never being adopted for stations following the stable branch (described in the 1.7 release post).
Finally, we switch to a newer dataset to focus on the last 2½ years.
Indeed, the added requirement to re-flash the station to get version 1.8,.1 hampered its adoption but despite this more than 30% of the active Stations already use the latest version.
This analysis showed how adoption rates differed between several past transitions based on the prevailing conditions. It confirmed that version 1.8.1 was adopted by many stations but not by the majority in SatNOGS network yet, thus additional actions might be needed. Fortunately, work is underway to simplify station setup & configuration which will help with future updates.
The sources for creating the plots in this post can be found in these IPython notebooks.
