Snooze Button For Blues Wireless Notecard Alerts

Machines don't really grasp the concept that they can be annoying... ¯_(ツ)_/¯

This became incredibly apparent to me while I was building the Remote Alerting Mailbox Project. The first overnight rainstorm generated over 100 alerts, each complete with its own text message. Not only was I losing sleep over the incessant SMS alerts, but also my dwindling Twilio balance!

Rock 'n Roll All Night...

Rock 'n Roll All Night...

Just write some code, right?
Well, sorta.

The typical model for designing a low-power application using the Notecard is to configure the Notecard to disable/enable the host microcontroller based on certain events (e.g. timer, motion, incoming message, etc...). When used in this manner, the Notecard can idle at ~8uA, and your host can be awakened for a specified condition. This allows you to maximize battery usage, by only consuming the power necessary for a specific computational task, then returning to rest at near zero power consumption.

A side-effect of this model is that all volatile memory is discarded each time the host microcontroller is disabled. Therefore persistent, or non-volatile, memory is required to maintain state across reboots. This could be achieved using an EEPROM, or by allowing the Notecard to maintain your state (another one of it's great features). However, the state I'm trying to maintain (deciding whether or not to generate an alert) is not well suited for a sleepy microcontroller.

Codes?! Where we're going, we don't needcodes...

My circuit is based on componentry found in this modified Delorean.

My circuit is based on componentry found in this modified Delorean.

I was describing my conundrum to a dodgy Austrailan guy, and he encouraged me to watch a soft switch video from another dodgy Australian, Dave Jones of the EEVblog. It turns out Dave's soft toggle-switch implementation works brilliantly for my application.

Unlike the soft toggle switch, which is driven exclusively by a momentary switch. The Snooze Button works as a two-way switch, bridging between mankind and machine. That is to say, the state can only be set to ON by the MCU, and can only be set OFF by a mechanical push button (i.e. human intervention).

The Snooze Button is comprised of an PNP and NPN transistor working in concert. Theoretically, the collectors of the PNP and NPN transistors will latch the corresponding transistor's base open or closed. Although in practice, inducing this behavior requires the assistance of a pull-down resistor.

In order to function, the circuit requires a connection to power and ground, as well as a test line connected between the collector of the PNP transistor and the base of the NPN transistor. When latched open, the test line will have a voltage equal to the power source, and when latched closed the test line will equal ground.

To activate the circuit, it can be "jump started" by providing a voltage on the test line. To reset the circuit, the base and emitter of the NPN transistor can be shorted to ground.

By including optimal sized resistors in the circuit, power loss can be minimized. The circuit in the schematic below, consumes 60µA when the transistors are closed, and 600µA when the transistors are open. While this uses much more energy than an idling Notecard, it is still superior to a sleeping MCU and was easily supported by my solar power solution.

The Notecard conserves battery by disabling the host MCU, which makes maintaining state and capturing button presses more complicated than usual. By using a circuit to capture this logic, we can simply bypass this concern.

The Notecard is designed to wake the host MCU, after a predefined event has occurred. Often alert events only need to be reported once, until human intervention has reset the system into a good state.

By using a circuit to determine whether or not an alert should be sent, the computation required by the host MCU is greatly simplified. Now, the MCU only needs to wake up, check the state, take action (or not), then return to sleep.