ESP8266 LED Display

This is my proof-of-concept for using mqtt with the esp8266.  I saw this LED display sitting around and I couldn’t imagine why no one was using it, the answer was no one knew how to talk to it.  Easy, I think.  Looking at the board it’s just an 8031, a serial level shifter, and a bunch of display-centric parts.  The pile of capacitors around the max232 equivalent was the give-away.  capacitors external to the chip are needed in the voltage boosting/negative voltage generation circuits for rs232 levels (until recently, I hear someone put them on-die).  Tracing those signals is easy and I found they went to UART pins on the 8031.

Assuming this chip is just listening for ASCII to be sent to it I started trying all the common baud rates… nothing.  OK, uncommon baud rates… nothing.  Maybe it’s some other parity, or stop bit encoding… nope.  It takes a while to run through all the permutations of rs232, and I did.  Now I’m thinking this takes some special character (or maybe CR/LF) to display a line.  Black-boxing that could be quite difficult.  Somehow, while hammering on the keyboard I saw something.  After trying every character from the ASCII table I came up with this list of printable characters: A-Z, 0-9, space, hyphen.  That’s it.  On a set of sixteen-segment displays.  Even the BOOT MESSAGE has lower case letters! Maybe there’s codes for some things but that’s what I finally gave up on determining.  I’ve settled for that subset of the ASCII set (at 4800, 8N1 if you care).

Serial connector added by me

Now we get to interfacing the ESP to this.  Really all I needed was the serial TX pin (actually I could probably use a software serial if it’s just transmitting at 4800 baud and not even listening, but I had a TX pin).  The signals for this sign are RS232 level, not ESP friendly.  I just patched in between the level shifter and the 8031 to get to the 5v level signals, much more microcontroller friendly (if someone says to just flip the polarity and let the rs232 driver at the other end sort it out, just say no!.  Luckily since the ESP only needs to transmit the level converter up to 5v is… nothing! That’s right, sending the 3.3v signal to the 5v chip is just fine.  Probably even in-spec.  Not that it matters since it works.  So now I have a way to talk to this sign from the ESP, but I want to stick it in a box and have it as a completed project unlike most of my hacking which is to write an interface for something and just let it be (never mind that I’m just making this interface to mqtt).

This is what I came up with.  It has an FTDI header, a 3.3v power regulator, and jumpers so I can pick where the signals go.  I don’t feel like typing this out so I’ll add the pictoral documentation (god bless white-board tables).

This allows me to set the ESP into program mode, connect the ftdi to the display so I can talk to it over usb directly, or connect the display back through the level shifter to the serial port.  that sounds like enough configuration to me.  Now it needs to go in a box.  Now I’ve got this breakout board soldered to a more edge-friendly one and the pinout looks like this:

So, along the side of the case I have a barrel jack for power, a DE-9 connector for RS232 level serial, and this layout of jumper positions and FTDI header.  All put together this makes for a pretty decent interface and I have been successful in connecting the FTDI friend (stock one, not my modified one) for programming of the module.  The completed box is transparent acrylic and was made using inkscape, boxmaker, and some custom holes for mounting.

The code for this is fairly simple.  I’m using the PubSubClient library to communicate over mqtt and I use the display for debug since, you know, it’s there.  Connecting the ESP to the wifi means you need an ssid and password (you could implement a clever hopper that looks for unsecured wireless and jumps on that, but I decided that for this I’m not going anywhere and would hardcode the ssid in.  I had it display whether or not it was connected to the wifi, then the IP address it got so I knew it was on (and the right network).  The code then publishes to OutTopic that it has connected (it actually says ‘hello world’ but for now that’s fine, it will change to a unique identifier when I get more of these devices.  It also subscribes to two topics, DisplayTopic and DelayTopic.  Both of those are used for changing the behavior of the sign.  Since this sign takes no input (not even a light level meter) it has no reason other than boot (or perhaps heartbeat) to send any signals out.

The code that handles the scrolling is actually pretty simple.  Since this is updating at 4800 baud the redraw rate is visible, and annoying.  I decided that since every character sent to this pushes the others off the end I’d take advantage of that and just push one character at a time and delay between them to have a given speed for scrolling.  anything sent on DelayTopic will get picked up by this sign and sent through atoi() to convert it to a number.  that number will be the number of milliseconds the program delays for between characters.  Because of this trick I can’t scroll the other way, that would involve redrawing the entire display and it looks terrible.

<Update: the following has been implemented, first try too!> The text interpretation is handled by simply padding with spaces to make the whole message at least 16 characters.  That doesn’t work however since if they are un-displayable the sign does nothing rather than inserting a space so you get smaller strings and artifacts.  The thing to do then is check to see if there is a valid character there and if not put something else there (I wasn’t quite truthful when I said it didn’t display other bits of the ASCII set, it does, but as garbage).  I think in the very near future I’ll put in a check and if the characters are not on the approved list then there will be a garbage character in place instead.

As should be expected the code is here.

The rest of this series can be gotten through from the home page here.

Tags: esp8266