Rocket Development Environment

This is the story of when I built an advanced rocket engine static test system / development environment.

Upon having decided to do it, the studying began around late April 2017.

2017-05-06 17.07.02.jpg

Study followed by system design, consulting friends and friends of friends for their rocket expertise and safety inputs…

2017-05-14 12.28.04.jpg

System design followed by detailed engineering, testing & fabrication…


Followed by buying materials…

2017-05-16 08.20.03.jpg

And tooling…

2017-05-17 18.57.01.jpg

Having acquired all the instrumentation, I began the software development process.

I love doing software development first, because the iteration cycles are hyper-fast, giving you confidence and the right mindset to move on to hardware.

2017-06-09 23.42.21-1.jpg


A key decision was to go with a graphical user interface (GUI) for the test system. The idea is that a GUI speeds up the actual rocket engine development, because data can be visualized and analyzed immediately.

2017-06-10 08.51.04.jpg

After completing the GUI, I hooked up a router to a Raspberry Pi 3, to 3 Arduinos, analogues for the system which would ultimately do data acquisition and control.

Working day…

2017-06-14 10.26.11.jpg

And night…

2017-06-20 21.15.14.jpg


Once the software was squared off, I proceeded to disassemble the test stand I built for electric aircraft engine testing, and paint it white (mainly for rust-proofing but also style)!

2017-06-21 13.33.36.jpg


A key component in the test system is a manually controlled override controller. Best not to trust Windows to safety critical systems… Best to built those from scratch and have ultimate control.

2017-06-26 14.31.30.jpg

This unit, dubbed HACS (Human-controlled Analog Control Station) has (left to right) a:

  • Controller Voltmeter
  • LCD screen for status
  • Guarded ARM switch
  • STOP button
  • Fire suppression toggle switch
  • (Later added: RSSI meter)

2017-06-26 16.19.10.jpg2017-06-26 12.02.05.jpg

The primary frame was 3D printed out of PLA, and then Aluminum was used extensively to beef up the structure.

2017-06-26 09.05.50.jpg2017-06-26 06.33.22-3.jpg

By the end of the 1-day build process (spent all night printing and soldering)…

2017-06-29 20.30.25.jpg

It was done! Pretty isn’t she? I eventually decided to scrub the LCD screen for time.

2017-06-27 12.39.54.jpg

Initially tested with a Raspberry Pi…

2017-06-27 12.03.20.jpg

Eventually a LoRa controller established the wireless connection between the main test control board (ADCS) and the HACS.

2017-07-02 12.04.00.jpg

2017-07-06 17.40.14.jpg

Awwwww yeaaa! Gorgeous!

2017-06-29 20.31.12.jpg

Further electronics engineering ensued – mainly to drive the 4 relays required for the system (more on those later), as well as instrumentation level shifting, acquisition, and logging.

2017-07-01 18.10.24.jpg

This alien-like structure was the optimal shape for fitting the Pi3 and Feather LoRa into the ADCS box (seen in a previous image)

2017-07-01 19.20.16.jpg

Picked up this massive case at AllElectronics for housing electronics and protecting them nearby the test stand.

2017-07-05 10.58.08.jpg

Of course, had to paint it white!

2017-07-05 21.30.23.jpg

Installed the instrumentation interface, as well as the high power connector version 1. A more water-safe version of this was later designed.

2017-07-06 18.48.25.jpg

Here the test stand is in it’s “version 1” test configuration. The HVAC tubing acts well as a flame duct.

2017-07-13 17.42.12.jpg

This is the fire suppression hose. A solenoid controlled by a 12V relay, which in turn is switched by a high power transistor, in turn switched by the primary control microcontroller. Two hose nozzles pointing in the key directions provide water suppression. The only worry, is that in a power outage, all fire suppression is lost (a problem fixed later on)

2017-07-14 16.45.05.jpg

Initial tests

To shakedown the system and help out a friend, Joe Barnard of, I ran 4 Estes F15-0 solid motors, mainly looking for thrust profiles.

A series of videos [1, 2, 3, 4] on my YouTube channel capture the system in use. Data from these tests can be found for free in the description box of each video.

A robust series of procedures and checklists were developed to operate the system, and I particularly trained all emergency procedures prior to each test. Safety trumped literally each and every decision. With that said, iteration between tests took approximately 1-2 days (a problem fixed later).

These shots show the GUI and HACS working together, as well as the work station / mission control after one of the solid motor tests.

2017-07-15 21.35.45.jpg

2017-07-18 20.54.31.jpg

2017-07-18 20.55.36.jpg

I photographed and inspected each fuel grain prior to each test.

2017-07-14 16.47.17.jpg

Ignitor in place (ignitor holder designed by Joe Barnard)

2017-07-14 16.49.53.jpg

I love seeing the charred ignitor holders… They’ve been through hell and back!

2017-07-18 19.44.40.jpg


Immediately after these tests I joined my family on a vacation in Yellowstone. Some pretty pictures! This turned out to be a good time to consider what to revamp in the test development system.

2017-07-19 14.35.56.jpg2017-07-22 13.35.54.jpg

Rocket Development System Version 2.0

After about 3 weeks developing GFOLD Python, I got back to the improvements in the rocket development system.


  • Redesign the test GUI for ease of use and simplicity. (video)
  • Clean up the wiring and make all critical system wires low strain and high reliability
  • Add a secondary electrical bus (in addition to the main 12V supply)
  • Implement current shunts to measure the current load on the 12V electrical buses
  • Redesign the power interface, and generally all interfaces in the outdoors to be waterproof or at least water resistant
  • Build a backup, battery powered fire suppression system (dubbed “F2”), in addition to the primary one. This system MUST be 100% seperate from the primary system
    • Separate laptop for actuation, on the more reliable Ubuntu Linux
    • Separate, isolated network for control signals
    • Separate power supply (battery)
  • Build a nitrous oxide tank instrumentation unit
    • Pressure instrumentation
    • Temperature instrumentation
    • Wireless to reduce number of extraneous connections and allow movement of nitrous tank.

2017-09-03 13.26.32.jpg

2017-09-03 13.26.46.jpg

Redesigned power interface, with a rubber seal and properly oriented power terminals.

2017-09-06 17.32.47.jpg

2017-09-06 19.34.57.jpg

The redesigned instrumentation interface. Green chips are load cell amplifiers, blue chip is the venerable Arduino Mega.

2017-09-09 16.35.40.jpg

Used a 100% waterproof circular pin connector for the updated cable of wires going to the test stand.

2017-09-09 16.36.32.jpg

2017-09-10 14.05.29.jpg

The IU (Instrumentation Unit), name borrowed from the Saturn V, houses all on-test-stand electronics in a water-resistant housing

2017-10-12 10.02.18.jpg

2017-10-12 10.24.09.jpg

This is the nitrous oxide instrumentation unit. Inside is a thermocouple amplifier, plus two level shifters (one up, one down) for converting everything into usable voltages for the 3.3V Adafruit WICED board. It sits in a custom 3D printed housing with a LiPo battery underneath.

2017-11-01 10.38.57.jpg

Some physical upgrades were also made, such as using U-braces for the cross-brace element.

2017-10-11 17.52.07.jpg

Also, dug the flame duct into the ground for easier test stand securing and transport.

2017-10-03 11.09.08.jpg

2017-10-03 11.16.06.jpg

In one shot, this is the test stand hardware during a night test of a hybrid rocket motor.

2017-11-15 20.34.48.jpg

2017-11-15 21.21.11.jpg