# Robust and Reconfigurable On-Board Processing for a Hyperspectral Imaging Small Satellite
## 4 Testing and In-Orbit Results
### Ethernet and Data Recording  
It was noticed that the Central Processing Unit (CPU) of the chosen SoC does not have sufficient processing power to record at the maximum advertised frame rates of the camera module.  
A number of factors made predicting the achievable frame rate of the camera system difficult, among these are limited CPU performance with respect to processing power and Input/Output (I/O) bandwidth, Linux kernel configuration or various system implementation choices. The proprietary driver for the COTS camera module was also a source of uncertainty. Knowing the achievable frame rate is important from an operational satellite perspective because it influences the ground resolution, the SNR and total recording duration. Thus, throughput and data-recording tests were needed to characterize the capability of the system.  
For throughput testing, nuttcp tool was used. The HSI camera was disconnected and replaced by a desktop computer. A single nuttcp test works by transmitting data packets from the desktop computer to an nuttcp server on the OPU at a specified constant data rate for a specified duration of time. nuttcp tracks how many packets are received and how many are dropped and reports the results. Many single tests were repeated while varying the transmitting data rate. Three test sets exemplary of the Ethernet performance are shown in Figure 8, consisting of one sparse test varying transmission rate from 140 Mbit/s to 500 Mbit/s in 20 Mbit/s steps and two dense tests with smaller step sizes. This testing found throughput to drop in reliability at around 260 Mbit/s, which is about a quarter of the theoretical maximum speed of the physical link. This means to achieve the maximum advertised frame rate, the number of pixels that is being read out from the sensor must be reduced to a quarter. This motivates the choice of nominal dimensions 1080 by 684 pixels as described in [32].  
Testing the frame rate capacity of the system was done by storing software timing information during capture. By comparing this to hardware timing information from the time-stamping module, it was determined how many frames were dropped, indicating that a bottleneck is limiting Ethernet throughput. Additional frame rate testing was necessary because the throughput tests alone were not a reliable predictor of frame rate capacity at different configurations.  
As Linux is not a real-time operating system, data recording performance is inconsistent. An accurate picture was achieved by experiment repetition and averaging over many samples. Individual capture tests were repeated to determine performance statistics. Capture repetitions were performed in sets of 5. Each set had a given frame rate and resolution. The OPU was rebooted between each set. Figure 9 shows the data gathered from an example run of three capture sets at, respectively, frame rates 23 Hz, 24 Hz and 25 Hz. The plots show the time between frames measured in software. All captures were at nominal resolution of 684 samples by 1080 bands and recording 500 frames. The ideal plot in a system without bottlenecks would show perfectly regular times, meaning the time  
Figure 8: Figure showing packet loss percentage at various data rates.  
between frames is very close to \(\frac{1}{f_{r}}\). This is almost the case in the top plot of Figure 9 when recording with a frame rate of 23 Hz. This capture set shows almost consistent values of around 43.5 ms, with one anomaly in one recording near frames 440-450. A further test sequence was done over 30 captures for each of 5 different frame rates from 21 Hz to 25 Hz. The number of captures for each frame rate contains dropped frames is shown in Table 6. For safe overhead, the maximum nominal frame rate of 22 Hz was chosen, even though 23 Hz did not show any captures with dropped frames during testing. This method was repeated for more sensor resolution and binning modes to determine their nominal frame rates shown in Table 7.