A little over a week later we returned to the test site, once again ready to test the PSCC. This time we were better prepared, bringing with us a wider selection of tools and an upgraded battery charger that could charge the FTS’s (Flight Test System) battery much faster. While originally we planned to fly only a handful of tests, it quickly proved apparent that many more tests would be needed, as each test revealed more issues with the PSCC (Parachute System Control Computer). As the day wore on we quickly fell into the following pattern.
The first step of each test run was the flight. The PSCC, mounted in the PTP (Parachute Test Payload) would be loaded with the newest version of the code and then the whole PTP would be attached to the FTS. After both the PTP and FTS were powered on and confirmed working, the FTS would take off, starting the test flight. The flight profile of these tests were simple. The FTS would lift the PTP about 50 ft off the ground and hover for a moment. Then it would ascend to ~300 ft. After another brief pause the FTS would then descend and land. This profile was designed to replicate the altitude changes the PSCC would experience during a drop test, as during such a test the payload would be raised to a high altitude and then dropped.
After each unsuccessful test the cause of the failure had to be found and fixed. To find these failures we relied entirely upon telemetry that the PSCC logged to an SD card during the test.
Time = 19:46:52
GPSAltitude = 166.55
APAltitude = 312.72
AltitudeDifference = 146.17
TriggerState = 0
Speed (knots)= 0.65
Angle = 170.79
Altitude Above DeployAltitude ft
Difference Value Nominal
Pictured above is a small section of this telemetry. The above data shows the current altitude that both sensors are reporting (GPSAltitude and APAltitude), the difference between those two values (AltitudeDifference) and if the PSCC as been armed or not (TriggerState). By comparing how the code was expected to operate and how it did operate we can determine what likely caused the discrepancy. For instance in the above example the PSCC is reporting that it has armed, yet the TriggerState = 0, meaning that it has not actually been armed. This suggests that we need to investigate the code that relates to arming the PSCC, as that is likely what is causing this problem.
Fix and reset
Now that the problem was identified, we had to fix it. Almost all of these fixes were relatively minor, with some only requiring the changing of a single line of code. Once this fix was implemented, we could then start preparing for the next test flight, by uploading the new code to the PSCC, resealing the PTP and reattaching it to the FTS.
We would perform a test, recover and analyze the data, make the needed changes and repeat. The FTS battery has the capacity to perform 2 flights before needing a recharge. Recharging took approximately 20 minutes. All in all, we were able to perform roughly 2 tests every hour. With each test we completed and each issue we solved, the PSCC grew closer to being fully functional.