Updating ematch ignition circuit for altimeter

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

First, forgive my ignorance

What do you do with the continuity input? In the 1s lipo scenario can that feed directly into a GPIO input pin? Or do you use an ADC pin to read it? Funny thing finding this thread today, I was playing around with the idea of making a pyro board with an i2c interface. Below is a video i made today of using a 1s lipo, darlington transistors, and an i2c gpio expander board. It's connected to an RP2040 running CircuitPython and i'm on the REPL firing the e-matches by setting gpio pins high then low. The circuit i came up with is almost identical to yours only no continuity detection.

Also, all my circuits are scribbled down on various pieces of paper. Is there a program that works well for circuit design? I found circuitlab.com but have no idea if it's decent or not.

 
As far as circuit design, I'm also a complete n00b. I'm struggling with Fritzing. Adafruit supports Eagle CAD.

Having a dual deploy fail is a safety risk, flying without getting a continuity check adds to that risk. Putting current through a starter is also risky if your hands or face are nearby. Therefore, an automated check preflight, is prudent.

I have the code detect vertical within 15 degrees and if that holds for a minute, I assume the rocket is on the pad and my hands and face are near the motor, do the check. I get a RTF from the computer and we are Ready For Launch!
 
PCBs in to the fabricator and through DFM analysis. Will have assembled boards back in 2-3 weeks and then will update.
View attachment 453128

Comparing the BOMs:
DPak Darlington $0.48
SOT223 Darlington $0.69
NFet $0.81
PFet $0.68

In quantity 5, the setup and shipping are high etc so the BOM makes only a small difference.
You have tons of unused board space here. I would make the VB/3.3/GND traces much thicker. These are carrying all of your current. You don't want to burn out a trace. This would make it more robust without adding a cent.
 
Ok. Per voyagers suggestion I moved to a high side p channel switch. View attachment 452491
I am using a pfet for false economy! It saves me $2 on the protoboard. I will look into availability of low Vth nfets. It will save me the problem of the 3.3V vs VBat issue at the gate of the Pfet for pull up.

I like this best. I feel much more comfortable with high side switching pyro's. What max current are you trying to target? I would add a current limiting resistor sized appropriately to prevent a brownout by effectively shorting the battery. Think ematch shorted at the connector or on a metallic charge well. and or a PTC to disconnect power to the module in the event of a long term short. Then to go overboard with for reliability I would add ESD diodes on any external connection.

  1. VBat
  2. +3.3V
  3. CONT1
  4. Ematch1 pin1
VBAT 3.2VVBAT 4.2VNotes
Ematch Connected2.62V3.44Even with the ematch connected 2.62V is not low enough to be read as a low in 3.3V logic.
Ematch not Present 3.2V4.2VAt a VBAT of 4.2V you would overdrive your GPIO on the MCU relying on internal protection on the GPIO pin. This is not a good practice.
Ematch continuity test current2.62mA3.44mAThis is far more than required

If you change the 2.2k to 100k
VBAT 3.2VVBAT4.2VNotes
Ematch Connected0.29V0.38VThis is less than 0.8V and will work with 3.3V logic
Ematch not Present3.2V4.2VYou still have the same problem as before overdriving the MCU GPIO. if you add a 3.3V zener diode to CONT1 this will limit the output to 3.3V.
Ematch continuity test current29µA38µA
 
That's similar to the ST VN5E160S driver that we use in most of our altimeters now. Same parts availability issue that's endemic to all automotive silicon, though... fortunately we were able to round up some recently.
I noticed with the BV1HD090FJ-CE2 the high-level Input voltage VIH min value = 2.8V, compared to the ST VN5E160S with a VIH min value = 2.1V.

Would that be an issue with 3.3V logic?

If it isn't ROHM also have a dual channel driver BV2HD045EFU-C...
 
I noticed with the BV1HD090FJ-CE2 the high-level Input voltage VIH min value = 2.8V, compared to the ST VN5E160S with a VIH min value = 2.1V.

