Introducing Night Sky Pi

This is the initial post to kick off the night sky pi project officially. There have been a few false starts in the past, and I thought to myself I want to restart the project with a clean slate. So might as well start it as early as possible to give myself the best chance of completing it. The project will be hosted on Codeberg as part of the Night Works Organisation.

Project Restrictions

So this project has some hardware restrictions so it is accessible to everyone. The limiting factor would be the compute module, which in this case is the Raspberry Pi Zero 2 W. The reason is that this module only costs £15 and can be easily found compared to other Raspberry modules.

The camera has also been restricted to the Raspberry HQ Camera for a similar reason, as it’s affordable compared to other camera systems, and easily found.

There are issues with the above hardware which is that they are not the most powerful or best hardware out there. This means that there will be limitations in the design and software. For example, the night-sky-pi will not process the data that has been captured. This could prove too much for the low-powered chipset to handle and could easily overwhelm the onboard memory. Therefore this device will be purely responsible for data capture only, with the data being packaged for processing elsewhere.

Overview Design

The boundaries of the software responsibility are rather straightforward, with the processes during the running clearly stated and having a single role to complete. Let’s walk through the below flow chart.

The software will be written in Python, and installed to the compute as a system service to start on boot. When the software starts it will perform a system check. This would include checking that the camera works and that there are correct properties for the location and storage of data. Next would be the loading of the configuration so that the values are ready for other sub-processes.

Based on the configuration it will check with the location and time, if it’s supposed to be capturing images, for the initial version this will be from sunset to sunrise the next day, with future enhancements to allow configuration of this period. If found to be within the capture period then the camera will be initialised to capture an image that is saved. Once the image is saved the image quality will be checked to see if the exposure values need to be modified for the next image. Then the process will check again if still within the capture time, and the process loops until this isn’t the case.

If we’re not within the desired capture period, for example between sunrise and sunset then the next task is to package the data that was captured. This could simply be zipping up the directory that has all the images and metadata for each image, along with a manifest file to describe all the parameters and settings for the observation period. Once this data has been packaged then a check will be carried out on what to do with the data. For the initial version, two options would be to either keep the data locally or transmit the data to another location via FTP or AWS S3. Once this is done then the check is carried out for the capture period and the process continues.

There could be another step here if we are out of period and there is no data to package or transmit then we just sleep until the known next capture period and attempt to go to deep sleep to save power. This might give us the option to allow solar/battery power operation.

Next Steps

Firstly I need to prepare the repository and the readme file. But for the software, I’m going to be working on the system check and configuration followed by the big loop that triggers each stage to build a structure of the flow before working on the functionality of each section. I feel that this is the best approach to ensure that the usability is correct before focusing on the details. You can follow this project on either Codeberg.