The mosfet idea puts the battery voltage on the Gate, the Source tied to ground, and a resistor from the Drain to a programmable pin on the microcontroller. When the programmable pin is 0v, pretty much zero current is flowing because the Gate is essentially infinite impedance.
When I want to figure out the battery voltage, I turn on the programmable pin to 5v. The voltage on the Gate controls how much current goes through the transistor which controls the voltage across the transistor. Sampling the voltage across the transistor, and guessing what the Vgs-to-Vds amplification factor of the transistor is, I can figure out what voltage must be on the Gate. The problem is the amplification of the transistor varies from part to part and varies even within the same part over temperature differences. I'd have to somehow calibrate for all this and if the difference between a 50% battery and a 25% battery is only a quarter volt, I have to be accurate about it. And I don't like calibrating things. The only other solution I've come up with is, like you mentioned, a reed relay, or to avoid mechanical wear and tear, an opto isolator. Turn on the diode enough that the transistor side saturates, and the optocoupler acts like a relay and there's no calibration needed. This would let me isolate the 12v from the 5v and keeps the 12v from pushing through the ESD diodes on the microcontroller pins. I take a programmable output pin, put a small resistor on it to turn the diode on all the way, and put the pin to 5v when I want to sample and 0v when I want to conserve power. The transistor side of the optocoupler has the collector tied to the 12v battery and the emitter goes to a voltage divider to bring the 12v down to something less than 5v so the ADC can handle it. This is basically how it works now, but with a relay/coupler on the 12v end to disconnect the divider from the battery when its not being used. Then I just have to turn off the diode when I'm not sampling and leave it off long enough so that the "on" time plus "off" time averages out to be less than the 100 uA continous current leak I have now. Maybe I sample the voltage once a minute, even if I blink the LED's every couple of seconds. Then when I average out the power consumed by the battery sampling circuits, it works out to be equivalent to a 10uA continuous leak or something. The main thing is no calibration needed. Greg > Greg London wrote: >> I was hoping to figure out a way to turn off the voltage divider, but >> so far I havent figured out a way that doesnt do it with less than 50 >> uamps. > > You mentioned you were going to try putting a MOSFET in series with the > voltage divider. So you're saying even with a MOSFET in the off state, > you're still getting too much leakage current through it? Or the > MOSFET's support circuitry is leaking? > > This doesn't sound like it should be a hard problem to solve. > > > As you mostly only carte about current consumption during the off state, > you could always use a reed relay. :-) It'll get you zero leakage > during the sleep cycle, but likely double your circuit's consumption > during the wake cycle. > > Though even with something like a reed relay that can handle very high > cycle counts, I wouldn't be keen on a design that cycles it every few > seconds perpetually. > > > The other thought I had was to use a much higher impedance voltage > divider, which you'd then need to buffer through an op-amp. Then the > challenge becomes finding a super low current op-amp and the > complication of adding anther part. > > > Another possibility would be to leave the bottom leg of the voltage > divider open, and use the input impedance of the A-to-D for that. Here > again you could switch to much higher value resistors. The input > impedance is probably not very consistent from part to part, but likely > stable over the life of the part. The upper leg would need to be a > variable resistor to allow for calibration, and that would incorporate > compensating for the unit variances in impedance. (There is a > possibility that the input impedance may vary as the A-to-D takes a > sample, depending on its design and whether it has buffering.) > > I like this last approach the best, but you'd have to do some > experiments, first on the bench, and then in some real world conditions, > to make sure it isn't thrown off by noise. > > Drew will probably have some better suggestions. > > -Tom > _______________________________________________ > Hardwarehacking mailing list > [email protected] > http://lists.blu.org/mailman/listinfo/hardwarehacking > -- _______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
