To estimate how much current the GPA draws can be quite difficult, depending on how accurate and detailed the information is that you’re after. But let’s start simple.

We could insert a multimeter between the entire circuit and the power source, but…

• The power consumption of digital circuits can fluctuate immensely – not surprising, when you consider that the µC itself can draw anywhere from a µA to several mA.
• All multimeters have a “burden voltage”, i.e. the voltage drop across the multimeter itself, caused by the internal resistor used to measure those currents.

The bad news is that to gain real insight into current use, we’ll need to use an oscilloscope.

But no worries: the good news is that we can estimate a few things with just a multimeter if we take some precautions. Let’s start by not relying on the multimeter’s built-in current measurements, but instead using Ohm’s law to help us out a bit. A 1 mA current through a 1 Ω resistor generates a voltage drop of 1 mV across that resistor – a bit low to measure well.

So let’s insert a 10 Ω resistor between the circuit and the power supply. A 1 mA current will cause a 10 mV voltage drop. Let’s also include a capacitor, to absorb any big current spikes:

The multimeter needs to be connected across the 10 Ω resistor (in parallel). The capacitor should be large – aim for 4,700 µF or more – and must be connected the right way around.

Measuring the voltage in the case of our GPA circuit, the readout will be around 0.30V, corresponding to an average current consumption of 30 mA. Now let’s do the math:

• an AA battery can supply 2000..3000 mAh before it’s empty, let’s assume 2000 mAh
• we can draw 30 mA of current for 2000 / 30 ≈ 67 hours, or ≈ 2.8 days

Whoa, this GPA design is a battery eater!

It gets worse. That “average” current consumption actually looks completely different on an oscilloscope, when the large buffer capacitor is removed:

The horizontal scale is 10 ms per division. And yes, those are 1.8V spikes across the 10 Ω.

Ignoring for a moment that the supply voltage to the IR sensor is now far from being a clean 5V, we can see that the IR sensor is nasty: lots of brief 180 mA current spikes.

There are some very interesting guesses to make from this as to how the IR sensor actually works, but the really bad news is that it’s a pretty horrible sensor for battery operation.

Let’s fix this

A circuit which devours four AA batteries every few days is useless, but all is not lost. An effective trick for power reduction is to do things less often. If we were to enable the IR sensor only 1% of the time, and if we can reduce power consumption to near zero the other 99%, then that same battery would last 100 times longer, i.e. over 250 days in this case.

Idea: we don’t need to measure distance continuously – once a second would be fine.

But there’s a second nasty detail in that IR sensor, and it’s mentioned in the datasheet:

The IR sensor needs some 50 ms to deliver its first reading after power up. With once-a-second readout, we’re going to have to keep it powered up at least 5% of the time. That’s 1/20th of the time, so the battery life will increase from 67 to 1,340 hours, i.e. 56 days.

It’s a start, but replacing batteries every 8 weeks is still not a terrific outcome.

Note that the actual measurement cycle is clearly visible in the above oscilloscope capture: a new measurement burst is being started just about once every 40 ms.

Working back

Let’s turn around and estimate how often we can measure and still get a year of battery life:

• the sensor must have power for at least 50 ms to produce a measurement
• while powered up, the circuit draws 30 mA
• at 30 mA, the batteries will last 67 hours
• we need to keep them running for a year, i.e. 365 * 24 = 8,760 hours
• so we can’t have them on more than 67 / 8,760 * 100 ≈ 0.76% of the time
• each measurement takes 50 ms with the IR sensor powered on
• 0.76% duty cycle represents a 50ms / 0.76% = (50/1000) / (0.76/100) = 6.6s period

Let’s add a 50% margin: it should be possible to run for a year with a 10s readout cycle.

This is bad news – our GPA would be a very sleepy parking aid if its sensor only reported distances once every 10 seconds! Better stick to the once-per-second readout, it seems like a good level of responsiveness. We’ll need to find other tricks to reach that 1-year goal.

And let’s go after that 8-week goal first – it’s a 20-fold improvement, after all.

Switching off

We need to totally power down the IR sensor under µC control. There are several ways to do this, but a simple one requiring only a few standard components is with a P-MOSFET:

Here’s another, more oblique view:

Note very carefully the polarity of the different components in this image:

• 3-pin voltage regulator on the bottom left: the flat / labeled side is facing down
• 3-pin P-channel MOSFET on the top right: the curved / labeled side is facing down
• a handy reminder with both 3-pin components: the labels are facing down
• 47 µF round electrolytic capacitor: gray band left and a (longer) “+” lead right
• both red LEDs: the flat side to the left and the long lead is to the right
• the dot is near pin 1 of the LPC810 µC – all other components can go either way

Pin 3 of the LPC810 now goes to a 2nd red LED and some other circuitry. The IR sensor’s power (red wire) is now connected to the P-MOSFET. The MOSFET resembles the voltage regulator, but is labeled “ZVP/410/5A” – don’t mix ’em up or connect either one in reverse!

There’s some trickery involved. The problem is that a P-MOSFET requires a high gate voltage to turn off, and 3.3V isn’t always high enough. The 100 kΩ “pull-up” resistor plus red LED address this issue, using the LED as a voltage “shifter” (it’ll blink very faintly).

The code, as included in 4-power on GitHub is essentially just this modification:

int getDistance () {
    LPC_GPIO_PORT->CLR0 = (1<<3);       // power up the IR sensor
    delay(50);                          // give it time to settle
    int v = analogMeasure();            // measure the voltage
    LPC_GPIO_PORT->SET0 = (1<<3);       // power down the IR sensor
    return v;
}

Plus some setup to use pin 3 as an output pin. The code from 2-analog and 3-distance has been combined: on start-up, we first send 10 measurements to the serial port for debugging and then switch over to the “production mode” LED-blinking behaviour of the GPA.

Does it work?

If you’ve uploaded software into the LPC810 chip before, then upload this code to it now.

If you’re using the pre-loaded chip from the shop, then the proper code is already on there.

The first thing to check (after double and triple checking your breadboard setup!) is that it all still works as intended: move your hand in front of the sensor and verify that the LED still adjusts its blink rate according to the measured distance.

If not: power off, re-check, get some coffee, re-check, fix, and try again – until it works.

Can we verify that our power consumption has gone down? Sure: by again using the same 10 Ω + big capacitor setup to average out the current, we can measure the voltage drop – it fluctuates between 15 and 65 mV: the average current consumption will be about 4 mA.

This corresponds to 2000 mAh / 4 mA = 500 hours, or ≈ 21 days on a fresh set of batteries. Although an order of magnitude better than before, it’s way less than our 8-week estimate.

Looks like our battery-life estimates were considerably off … but why?

[Back to article index]