ArdIU - Open source flight computer w/ ATMega328

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
How do you propose I fix this? I can't put a capacitor on it since a capacitor from ground to ground really doesn't do much... The ground voltage changes all the time anyway. Mount your altimeter on a sled? You just changed the ground voltage with all the static charge on the sled.

The problem isn't caused by the absolute ground voltage changing but that the difference between Vcc and ground changes. The regulator is almost certainly of the series pass design which means that it cannot sink current. So if something should cause the difference between its output and ground to rise, it can do nothing to stop it.

Filtering (ferrite beads and capacitors) are the only way to prevent RF entering via your external connections from causing trouble. You could ignore it and hope that there is never a source of RF around strong enough to cause trouble. That works for most altimeters most of the time.

The BMP280 may help as it has an internal regulator.

Everything sensitive has a decoupling capacitor attached to it.
Decoupling capacitors are not used to keep power supply noise out of the parts but to provide a local low impedance reservoir for when the current demanded by that part changes suddenly.
 
So I'm just getting back to this project, and I've reconsidered (again) and decided to go back to the ATMega based design. I figured that way I don't have to worry about burning a 3rd party version of Arduino on a different chip.

I've simplified a bit by removing the servos and shift register, then rearranging the sensors a bit and adding in a MicroSD card reader in place of the 8K FRAM chip. This way I can run a high data resolution and never run out of space- probably a good idea with an experimental altimeter. Since the previous iteration I learned more about SPI buses (namely how multiple SPI slave devices stack) and was able to free up 4 analog pins. Those pins became a battery voltage sensor and continuity checks for the 3 pyro lines.

My schematic and PCB are included- Chrome was having issues with inline images, so they're attached as files.

Still no resistors on the MOSFETs. I really don't think it's the most essential thing ever. I'm just going with how Arduino themselves recommend MOSFETs be connected to the Uno, which has no internal parts in between the ATMega and the I/O pin.

That said, there's probably something obvious I missed. Please feel free to say so if you see anything.

ardiu_1_0_pcb.jpg

ardiu_1_0_schematic.jpg
 
Hi LR. Thanks for posting your info on this project. Putting your ideas out for everyone to throw rocks at is a bit daunting at times. In a commercial environment it is part of the process: Design, Make, Release to factory, release for sale, sell to customer. Every extra step through the process costs about 10x the $ to fix than the one before it. This means reviewing early on to find problems reduces the cost to the company orders of magnitude than if they have to fix it after it has been sold. I actually accept review as a necessary part of the process rather than a personal attack. I encourage you to look at it the same way.

On with some comments:
Your schematic is a bit scrambled and unreadable. I suspect it is largely due to you trying to "do a drawing on a postage stamp" as my graphic communications teacher used to say. You have lines going over and under schematic symbols, lines overlapping symbol lines, symbols under other symbols and things generally too tight to see clearly. The area to the immediate left of IC1 is a good example of what I just said. Consider using more space and being a bit more disciplined in the placement and routing of wires. Try to keep the flow left-right if it makes sense to do that, as it can help readability. Try to keep positive voltages above more negative ones, or ground (see your regulator circuit as an example). Looking at your gyro connector for example, keep the wires coming out of one side rather than going over the symbol. Allow yourself to use more space and your diagrams should be more legible.

A little thought before you start sketching the schematic can make all the difference to it being legible. Try to make a logical layout with the functionality. Also consider who the schematic will be viewed by to determine what information is important. If it is not important consider leaving it off to make the page more readable.

Here is an example of one of my circuits to show you what I mean:
PWM-VoltsSchematic.png

Keep up the good work!

As a final comment I would suggest you put those resistors in the gate legs of the FETs :wink:
 
Last edited:
You really need to pull down the gates to ground so the FETs don't fire the pyro charges when the ATMega outputs are in an indeterminate or high impedance state.

I don't understand why you 'resist' this?
 
Hi LR. Thanks for posting your info on this project. Putting your ideas out for everyone to throw rocks at is a bit daunting at times. In a commercial environment it is part of the process: Design, Make, Release to factory, release for sale, sell to customer. Every extra step through the process costs about 10x the $ to fix than the one before it. This means reviewing early on to find problems reduces the cost to the company orders of magnitude than if they have to fix it after it has been sold. I actually accept review as a necessary part of the process rather than a personal attack. I encourage you to look at it the same way.

