Mangy_Dog explains in this video that he became intrigued with the notion of creating a modern LED replica of the 1970s-vintage McDonnell Douglas F/A-18 fighter jet’s archaic digital display panels as a part of an aborted project to produce a complete, programmable cockpit. Maybe the producers of the new Top Gun sequel were interested in just a simulator for shooting scenes for that film?
Anyway, Mangy_Dog describes the challenges in producing his impressive retro-themed display and outlines the steps for you to build your own DIY display. In his case, Mangy_Dog is using the display to show the subscriber count for his YouTube channel in celebration of surpassing 1,000 subscribers. Here is his explanation:
Each digit has its own 595 shift register, and solder connections on the side. The idea is that each digit can be placed side by side and small hoops of wire could be used to secure each digit.
In theory, these digits could run for many maybe over 100 connections. But power supply needs to be taken into consideration.
The digits use a matrix of 4×4 LEDs. That’s four rows of four LEDs. (though these are grouped in quarters of the square) with a resistor of 150 ohms, these LEDs max current draw is 15ma per led, though calculates to roughly 13ma.
As the LEDs are driven row by row in a four-row interlaced signal that gives each digit a maximum draw of around 60ma. 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. 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.
Some consideration should be made to the power supply, both on the 5V and ground. With multiple reconnections to power for long chains. For example, the subscriber counter I made using these digits, has 15 digits. And I connected the power to both ends of the chain to help take stress off the power traces.
I originally planned to have an ESP8266 drive the digits directly. But I found this to be impossible with the hardware available in the microcontroller. So, in the end, I made a dedicated controller with an Arduino pro mini (atmega328p). And created a serial interface setup that allowed me to feed data to the display from the ESP8266.
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. At this constant rate with the four-row interlace, I’m getting perfectly flicker-free image persistence. In fact, the data update rate is far faster than I had originally envisioned.
I also needed to manufacture the faceplate defusers for the digits. I considered making the faceplates with my resin printer. And this indeed may have worked out well. But in the end, I went with using my laser cutter in engrave mode. 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. This took a lot of trial and error but in the end, I got a fairly decent result.
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. I also gave the faces a spray with Plasticote matte finish to give them a more uniform look. This worked out really well.
But the defusing effect isn’t perfectly consistent with each segment and each digit. 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.
At 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. Currently, I think I have fixed any bugs in the serial receiving and error catching code, and I feel this is mostly locked down. Currently, only static text can be displayed with scrolling text not written in properly yet. And there is only one built-in animation at this time.
As for the ESP8266 side of the firmware. There are still some minor issues. 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. This throws up a bad header or checksum error message on the display. I’ve yet to trace what’s causing this byte to be inserted into the stream. This error also usually clears up as the next minute counts up on the clock data.
So, if you are looking for a challenge, here’s an opportunity for a cool project and maybe also the chance to help troubleshoot these remaining bugs.