Let’s imagine that you need to add a power switch to something that’s battery-powered but processor-free; perhaps it must also be waterproof and thus membrane-sealed. Or perhaps you just want to use a shiny modern push-button rather than a toggle/rocker/slide thingy, which may be cheap and reliable, but would look so last millennium.
This design idea (DI) shows how to transform a basic momentary push or tact(ile) switch into a latching bi-stable device. It’s shown in Figure 1.
 |
|
| Figure 1. | Two transistors form a power-switching latch, which can be set (power on) by a short button-press and then reset (power off) by a longer one. |
Q1 and Q2 are cross-coupled to form a latch, Q1 being the actual power switch which is controlled by Q2. Initially, both are off. Pressing Sw1 briefly injects a pulse through C1 into Q2’s gate which turns it on, thus also turning Q1 on to deliver power to both the downstream circuitry and Q2, latching both transistors on.
Holding the button down for around a second allows C2 to charge up through R4 until Q3 starts to conduct, thus shorting the drive to Q2’s gate and breaking the feedback loop, so that Q1 and Q2 both turn off. Opening the switch lets C2 discharge through D1 and R5, ready for the next cycle. When off, the circuit draws only leakage current.
Some components are marked TBD, because while the circuit as a whole can work with supplies anywhere from 3 to 20 V (or more, if Q1 is suitably rated), individual parts or functions may not. Typical values are:
| Supply | R2 | R4 |
| 3 V | 0R | 100k |
| 6 V | 0R | 330k |
| 12 V | 100k | 680k |
| 20 V | 300k | 1M0 |
R2 ensures that Q1’s gate-source voltage is enough to turn it on fully without causing its gate-protection diodes to conduct. R4 keeps the “hold-for-off” time close to a second. Other points to watch include Q1 itself. The IRLML6402 has a 20-V drain-source rating, an on-resistance of 50–100 mΩ under our conditions, and a gate-source breakdown of 12 V. It only needs 1.2 V to turn it fully on, when it will easily handle an amp or two.
Q2 and Q3 are not critical, though proper logic-level devices might be better than the ZVN3306As. If Sw1 is pressed while the circuit is on, C1 will still deliver a spike to Q2’s gate, briefly driving that to twice the supply voltage. This should be clamped by Q2’s input protection diodes, but if you don’t trust that, fit a catch diode from the bottom of C1 back up to the input rail. Those same protection diodes may also conduct with high supply voltages, the current being limited by R3.
If the switch button becomes jammed down for any reason, the circuit will stay off, though R5 will still draw some current.
Automatic turn-off
As it stands, all this works well with loads from nothing up to that amp or two and with load capacitances up to at least 100 µF. But it might be useful to add something to turn the power off automatically several minutes after the latest button-press, and Figure 2 shows how to do that.
 |
|
| Figure 2. | Adding an oscillator/counter can turn the circuit off automatically after a suitable delay. |
This adds a CD4060B oscillator/counter to the mix. It’s powered from the output, and oscillates at about 13.7 Hz – at least, my sample did – while the circuit is on. After about 10 minutes, its count reaches 8192 and Q14 goes high, charging C2 through D2 to turn Q3 on, and Q2 and Q1 off. Any extra presses of Sw1 reset it, restarting the timing cycle.
The CD4060B is a 3-to-18-V part, which is why the voltage rating of the Figure 2 circuit is lower. (Data sheets claim 20 V is survivable, but I lost one at 19 V while experimenting. Beware! And that explains R8, added to avoid any spikes taking out the reset pin, which is what happened.) Because the load capacitance needs to discharge adequately to avoid the circuit restarting, it should now be no greater than about 10 µF, at least with light loads. I couldn’t find a simple (meaning cheap and reliable) way of draining or even crowbar-ing it at switch-off: thought that should be easy; it wasn’t.
Using counters and logic to control everything would be nice, but even more elaborate unless a microcontroller were handling things. Such an approach would need far less hardware and have many opportunities for extra, interestingly-coded features – but wouldn’t it be cheating?
