# Robust and Reconfigurable On-Board Processing for a Hyperspectral Imaging Small Satellite
## 4 Testing and In-Orbit Results
### Compression  
The cubeDMA and CCSDS123 IP cores have been verified by streaming data of size \(512\times 2000\times 128\) collected by HICO imager [7] for a variety of generic parameter cubeDMA and CCSDS123 values. The resulting processed data streamed by cubeDMA to and from the CCSDS123 core back to the memory have been successfully compared to the compressed data generated by the CCSDS123 reference software Emporda [73].  
The time taken for CCSDS123 compression is necessary to know for scheduling tasks on-board. Figure 10 shows the test results of compressing data cubes with varying dimensions. The compression time did not vary depending on data content, only depending  
\begin{table}
\begin{tabular}{c c} \hline \hline \(f_{r}\) [Hz] & **Bad Recordings/Total** \\ \hline
21 & 0/30 \\
22 & 0/30 \\
23 & 0/30 \\
24 & 3/30 \\
25 & 29/30 \\ \hline \hline \end{tabular}
\end{table}
Table 6: Testing recording consistency. A bad recording is one that contains dropped frames.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline \(f_{r}\) [Hz]/Mode & **1936 \(\times\) 1216** & **1080 \(\times\) 1194** & **1080 \(\times\) 684** \\ \hline SIMD Bin9 & 5 & 12 & 22 \\ SIMD Bin18 & 5 & 12 & 22 \\ SIMD Bin9 Sub 2\(\times\) & 9 & 20 & 36 \\ \hline \hline \end{tabular}
\end{table}
Table 7: The maximum nominal frame rate at different resolution and binning capture modes. Sub 2\(\times\) means on-sensor sub-sampling in the spectral dimension.  
Figure 9: Plots of the time interval between when the uEye daemon reports new frames to the main application (i.e., the delay between each frame). Colors indicate the capture repetition, where blue, orange, green, red and purple are respectively the first, second third, fourth and fifth capture in the capture set. Above a frame rate threshold, timings become very irregular, and dropped frames become a possibility.  
on data size. Notably, the nominal resolution of 956 \(\times\) 684 \(\times\) 120 takes about 398 s in software and 186 ms on FPGA. This corresponds to a decrease in throughput compared to the results in [58] from 750 MSa/s to 422 MSa/s. This is explained by overhead that is present when integrating an IP Core into a complete embedded system with a non real-time Linux OS. Further FPGA compression tests for different cube dimensions were performed by compiling multiple FPGA images corresponding to different cube dimensions, booting up the OPU, and uploading the FPGA images to the SD Card. The FPGA was reconfigured using the CLI service of the main application. The following empirical formula for software compression time is determined by observing the linear dependence on cube dimensions and fitting a likely expression to the test data in Figure 10a,  
\[t_{\text{sw}}=5.1\times L\times S\times B\]  
where \(t_{\text{sw}}\) is the time required for software compression in microseconds [\(\mu\)s], and \(L\), \(S\) and \(B\), respectively, refer to the lines, samples and bands of the data cube. This expression is successfully used during operation to schedule actions on the satellite when not using recording with nominal cube dimensions where fast FPGA compression is not currently possible.