The Zenith Rocket’s most critical, and certainly most expensive, component is the flight computer. The flight computer is a custom circuit board containing all of the avionics required to guide and control the rocket, as well as outputs to drive the motors in the TVC gimbal. I’ve already made a post explaining the basics behind model rocket flight computers, which may be referred to for additional information on the general principles behind their construction.

This summer, I set out to design an improved, compacted flight computer centered around SMD components.

In case you didn’t know, electronic components come in surface-mount and through-hole (THT) mounting styles. A THT component has its contacts go, as the name suggests, through the circuit board. These components are easier to solder and handle, but are typically much larger than their SMD counterparts. Surface-mount parts (surprise!) mount directly onto the PCB’s surface, and as a result can be far more compact.

The bulkiness of THT pins means that more advanced modern ICs like microcontrollers and sensors rarely ever come in that style. This means that to have such components on a purely THT board, we use breakout boards, smaller PCBs that have the required SMD components pre-assembled, and attach to the primary circuit board through the required pins. This is not very space efficient. However, since the passives (the supporting circuitry around the ICs) are already taken care of on breakout boards, designing around them is much easier. SMD devices are also more difficult to solder, and traditional soldering irons will often not suffice for certain packages.

In order to compact the flight computer to fit within the ~ 47.7 mm diameter of the Zenith rocket, I knew that a fully-SMD board was the only option.

Shown above is Revision 1 of the Horizon flight computer. At the heart of the board is an MK20DX256VLH7 microcontroller, running at 72 MHz. The chip has 256Kb of onboard flash memory for program storage; this is much more computing power than the guidance software needs. It also sports an impressive amount of general-purpose input/output pins, visible above in the various header pins to each side. This chip is the same one found on the Teensy 3.2 made by PJRC, who kindly provides schematics for all of their microcontrollers.

For the Inertial Measurement Unit (IMU), the sensor which provides orientation and acceleration data, Revision 1 had a 9DoF Bosch BNO055. This IMU is precise, but somewhat suboptimal. This is because a primary feature of the BNO055 is its ability to perform sensor fusion: combining accelerometer, gyroscope, and magnetometer data together through a Kalman filter, using an onboard processor. This increases the complexity of the circuitry, and the additional pins required for this makes soldering difficult. Furthermore, sensor fusion is useless in this case, since the massive acceleration spike during launch is likely to throw off accelerometer values. I chose the BNO055 initially due to experience working with it previously.

The barometer, the sensor which measures atmospheric pressure (and converts this to altitude), is the MS5611. This sensor is very accurate, but above all very friendly to solder.

Apart from this, the board has an onboard flash chip (a Winbond W25Q32) and a micro SD card receptacle to log flight data. The micro SD allows for convenient extraction of files, while the solid state flash chip serves as a backup in case the SD card is disconnected at any point during the flight. Data logging capability is crucial, as it allows for anomalies to be diagnosed and flight performance analyzed.

Beyond this, the other important function of the flight computer is driving the TVC mount’s servo motors. While some recommend using a buck converter for the power supply as it much more efficient, I have never found simple linear regulators to cause issues with overheating, especially given how short flight durations are.

Being my first time working with SMD parts, and designing such a complex circuit in general, the process was far from smooth.

As you may be able to tell from the strange segment of wire bridging the “on” pad to an adjacent one, the first issue lay in the power switch. I foolishly assumed that DPDT switches, when set to a position, created continuity across that row, instead of along the column with the middle pin. This resulted in the switch being wired up incorrectly. The segment of wire you see was my makeshift solution to this, connecting the correct set of pins together; of course, this means that switching functionality was lost, and the board could only ever be on when connected to power. Still, the remedy was necessary so that I could test the other functionalities of the computer. As a side note, you may recognize that such a small surface-mount switch would almost certainly not be rated for more than 1A, meaning the current draw from the servos would likely fry it. To circumvent this, the switch controls a MOSFET, capable of far higher currents, through which the full current runs.

Also to my dismay, the library I used for the Micro USB AB receptacle gave the incorrect mapping of pins (the order was exactly flipped, actually). This, however, was an easy workaround: I discovered that upside-down USB receptacles exist, and simply installed one such component to reverse the connections.

Once the previously mentioned repairs were implemented, the microcontroller, to my great relief, functioned largely as intended (though with one caveat that I still have yet to fix). It was is a different story for the sensors. When I first checked the I2C (a communication bus allowing devices like sensors to interface with the microcontroller) addresses, I discovered that the microcontroller could find neither the IMU nor the barometer. I initially thought it was an issue with the design, but could not isolate any problems with the I2C bus. I connected an external I2C sensor breakout using the header pins, and found that it worked. I become suspicious that it was a soldering issue, and resoldered the sensors. The MS5611 (the significantly easier one to solder out of the two sensors) suddenly came online: the fault was indeed in the solder joints. I could never make the BNO055 work, however, since its package was far too difficult to solder without the aid of a solder stencil, which I could no longer use with the board populated. However, somewhat confident that the design was sound, I decided to move on to the next revision.

Revision 2, first and foremost, fixed the previous issues with the power switch and USB port. Minimal changes were made otherwise, apart from the IMU; the BNO055, disadvantaged as previously described and a challenge to solder, was simply not the ideal choice. I swapped it out for a BMI088, a 6DoF sensor with similar accuracy but lacking the onboard sensor fusion capabilities and magnetometers, reducing the pin count. Here, I made another mistake. Not having a BMI088 at hand, I decided to test the R2 board using a BMI055 instead, as they had the same exact pinout and application schematic. This time, both sensors were detected by the microcontroller. However, I quickly realized that, being a deprecated component, the BMI055 did not have any Arduino libraries written for it. I could not get the BMI088’s library to work with it, and I was not about to create my own library to interface with the sensor, which I simply do not have the skillset for. And with that, I waited a few weeks for a few BMI088s to ship from China (a necessary detour given the current silicone shortage), and sought to replace the BMI055 with it. This also turned out to be a lot of work, and resulted in me transferring the contents of the board to a completely fresh one, so I could reapply a precise layer of solder paste using the stencil. Finally, the sensors were completely functional.

After much tedium, all of the important functionalities were finally achieved. However, when using connecting an analog pin of the flight computer to a thermistor before Zenith’s first TVC static fire test (I had wanted to log temperature data to determine whether the motor tube needed extra insulation), I realized that the analog reading was dysfunctional. Instead of a smooth signal, it returned a bizarre square wave (not even the 10-bit resolution was correct, with the highest reading exceeding 1024). I discovered that this anomaly was not limited to one pin, as all analog pins displayed the same behavior. I then tested Revision 1 board, which also shared the problem.

Currently, I believe the issue lies in the analog-digital converter (ADC). This is a module within the microcontroller, which translates smooth analog inputs to the discrete, digital language of computers. What exactly caused it, however, I am not sure. Analog inputs are, surprisingly, not crucial to flight: the sensors and data logging components communicate using either I2C or SPI (Serial Peripheral Interface), while writing to the servos is done through PWM (pulse-width modulation). However, I still wish to resolve this issue, as analog capability adds more flexibility.

This about sums up the progress I’ve made so far on the Horizon flight computer. Thank you for reading!