RockSat-C is a fantastic program sponsored by NASA that allows students from universities around the country to work on a real-world engineering problem by designing a scientific experiment, building a module that can collect data, and finally integrating it into a rocket. The project is built over the course of two semesters, and the rocket is launched in the summer at NASA’s Wallops Flight Facility on Wallops Island, Virginia. My school works with the New Jersey Space Grant to acquire funds, and the rest is up to the students to construct a hypothesis, design an experiment, and build the electrical hardware and software to make it happen. Our Experiment In 2015-2016, my team worked with Professor Parziale at Stevens to analyze aerodynamic boundary layer effects of high speed vehicles and rockets. In essence, as the rocket cuts through the air at around Mach 4, there is a distinct boundary between the stationary air molecules that hug the outside of the rocket, and the fast moving air molecules further from the surface of the rocket skin. We were interested in the transition between these two layers, and how oscillations manifest themselves on the outside of the rocket as a function of rocket speed. This research has potential applications in the construction of stronger materials for building rockets, as well as reducing friction between the air and the rocket. To analyze the properties of the boundary layer, we wanted to analyze any high-speed pressure fluctuations that occurred on the rocket skin. To do this, we mounted a small pressure sensor in an aluminum block called the Port, with the face of the pressure sensor flush with the rocket skin, directly exposed to the elements. We also needed to create a data acquisition unit (DAQ) capable of 2MS/s (2 megasamples per second) with a 16-bit resolution. That’s a lot of data, generating 4 MB/s (read: 4 megaBYTES per second), and this data needed to be collected for a 3 minute duration. I designed the DAQ hardware, and worked with another student to create the software to capture this data.   Figure 1. The Port, which housed the pressure sensor (to be mounted on outside of rocket) DAQ Technical Details 1. Hardware Designing the hardware was a lot of work, from component selection, choosing which microprocessor to use for the system, designing the schematic, and finally building a hardware prototype. We opted to build using a general-purpose PCB and solder everything by hand, just in case we needed to make major changes to the system.   Figure 2. DAQ Circuit Board. On left: Beaglebone Black; on right: ADC, power supplies, analog signal filtering Figure 3. DAQ Testing in the Lab 2. Software This is where things got quite difficult. While it was fairly straightforward to get the ADC to crank out samples consistently and without error, the real challenge lied in shoveling 4 MB/s of data into memory fast enough to keep up with sample generation. Unfortunately, we failed to do this consistently enough to make any data collected very meaningful. We had multiple options for data storage: We could have written to the SD Card, Flash Memory, or the internal RAM on the Beaglebone Black. While SD cards are often advertised with write speeds in excess of 10 MB/s, it is actually quite difficult to attain these speeds, and we found that we could not get the Beaglebone to write 4 MB/s onto our Class 10 Ultra High Speed SD card. This may have been an issue with the Beaglebone’s implementation of the SD interface, or it could have been an inefficiency in the way we attempted to write to the SD card. To circumvent this issue, we ultimately wrote all of the data for the entire flight into the on-board 512 MB of DRAM on the Beaglebone, and once the experiment ended, transfer this data from the RAM to the SD card. This allowed us to achieve the speeds necessary, although 512 MB of RAM was not quite enough to store the entire 3 minutes of sample data. The code was ultimately written in C and executed on the Linux CPU, although as we quickly learned, Linux is not necessarily a real-time operating system (unless you are running FreeRTOS). This ultimately meant that our sampling rate was somewhat inconsistent due to the overhead of the operating system sometimes interrupting the execution of the program. It would have been much more ideal to utilize the Programmable Real-Time Unit (PRU) on the Beaglebone, which are high-speed microcontrollers clocked at 200 MHz that have access to the shared memory on the Beaglebone. This would have made sampling much more consistent and much faster, but time constraints near the end of the build did not allow for this development.   Results We ultimately failed to collect useful data from this launch, but not because of the memory issues we encountered. Rather, the simplest of errors caused the DAQ to begin sampling at the incorrect time. When the rocket was on the launch pad, a T-3 minutes signal was sent from the rocket’s main flight computer to turn on our DAQ 3 minutes before the flight. This would allow time for our Beaglebone Black computer to boot and initialize itself before the launch. In our code was a delay statement to wait for 3 minutes, and then begin sampling. A problem occurred in which the necessary timing library to perform the wait function did not load properly, so the code threw an error an simply skipped over the wait command. This caused the DAQ to begin sampling 3 minutes before the launch occurred – and because we only collected data for a 3 minute window, all of our data was collected while the rocket sat on the launchpad. Figure 4. The completed Stevens module, complete with our DAQ, battery system, and our school’s second experiment, which involved analyzing plastic extrusion in micro-gravity. Figure 5. The canister, which held the Stevens Team’s module on top, as well as a Colorado Team’s experiment on the second half of the canister. About 13 of these canisters were stacked and bolted together to form the payload section of the rocket, and a rocket skin was mounted around these canisters to protect them from the elements. Lessons Learned “Test like you fly, fly like you test.” In systems like these where there are many integrated systems, from a power subsystem, an analog signal conditioner, and a digital data acquisition system, everything must work properly, otherwise the entire mission fails. We spent incredible amounts of time working on the digital subsystem, ironing out details in the sampling code, but it was ultimately a very simple error that resulted in mission failure. 20% of your work creates 80% of your results, and likewise the other 80% of your work only results in 20% of your results. Had we spent more time testing our systems more rigorously and in a more structured manner, we could have greatly improved our probability of mission success.