On with some comments:
Your schematic is a bit scrambled and unreadable. I suspect it is largely due to you trying to "do a drawing on a postage stamp" as my graphic communications teacher used to say. You have lines going over and under schematic symbols, lines overlapping symbol lines, symbols under other symbols and things generally too tight to see clearly. The area to the immediate left of IC1 is a good example of what I just said. Consider using more space and being a bit more disciplined in the placement and routing of wires. Try to keep the flow left-right if it makes sense to do that, as it can help readability. Try to keep positive voltages above more negative ones, or ground (see your regulator circuit as an example). Looking at your gyro connector for example, keep the wires coming out of one side rather than going over the symbol. Allow yourself to use more space and your diagrams should be more legible.

A little thought before you start sketching the schematic can make all the difference to it being legible. Try to make a logical layout with the functionality. Also consider who the schematic will be viewed by to determine what information is important. If it is not important consider leaving it off to make the page more readable.

Here is an example of one of my circuits to show you what I mean:
View attachment 333439

Keep up the good work!

As a final comment I would suggest you put those resistors in the gate legs of the FETs :wink:

I agree that my schematic is a mess. I'll fix that next time I have some time to devote to it.

I appreciate all the help- I totally get what you're saying about time to fix. I'm having that issue already- I tend to wire up a schematic, start laying out the PCB, then realize I forgot something and have to start over :facepalm:.

The regulator circuit is how it is mainly because of the ATMega footprint I have- I just lined it up with where VCC and ground on the ATMega are. I guess I could make that part separate, kinda like what I did with the SPI pins. Also, I'll try to add labels to said connections to make the schematic a bit more readable.

While I'm at it, I'll see if I can fit some gate resistors under the SD reader (silkscreen box on the schematic, already has some resistors under it). If not, they'll go in next time I redo the board- I meant to do them this time but honestly completely forgot.

You really need to pull down the gates to ground so the FETs don't fire the pyro charges when the ATMega outputs are in an indeterminate or high impedance state.

I don't understand why you 'resist' this?

I gave a reason in an earlier post- this is intentional. This is a protection against brownout due to high currents pulling the regulator below 5V. There is a separate key switch that powers on the pyrotechnics, and the processor can tell whether the key is in. If the altimeter boots with the key out (armed), it will assume it just browned out and not reset the ground altitude.

I realize this isn't ideal, but I came up with it on an older design that used a shift register, which can't be simply pulled down. I originally used it as a workaround to the shift register issue, but when I realized the potential to reduce brownout I stuck with it.


Thanks to everybody for all the help! You know it's a great hobby when you're making a DIY gadget and TWO different manufacturers of said gadgets help out...
 
I gave a reason in an earlier post- this is intentional. This is a protection against brownout due to high currents pulling the regulator below 5V. There is a separate key switch that powers on the pyrotechnics, and the processor can tell whether the key is in. If the altimeter boots with the key out (armed), it will assume it just browned out and not reset the ground altitude.

Ok, very clever, I like it.

One thing you can look into for future iterations is using the brown-out detection features of the ATMEGA's. The chip knows if it resetting from a power-on reset versus a brown-out reset and you can branch to different code appropriately.
 
Ok, very clever, I like it.

One thing you can look into for future iterations is using the brown-out detection features of the ATMEGA's. The chip knows if it resetting from a power-on reset versus a brown-out reset and you can branch to different code appropriately.

Thanks!:blush:

Do you know if the Arduino firmware supports brownout detection? It sounds like a nice feature to have.

In other news, I cleaned up my schematic a bit. Of course, the way Eagle PCB works, this means I have to reroute most of it... Ah well...

OTT will be happy to note, I added gate resistors on the MOSFETs... Haven't wired them in on the PCB, but they're there in the schematic.
bIG7SwC0Tk7qELCx2


ardiu_1_0_schematic.jpg
 
