Re: My Battery Monitor

["Darrell N." <darrelln@datalog.ab.ca>]

Lee wrote:

> Remember that you are monitoring a VERY noisy battery, in a VERY harsh
> environment, with huge noise levels, temperature extremes, shock,
> vibration, acid, etc. Here is what I think is important:

You're bang on, Lee.  Careful thought is important before you even start 
ordering parts.

> 1. The box you put it in.

Pot it in epoxy or silicone potting compound.  Impervious to all but a 
hammer.  If it blows up, throw it away.  One of the main concepts here 
is to keep it cheep enough that you don't squirm too much if you have to 
replace one.

> 2. The voltage reference.
>    - what is its initial accuracy?
>    - is it temperature stable?
>    - how much does it drift with time?

Select the proper device, with the specifications you need.  

>    - are they repeatable? will different boards match each other?

This is not a real big issue, since you can build in calibration constants 
in software (aint it wunnerful) and ensure that they all read the same 
regardless of component tolerances.

> 3. The power supply.
>    - can it provide stable power to the micro despite huge noise levels? -
>    is it protected from reversed voltage? - protected from "load dump" type
>    overvoltage transients?

There are lots of off the shelf voltage regulators which have built in load 
dump and reverse transient protection.  Automotive electronics is a big 
market, and the chip houses scramble to keep automotive customers 
happy.  Again, do your homework.
 
> 4. The watchdog/reset circuit.
>    - will it reliably start if the battery is pulled dead, and then
>      the voltage s-l-o-w-l-y rises slowly as it gets recharged?
>    - will it reliably detect "crashes" and reset the micro?
>    - will it reset the micro even after a pin is hit with a static zap?
>      (many micros "latch up" if a pin is forced below ground or above
>      supply voltage, and won't reset properly until power is removed
>      and then re-applied)

Protect all I/O pins that go outside the box with suitable ESD protection.
Watchdog timers usually are only as good as the software used to run 
them.  For instance, don't reset the watchdog from within an interrupt 
service routine, because the main program can crash but the interrupts 
can still be running.  Hopefully, the processor will have an illegal opcode 
trap, and other reliability features.  Make sure all unused interrupt 
vectors point to the Reset vector.  Use an external Low Voltage Inhibit 
device on the reset line to prevent power related glitches.
 
> 5. Connectors.
>    - will they corrode or fail when dirty? wet? if acid gets on them?
>    - can they be hooked up wrong? if so, what happens?

Can't beat a crimp on terminal for reliability.  If you hook it up 
backwards, it's yer own damn fault.  Communications can be handled 
using screw type PCB terminals, or fly leads with keyed automotive 
watertight connectors.
 
> 6. Isolation.
>    - what provides isolation? a single component? what if it fails?
>      (example; inexpensive optocouplers have a thin piece of plastic
>      between LED and phototransistor. If it over-heats, say from
>      excessive current, the plastic melts and you lose isolation)

Optocouplers are pretty reliable.  Make sure it (and the rest of the 
circuit) is protected from high currents.  (ie fuses, polyswitches, etc) 
Get the ones rated for use directly on AC line applications.  They have a 
list of approval initials (UL, CSA, VDE, etc) as long as your arm, and 
are rated for use in consumer items to isolate you from the AC line.  

> Software is another troublesome area. Most internal A/D's are successive
> approximation types, which are very poor at rejecting noise. You either
> need aggressive external filters, or sophisticated software to digitally
> filter the signal. On one project where we used a PIC to monitor battery
> voltage, we had to take 10,000 samples, eliminate obviously bad ones (noise
> glitches, etc.) and calculate a running average to get usable data.

Come on, Lee, 10,000 samples?  If you couldn't get a decent reading 
after 16 or 32 samples, it was time to throw it all out and start again.
There had to be some serious design flaw(s) for things to get that bad.  
Garbage in, garbage out...

> Networking software is another challenge. It is one of the more
> difficult things to get micros do do reliably. Simple schemes will
> crash, lock up, or allow one micro to take down the whole system.

This is something I wanted to comment on.  One of the other list guys 
mentioned having each device receive data from the last, tack on it's 
own data, and pass it on.  This does not sound like a good idea.  If one 
unit fails, all the others fail as well.  It's also very difficult to time this 
type of system, and the unit which initiates the transmission would have 
to be different from all the rest.

The best way, IMHO, is to set up some sort of addressable bus 
architecture, where a master unit polls each slave in turn for it's 
information.  Each slave would have it's own unique address, perhaps 
set by DIP switches.  The devices would simply need some sort of open 
collector output, and the master unit pulls the line up.  If you have an 
isolated system, you could pull the line up to 12V or even higher, to get 
good noise immunity.  Some sort of current loop approach could also be 
used for even better noise immunity.  Pulling the line low would be a "1" 
bit, leaving it high would represent a "0" bit.  Timing is critical, time each 
mark and space, and define a length of idle time that signifies end of 
transmission, or pre- define a transmission length, or number of bits, or 
an EOT sequence.  Use a checksum to verify data.

The slaves would speak only when spoken to.  This will eliminate most 
instances of  bus contention, timing problems, latchup, etc.  It would 
also generally allow the system to identify bad slaves and ignore them if 
necessary, whilst still allowing the other units to work.  Take a look at 
Dallas Semiconductor's "one wire" protocol, or the Phillips I^2C bus.  
This will give you some ideas of how to proceed.

> All these problems are solvable, but it takes some thought and effort. It's
> not as easy as throwing a few parts on a board and writing a few lines of
> code! 

Amen to that!


darrell n
Calgary, Alberta, Canada