We’re doing vacuum chamber tests of the FRETS1 satellite’s ion engine and building an embedded data collection system. Naturally, I want every nuance to every signal trace at several million samples per second on lots of channels. Even after being talked down to 4 channels, 2MS/s/channel, and 8 bit samples, it’s still a lot of data for an embedded system that must be the size of an Arduino in the prototyping stage and even smaller on the satellite.
Lots of and lots of searches later, it is clear we aren’t going to have that system. We’re going to have one better. To start with, the incoming data can be fed into a flexible triggering system and threshold events counted in small time slices. The data storage and sampling requirements are 3-6 orders of magnitude less for this approach, removing large amounts of add-on SRAM and engineering headache. The downside is that the data is essentially compressed in the hardware before it gets to the collection CPU. Now it gets interesting. Such data can be converted using the Compressed Sensing GPU library I presented at NVidia’s GTC this year. Further, the recovered signal can be modeled with an equation using Cartesian Genetic Programming (CGP). The equation is fit to the compressed data, the recovered data from the Compressed Sensing library, and to physical truths of continuity.
Admittedly that’s a lot of math for an embedded controller to be doing. However, we can build basic engine controls using just the compressed data. The engine controller will have even better data over time as the CGP and Compressed Sensing solutions converge. And that is what I mean by a “better” data collection system – it has a series of fallbacks needed for a space mission and still works just fine on the bench.