Posts Tagged ‘PWM’

Lowering power consumption tip #3 – Using Relays

Monday, November 2nd, 2009 Nigel Jones

This is the third in a series of tips on lowering power consumption in embedded systems. Today’s topic concerns relays. It may be just the markets that I operate in, but relays seem to crop up in a very large percentage of the designs that I work on. If this is true for you, then today’s tip should be very helpful in reducing the power consumption of your system.

I’ll start by observing that relays consume a lot of power – at least in comparison to silicon based components, and thus anything that can be done to minimize their power consumption typically has a large impact on the overall consumption of the system. That being said, usually the thing that will reduce a relay’s power consumption the most is to simply use a latching relay. (A latching relay is designed to maintain its state once power is removed from its coil. Thus it only consumes power when switching – much like a CMOS gate). However, latching relays cannot be used in circumstances where it is important that the relays revert to a known state in the event of a loss of power. Most embedded systems that I work on require the relays to have this property. Thus in these cases, what can be done to minimize the relay’s power consumption?

If you look at the data sheet for a relay, you will see a plethora of parameters. However, the one of most interest is the operating current. (Relays are current operated devices. That is it is the presence of current flowing through the relay coil that generates a magnetic field that in turn produces the magneto-magnetic force that moves the relay armature). This current is the current required to actuate (pull-in) the relay. Not much can be done about this. However, once a relay is actuated, the current required to hold the relay in this state is typically anywhere between a third and two thirds less than the pull-in current. This current is called the holding current – and may or may not appear on the data sheet. Despite the fact that the holding current is so much less than the pull-in current, almost every design I see (including many of mine I might add) eschews the power savings that are up for grabs and instead simply puts the pull-in current through the relay the whole time the relay is activated.

So why is this? Well, the answer is that it turns out it isn’t trivial to switch from the pull-in current to the holding current. To see what I mean – read on!

The typical hardware to drive a relay consists of a microcontroller port pin connected to gate of an N channel FET (BJT’s are used, but if you are interested in reducing power, a FET is the way to go). The FET in turn is connected to the relay coil. Thus to turn the relay on, one need only configure the microcontroller port pin as an output and drive it high – a trivial exercise.

To use the holding current approach, you need to do the following.

  1. Connect the FET to a microcontroller port pin that can generate a PWM waveform. The hardware is otherwise unchanged.
  2. To turn the relay on, drive the port pin high as before.
  3. Delay for the pull in time of the relay. The pull in time is typically of the order of 10 – 100 ms.
  4. Switch the port pin over to a PWM output. The PWM depth of course dictates the effective current through the relay, and this is how you set the holding current. The other important parameter is the PWM frequency. Its period should be at most one tenth of the pull-in time. For example, a relay that has a pull in time of 10 ms, would require a PWM period of no more than 1 ms, giving a PWM frequency of 1 kHz. You can of course use higher frequencies – but then you are burning unnecessary power in charging and discharging the gate of the FET.
  5. To turn the relay off, you must disable the PWM output and then drive the port pin low.

Looking at this, it really doesn’t seem too hard. However compared to simply setting and clearing a port pin, it’s certainly a lot of work. Given that management doesn’t normally award points for reducing the power consumption of an embedded system, but does reward getting the system delivered on time, it’s hardly surprising that most systems don’t use this technique. Perhaps this post will start a tiny movement towards rectifying this situation.

Next Tip
Previous Tip

Lowering power consumption tip #2 – modulate LEDs

Tuesday, September 22nd, 2009 Nigel Jones

This is the second in a series of tips on lowering power consumption in embedded systems.

LEDs are found on a huge percentage of embedded systems. Furthermore their current consumption can often be a very large percentage of the overall power budget for a system. As such reducing the power consumption of LEDs can have a dramatic impact on the overall system power consumption. So how can this be done you ask? Well, it turns out that LEDs are highly amenable to high power strobing. That is, pulsing an LED at say 100 mA with a 10% on time (average current 10 mA) will cause it to appear as bright as an LED that is being statically powered at 20mA. However, like most things, this tradeoff does not come for free, as to take advantage of it, you have to be aware of the following:

  • LEDs are very prone to over heating failures. Thus putting a constant 100 mA through a 20 mA LED will rapidly lead to its failure. Thus any system that that intentionally puts 100 mA through a 20 mA LED needs to be designed such that it can never allow 100 mA to flow for more than a few milliseconds at a time. Be aware that this limit can easily be exceeded when breaking a debugger – so design the circuit accordingly!
  • The eye is very sensitive to flicker, and so the modulation frequency needs to be high enough that it is imperceptible.
  • You can’t sink these large currents into a typical microcontroller port pin. Thus an external driver is essential.
  • If the LED current is indeed a large portion of the overall power budget then you have to be aware that the pulsed 100 mA current can put tremendous strain on the power supply

Clearly then, this technique needs to be used with care. However, if you plan to do this from the start, then the hardware details are not typically that onerous and the firmware implementation details are normally straight forward. What I do is drive the LED off a spare PWM output. I typically set the frequency at about 1 kHz, and then set the PWM depth to obtain the desired current flow. Doing it this way imposes no overhead on the firmware and requires just a few setup instructions to get working. Furthermore a software crash is unlikely to freeze the PWM output in the on condition. Incidentally, as well as lowering your overall power consumption, this technique has two other benefits:

  • You get brightness control for free. Indeed by modulating the PWM depth you can achieve all sorts of neat effects. I have actually used this to convey multiple state information on a single LED. My experience is that it’s quite easy to differentiate between four states (off, dim, on, bright). Thus next time you need to get more mileage
    out of the ubiquitous debug LED, consider adding brightness control to it.
  • It can allow you to run LEDs off unregulated power. Thus as the supply voltage changes, you can simply adjust the PWM depth to compensate, thus maintaining quasi constant brightness. This actually gives a you further power savings because you are no longer having to accept the efficiency losses of the power supply

Anyway, give it a try on your next project. I think you’ll like it.
Next Tip
Previous Tip.