The advantage of this setup is that if the processor browns out due to a power-hungry ematch it'll continue firing.

The voltage on the GPIO pins is limited to about Vcc + 0.5V, due to the internal clamping diodes of the AVR (see 18.1 and 32.1 in the ATmega328/P datasheet). Depending on the lowest voltage reached during brown-out, there is no guarantee that Vgs stays sufficiently high. Lowering Vgs will also increase the FETs resistance, which will increase the risk of thermal damage to the FET.
Besides a short, very high currents will be a sign of an arc discharge in the igniter. If this happens, the igniter has already done its job. Keeping the FET on any further, will only increase the risks that something gets damaged.


I gave a reason in an earlier post- this is intentional. This is a protection against brownout due to high currents pulling the regulator below 5V. There is a separate key switch that powers on the pyrotechnics, and the processor can tell whether the key is in. If the altimeter boots with the key out (armed), it will assume it just browned out and not reset the ground altitude.

Are your switches designed to enforce the proper sequence or is there a possibility that it will be armed before it gets powered up by user error? What will happen in this case? Besides the "undefined GPIO pin during reset" scenario, what will the altimeters state machine do if it assumes a brown-out after booting? For example, will it immediately fire the main because it is below the main altitude? Or will it wait for liftoff, which may never be detected if the rocket is descending past apogee? Something else? While it is possible to recover state after a brown-out, this is also a good way to shoot yourself in the foot, if you overlook something and the law of unintended consequences strikes.


Reinhard
 
Hi LithosphereRocketry,

Thanks for posting this thread. I am followig this discussion and learning quite a lot. And thanks to everyone for posting all those informative replies.

Peace,
Tobor

Edit: oops
 
Thanks!:blush:

Do you know if the Arduino firmware supports brownout detection? It sounds like a nice feature to have.

I do not know if the Arduino supports BO detection programmatically but it is easy to implement. The MCUSR register on the AT328 indicates the source of the reset It is described in section 11.9 of the AT328P datasheet.
 
OTT will be happy to note, I added gate resistors on the MOSFETs... Haven't wired them in on the PCB, but they're there in the schematic.
bIG7SwC0Tk7qELCx2
Hello
For the MOSFET the resistors on the gate should be pull up resistors rather than from the Arduino output to the gate. You need to wire your resistor from ground to the gate.
 
OTT will be happy to note, I added gate resistors on the MOSFETs... Haven't wired them in on the PCB, but they're there in the schematic.
bIG7SwC0Tk7qELCx2

Boris, your FET gate resistors need to be connected from the gate to GND, not in series with the processor outputs and the gates. This ensures that that gate will be kept at GND unless you explicitly send it high. On your PC board, you can simply run the resistor between the gate and the drain of the FET; it's often hard to find real estate right next to the processor pins to put them there.
 
Series resistors to gates in MOSFETS is a best practice to limit in-rush current and provide stability. Probably not needed in hobby electronics but it is standard practice in industrial and commercial products where 5 9 component reliability is required. At least that is standard practice where I work.
 
Interesting, I've worked in consumer electronics for 20 years and have never seen a series R on a MOSFET gate unless that gate was exposed to a connector (where of course other sorts of transient protection are also recommended, the series R was just to help protect the gate, which tends to be pretty sensitive, from ESD). A series R is common (expected) on BJT bases since they can't be pulled all the way to the rail (or to help set the current through the BJT). But a pull (down on a N-FET or up on a P-FET) to ensure the gate never floats into the active region has certainly been standard practice where I work or any other vendor schematics I've seen, unless the design didn't care that the FET might turn on randomly (i.e. if it's just being used as a signal inverter or level-shifter and it's known that the input will be stable before the output will be read, then the pull could be skipped to save space/cost). But for a deployment FET lack of a pull seems like an extremely bad idea, as it would lead to a much better chance of the FET accidentally firing during power-up before the micro is in full control of its outputs.
 
Have seen MOSFETs oscillate without series R in the gate (they make a Colpitts oscillator with the parasitics). Seen it twice in 30 years. I don't want it happening on my electronics. I use the series R... Don't need high value, typically 15ohm is used.

