The PSP Satellite team decided to use this payload opportunity to test our manufacturing capabilities, how our frame design would hold up structurally, and if a dampener could be beneficial on launch. I was in-charge of setting up the onboard data sensing suite. This payload opportunity was under extreme time constraints. The initial prototype/proof-of-concept had to be built in 2 weeks and the final flight units were due 5 weeks after that (It was really more like 4 weeks because of Final Exams and moving at the end of the semester). Because of this, I elected to go with a COTS module-based approach, using modules I have had previous experience with, as a general design philosophy.
After brainstorming with the PSP Satellite Structures, Mechanisms and Thermals (SMT) sub-team, we decided to have 2 types of sensors: 9-axis IMUs and Strain Gauges. The IMUs would be affixed at various locations on the satellite frame to analyze if the different parts of the frame were moving as a single body, and if our dampeners made any difference. The Strain Gauges would be used to see any flexing in the walls or end plates.
Team at the Practice Launch!
For the prototype, I was on a short timeline. This meant I wasn't going to be able to prototype the full system. I decided to delay the implementation of the strain gauges and instead focus on having the IMUs and data recording up and running. My main reasoning for this was because I have a decent amount of experience with Wheatstone Bridges and the HX711 precision ADC I planned to use, as well as my fear of the wiring mess the strain gauge set-up would make as I didn't have enough time to order any custom PCBs. In hindsight, this omission would lead to my strain gauge integration problems when adding them to the system. I used an Arduino Nano to control three IMUs and record data to a MicroSD card. The Arduino Nano was chosen because it was the microcontroller I felt most comfortable using, again especially with the short timeline. However, I planned to replace it for the final flight unit. The three IMU modules had to be controlled and wired using SPI and not I2C because the modules are set to the same address. And the MicroSD Card Adapter was wired to the same SPI bus. For the test flight, the IMUs were set on the dampened mass, the central bulkhead plate, and the main board.
For power on both flights, I just used normal AA alkaline batteries. The battery packs were given enough capacity to run the system for a full day and a half. This was done based on the Spaceport Launch team's procedures and the fact that no one who worked on the electronics with me would be at the final launch. A simple power switch with a blinking LED seemed like the easiest thing to communicate effectively to the launch team. An important note, in the competition, the payload couldn't be physically accessible from the outside of the rocket, so the payload had to turned on upon final integration into the rocket. Additionally, I didn't set up any sleep mode which would have greatly improved the power efficiency due to the desire to have detailed data of the immediate launch shocks.
The prototype was tested with a full trial flight. On this flight, the recovery system malfunctioned resulting in a few thousand feet of freefall. On impact, the payload mounting system failed and the satellite smashed into the nose cone, impaling itself on the central mounting bolt. The alkaline batteries were pierced and, as can be seen in the pictures below, there was no data to be recovered. While no sensor data was recovered, it was really fun to launch and recover the rocket as well as analyze all the ways the system failed!
The design of the final flight unit had some major changes from the prototype design. First of all, I added the strain gauges and added five more IMUs. For the strain gauges, I initially hoped to add a bunch of strain gauges, but at integration they became physically problematic to mount and test. This led to only two quarter-bridge testing locations to be implemented on the bottom and bulkhead plates. The additional IMUs were quite simple, I just added them to the SPI bus. The biggest change was swapping out the Arduino Nano with a Teensy 4.1 to deal with the higher processing load of and the higher clock speed needed due to the additional sensors. It having an integrated micro SD card reader also was a factor. Lastly, I had enough time to create custom PCBs which made integration of the board stack a lot easier and more reliable. Those changes being said, I didn't change the alkaline battery bank power system, with the exception of new mounting boards.
With the exception of the strain gauge physical integration I mentioned earlier, there were only two real issues that arose during system integration. The first was the comical wiring that had to be done to get the SPI bus lines to the various IMUs that you can see in the right-most picture below. I really wish I had more time to develop my own IMU module or determine how to edit the IMU module so I could have used I2C (Each sensing module has the same address). This issue was "solved" by a lot of man-hours soldering everything together and testing as I went. The second issue was more problematic. When all the devices were integrated the SPI lines would not work consistently. Being on a major time crunch (a day before needing to hand-off to the rocket integration team), I did a quick analysis of the problem and brought in a few Electrical Engineering friends to help. We deduced, with no certainty, that the issue was probably how long the SPI lines were. We think the lines were acting like capacitors, slowing the charging and discharging the bus lines or power lines. To counter act this issue, I removed the two IMUs with the longest connector lines (In hindsight, I probably could have add a large resistor to held discharge the line, but I didn't think of that at the time). With the improvements and integration troubleshooting, the payload had 6 IMUs, 2 strain gauges, and a microSD card to store data.
On the final flight, the recovery system again malfunctioned, resulting in a few thousand feet of freefall of just the nosecone with the payload inside. On impact, the payload mounting system held, however the payload did not hold up well to the shock. One note is the corner rails had to be removed in order to fit the satellite in the new payload mounting system, which made the payload structurally weaker. The walls were extremely deformed, which caused our power switch to break and the wires to the IMU on our bottom plate to be cut. The cut wires in the top-right picture below was not intentionally cut, the wall pinched them! Additionally, the structures team, last minute, switched to using carbon fiber reinforced 3D prints to use as board spacers. While these did support the loads at impact, the boards, presumably on the edge closest to impact, could not take those forces. The boards exploded out & delaminated as can be seen in the pictures on the right. The control board also cracked down that edge. No data was recovered.
While this project was a failure with no payload data collected at the end of the day, it was still an incredible experience for me! Most of my college experience has been focused on satellites, and it was really great to learn a bit about rockets and structures while rapidly prototyping electronics!