Thursday March 25, we took SpeedBall-1 to the brink of flight, and it kicked and screamed all the way to the launch pad. This was the first launch attempt by the White Star team, and they performed fantastically. We are correcting the issues and will be attempting a launch again shortly!
We encountered a slew of problems, but through our months of training and planning, we already knew our options and flight impact associated with each hiccup we ran into. The massive communications infrastructure we laid out was revealed to those of you who watched on ustream, and facilitated our preparation and troubleshooting phenomenally well. I’ll detail our cool worldwide voice and video comm systems in another post though.
A ton of things went well, but the exciting bits are always the gory failures, so here they are!
1. Homebrew satellite coverage predictor program didn’t work
The day before launch we run an app that tells us how many gaps in sat service we should have, based on predicting satellite orbits. It said we’d have pretty much solid coverage for launch. In reality, we had very little coverage. That changes from hour to hour, and isn’t a problem if we know about it ahead of time. It severely delayed our departure from LVL1 Mission Control while we waited for a check of up and down telemetry, and caused an emergency rewrite of flight firmware to try to deal with it better.
2. 5volt power bus stopped working when we hooked up the cutdown
Still before departure to launch site, It was discovered that there was no power on the 5v power bus. We determined that there were no flight critical items running 5v, and would just lose a lot of science sensors. Flight was cleared to go without 5v bus, but a last check by switching to the flight batt pack caused it to come back online, and switching back to ground power had it still online as well. We do not know what caused this anomaly and have not seen it since.
3. Gps would not stay locked in transport vehicle
Likely due to the proximity to the metal van roof, the GPS lock was a critical part of preflit setup while in transport. This must still be resolved or the setup steps reorganized to work around.
4. HF telemetry could not be verified in transport vehicle
Portable receiver was left behind, and there wasn’t any provision to verify it’s decoded data or GPS lock anyway. Should be adding an audio cable to allow decoding on the road using one of the laptops in the vehicle. May need to add a Mifi to the vehicle to allow HF telemetry to be sent to the Internet servers after decoding.
5. Mobile ground support battery pack had a cell rupture in transport
A D-Cell was found to be inserted backwards in the 12-cell series string of batteries, and was violently boiling over under the multiple-amp drain of payload setup. The cell was removed, halting payload setup near the end of the procedure. Very little was left to do, and was continued on the launch pad using flight power.
6. Cutdown device fired on launchpad
The rope was cut, but since the payload was sitting on the prep stand, it did not fall. The unexpected cut was due to the long power-off period of the payload. The flight computer’s software was never designed to have power removed for more than a few seconds during the preflight phase. It went bonkers and issued every command it was capable of. We painstakingly restrung a new rope through the cutdown and proceeded.
7. HF Backup tracking radio’s GPS would not pick up any GPS signal
This was recently determined to be caused by the GPS located too close to the HF transmitter circuit board. It is easily movable and works fine now only a few inches farther away.
8. Primary sat telemetry antenna failed to receive strong enough sat signal
No up or downlink telemetry was ever passed to/from the payload on the launch pad, which is a required milestone to fly. We are working on a new antenna design now.
Note: Running into this many problems should have scrubbed the launch sooner for a normal program launch. However, as Project Lead, with much experience in large balloon launches, I recommended pressing on as far as we could get with on-the spot troubleshooting. The reason for taking such a seemingly cavalier stance though was twofold- we needed to press as far into launch as we could to uncover any FURTHER problems, and to try out our launch procedures to see how they worked in a real launch environment. There was also a slight chance that we could overcome all problems found. So we proceeded, and we did uncover very necessary data to improve the payload and procedures.
Hope you enjoyed being along with us from home!