Ultra low energy switch detection?

Are you interested in paying for this engineering or just mooching?

tm

How fast do you need to respond? How noisy is the environment? Are there other considerations (how clean is it, how much current leakage when the switch is 'open')? Does your processor have a really low-power 'sleep with clock' mode?

Using a high pull-up resistor would reduce current, as would waking up the processor periodically to sample the switch.

Debounce is an issue, but why not let the processor sleep while it's waiting for the switch to debounce? Or just check the switch seldom enough that the bounce will always settle out? Or assume that any transition is "real", then wait out any bounce before you recognize more transitions?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

I have heard of microprocessors that have power consumption roughly proportional to clock frequency. Many of these have power consumption getting impressively low when clock frequency dips down to audio frequencies.

As for a micropower clock oscillator: A 4049 stage with a resistor from output to input and a capacitor from input to ground oscillates. Have the output go through another stage of the 4049 to clean it up somewhat.

Put a .022 uF capacitor from Vdd pin of the 4049 to ground, and put a high value resistor (100K to 470K ohms ? ) between Vdd pin and positive power supply.

From the 4049's final output, add a resistor from output to positive power supply for pullup to full supply voltage of the microprocessor. The 4049UB ("4000-B-series CMOS 4049") was designed for "logic level conversion" with pullup to a voltage higher than that at its Vdd pin.

If you need cleanup to shorter risetimes and falltimes, use additional stages of the 4049. Maybe add a stage or 2 of a 40106 into the "cleanup chain", but make the last stage of the "cleanup chain" a stage of the

4049 since the 4049 can use a pullup resistor for "logic level conversion".

I publish a "4049 abuser" used to pulse a high-efficiency LED at an instantaneous current at which it is more efficient, with a low duty cycle. The purpose is to light an LED to brightness useful for use as an indicator lamp at 50 microamps, which is a low amount of current where most LEDs do not work efficiently.

Look for the schematic in:

(I hope I got my "4049 abuser" schematic correct there!)

--
 - Don Klipstein (don@misty.com)

SNIP

Use the switch with pullups.... In sleep mode, turn off the pullups etc..Use an external pullup of xMeg. In sleep mode, with an Atmel Mega48 running internal 8MHz RC osc., I get sleep current of

One option depending on how fast you have to respond to changing state is to have the CPU wake up at a very modest clock rate and then if it has to do real work switch to a faster clock. PICs provide a means to vary RC based system clock speed with a little ingenuity.

Slugging the switch with a bit of RC or debouncing it switch with discretes or a humble CMOS 555 might be another option.

You have to state your power budget and timing requirements before meaningful answers are possible. A very tiny current drain can sometimes increase battery life. Your idea of ultra low power may not coincide with mine.

How many years does it need to run on say a pair of AAAs or a button cell?

It is usually fair game to assume that a transition means the switch has changed state and allow a dead time after the initial transition. This is less costly if the CPU clock is relatively slow eg ~10kHz.

Regards, Martin Brown

Fussy fussy.

If you want really low power, glue a piezo to the side of the switch, and use that to generate the pin-change interrupt. You might need a bit of protection on the MCU input though (start with 10k series resistance).

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058

email: hobbs (atsign) electrooptical (period) net
http://electrooptical.net

How about charging a small capacitor, say about 150 pF through a large resistor, say 20M, while the switch is open. When the switch closes, it dumps the cap into the port pin. As Tim said, don't allow the processor to wake again for the switch bounce time, probably somewhere around 10 to 50 ms. Or, maybe it is possible to adjust your values such that the cap discharges completely on the first bounce.

Just a thought.

Cheers, John

If the switch closes once per second, the average current drain would be about .75 nA. I think that would make no difference to the battery life.

John

Arrrgh! I meant on the first contact before the first bounce.

John

Thanks for the input. I need just a little more detail. I haven't been able to come up with any cap-related topology that allows detecting BOTH transitions of the switch without wasting current through the switch. If the switch maintains current when it's closed, I might as well use a pullup. If the switch current is zero, the circuit can't tell when it opens. yes???