Would that be an issue with 3.3V logic?
No, not an issue. I run 3.3v logic directly to the BV1 input with only 50ua draw. The 2.8v indicates an "on" voltage threshold and the 1.8v indicates an "off" voltage. A good MCU will output 3.3v for on and 0v for off, so well within range. On the business side of the chip the vbb switching power is 4.5vdc - 36vdc, so it has a very broad range.
 
I've noticed the VN5160S-E has digital status pin, but the other version all have current sensing (e.g. VN7140AJ). Could these be viable alternatives?
That's similar to the ST VN5E160S driver that we use in most of our altimeters now. Same parts availability issue that's endemic to all automotive silicon, though... fortunately we were able to round up some recently.
 
Here's mine which is pretty much the same as @profmason but I used a 3.3k resistor instead of 2.2k and a Darlington transistor. When breadboarded, I measured 3.1v on the continuity output with the e-match connected and 0v volt without. That went straight into a GPIO Input pin on my little i2c gpio expander and worked just fine. The Fire1 label goes into a GPIO output pin and fires the match when its value is set to true.

(I'm still learning kicad, the ematch is represented by a lamp)
 

Attachments

  • i2c-pyro.png
    i2c-pyro.png
    12.6 KB · Views: 0
If ut still triggers, try a 1ufcapacitor at the gate where the 470 connects. It will require it to be high for longer, before it triggers. 470*1e-6=470uS delay, before the voltage hits 66% of the applied voltage.10uf might work even better, you'll have to find out empirically. This is called a start up glitch, and is common to run into. We used to use a circuit that was set up so nothing worked unless we set a certain output high, and a different one low. That solved some really knarly problems. Never again am I writing control code in Visual Basic. :)
 
That's similar to the ST VN5E160S driver that we use in most of our altimeters now. Same parts availability issue that's endemic to all automotive silicon, though... fortunately we were able to round up some recently.
A bit late, why do you use an additional mosfet on the quantum (not the one for the buzzer), aren't the drivers enough? What does the rectifier do on your altimeter? Is it only for reverse polarity?

I bought quantum before ( Rev A18 board) and plan on buying the newer version, but I am wondering how it really works and why some things are changed. That's why I am asking.
 
Last edited:
A bit late, why do you use an additional mosfet on the quantum (not the one for the buzzer), aren't the drivers enough? What does the rectifier do on your altimeter? Is it only for reverse polarity?

I bought quantum before ( Rev A18 board) and plan on buying the newer version, but I am wondering how it really works and why some things are changed. That's why I am asking.
Starting with the rectifier, yes, it's for reverse-polarity protection.

The large FET is there to remedy what we have perceived is a ground safety issue with many altimeters...

Since the Quantum debuted in 2016, all of our Wifi-enabled deployment altimeters have had a separate switch on the negative side of the igniter (basically a WiFi Switch). The drivers switch the positive side. Essentially, the igniter is "dead" except for about a 80 uA continuity check current (deployment voltage / 100K ohms). Unlike most other altimeters, there is no "battery common" connection to the non-switched lead of the igniters. With a single common connection, if you blow an output FET (and the most common FET failures are CLOSED, not open like a BJT) and you connect the battery, your igniter blows right there and then. With a double-switched architecture, that's not going to happen.

You'll also notice that the FET (and rectifier) that we use are a lot larger than on other altimeters... we like to build a lot of extra margin in the power supply parts. We don't get too hung up on the size of parts, especially since they're kits and you have to be able to hand-solder them.

The negative-side FET isn't turned on until 1) You arm the altimeter on the pad remotely; 2) The altimeter has detected a launch (typically at 200' and/or 3G for .5 secs in the case of the Proton); and 3) The first deployment/airstart event is triggered.

Hope this makes sense... FYI, your older Quantum DOES have the double-switched architecture, it's the high-side switching that changed between the Rev A and Rev B boards (we went from optoisolator-driven BJT's to the automotive drivers).

Cris Erving, Eggtimer Rocketry
 
Back
Top