A look at Load-Dump and other transient conditions

Part of the run I did yesterday (using PID-Lite) included seeing how the system responded to sudden changes in battery voltage.  Specifically I switched on and off 2250w's of heating elements via one of our inverters.  The debug data from the controller showed:

•    Max transition DOWN noted:   -1.38v    dip @  -194V/s rate.   (Application of 2250w load)
•    Max transition UP noted:       +460mV raise @  +284V/s rate.  (Removal of 2250w load)

I am most concerned about overshoot and am pleased to report the controller responded by capping the UP transition to 445mV over 'target', and brought it back to under 30mV  in two sample cycles (261mS ). 

This got me to thinking about a condition called Load Dump (where the battery is disconnected while charging) and how the controller would respond.  Load-dump is characterised by a large raise on voltage over a short time (typical specs seem to 'define' it as around 100v with Tr = 5-10mS).  There are three  ways the controller might be able to detect a load-dump condition:

1. Normal regulation functions (ala the response to the load transition above)
2. VBat > VBAT_ERROR error trap, causing controller to fault out.
3. VBat > Crowbar hardware trap, causing fuse to blow.

Obviously the methods increase in their side effects, so I was wondering if I could add a step between 1 and 2 - looking at dv/dt  to decide if there was a Load-Dump occurring   Then we could take a less dramatic action then blowing the fuse (a method #3), perhaps by setting the Field_PWM = 0 and re-entering RAMP phase.

First step was defining what a Load-Dump is...   Turns out this has been done before.  In fact, there are may transient conditions in a 12v system that need to be considered (Mostly from the side of what an electronic  device needs to be able to survive in an auto).   One the best documents I have located on this is:  ST Micro's "AN553: Protection Standards Applicable to Automobiles" (here).   And here is a nice table documenting what we can expect:

 The ones of interest right now at  Power cut-off (disconnecting a large load, like I did above), switch bounce (noise generated from switch bounce of a load), and Load dump.  And the question is:  Can we recognize these conditions by looking at dv/dt and decide how to handle them nicely?  (Rather then the steps 2 or 3 above which rely only on the absolute voltage levels?).

First need to define dv/dt for each of the three conditions   Looking deeper in the referenced App Note (and other sources) each of the events have a Vp of around 100v, but dramatically different characterized rise times:

• Power Cut-off:       Tr = 1uS
• Switch Debounce:  Tr = 5nS      
• Load-dump:           Tr = 5-10mS

The 1st two in nS and uS time-frames are not manageable by our regulator (which works in mS timeframes).   Electronic devices need to be able to accept them on their 12v input, using suppression techniques, but for us to be able to use a massively slow Alternator and respond to them is not possible. When  attaching an O-Scope to the 12v line I can already see lots of sub 1uS noise spikes (+ and -) on the line.  The truth is, though they may be high voltage, their time is so short we do not need to concern ourselves with them - from a regulation standpoint. 

 However, perhaps we can recognize Load Dump and do something.  There seem to be several 'standards' in existence that 'define' the shape of a load-dump, in looking at several of them I select the following:

• Voltage raised from 14v to 85v
• Over a time period of 7.5mS  (Half way between 5 and 10mS)

That gives us a dv/dt of (85-14)/7.5e-3    or around 10,000v/S, which scales into 10V/mS.

So, at 10V/mS what can we do from within the program?  Not much...

The INA-220's are sampled in lock step with the stator - at 2600RPMs this is about every 35mS on my system. This would allow a 350V rise to occur before the system would even be able to recognize something was happening - clearly well past when the crowbar steps in.

Bottom line:  The controller really does not have the responsiveness needed to 'recognize and address' a load-dump other then what already exists.  So will not be adding in any 'load-dump' routines.  It does handle EXPECTED transients nicely (See above),  and will handle unexpected transients (like Load-dump) - probably by blowing the fuse.  But then, if there is really a load dump I suspect a $0.10 fuse will be the least of the concerns. . . .