This marks the continuous efforts of hundreds of owners of SatNOGS ground-stations operating numerous ground-stations globally (more than 170 stations on-line, more than 90 in testing and more soon to come) while continuously enhancing the network software and hardware solutions.
So this week the team migrated the SatNOGS database to its new platform. This operation was crucial and ensures that we have a stable and well scalable database. Whilst the total data held on the database might not be huge, it contains a very large number of files. Overall, the migration went well and downtime was kept to a minimum. We would like to thank the team for their hard work making this a flawless process.
How to Schedule an Observation blogpost
This week a blog appeared with a walk through of screenshots explaining how a ground station owner schedules observations on the SatNOGS network. This aspect of the SatNOGS network is accessible only once someone has a station set up therefore it’s helpful to show people how easy they are to use once they do! Check out the blog here.
ARISS Contact Kenilworth, UK
On the 14th December many SatNOGS stations were able to hear an ARISS contact scheduled between Kenilworth School and Sixth form College and the International Space Station. The scheduled astronaut was Serena Aunon-Chancellor KG5TMT. As usual, you can find the list of successful observations and can listen to them via this post on the Libre Space Community page.
Single Sign On for all Sites, Auth0.
This week members of the team made changes enabling us to have a single user database across our websites. This means users can log in to one site in the ecosystem and authenticate across the rest with just one-click. This now applies to community.libre.space, network.satnogs.org, db.satnogs.org, network-dev.satnogs.org, db-dev.satnogs.org, and dashboard-dev.satnogs.org. As a result, there’s no more need to create individual accounts across those 6 sites, one account now works on all! In conclusion, massive thanks and respect to Auth0 who provide this as a service through their Open Source program.
Rocketlab Electron Curie Launch and Hunting Satellites!
This week Rocketlab successfully launched their Electron ELaNA-19 mission succefully and deployed some satellites to orbit. As with every new launch, the SatNOGS team and community have been trying to hunt the satellites. Currently 5 satellites TLE’s and information have been made available and one satellite has been heard! Additionally, track the development of this over at this post on the Libre Space community page.
SatNOGS is maintained by the Libre Space Foundation, a non-profit built to develop and promote open source space technologies and open access to space-related data. The passion we have for space and open source is what drives us, and we are proud of the community that has been built around SatNOGS. Over the past four years of development, the SatNOGS community has grown to more than 100 ground stations around the world with more than 2000 satellite observations per day.
On November 27th, Amazon announced the AWS Ground Station service. Like other companies who are currently operating ground stations as a service, this will allow satellite operators to receive their data using proprietary and closed-source technologies. The SatNOGS community is focused on building a ground station network that provides downlinked satellite data to researchers and operators worldwide, in an open way and free of charge. As we have for four years, SatNOGS will continue to serve organizations and missions that value the openness of science and data.
With Amazon and other companies entering this space, our vision for SatNOGS remains the same: to advance open technologies and open data for space by creating the best and largest open source satellite ground station network.
After a nice code push, scheduling observation functionality is now complete in SatNOGS Network website. The website is now able to dynamically calculate and schedule observation windows given a satellite for all available Ground Stations. The functionality works like this:
The observer enters the New Observation page. After selecting a Satellite and associated Transponder desired, the observer selects the timeframe for the observation. The timeframe selection is constrained in the future with maximum width being 8 hours (this could change as we scale the Network). After hitting ‘Calculate Observation’ the system returns a proposed Timeline of the observation, that includes the Ground Stations to be used and their individual observational windows. For this calculation we use PyEphem library and input the Ground Station locations, Satellite TLE, and timeframe desired.
Once the proposed timeline is reviewed and/or modified the observer can schedule the observation by hitting ‘Schedule Observation’. This creates the Observation in our database as planned, together with its associated individual observations for the Stations.
The Stations, through the Client, query the Network API frequently for scheduled individual observations.They then execute them on time, and push back the recorded data to Network, for further analysis by the Observers (making them also publicly available!)
Optimization of the Scheduling functionality will be further pursued. Ideas like deduplication of overlapping (more than 50%) individual observations, and accounting for horizon constrains are already in the works, and will be evaluated (in terms of their efficiency) as the Network scales up.
You can check a sceencast of the workflow in SatNOGS Network below:
The SatNOGS Network website has had the focus in terms of development from our software team in the past week. While the major functionality (observation calculation and scheduling) is coming along nicely (thanks to libraries like python-ephem) we are also delivering other needed functionality. This time it was a public, well documented, open API.
Based on Django REST Framework, we deployed an API that matches our current DB model and enables other applications or services to query SatNOGS Network for information about Ground Stations, Observations, Data, Transponders or even Satellites.
For now authenticated users of the website are the only ones with POST (write) access, anyone else can view only (GET). We are planning API-key based access so that Stations can submit recorded Data once they are done with their scheduled part of the observation.
Continuing the development of SatNOGS Network, we focused on enhancing the observation results page. Check out how it looks overall:
What is new?
The new timeline view gives a quick overview on the data that each ground station collected within the observation timeframe. On the left you can see the list of the Ground Stations that participated in the observation and on the right you can check the timeblocks each ground station got data. We used the nice d3-timeline js plugin for it.
Each data that is associated with an observation is displayed in a new panel-based section. The data we collect can be either text (decoded messages) or sound (available for further processing). We dealt with the hardest one first. We used Wavesurfer.js to visualize the waveform (HTML5, WebAudio and Canvas FTW!) and added the ability for playback directly in the browser. A download link is also available.
The code for the implementation of the new views is already pushed in our repos. Soon we will be updating the dev instance with mock data so that you can check out the new functionality yourself.
As outlined in project description and previous logs, a central part of our projects is what we call “SatNOGS Network”. SatNOGS Network is a web application running on a server that takes care of discovery of ground stations, registering of users, scheduling and job-detailing of observation as well as data collection and analysis once an observation is done.
The model of the application is now polished and able to handle all basic operations for Stations, Users, Observations, Satellites, Transponders, Antennas and Data.
Next in line in terms of functionality implementation is the ability to plan observations based on user provided info (satellite, transponder etc) using SGP4 in python, and also a detailed view of Observation (with data and timeline).
The main page features a map with all ground stations, details about a featured ground station and latest completed and scheduled observations.
The code can be found (follow and contribute too!) here: https://github.com/satnogs/satnogs-network
A live development version of the website with demo data [WARNING ;)] can be found here: https://dev.satnogs.org/
SatNOGS as a project has been concieved as many Satellite Ground Station implementations (like the v0.1 which is ready) coupled together under a global Network that would enable anyone to utilize SatNOGS as a single platform for observations.
The UX idea is simple. An observer/astronomer/maker/hacker accesses our global Network via a web interface. Then she provides details about the observation that she would like to schedule like, which satellite, which band, what timeframe, which encoding etc. Then, having all the info , the system calculates the possible observation windows, on the available Ground Stations connected to the Network for the given timeframe (taking into account any tool, location and time constrains). Once the observer confirms the proposed “observation job” then it gets sent as a job to each Ground Station (GS) job queue to be executed when it has to.
GSs are gathering observations, decoding/recording them and sending them back to the Network, making them available to the observer (and the world!).
Here is a glimpse into the initial DB Schema of the Network (not all attributes are populated in the tables)
The general design of the Network part of SatNOGS constitutes a typical many-to-many scheduling problem (many observers to many ground stations) Interestingly enough projects have been developed for observations planning and scheduling on satellites like Hubble (HST) Projects like SPIKE  and ASPEN . Those are examples of many-to-one scheduling system s and we have been looking around for implementations that would be similar to our proposed one. Unfortunately we haven’t found anything closely related, thus we are building the Network part from scratch.
Given the expertise of our software people, we are building the application part on Django (python), and relying on rest APIs for communication with our ground stations. The first iteration of the network will be focused on a client-pull approach (versus a server-push) to eliminate any network restrictions.
Our challenges towards the global network are interesting. Given the data-heavy approach of the network (imagine all observations from all stations stored and indexed) we expect data storage to be a serious challenge. We are evaluating deep-storage as an approach to this, and we welcome any feedback or ideas around that.