I2C Rocket Starter Controller

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Joined
Aug 13, 2022
Messages
20
Reaction score
7
Location
86314
OK folks, I see a great need in our community for this product. Trouble is, it's not invented yet. So, let's collectively get to work! I'll get y'all started...

I2C Rocket Starter Controller Requirements

1. Definition
The Controller is a device built into a PCB with I2C connection to a host. It connects an attached, yet isolated source of power to a low-impedance resistive load upon command from the host.
2. Requirements
2.1 The I2C connection shall comply with the published Qwiic standard promulgated by Sparkfun and in-use by Adafruit.
2.2 The device shall accommodate a connected power source of a 3S, high C, low mAh, (ie micro Drone) LiPo battery.
2.3 The device shall provide a continuity test function.
2.3.1 The test function shall provide an indication of connected battery charge condition.
2.3.2 The test function shall pass not more than 10uA through the resistive load.
2.3.3 The test function shall be initiated by a test command from the host.
2.3.4 The test function duration shall be 1s - 1.5s.
2.4 The device shall take the load out of circuit unless testing or starting.
2.5 The device shall provide >=26W to the load for 1s – 4s at the start command from the host.
2.6 The device connection to the load shall be PTH, spaced to accommodate a 2-post screw terminal.
2.7 The device connection to battery shall be an XT-60 female plug, with or without pigtail.

3. Assumptions
3.1 The load resistance will be in the range 1-4ohms.
3.2 For Goal D, the device may assume the load is matched to the power supply attached. ie. a 4ohm load is not expected to be started with a 9V battery.

Prioritized Design Option Goals
A. Number of loads controlled: 2-4.
B. Board size: 1"sq
C. Mounting holes!
D. The connected power source may include any of: 9V Alkaline, 2S and, 3S, high C, low mAh, (ie micro Drone)LiPo batteries.
E. Quiescent power consumption: <15uA.
F. The device may provide a breakout for 5V regulated voltage up to 600mAh.

A Preliminary design
The attached battery is connected to a voltage divider that limits current to 10uA and outputs 3.3V to match supplied I2C voltage. Less with a weak battery, more with a fresh charge. These values are compared in the Op Amp and output as a digital, 3V3 signal; 3.3V for a good battery, 0V fails the battery test. This signal is then fed into the collector of the NPN Transistor, the emitter current limited to 10uA and connected to the P-FET drain (and the high side of the load). An attiny85 accepts I2C commands from the host and controls an 8-bit shift register. One channel of the shift register switches both the NPN transistor base and the P-FET gate to either the test or start configuration. Remaining channels each switch an N-FET to connect each load to ground. A second attiny85 sends status to the host over I2C and accepts digital input from a parallel load shift register. Each of 4 (one for each load) active channels of this register is connected to a single N-FET drain (and the low side of the load) to sense continuity. The diode is included to protect the transistor from reverse current when applying starting current to the load.

Use Cases
When the device is initially powered on through the I2C connection, all N-FET gates are low, the P-FET gate and NPN base are high, putting the device in the "not testing", "not starting", load is out-of-circuit state.
During pad preparations, before launch, all active load channels should be checked for continuity WHEN NO HANDS OR FACES ARE NEAR!. At the "test all" command from the host, the P-FET gate/NPN base goes low and the all N-FET gates go high for 1s-1.5s. Then returns to the former state. Following the test command, the host is expected to issue a "read status" command to the second attiny85 to obtain the result of the test. A test failure should hold launch until the problem is corrected.
At the appropriate point during flight, the host will issue start commands for each active channel, one at a time. Upon receiving a start command for a channel, the device sets the P-FET gate/NPN base high (should already be there) and the commanded N-FET gate high for 2s-4s. Then returns to the former state.

The design can meet all requirements. Goal D is not met. Goal A is met and can be exceeded to 7 from 4. Goal B may be obtainable with SMT components. Goal E may be met. Goal F may be obtainable with the addition of an LM714 Voltage Regulator.

Preliminary design BOM
2 Attiny85 slave MCU, one for digital output, one for digital input.
1 74HC595 shift register
1 74HC165 parallel load shift register
1 FQP27P06 P-FET 60V 27A, Power MOSFET
1 2N2222 NPN Transistor
1 1N1004 Diode
.5 LM358 Op Amp
4 FQP30N06L N-FET 60V 30A, Power MOSFET, one for each load.
Crews of resistors!
And a sprinkling of capacitors.

So, if you've gotten this far you must be interested. Anybody care to put this into a CAD package that can output Gerber files? I tried this as my first Fritzing project but I need HELP!
 
I2c probably isn't the best protocol for this... maybe some kind of serial connection through an optoisolator, or some kind of wireless status from the altimeter. I know of at least one group that did a pad monitor, we actually built a "ready" signal output into the Proton and Quantum altimeters for them. It's in the user's documentation for them... IO16 on the ESP8266 processor goes high when the altimeter is armed (which implies that continuity checks passed).
 
I'd thought I2C was good up to 6" or so. What are the issues?? Anything that can be mitigated with a LTC4311, I2C extender or a ISO1540, bi-directional isolator?
 
I'm not understanding the use case. Is this a building block for a pad-side controller? If so, in your view how do you communicate to the LCO table? Too many microcontrollers here for my taste, and shift registers are kinda 70s (admittedly that's purely a question of taste.)

FWIW, I used https://www.dfrobot.com/product-496.html with an XBee for a three-channel controller (one relay used for arming.) And even though this is an Arduino shield, I use it standalone with no Arduino, the XBee does everything using I/O passing.
 
Last edited:
I gathered that it was a pad monitor, that's used to check the status of the altimeters before allowing the motor to be ignited from the LCO console, but apparently this is something else... what is it exactly that you are trying to "control"?
 
I'm not understanding the use case. Is this a building block for a pad-side controller? If so, in your view how do you communicate to the LCO table? Too many microcontrollers here for my taste, and shift registers are kinda 70s (admittedly that's purely a question of taste.)

FWIW, I used https://www.dfrobot.com/product-496.html with an XBee for a three-channel controller (one relay used for arming.) And even though this is an Arduino shield, I use it standalone with no Arduino, the XBee does everything using I/O passing.
Mike: hot a schematic of your setup with this that you might want to share?
 
Sorry, back from sailing class....
This is supposed to be a pyro board for my homebrew telemeter. I cobbled together an Adafruit Feather GPS, and a LoRa, together with some cheap Chinese sensors to send data to my homebrew telemeter base. That part flies Saturday on my L1. So, I'll get 15s updates of range and bearing to my rocket, reported by the base unit hanging around my neck on a lanyard. The Rocket Starter Controller is intended as an on-board add-on for such a setup. Two-way comm, rocket to base and back. That part is already done. This unit should add dual-deploy capability as well as air-start capability. I want to have this as my go-to starter solution. Any starter, anywhere, anytime.
 
Any updates on this, or photos? Noticed it's been a few months and was curious myself.
 
Back
Top