Table of Contents
Power Distribution System IntroductionPower distribution initially described, quite literally, the method by which electric power is distributed to the system. Because the final system requirements were still being developed (and changed many, many times through the project), it was not known at the start of the project what this system would come to encompass. As time went on, the scope of "power distribution" came to envelope all electronic hardware systems developed for the project.
Special thanks for advisement on this part of the project goes to: Martin Pepe, Mark Indovina, Carlos Barrios, Mark Saunders, and Dorin Patru.
Design of this subsystem was handled by Ryan Chojnacki. firstname.lastname@example.org
The initial subsystem requirements for power distribution called for the following:
- A battery with sufficiency voltage, amp-hours, and discharge rate to power all components of the flight engine
- A charger capable of communication or monitoring with/from the engine controller
- A circuit that distributes power to all the components, including voltage regulation or conversion as needed
- A rechargeable battery that is light-weight, i.e. a lithium-ion battery.
The final results included:
- A 14.8V, 20A max lithium-ion battery
- A 4-layer PCB including:
- A charging circuit with a path for monitoring by an ADC on the microcontroller
- 3.3V 1A, 5V 1A, 5V 1A, 24V 2.5A, 24V 2.5A power domains through conversion/regulation
- Extra pins for back-up 3.3V, 5V, and 24V supplies
- Integrated ICs for all sensors, including thermocouple ICs, a transceiver IC, and valve control power FETs, as well as mounting for the micrcontroller
- Connectors for support of 6 valves, 3 pressure transducers, 4 thermocouples, 1 RS422/RS485 transceiver, 1 battery, 1 battery charger, 1 auxiliary valve control system, 2 pin headers for interfacing with extra micrcontroller pins
- A PCB with relays for auxiliary valve control, an ignition circuit with relay, shunt switch, and buzzer, and 5V and 3.3V regulators for test stand sensors (if needed)
- A PCB with switches for controlling the relay board, with feedback LEDs
Stage 1: Initial Design Figures and Tests
Initial circuit designs were prototyped by pitching the circuits rudimentarily in PSpice or on paper, and then running simulations in PSpice if possible. As system requirements came up, new circuits were proposed and their components were looked into. Throughhole components compatible with breadboarding were purchased when possible, so that they could be tested and/or prototyped ahead of time.
One of the earliest tasks was choosing a battery, as batteries had potentially long lead times, and initial system requirements called for a system ready for flight (although the mechanical engineers later scaled this back to test stand only).
Intially, it was thought that a charging circuit could be purchased as a pre-populated circuit board. It was desired for the board to be able to charge the batteries, communicate the battery's status over I2C, SPI, UART, etc., as well as handle battery balancing, protection, and so on. This was determined to be overly complicated, limiting, and quite cost prohibitive. A battery with integrated balancing and protection circuitry was purchased instead, with an accompanying battery charger.
A DC switch of some kind was proposed for enabling or disabling various power domains or sections of power usage, though this was a vague suggestion. This idea was removed. Op Amps were also considered for some of the sensors, although this was later determined to be unnecessary.
Some initial, back-of-the-envelope battery considerations are given below. The battery purchased during this stage was the HPL-6745135K-4S-FG from BatterySpace, a 14.8V, 59 Wh lithium-ion battery that more than met the requirements. It has an integrated fuel gauge (battery energy level monitor) as well as integrated circuitry for balancing and protection. Its maximum charge is 17.4V, and its maximum current output is 20A. An accompanying charger was also purchased.
|Power||Charger||Charge, discharge, and monitor battery|
|Power||Voltage Regulator||Supply voltage rails|
|Power||I2C Logic Shifter||Shift I2C logic level if necessary|
|Power||Misc. Passive Components||Filtering, Regulating, etc|
|Controller||Pressure Sensors||Measure pressure|
|Controller||Temperature Sensors||Measure temperature|
|Controller||Operational Amplifier||Amplify signals|
|Controller||DC Switch||Switch on/off major components|
|Controller||Temperature Compensators||Compensate K-type thermocouples|
|Controller||DB9 Connectors/Cables||Serial RS422|
|Controller||RS485 Logic Shifter||Shift RS422 logic level if necessary|
|Controller||Wiring (<22 AWG)||Wiring|
|Controller||Misc. Passive Components||Filtering, Regulating, etc.|
- Some Initial Component Considerations
Example Components Voltage (V) Current (A) Quantity Power (W) Teensy 3.6 5 0.5 1 2.5 LTC1049 Op Amp 5 0.2m 8 8m LT1025 Compensator 5 80u 3 1.2 PX249 Gauge Transducer 5 10m 8 4 McMaster-Carr Compact
Actuated On/Off Valve
24 0.4 5 48 LM2651 Regulator 5 1.6m 1 8m 24 Input Switch 5 10u 1 50u 2.6A Total 56W Total
- Some Initial Battery Calculations
The initial charging circuit had a ground to the chassis, but it was deemed unnecessary, especially given that there was no proposed chassis design. The later design was an attempt to have the charging circuit disconnect the load during charging, though the inverting NMOS resistor transistor logic circuit was ineffective in simulations and replaced with a simple power PMOS transistor. An ADC circuit was added to measure the battery.
The initial transceiver proposal made use of a full-duplex RS422 transceiver, as was requested by the customer, and would be carried on to later designs.
Initially it was thought that the transducer would have two outputs, a lower voltage reference and a higher voltage output, as well as an excitation (supply) input voltage and ground input. However, the transducers that were chosen have an ASIC which handles amplification, calibration, and compensation, and a single voltage output, so no operational amplifier or other support circuitry beyong supplies was deemed necessary.
The thermocouple design is implemented from an Adafruit board which uses the IC in question, and was suggested by one of the customer's engineers, Mark Saunders. It handles all compensation and measurements needed of a thermocouple, as well as communication over SPI.
Valve control occurs through optocouplers, as they allow the high voltage, high power valves to be controller by low power microcontrollers, without using a relay. They are highly recommended.
The 24V converter requirements were a challenge, as the highest current needed by a valve was 1.9A. Initially, a TI IC was chosen, along with accompanying circuit components, to meet this need, although the design was power intensive, reached the outer limits of the part's capability, and had large spiking currents and voltages, as seen in the SPICE simulation. The benefit was that TI provided SPICE models and a design spreadsheet.
Linear regulators were chosen to supply sufficient current and voltage for the various IC loads. Two 3.3V and 5V regulators were chosen with enables so that the resultant loads would not use power during idle states, and a 3.3V supply was chosen for the microcontroller with a simple push button for quick power cycling during testing.
Click on this link to watch a video and hear the valve opening and closing: Valve Circuit
Click on this link to watch a video of the full duplex capabilities being represented by blinking LEDs: Full Duplex
Stage 2: PCB Design
One PCB was originally planned, with the implementation of support circuitry up in the air. The original PCB design was an attempt to bring over the prototypes and conceptual circuits as closely as possible. It was designed with the licensed version of Eagle.
Ultimately, this design was not chosen for several reasons:
- It was unclear if it would meet many common PCB fabrication design tolerances.
- It was large and expensive, and could easily be made more compact.
- There were many circuits that needed more testing or could pose a significant debugging challenge, especially the 24V converter circuit.
- Some of the circuits' operations were suspect. Despite approval by consultatory sources, upon extra SPICE tests and real life tests they were determined to not work as expected, with the most concerning circuit being the RTL charging circuit.
- Via-in-pads were used which was easily avoided and increases the price of the circuit a lot.
The design of the PCB was a valuable learning experience, but needed to be revised.
Stage 3: Final Design
An extra thermocouple setup was removed, from 5 thermocouples to 4. The data ready and error lines were left unconnected, as they were extra pins for increased functionality of the IC and are not necessary for normal operation.
The final PCB makes use of an optocoupler array IC as well as a power NMOSFET IC, leading to a compact valve control solution.
The push button was replaced with a switch circuit.
The previous 24V converter circuit was replaced with a package that integrates all the 24V conversion functionality. The filter circuit coming in is, in fact, unnecessary for operation, but is helpful in case of a noisy system as suggested by the manufacturer (which this system really is not, but it's good to be cautious).
The footprint designed for the package was the only incorrect design made for the PCB. The 24V output and 24V trim pins were, unfortunately, mixed up. As a result, the package had to be connected via wires to the PCB.
External valve controls and 24V supply can be seen here, as well as the pinout of the Teensy 3.6 and its extra headers.
The relay board, as mentioned, has an ignition circuit with a buzzer and shunt switch, as well as relays for external valve controls, and some extra linear regulators. The asymmetric relay pin needs to switch sides (top -> bottom). The shunt switch works great, and does in fact shunt the ignition circuit if not unflipped before ignition. Unfortunately, this causes the ignition relay to latch, so it is imperative that before the circuit is reset, the ignitors and ignitor battery are disconnected, the circuit is unlatched, and the relay board is tested. The best way to unlatch the relay is to knock it gently against a surface a few times (seriously, it's just a mechanical connection after all).
The switch board has holes and wire connections for switches, and feedback LEDs. The switches need ~1kOhm resistors on their outputs to the output connector.
The final BOM can be found here: Final BOM
The boards were made by a Chinese manufacturer, because with 48hr turn-around (not counting shipping) it was 5 times faster and still 3 times cheaper with twice as many boards than a domestic solution. Ah, capitalism. The total cost for all three boards was ~$500, though this could be reduced significantly with thinner, smaller boards and slower production times.
Everything worked as expected, minus the incorrect footprints of the 24V converter, the backwards relays, and the needed resistors on the switchboard (which were added via a protoboard). All functionality worked correctly and with the expected voltages, including but not limited to battery charging (up to 16.8V due to the drop over the input schottky diode), voltage conversion/regulation, sensor powering and readback, and the ignition circuit. With some clever thinking and testing weeks in advance of usage, these were easily fixed and made usable.
- Final Eagle PCB Files: Engine PCB | Relay PCB | Switch PCB
- Eagle Design Blocks: Eagle Design Blocks
- Part libraries: Library 1 | Library 2
Of note are the custom footprints for:
- The Abracon LLC ASPI-0630LR-4R7M-T15, the 4.7 uH inductor used with the 24V converter package
- The Omron G5LE-1A-VD, the 10A 12V-coil relay used, though it needs the asymmetric pin correction
- The RPA60-FW 24V converter with enable, which was initially incorrect but is fixed in 'Library 2'
- The BUK7K17-60E power NMOS array IC, which uses an SOT1205 layout (and fits great!)
All of the connectors used were custom footprints except for the Molex connector used for the transceiver. The panel mount switch footprints were also custom made. The thermocouple IC, optocouplers, and transceiver IC were taken from some Sparkfun and/or Adafruit projects. The Teensy 3.6 was taken from the PJRC forums. Everything else was found or modified in the standard Eagle libraries or the standard Sparkfun libraries.
PCB improvements that could be made:
- The engine controller could get rid of a lot of extra "safety" components. Many TVS diodes could be removed (though not the reverse protection diodes!). The fourth thermocouple (a battery thermocouple) did not end up being used. A lot of the pins on the Teensy 3.6 ended up being unused, so it could be scaled back to a smaller (and cheaper) micrcontroller.
- In all honesty, most of the sensors were great for test stand usage but end up being kind of useless in actual flight, since thermocouples and pressure transducers tend to have response times that are much slower than the speed at which events unfold. They could be moved to test stand hardware in the future, or sensors with faster response times should be investigated. Pressure transducers are probably okay to keep but thermocouples don't do much good except for post-analysis.
- A relay added to the engine controller that is last-in-line in the ignition circuit could be used to control the ignitor by the microcontroller.
- Tolerances on the engine controller PCB were very high, as concern was expressed online in reviews that alignment was sometimes shoddy for the specific manufacturer. The tolerances were not used for the relay or switch PCBs. No problems were detected for any of the PCBs. Thus, a lot of the extra space could be removed.
- The engine controller could be made to be double sided (that is, surface mount components on both sides). It would save a lot of space.
- Pushback on the 1.9A valve would have been a smart decision. Without that, only one 24V converter would be necessary, and even then probably not a 2.5A one.
- The 5V converters could be combined. Not much power would be lost.
- A smaller battery could be chosen. The charging circuit, while relatively unintrusive and very convenient, could be removed.
- An enclosure for the engine PCB would have protected it from damage (though it did not get damaged when the engine blew up).
- Wires could have been given harnesses.
- Different connectors could definitely be chosen. Since a lot of moving, testing, and wire replacement was necessary, many push terminal connectors were used. They are very secure, but not as secure as a solution that uses attached/soldered connectors on the end of wires, and they also tend to be fairly large.
- Everything in front of the 24V converters except the optocouplers for the enable pins could probably be removed - the power FET for giving power to the 24V converter, the filter network, etc.
- Power and ground really should have been on the outer layers (as outer layers are able to pass more current as they tend to be thicker), and the internal layers should have been the signal layers.
Despite these suggestions, it is important to note that for all intents and purposes, the engine controller worked perfectly. The biggest criticism post-catastrophic-engine-expansion was that the wiring solution could have been taped down a little better. Thus, there is a benefit to having all your circuits manufactured and tested weeks in advance (even if it required many all-nighters).
Suggestions for the FutureThere are definitely improvements that could be made by future teams. There were many lessons learned that should be noted early on, as well.
- Attempt to make the engine controller smaller and thus suitable for mounting in the actual engine. The improvements listed above would help a lot.
- At the same time, don't reinvent the wheel. A lot of stuff worked. If it works, it works. The first 24V converter had many parts, so a package that handles it all was chosen. Was it a little bulkier? Yes, but it was guarenteed to work, and needed very little debugging.
- Pushback on the rest of the team. The electrical team got a lot of... very unwarranted criticism, concern, and even a little attitude from the rest of the team. Ultimately, the electrical team was the team ready in advance, with tested components and back-up solutions, and was the team who had 100% success. (This is not to understate the success of many of the other project members, but a small part of the project needed a LOT more testing and factors of safety) The critical failure was in no way related to the electrical systems. Additionally, a lot of system requirements were changed around a lot, or requirements weren't communicated well (the fifth valve wasn't mentioned until the PCB designs were almost done!). Demand respect! You deserve it, you've come this far.
- Start the PCB design or design concept tests as early as possible. Because system requirements kept changing, a lot of the work was repeated or done last minute. Thus, many of the final design choices probably have better solutions (such as the connector choices).
- Domestic orders are fine for everything but PCBs. Fight tooth-and-nail to get the Chinese stuff. Launch was the purchaser for the PCBs, so the no-international-orders limitation by MSD was not in place.
- The high power 24V solutions were ridiculous and only suited for a test stand solution. Pyrotechnic valves are way better solutions for a final flight design, and tend to have much lower power requirements, even if they need to be re-charged. Thus, trying to design an engine controller for flight from the start was a bad idea and introduced too many restrictions.
- Learn your PCB tools early. Don't use Eagle. Open Eagle and export to your CAD tool of choice. Please.
- Get a headstart on your BOM. Bookmark components on Digikey.
- If you're unsure if something might work, buy the components and test it yourself. Take components from the labs or the Construct and test them. Build a back-up if necessary. Tested hardware (even shoddy/janky set-ups) > SPICE simulations > confirmation from anyone that something 'looks like it should work'.
- Don't be afraid to take criticism. Sometimes design requirements weren't communicated, sometimes resources/advice was bad, sometimes requirements were misunderstood - and sometimes, mistakes just get made. Take a deep breath and admit your mistake - it's much easier than trying to defend yourself during a design review!