Pulldowns needed also. If you need the inputs to be floating for some clever function then design the cleverness differently. If you are relying on special sequencing of switches, what happens when the sequence doesn't conform to your expectationis. You need to design for off-nominal situations or bear the consequences. Incidentally, just had a weird problem here at work where an uninitialised processor was letting IO pins waft around and screwed with an attached module. The relevant engineer spent days chasing that fault and fixed it with a pull-down. The lesson is that if it is undefined at some time then make sure you do something to define it deliberately in that time. Nothing is worse than variability, except maybe unpredictability.
 
Last edited:
Series resistors to gates in MOSFETS is a best practice to limit in-rush current and provide stability. Probably not needed in hobby electronics but it is standard practice in industrial and commercial products where 5 9 component reliability is required. At least that is standard practice where I work.

Then I would assume he'd need BOTH resistors... correct?
 
Then I would assume he'd need BOTH resistors... correct?

Yes I suggested that several times. He explained how he is de-risking the system with an additional switch in the pyro lines.
 
Last edited:
Boris, your FET gate resistors need to be connected from the gate to GND, not in series with the processor outputs and the gates. This ensures that that gate will be kept at GND unless you explicitly send it high. On your PC board, you can simply run the resistor between the gate and the drain of the FET; it's often hard to find real estate right next to the processor pins to put them there.
Cris
I thought that is what I was saying
"For the MOSFET the resistors on the gate should be pull up resistors rather than from the Arduino output to the gate. You need to wire your resistor from ground to the gate."
On my altimeters with some of the mosfet I am using, it can accidentally turn on the charges if you do not have resistors from the gate to ground. So far I have noticed that problem with smt/smd resistors
 
Boris, your FET gate resistors need to be connected from the gate to GND, not in series with the processor outputs and the gates. This ensures that that gate will be kept at GND unless you explicitly send it high. On your PC board, you can simply run the resistor between the gate and the drain of the FET; it's often hard to find real estate right next to the processor pins to put them there.

My name isn't Boris, technically speaking, but I know this is typical practice, and I do this on other circuits. I'd love to find some automated way to add anti-brownout capabilities, but I haven't been able to think of one.

Series resistors to gates in MOSFETS is a best practice to limit in-rush current and provide stability. Probably not needed in hobby electronics but it is standard practice in industrial and commercial products where 5 9 component reliability is required. At least that is standard practice where I work.

This is what I was going for.

Cris
I thought that is what I was saying
"For the MOSFET the resistors on the gate should be pull up resistors rather than from the Arduino output to the gate. You need to wire your resistor from ground to the gate."
On my altimeters with some of the mosfet I am using, it can accidentally turn on the charges if you do not have resistors from the gate to ground. So far I have noticed that problem with smt/smd resistors

Right, I realize that having resistors there is a good idea too, and that a MOSFET that floats will stay where it is, more or less, due to internal capacitance and very low leak. However that loses the anti-brownout capabilities, which I was really hoping to have. I'd love to be able to have anti-brownout settings that don't need to float the MOSFETs, but I haven't been able to think of a way to do that.

In other news, I got my ATMegas in the mail and- after much wrestling- got them to work with my cheap $1.50 USB adapter. Of course, nothing ever works how I expect it to, so this means doing a bit of rearranging on the PCB. Not a big deal.
1222172223.jpg
 
So I'm still on the fence about anti-brownout. I did redo the board (again) and get the size down much smaller, 1.35" x 4". I should have no problem putting that in a 38mm coupler with a small 2S LiPo, which is good, because my testbed rocket is BT-60. My plan, since I can't legally do electronic deployment, is to test the pyro capabilities by staging LPR (with plenty of "dry" tests beforehand). Of course, then there's the issue of failed ignition. I'd love to have a backup, but I can't do electronic deployment. :mad:

Anyway, I'm pretty close to ordering boards for the first iteration. Anyone with ideas for brownout protection without introducing risk, please speak up!

Also, I'm considering selling these as kits at some point, once the design is really locked in. (CErving, I'm not trying to put you out of business, I promise... I just built an Eggfinder to make up for it.) That means I'd like to do a small beta run if anyone's interested- keep in mind that this is a beta run, so having a "real" altimeter as a backup is definitely recommended.
 
