I've yet to trace what's causing this byte to be inserted into the stream. This throws up a bad header or checksum error message on the display.
While I have got text working and I am displaying data on my display, for some reason certain combinations of time (strangely usually involving the character 4) trigger the serial sending code to place a frame start byte just before the frame end byte in the packet. And there is only one built-in animation at this time.Īs for the ESP8266 side of the firmware. Currently, only static text can be displayed with scrolling text not written in properly yet. Currently, I think I have fixed any bugs in the serial receiving and error catching code, and I feel this is mostly locked down. With more practice and homing in on the technique, this could be improved but, I got a good enough result for the project I wanted at this time.Īt the time of writing this, the Arduino side display driving firmware is at a working state, but not all planned features are written in yet. This worked out really well.īut the defusing effect isn't perfectly consistent with each segment and each digit. I also gave the faces a spray with Plasticote matte finish to give them a more uniform look. I then used clear UV curable resin to fill up the holes, using a sewing needle to paste the liquid over them, and after curing them sanded the faces flat again leaving a matt clean finish. This took a lot of trial and error but in the end, I got a fairly decent result. And engraving into black perspex to route out spaces for the components before another engrave pass for the small 3 dot holes for each segment of the display. But in the end, I went with using my laser cutter in engrave mode. And this indeed may have worked out well. I considered making the faceplates with my resin printer. I also needed to manufacture the faceplate defusers for the digits. The F/A-18's original display module, using light pipes.
In fact, the data update rate is far faster than I had originally envisioned.
At this constant rate with the four-row interlace, I'm getting perfectly flicker-free image persistence. The Arduino drives the display constantly by regular hardware timer intervals of 500ns, using the built-in SPI hardware to shift out the data at a more than fast rate. And created a serial interface setup that allowed me to feed data to the display from the ESP8266. So, in the end, I made a dedicated controller with an Arduino pro mini (atmega328p). But I found this to be impossible with the hardware available in the microcontroller. I originally planned to have an ESP8266 drive the digits directly. And I connected the power to both ends of the chain to help take stress off the power traces. For example, the subscriber counter I made using these digits, has 15 digits. With multiple reconnections to power for long chains. Some consideration should be made to the power supply, both on the 5V and ground. There is also a PWM signal that can control the brightness, and I've found on the 8-bit Arduino PWM control, the value of 50 is plenty.
if the LEDs were being driven at full brightness, and if the Arduino code was behaving and not trigger multiple rows at the same time. As the LEDs are driven row by row in a four-row interlaced signal that gives each digit a maximum draw of around 60ma.