Python and the 555 Blinking Eyes in the Bushes

Blinking Eyes
LED blinky eye units consisting of craft popsicle sticks and pipe cleaner anchors deployed in a bush.

For Halloween, I had wired the bushes in front of my house with a dozen or so pairs of blinking LED eyes. Each pair of eyes blinked at their own rate–all powered by an Arduino. After building these centrally-wired daemonic bush entities I wanted to be able to deploy a few more in remote bushes and trees without having to wire them up to an Arduino. So I turned to my good friend the 555 timer chip. 555 timers for the uninitiated are a very versatile integrated circuit that can be used in a variety of timer-related circuits.

I was looking to achieve a very specific blinking pattern and was having a hard time figuring out the optimal set of components to use. There are tons of calculators out there for figuring out the characteristics of a 555 circuit based on the values of the components you use. If you’ve ever tried using one of these calculators for this sort of project it can be very frustrating. I don’t actually care what the components’ values are; I’m usually not thinking about that side of the equations at all. What I really care about are the timing characteristics of the circuit in terms of how long a signal is high and how long it is low. I want my “on time” to be X seconds and I want my “off time” to be Y seconds. You figure out what components I need to plug in to get that behavior.

Most of the existing 555 calculators I was able to find take the component values (e.g. R1= 100k, R2= 150k) and then compute the frequency, time_high, duty cycle, etc. I would rather think about the behavior I’m after and plug in the time_high and time_low and receive the values of the components I should use to achieve such a circuit.

Hang on. Let’s turn the real world dial up one more notch. It just so happens, I don’t have a resistor measured at 183.45 Ohms to achieve the specific oscillation I desire. Maybe we could constrain the calculator to only consider component values for components I actually have in my possession. Give me the best possible fit for the components that I do have (or can get my hands on).

So, I whipped up a simple Python tool to help me optimize my component selection to best achieve my desired blinking pattern. Here is an example snippet that solves the 555 timing equations using my inventory of components and my desired signal characteristics:

from optimize_555.opt import optimize
target_high = 42  #42 seconds on
target_low = 15 #15 seconds off
R1, R2, C, time_high, time_low = optimize(target_high, target_low)

This results in a timing circuit that goes high for 45.7 seconds and then has a 15.2 second low. And the best part of it is it’s accomplished using components that I have in-stock. R1 is 200KOhm, R2 is 100KOhm, and C is 220uF. The system defaults to a set of commonly available components, but you can override and define your own inventory.

In its current form its a very thin wrapper around some basic SciPy functions. You can check it out over at github. If there is some interest, I hope to expose it through a web interface at some point to make it more accessible to non-programming, electronic hobbyists. Hope it helps and happy blinking!

Ingress: Dangers and First Impressions

I push through the front doors of the US Post Office, my eyes still glued to my Ingress exotic matter (XM) scanner. I’m so going to hack this portal! “Target Acquired,” my cell phone chirped and loud enough for a few other patrons to notice. Oh crap, I may have just made a poor life decision, I thought as I glanced around the federal building.

Ingress is a new augmented reality game created by Google’s Niantic Labs. Imagine a cross between Pac Man, Foursquare, Geocaching, and Capture the Flag all rolled into one app on your phone. You run around town looking at a Google Map-like view gathering energy so that you can capture and defend geographically-distributed portals against an enemy faction.

Luckily, I walked away from my first big Ingress encounter unscathed, unfrisked, and undetained. But, I’m now picturing very different scenarios in the near future with people suspiciously circling buildings, eyes glued to their phones that occasionally make scary, threatening, futuristic sounds. Just ask the Mooninites or that student wearing art composed of exposed electronics, but it doesn’t seem to take much to freak people out these days.

Mooninite device that people freaked out about: . Image from Wikipedia.

The game has placed portals on a number of sites that the broader citizen base may not appreciate seeing trampled including federal buildings, libraries, and even some public middle school grounds. Fire departments also appear to be a very popular location for portals. One fire department with a portal I investigated could not be hacked without driving or walking up into their parking lot, potentially blocking their garage. I took a moment to talk with the on-duty firefighter at the station to get his take on the game and to see if anyone had notified them that their station would now be a part of some geeky capture the flag game. Nope. He hadn’t heard of it and while he sounded intrigued by the concept he did not like the idea of increased traffic pulling into their parking lot. As a local homeowner, I have to agree.

The game is still in beta and perhaps one goal is to identify some of these concerns before unleashing the nerd hordes. Suspected terrorist and arsonist concerns aside, this has been a pretty entertaining game. I’ve hoped for an augmented reality game like this for awhile and I think the folks at Niantic Labs have done a great job. It’s even provided enough motivation for me to get a little extra exercise in as I take walking breaks to hack and recharge portals. I don’t know how the game dynamics will change or scale once more people join the action, but it definitely has my attention for the time being.

Just think twice if Google tells you to visit the local fire department at night and lets revisit portal placement. Make good life choices.

Ingress Activity
Snapshot of Ingress activity in Durham (Nov 2012)