Last edited:
I thought brownout protection was usually done by attaching a large capacitor to the power input so if battery voltage dropped the capacitor maintained voltage for a few seconds. This probably wouldn't provide current to fire matches, but it would provide protection for voltage sag during flight.
 
I thought brownout protection was usually done by attaching a large capacitor to the power input so if battery voltage dropped the capacitor maintained voltage for a few seconds. This probably wouldn't provide current to fire matches, but it would provide protection for voltage sag during flight.

I am doing that somewhat- I have 100uF on each side of the regulator. Most "real" altimeters that do that probably have more, but for a momentary brownout 100uF could probably keep it alive. (Now that you mention it... I guess I could put a diode in so, in the event of a brownout, the unregulated-side capacitor would only power the processor, etc. rather than dumping charge "backwards" through the ematches. Hmm...)
 
Why do you think you can't do electronic deployment? Is it the black powder issue? Find an adult partner and do it.

Have you looked at the brown out features of the 328P? You can set the BO fuse at 2.7V. During flight you can write latest status data to the EEPROM. On startup you can either check the reset register to see if the reset was a power-on or brown-out reset. And/or you can write an "events completed" byte as part of your status bytes written to EEPROM. Then on power up you can check these bytes to see if you need to run a normal startup or invoke a recovery from a brown-out or black-out.
 
Why do you think you can't do electronic deployment? Is it the black powder issue? Find an adult partner and do it.

Have you looked at the brown out features of the 328P? You can set the BO fuse at 2.7V. During flight you can write latest status data to the EEPROM. On startup you can either check the reset register to see if the reset was a power-on or brown-out reset. And/or you can write an "events completed" byte as part of your status bytes written to EEPROM. Then on power up you can check these bytes to see if you need to run a normal startup or invoke a recovery from a brown-out or black-out.

The EEPROM thing combined with my current setup was kinda what I was thinking, and I'd love to be able to use the built-in brownout detection. However, I have two questions/concerns-

- It seems I have to modify the Arduino bootloader to enable brownout detection. This isn't something I've done before, and I'd like to avoid it if at all possible. However, if I can make minor modifications and end up with a more reliable altimeter, that would be fine.

- How is a brownout any different from simply disconnecting the power and reconnecting for the next flight? If you have to hit the reset button every time that's really no better than having a separate key.


About electronic deployment- I was under the impression that those under 18 can't do electronic deployment, going by this bit of text from the NAR Jr certification page:
National Associaion of Rocketry said:
[FONT=&amp]Model propelled by Hybrid motors require deployment charges external of the motor and these charges are currently regulated. For this reason, Hybrids cannot be used for Junior HPR Level 1 Qualification flights.[/FONT]

If electronic deployment is allowed but the BP has to be purchased by an adult, then I'd love to set up an electronic deployment system to test the ArdIU. However, I would have thought that the NAR would include something about that possibility if it were the case.
 
You do not really need the built-in brown out stuff if you are doing the EEPROM thing. On startup just check a status byte that would indicate if an interruption of power has occurred.

A brown-out is a drop in voltage below a threshold you set. When set, the controller stops running and resets. During the brown-out the controller might be still capable of running but it prevented from doing so.

Disconnecting and reconnecting the power is a "Black out".

For an altimeter you do not want the program to run while its on the "way" to a black out because program execution can be erratic. The stack pointer and the address of the next instruction is in static ram which becomes unreliable as the voltage drops. On the way down your program could jump to the part that fires your ematches.

So you set a brown-out threshold where the controller can still reliably run. So on the way to a black-out the controller safely stops program execution.
 
You do not really need the built-in brown out stuff if you are doing the EEPROM thing. On startup just check a status byte that would indicate if an interruption of power has occurred.

A brown-out is a drop in voltage below a threshold you set. When set, the controller stops running and resets. During the brown-out the controller might be still capable of running but it prevented from doing so.

Disconnecting and reconnecting the power is a "Black out".

