# Robust and Reconfigurable On-Board Processing for a Hyperspectral Imaging Small Satellite
## 5 Discussion, Future Work and Conclusions  
The design principles after which HYPSO-1 was designed were presented in Section 3.1. On-ground tests showed the resilience against faults via integrity and redundancy; however, there has not yet been an in-orbit event putting this into action. While the system is designed to be redundant, there is still one design flaw through which a single-bit error can break the OPU, which is in the FSBL. This is work in progress and will be addressed in a future publication. As discussed in [32], further on-board processing algorithms are planned and will be uploaded to the satellite and tested. The next ones are RGB composite/thumbnail generation, georeferencing and segmentation using SVMs and binary decision trees. As HYPSO-1 continues to generate data, the potential for the successful training of machine learning models and implementation for on-board processing on HYPSO-1 is increased. Sensor calibration represents much of the work undertaken by the team since launch [36], in addition to identifying methods to succesfully optimize, automate and schedule the operation of HYPSO-1. As we move on to the next phase in the mission and integrate software updates and reconfigurable on-board processing pipelines in the operation, similar work on learning how to operate the satellite optimally is likely required. A future update to the main application will include on-sensor subsampling in the spatial dimension of the sensor (see Table 3) to enable higher frame rates at a sensor resolution of 1080 \(\times\) 1194 or similar at the expense of across track spatial resolution, but without losing spectral resolution. The average number of daily images can not exceed about 5-6 images. Otherwise, there would be more images recorded than there is capacity to downlink with a single ground station. Thus, the energy use per orbit varies depending on whether an image was recorded during that orbit. However, it is possible to determine the average energy use per orbit. The payload uses about the same amount of energy as when recording a single image. When assuming 5.5 images per day, 2.16 Wh per image recording (Table 9) corresponds to an average daily energy use of 11.88 Wh. With about 15 orbits per day, the HYPSO-1 payload uses about 0.79 Wh per orbit. Comparing the in-orbit measured power draw numbers (Table 9) with the previous estimations in Table IV of [32], reveals the previous estimations to be overestimates. The power use of the OPU does not differ much between buffering and software compression (Table 9). The most power can be conserved by reducing the time spent in phases 3 and 4. The time spent in phase 3 can be drastically reduced by implementing compression for multiple capture modes on the FPGA. The most energy can be conserved by optimizing phase 4. This can be achieved for example by updating the on-board compression algorithms that feature higher compression ratios and thus reduce data volume. For example, using lossy compression methods or dimensionality-reduction-based algorithms. Based on \begin{table}
\begin{tabular}{c c c c c} \hline
**Phase** & **Duration [s]** & **OPU [W]** & **HSI [W]** & **Energy OPU \& HSI [Wh]** \\ \hline
1 & 120.0 (3.87\%) & 2.35 & 1.20 & 0.12 (5.58\%) \\
2 & 45.0 (14.5\%) & 3.09 & 2.65 & 0.08 (3.70\%) \\
3 & 520.0 (16.76\%) & 2.35 & 0.00 & 0.34 (15.61\%) \\
4 & 2418.0 (77.93\%) & 2.43 & 0.00 & 1.62 (75.10\%) \\ \hline \end{tabular}
\end{table} 
Table 9: Overview of the mean power draw and energy use of the OPU and HSI camera during a single image-recording operation. Percentages indicate fraction of the total. downlinked highly compressed data, less than 5-6 images per day could be selected to be buffered to the PC and downlinked fully. This could increase the number of images that can be recorded per day, which would increase the average energy use per orbit. Most other missions outsource implementation of key payload components like PhiSat or HICO. However in HYPSO-1's case, the payload software is developed entirely in-house.