Close

Day 2 (Part 1) - Power, Breadboarding, User Interface

A project log for IRL-DND (Do Not Disturb)

Since I work from home, communicating when I'm busy and available to my wife can be troublesome. Enter IRL-DND.

scottmcgimpseyscott.mcgimpsey 08/26/2019 at 21:000 Comments

[Update: I've uploaded the code discussed in this post to the project page.]

I've added the headers to the Oak. If I want to use this specific module on my prototype, I can just pop some male headers on the protoboard for the board to plug into. I'm a bit short on headers at the moment, but I'm sure I can scrounge up enough to make do for this board. Programming is a lot easier this way anyhow.

Since the WS2812B uses 5v for power and communication, and the Oak uses 3.3v, I'll be using the Oak's 5v->3.3v voltage regulator to power the ESP8266 (built in already) and as the voltage reference for the logic shifter. The WS2812B will take straight 5v from the USB supply.  Typical USB ports off a computer offer 500mA on the high end. I'll use this as my low-bar for supplied power, as most USB Power supplies and batteries offer more than this. The NeoPixel (brand name of WS281x series) guide over at Mouser offers a quick rule of thumb estimate of 20mA for standard operation, and 60mA peak per RGB LED. Apparently the logic circuitry on the chip consumes very little power.

For the ESP8266 , this Espressif page lists the highest current draw of the in a series of tests at being 170mA. I have a 470ohm pull-down resistor on the 3.3v side of the logic shifter, so that's another 7mA consumed. The Voltage Regulator on the Oak is rated for 500mA, so no issues there. All in, that's around (5v * 60mA) + (3.3v * 170mA) + (3.3v * 7mA) = 884.1mW power draw, and a theoretical 2500mW supply. Plenty of wiggle room, though I may add a capacitor across the 5v line to buffer the supply, mostly for fun. I spent a few minutes looking for my USB inline power indicator, but couldn't find it for the life of me. Once I find it I will check and share my back-of-the-napkin against real-world measurements.


Breadboarding the circuit took a few minutes longer than expected. I was able to write code to the ESP8266 without trouble, but was having issues getting communication to work between the Oak and the WS2812B. I eventually found that the logic shifter needed that pulldown resistor, (must not be included on the circuit side of the ESP or Oak) and that the LED required the 400kHz communication option to be set instead of the 800kHz. 

Now that I have the circuit wired up, I've got a nice little flow for coding, testing, and updating the code. I was able to get the WS2812B test code to run alongside the vanilla Wifi Configuration code. After that, I found a quick example of a WebUI which toggles pin states, and used that as a template for my implementation. I'm not in love with the implementation, but I'm a big fan of getting the "Functionally Adequate" version to work, then refining the output.

After playing around with the HTML and CSS for a bit, and some of the logic, I have the device updating the state variable (Safe, Caution, Unsafe) whenever the user passes a Get request for a the /state/{state goes here}. I can use this as a call method later from a control device. For the web-ui, there's 3 buttons to set the different states, and the current state indicated on the page, along with some helper text. The state does not survive a reboot (intentionally, at the moment as I expect the person changing the state to be the most unreliable element of the flow -- I can implement in EEPROM memory later if I decide to alter my workflow), so when the device first boots up it holds an "unknown" state (blue on the LED), and suggests manually evaluating the situation before attempting to enter.

[Tom Nardi] made a very good point about the dangers of telling a significant other (my wife, in this case) where they can and can't go, so I may soften up the language a bit. Remember, safety first!

Next up I'll need to transfer all of these parts from the breadboard to some protoboard so I can do some field-testing to figure out where changes need to be made and features added. I'm already starting to build up a backlog of posts though, so I'm going to break this one up a bit to make sure I'm posting at a decent frequency, and so that no single post gets too lengthy.

Discussions