Yellow doorbell/dash project

In the previous post, I outlined how the “Yellow Development Board” from AI-Thinker had become my new, go-to ESP8266 board for projects, partly because the headers make it easy for interconnects and partly because it’s got lots of LEDs already on board.  Not to mention that it’s reasonably priced and comes equipped with a battery box and a low quiescent current voltage regulator (important when you’re running from batteries).

Even more recently, I wanted to experiment with a doorbell-cum-dash style button, based on one of the dollar-store LED push-button lights which seem to be available everywhere nowadays. The idea is that pushing the button will initiate a connection to the MQTT server Three-LED lightfrom the ESP8266 embedded inside the button and then, based upon which ESP just called, the MQTT server will initiate a process. That process could be anything from ordering another bottle of Rivella from Amazon, to switching on the stair lights, or announcing that there’s someone at the back door (or just about anything else you can think of where a momentary push button is used). The dollar-store light, as it comes, incorporates three, white LEDs and a latching switch, with a battery box for three, AA batteries built into the bottom. The construction of these lights is extremely flimsy (I just cracked the battery cover on the one pictured above while positioning it for the photo), but they are still amazing value for what they are. Taking the thing apart reveals that the LED “reflector” is nothing more than a flimsy sheet of white card, but that doesn’t matter, as we won’t be using it anyway. In fact, we can remove the LED PCB completely and just hold onto the white LEDs for some other project (our Yellow board already has more than enough LEDs) just keeping the base for our project. The original switch is a latching type, which isn’t what we want, either. On Prototype internalsthe first LED light that I bought, I tried to dismantle the original switch, with the idea that I’d convert it into a momentary type by throwing away the latching mechanism. However, the mechanism is so tiny that my motor skills weren’t up to the job (and that tiny little spring will no doubt be found by the vacuum cleaner, eventually). In the end, I simply removed the plunger from the original switch and glued a momentary “tact” switch on top of it (which put the new switch at exactly the right height to work with the push mechanism). The Yellow board (this time minus its own battery box) fitted perfectly on top of the built-in battery box (with that bit of flimsy white card insulating it from the exposed battery connectors), while some extra circuity fitted on a strip of prototyping board at the end of the battery box opposite to the switch. Despite the sticky-tape and hot glue, this prototype worked very well.

The circuitry on the prototyping board deserves a quick explanation here. The whole purpose of this project was to have an ESP8266 which would sit doing nothing at all for very long periods. Basically, that’s something that the ESP isn’t very good at. Even if it’s sitting there in deep sleep, it can still deplete three AA batteries in about three months, which is not very useful for a doorbell/dash type application, so the intention here was to have the ESP turned off completely, until it needed to wake up. The button implies physical interaction, so we know we can get the unit to switch on for the length of time that the button is held closed, at least. For a doorbell type application, that’s likely to be some significant part of a second, at a minimum, but still probably not long enough for the ESP to go from a cold start, through negotiating a connection with an access point to sending an MQTT message.  What  we needed was a method for the ESP to ensure, once it had been initially powered, that it could latch the power on until its work was complete and then (importantly) turn it back off again.

The answer is provided by the circuit below.  The ESP will start up very quickly indeed, especially if you don’t muck about trying to initialize serial ports, or wireless, or sending debug messages.  So what we do in our application is, as the very first thing, use the pinMode() command to initialize a designated pin as an output (which we’ll call “POWER_SW”, for power-switch) and then call digitalWrite() to set POWER_SW to “HIGH”, then we go back to our normal setup() routines.  This happens in a few milliseconds and we use the output of the GPIO pin designated as “POWER_SW” to drive the PWR_LATCH input signal of our latch circuitry, below.†

MOSFET power-latch schematic

Okay, so how does all of this work?  Well first of all, power is coming in from the battery box on the L/H side of the diagram on the pads marked as BAT+ and BAT-.  Our Yellow board is supplied from the R/H side pads, marked PWR_OUT and GND.  In between, right at the top, there are two more pads marked as SW_BATT and SW_VREG.  These are the two wires to our actual momentary contact “tact” switch, which we just pressed (a few milliseconds ago) to provide the initial power connection between the battery box and the ESP.  What we have now is a situation where the switch has been released, the battery is disconnected from the ESP8266 again and the charge on the smoothing capacitor next to the voltage regulator on the Yellow board is rapidly starting to deplete.

The ESP though, has already started up from cold, initialized the POWER_SW GPIO and set it to high.  As we noted, that GPIO is actually driving the PWR_LATCH line (bottom, R/H side of the diagram above).  This is connected to the gate of Q2, an N-channel MOSFET and will turn that device on, pulling the voltage at the junction of R1 and R3 low in turn.  This turns Q1 (a P-channel MOSFET) on, providing an alternative path for the battery power to reach the ESP8266.  As long as the “POWER_SW” signal remains high, the power will remain connected to the ESP8266.

As you’ve probably already guessed, once the ESP has finished running its designated tasks, it simply flips the POWER_SW signal from HIGH to LOW and, before the ESP8266 has time to print out “Goodbye cruel world!” to the console, the power is gone.

