On Fri, 25 Feb 2011 23:22:03 -0800, DK Duncan <[email protected]> wrote:
> Does anyone see any unknown side effects to this change?  Aside from
> this file, I haven't looked much further into the code.

Well, I don't think you'll really hurt anything, but there are two
issues to ponder.  

The first is that because we're putting a very low resistance across the
LiPo when firing a pyro channel, and LiPo batteries have a very low
source impedance, there's a *lot* of current flowing.  As long as your
match actually fires and goes open in something like 150ms, you should
be ok, but if somehow the match retains continuity, you're going to
drain a lot of energy out of the battery and warm up some traces in 2
seconds. 

The second is that there's a risk of pulling the 3.3 volt rail down far
enough to cause a processor reset if you keep the FET "on" with a low
resistance across the pyro terminals for long enough.  I put a 100uF
ballast capacitor on the 3.3V rail which is on "the other side of the
regulator" from the LiPo to help protect against this eventuality, and
again, as long as your matches actually go open in a couple hundred
milliseconds, all should be fine.  But if you have a short across the
pyro terminals and leave the FET on for 2 seconds, you should expect the
processor to reset leaving you in a pretty seriously undefined state!

When we were switched to this pyro circuit for v0.2, I did some serious
bench testing with different commercial e-matches and the Quest Q2G2
igniters, and discovered that they all fired *really* fast.  That's how
we ended up with 50ms.

> What would be very nice is to allow this value to be specified as a
> parameter in a setup menu. I may look into adding that code if any one
> is interested.

Yes, we've talked about supporting that before.  I don't think it would
be hard to make that change, but we're constantly on the verge of
running out of flash space.  If you can make it clean and small, then I
suspect Keith would accept such a patch.

> Also, before making the change, I compiled the firmware and compared it
> to the distributed versions.  They don't match.  Any ideas why?

If you built from the head of the master branch, you're building our
latest "unstable" code.  Look for tags marking where the various release
points were if you want to rebuild one of those.

Bdale

Attachment: pgpRSj8HTkdR2.pgp
Description: PGP signature

_______________________________________________
altusmetrum mailing list
[email protected]
http://lists.gag.com/mailman/listinfo/altusmetrum

Reply via email to