Since last week we’ve mainly done three things : defining formal specifications, upgrading the architecture, and start choosing components.

Formal specifications

We’ve created a spreadsheet that would compute some figures like the maximum power, the maximum bandwidth, the bandwidth per LED driver, etc. We can immediately see parameters effects by varying them.

We’ve chosen to use 1200 LEDs using a 4:3 format. This seems sufficient to get a nice result without creating unnecessary complexity.

We also wanted to check the maximal throughput because we think it’s our main bottleneck. Using 8 bits per color, and 25 revolutions per second we measured a total throughput of around 50 Mb/s. Again this seems reasonable since we can transmit that much data both through WiFi or SDIO.

Finally we needed to check how many drivers and multiplexers we should use. Using 16-LED drivers and 8-columns multiplexers, a block that is at the edge of the panel (thus we the higher update frequency) would have a maximal throughput of around 8 Mb/s. We saw several LED drivers made by TI which have at least 20 Mhz bandwidth (and approximately the same throughput).

With all this, we add our final setup : 40×30 LED pane, decomposed in 8×15 blocks each controlled by a LED driver and a column multiplexer.

Upgrading the architecture

We’ve also been thinking about the fixed part of the project. We needed a way to control the motor and the IR LED used to synchronize the system. We tried to think about the usage flow, and finally came up with this :

• Push a button to turn the power on. This should power two BLE modules, one fixed and one mobile.
• When selecting or streaming a file through the WiFi interface, the mobile BLE module would communicate with the fixed part to start IR emission and motor rotation.
• When paused or stopped, the same process would happen to stop the motor.

It means that we’re going to have to design a (much simpler) circuit in the fixed part to control the motor and LED.

Choosing components

We’ve also started to choose components. In fact this is highly correlated to the architecture since we need to be aware of what’s existing to design the system.

Wifi

In particular, I’ve been searching for a WiFi module. After some research, I found the ESP8266 and its ESP32 family successors. These are particularly know, and adpated for our usage, because:

• The processor is dual-core, one core being dedicated to the IP stack, and the other being available for the user
• The processing power is sufficient for most usage. We are not going to do much work apart from forwarding data to the FPGA.
• It has 500 Ko of SDRAM and up to 16 Mo of external flash memory. This is clearly enough for our program and data.
• It is SPI and SDIO capable.
• It is cheap.
• It supports WiFi with an UDP throughput of 30 Mo/s
• It supports BLE
• It has a huge fan community, lots of tutorials and programming guides.

For all these reasons, we are going to use two ESP32 module. One will be used in the mobile part to handle the WiFi interface. It will also communicate through BLE with the second module on the fixed part. This is the module that will drive both the IR LED and the motor.

Moreover, the ESP32 is supported by, and mostly used with FreeRTOS. This is a sufficient reason for choosing FreeRTOS as our main OS.

Driver

I’ve been digging into TI website to compare their LED panel drivers. I noticed that two of their drivers are suited for “large high frequency multiplexed panels”. Furthermore, TI even wrote a document aimed at explaining the whole process of using those two drivers to build a panel. Since this is pretty much what we’re doing, it looked like a good idea to use those.

Ambroise checked the differences with other drivers that were available and noticed that, although the bandwidth is lower, they provide lower rising/fall time and most importantly have buffers to store the whole frame.

As a result, we are going to use the TI TLC59582.