Why don’t we just invert the logic and have the ESP8266 drive Q1 directly, instead of adding the extra components around Q2?  Well the main reason is that the battery pack on the LED light has three 1.5 volt batteries in it.  When they’re brand new, the total voltage across all three cells can measure as high as 4.8 volts.  The ESP, as we all know (despite rumours to the contrary) is a 3v3 device and the voltage at the end of the resistor chain of R1 and R3 would float up to full battery voltage when the ESP was switched off and not pulling that line low, so Q2 is mainly there to protect the ESP from the full battery voltage (the N-channel used for Q2 needs to be chosen to withstand full battery voltage with some additional headroom, which isn’t asking much of a stand-alone MOSFET).  The chain of R1 and R3 is also there to protect the gate of Q1, the p-channel device, from being driven beyond its gate/source voltage limit (which is unlikely in this particular circuit, anyway).

Finally, the question is, which GPIO should we use as the POWER_SW drive?  Well, GPIO-0, GPIO-2 and GPIO-15 are bad choices, because they are all read at power-up time to determine which mode the ESP will boot into.  GPIO-16 is a good candidate though, as we definitely will not be connecting it to the reset pin for deep-sleep wake-up in this project.  If you want to change this on your particular board, feel free.  Just change the definition in the user_config.h file (and ensure that your chosen GPIO is not used for any of the other functions).

Update – The prototype auto-latching switch board worked very well, so I’ve knocked together a PCB using mostly through-hole components (that’s what I have in my parts drawers and besides, my hands are too shaky for SMD stuff nowadays …I can just about manage the AO3415, but only because I can’t find it in TO-92).  If anyone wants to roll their own, the board files (Eagle format) are available on GitHub.  My next version will probably provide an alternative SMD footprint for the 2N7000 (using the AO3414, which is what I had originally planned), but feel free to go 100% SMD if you prefer.

Okay, that’s our hardware.  The software is coming along next in two or three separate pieces.

† – It’s worth noting that if the GPIO on the ESP8266 isn’t initialized to “digital” mode, the MOSFET switch will be held “on” and you’ll be unable to switch it off (which is somewhat counter intuitive).

Advertisement

Simple projects with the Yellow Dev board

A few months back I wrote an article on the “Yellow Development Board” from Ai-Thinker.  At the time it was, I admit, an attempt to add a little balance to the blog after my lambasting of their “Black Board T5”.  However, after a few months of using these little beasties, I suddenly realized that it had become my go-to board for new, ESP8266-based projects.   My experience with electronics dates back way beyond transistors, let alone integrated circuits or microcontrollers, so one of the tools I still have in my kit is a wire-wrap pen, which turned out to be quite handy with the “Yellow Development Board” (and that is way too much of a mouthful, so from here onwards I’ll refer to it simply as “Yellow”).

Wire-wrapping is just what it sounds like… it was a technique used extensively in the early days of computer manufacturing to provide interconnects between components.  Typically, individual chips would be plugged into ic-sockets with long, chunky pins with a square profile.  Wire-wrap wire is single core, so the “pen” enabled you to strip the insulation off the end of your wire and then wrap it tightly around the pin (the square profile ensuring that the electrical connection was good, as the corners bit into the wire).

I mention this not because of a sudden burst of nostalgia, but because the header pins on the Yellow board reminded me of wire-wrap as soon as I saw them and one of the really good things about wire wrap (and there were plenty of bad things, as anyone who had to troubleshoot a wire-wrapped system will tell you) is that it was, and still is, one of the fastest ways to prototype a new circuit.  You don’t have to wait for a soldering iron to heat up and you don’t lose half of your connections if you accidentally knock your breadboard onto the floor.  Yellow dev board with i2c RTC attachedSo wire-wrapping seemed like a natural step for quickly connecting up the Yellow board to some peripherals when building a project.  The header pins are not ideal (they’re a little too skinny and definitely not long enough), but they’re more than good enough for prototyping.  It was only a few minutes work to connect up a DS3231 i2c RTC board (+ve, gnd, clock and data) and only another couple of minutes to add yet another board (this time a custom i2c slave built from a PIC16F1825) for more fun and experimentation (I should add that the RTC was something which I already knew was working and was just a test connection to ensure that i2c still worked with the red LEDs on the Yellow board with i2c RTC and custom PIC boardYellow board’s i2c lines still in place; the PIC board was/is the intended target for that particular project).

The point here is that it proved to be incredibly easy to integrate an ESP8266 into a project using the Yellow board.  It even had the added advantages of having LEDs on virtually all of the available pins, so there was some visual debug capability thrown in for free.

Shortly after this initial foray into i2c, I came across Cicero’s Ethernet-for-the-ESP8266 project and wrote up an entry here on the process of connecting the Yellow board to an ENC28J60 ethernet module to enable hard-wired ethernet to the ESP (on a side note, keep an eye open for an update from Cicero for a Linux-specific version of this project, coming soon).

So, over the months the awkwardly named “Yellow Development Board” has earned a place in my ESP8266 arsenal as a versatile and well-equipped prototyping tool and in the next post, I’ll look in a little more detail at a doorbell/dash type button project and how it interfaces with MQTT.

[Where to get these boards …I don’t generally give links to specific merchants, but the “Yellow” doesn’t seem to be quite so universally available as it once was.  When I was searching for a new supplier earlier I came across this eBay store selling them at a very good price.  The store has a feedback rating of 99.8% on over 20,000 sales, so they must be doing something right, but I should emphasize that, although I have ordered from them today, I haven’t ever used them before, so this is a “find”, but in no way an endorsement.]