Description

It's a pretty basic ESP8266 breakout board for controlling the apa102, ws2801 or similar lights that require clock, data, and power inputs (4 leads). The name is a play on ESP and SPI with the shortest word I could think of. I probably won't use this to spy on you.

Details

The end goal is to create a large video screen that I can roll up and put away after the party's over that can be driven from commodity hardware without having to run DMX or ethernet cables for control. To do this, the ESPionage connects to a pre-programmed wifi network and listens for ARTnet or TPM2.net commands and relays them over the SPI-like protocol to a strip of lights. It's similar to something like the PixelPusher but doesn't try to do as much while potentially costing considerably less.

By bypassing DMX, I'm able to avoid having to keep another set of DMX cables that cannot be used safely on the sound system. Additionally, DMX controllers are expensive and add a decent amount of complexity to the lighting system when you don't already have one, but there are a number of free solutions to control equipment from a computer over IP (Pixelcontrol, Glediator, etc).

Here's what it takes to build one:- esp8266-201 $4- ams1117 $0.57- PCB $3-5 for a small run

I've updated the sming project again. It's now accepting udp dataframes for tpm2.net and art-net as well as exposing the brightness var in an html page. It seems like it's capable of pushing 100+fps without issues with frames bunching up - that's up from 24fps with the half lua/half C++ solution that I used last time around. To build this, make sure the spi speed is no higher than 500kps. I got more length controllable with that speed than at 1mbps.

I've redesigned the board to try to address some of the issues with the first PCB. It's using the esp-07 variant board instead of the esp-201 since the need to swap out MCU's quickly is nicer for prototyping than for trying to put together a bunch of the units. The female headers I was using cost more than almost anything else, so taking those out dropped the price dramatically. Additionally, there's a CH340G for doing USB to conversion that should make the things much simpler to hand out. The updated designs are up on github and in the hands of dirtypcbs. I'll see how this works out in a month or so.

I finally got around to assembling the PCB's sent out to Dirty PCB's and OSH Park, and there were a few small errors on the original design. The ESP8266-201 breakout module has 10k pull-down resistors on at least the GPIO0 and GPIO2 pins, so when I tried to boot the chip, the pins were left floating (I'd used 10k resistors to pull down the pins, same as the ones on the 201). Additionally, the resistor between the dip switches and 3.3v is too big - it should be much smaller than the pull-down resistors so that when the switches are turned on, the pin goes high instead of low. The pull-downs were reduced to 1k, and the other resistor was replaced with a jumper. In the next revision, I'll just have the switches connect the pins to ground when closed instead of pulling the pins down and connecting them to 3.3v when closed.

The CH_EN pin had to be attached with a wire - I just put this on the bottom of the board. Fortunately, it doesn't protrude past the various through-hole components.

The one other awkward bit was attaching the USB micro connector: the OSH Park boards did not have the different shaped holes that were put in on KiCad, but the Dirty PCB's ones did. This means that to get the USB micro connectors to connect to the OSH Park boards, I had to trim the leads for the shielding because the slit-shaped holes on the design became small round ones.

Other than that, I've successfully managed to hook up the usb-uart adapter and flash over a test WiFi program.

I've been working on this project on-and-off for a while, now, but it's just now getting to hackaday.io. So far, I've got a first attempt at a board sent off to get fabbed and a more-or-less working protobard module. The framerate on the screen maxes out somewhere around 20-30fps, still, but I'm planning to rewrite the control software in pure C++ to squeeze a bit more out. The software receives data over IP from control software with either the ARTnet or TPM2.net protocol.