When the typical cpu sleep current is 100nA, a couple of microamps per pin for pullups is a BIG percentage. Once you give up and poll the switch, it becomes trivial, but costs cpu energy.

I don't think a solution exists, but if we took that attitude, nothing would ever be invented.

So, I'm here polling the greatest bunch of designers on the planet.

I missed that part. What I proposed will not detect both transitions either.

Sorry.

Well, an SPDT switch would be the easiest thing. Connect the pole to ground, and the throws to two processor pins with internal pullups. Turn off the pullup on whichever pin is grounded, and wait for the other one to go low. In the interrupt handler, toggle the pullups and the interrupt mask, so you're waiting on the other pin and not wasting power.

You can put caps on the pins if you like, and if you don't have level-sensitive interrupts, you should check periodically to make sure you aren't waiting for something that can't happen.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058

email: hobbs (atsign) electrooptical (period) net
http://electrooptical.net

What processor are you using ??

Nope. Such a circuit cannot remotely compete with a conventional transistor oscillator for ultra olw power.

--
Many thanks,

Don Lancaster                          voice phone: (928)428-4073
Synergetics   3860 West First Street   Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml   email: don@tinaja.com

Please visit my GURU's LAIR web site at http://www.tinaja.com

I have already achieved 5-6 microamp current consumption by a 4049 and its associated components for an oscillator.

Also, I have tried my hand at 2-transistor "direct coupled oscillator" for low power consumption. Maybe I did not try hard enough, but I did get whatever I do giving me worse results for very low duty cycle and low current draw when frequency gets up to around or over 100 Hz.

Or, is what you had in mind being the astable multivibrator? How good is that at extreme duty cycle with current draw only a few microamps?

--
 - Don Klipstein (don@misty.com)

Well, you could use something power-stingier than your main CPU, and have it do the polling... and it could apply the microamps of pullup for a few microseconds per 50-millisecond cycle, then the average pullup current is only a few picoamps. Saturating-transformer switches (these are activated by a permanent magnet saturating a toroid, strobed by pulsing a primary, and sensed at the secondary winding) will work reliably with a submilliamp current for a small fraction of a microsecond. I've always wondered what the low limit on power was for that switch style, with dynamic logic (pulse-only clocked logic).

How fast does the response need to be? You only need to power the pullup resistor just before checking the switch, and you probably don't need to check the switch all the time. And why do you need to run the processor during debounce? It seems like a very low power circuit wouldn't be running fast enough to see bouncing.

--
I will not see posts from Google or e-mails from Yahoo because I must
filter them as spam

You can run an entire PIC 16877 with a 32kHz crystal and a direct drive LCD display for around 10-12uA on 3v. Making it sleep about half the time would get the average current consumption down to 5uA.

The OP hasn't answered the question of what battery and for how long this is expected to run. There isn't a lot of point in making the current draw so low that noise immunity suffers, or the battery shelf life expires and it starts leaking due to corrosion before it runs down.

For instance 10uA from an AA cell with nominal 2000mAh capacity would last for ~2x10^5 hours or around 20 years and button cells typically around 200mAh will last a couple of years.

Regards, Martin Brown

Switch closes. Processor runs at 4MHz for 100 instructions or so deciding which interrupt happened and what to do. Put processor to sleep. How do I keep the interrupt from happening on the bounce? If I wait, how do I tell when the wait interval is over without running the CPU? Or at least some internal timer that I don't have.

It seems like a very low power circuit

If you're gonna poll the switch or use a DPDT switch, the solution is trivial. But to get the desired resolution, I'd have to wake up the processor about 5000 times for each switch close.

Let's not go off on tangents. The switch isn't the only input. The processor runs at 4MHz. to service the other interrupts. Yes, with a sufficiently capable processor, one could use multiple sleep modes and clock frequencies. That's for another thread. The additional complexity isn't worth saving a couple of microamps of pullup current. This thread is about SPDT switches. Like I said in the "in the interest of focusing the input" section... I'm not interested in discussing WHY. I'm interested in HOW. I think there is probably NOT a solution. Thought maybe someone might have a clever solution. Looks like that's not the case. Might as well close the thread and move on.