For an altimeter you do not want the program to run while its on the "way" to a black out because program execution can be erratic. The stack pointer and the address of the next instruction is in static ram which becomes unreliable as the voltage drops. On the way down your program could jump to the part that fires your ematches.

So you set a brown-out threshold where the controller can still reliably run. So on the way to a black-out the controller safely stops program execution.

My issue with brownout vs. blackout is that they're basically equivalent when you have capacitors across the power supply, at least as far as I can tell. Both will be a gradual sloping off of VCC.

I could just incorporate the brownout detection using EEPROM, but my worry would be a situation where:
-Rocket fails, battery disconnects for whatever reason, say, bad mounting and over-violent drogue deployment. Altimeter remembers it has to fire the main still.
-Altimeter is restarted at home for ground testing, remembers that it "just" fired a drogue charge, and that it's below the main altitude. Therefore, fires main charge.

I guess the altimeter shouldn't be powered up w/ charges armed anyway, so this wouldn't be an issue in that case. However, I'd like to idiot proof it as much as possible, especially since I'm considering selling them- if someone singes their eyebrows with it, even if it was their fault, I'd like to avoid being responsible in any way.

About safe processor shutoff, I did a bit of research, and it seems the Arduino (Uno at least) firmware automatically shuts off the chip below 2.7V. However, I haven't been able to find a way to write a custom addition that would store its current flight status.
 
I could just incorporate the brownout detection using EEPROM, but my worry would be a situation where:
-Rocket fails, battery disconnects for whatever reason, say, bad mounting and over-violent drogue deployment. Altimeter remembers it has to fire the main still.
-Altimeter is restarted at home for ground testing, remembers that it "just" fired a drogue charge, and that it's below the main altitude. Therefore, fires main charge.

I guess the altimeter shouldn't be powered up w/ charges armed anyway, so this wouldn't be an issue in that case. However, I'd like to idiot proof it as much as possible, especially since I'm considering selling them- if someone singes their eyebrows with it, even if it was their fault, I'd like to avoid being responsible in any way.

About safe processor shutoff, I did a bit of research, and it seems the Arduino (Uno at least) firmware automatically shuts off the chip below 2.7V. However, I haven't been able to find a way to write a custom addition that would store its current flight status.

You will just have to be clever in your code. When the altimeter "recovers" it can determine:
- Its altitude
- If its moving
- going up or down
- Temperature

Based on this you should be able to write a safe recovery routine to avoid hazards like the one you mentioned. Think of everything that can go wrong and make sure you have code for each situation. FMEA is the technical term for the process.

OR you can keep it simple don't implement any brown out recovery (like most commercial altimeters). If it browns out the rocket crashes.
 
Would it be difficult to implement 2 power sources, one for the electronics and the other for deployment?

This is the idea I will be using in my custom electronics package.
 
Would it be difficult to implement 2 power sources, one for the electronics and the other for deployment?

This is the idea I will be using in my custom electronics package.

Yes, in theory- however, I'm not likely to do that on this, at least in the current iteration, as I'll mostly be flying small ebays where I can't afford to have that much extra stuff. With a bit of Raven-class electrical engineering it would be doable outside the board though-
-Battery (-) wired together, wired to input (-)
-Logic battery (+) to input (+)
-Right terminal of each pyro channel to ematch (left terminal is just VIN)
-Other side of ematches to pyro battery (+)

In other news, jderimig has given me faith in my programming ability, and I've finally given up on hardware brownout protection. Pyro channels will have pulldowns and the secondary key will get ditched. This is the one bit of unreliability I was worried about, so I feel like I'm almost ready for a run of these. My plan is:
-Do a run of PCBs for myself
-Make a library for Arduino (already working on it)
-Do some flying on my own to get the major bugs worked out
-Offer a small run of kits for beta testing (beta testers will get a lower price, first priority on help & support, plus my undying gratitude and maybe some other goodies)
-If beta testing goes well, transition into actually selling these as kits

Before I start on any of that, I have a "final" schematic. Quotes because I am as always open to suggestions.
ardiu_1_0_schematic.jpg

Thanks for the help everyone! Anyone who beta tests when I get to that point or has helped out on this thread will of course get credit on the final PCB!
 
Back
Top