Ping Pong Screen - 24x24 synchronous controller

I document and reverse-engineer a LED screen controller I designed for a custom art piece, that uses some sick hacks and tricks

Similar projects worth following
Back in 2015/2016 I designed and built 2 boards that control a couple of LED screens, each made of 24×24 synchronous RGB LED, created by the French artist Fred Sapey-Triomphe.
Cost, reliability and serviceability are huge concerns so the solution was utter simplicity. A PIC16F818, a 16MB serial Flash chip, some TTL and I could avoid any concern with OS, updates, failures, ...
But the custom design means it is frozen for ever and the extremely tight schedule worked against the proper documentation. Many files were lost with a hard disk failure and I have to reverse-engineer the system from what I have gathered since then...
Maybe this could inspire people who don't want to use an Arduino or a Raspberry Pi for such a simple project ?

This project is featured at the beginning of this video :

Two ping pong screens (24×24 RGB LED) display alternating videos in an endless loop. The circuits must be reliable, simple, cheap, and start immediately when powered up. The other constraint was the LED : due to sourcing issues, the array uses synchronous LEDs, whereas the #WizYasep  can drive asynchronous LEDs only (so far). A custom solution was required...

I came up with a pretty crazy system that was reduced to its essential components, using ideas I explored with Cheap bulk removable storage. The principle is simple : the output of the serial SPI Flash chip is almost directly sent to the data pin of the synchronous LED, while a microcontroller toggles the clock and other control signals.

That's simple, right ?

This is possible because very high density Flash chips have hit the market at great prices and a 128M bits BIOS chip can store many many frames :

1 frame = 8×3×24×24 = 13824 bits, or roughly 1/10000th of a 16MB Flash chip (9709 frames to be exact).

At 25 frames per second, the chip can store 388 seconds of uncompressed, raw video. That's more than 6 minutes.

At first I created a system with parallel reading of 8 SPI chips but I had to change the strategy in the middle of the project because the videos are short enough to fit into a single chip : about 6000 frames are used, well within the range. I also changed the number of output channels, from 8 to 12 and the TTL/buffers needed a revamp...

Of course there is the question of streaming the bitstream from a SD card. But that's probably too complicated for the 818. I suppose some people could try it though, if they have the proper libraries.

1. The return of the PPS24
2. Radio synchronisation

  • Radio synchronisation

    Yann Guidon / YGDES09/26/2019 at 03:37 0 comments

    There has always been a requirement to synchronise both screens so they operate in a specific sequence. The rush of delivery in 2016 made me cut this corner...

    Lately the 2nd screen (almost a clone loaded with a different video ) arrived so I could make them talk. And I think I nailed it, thanks to improvements in the available technology. I used a pair of BBC Micro:bit modules to talk over radio and deal with the protocol, to keep changes to a minimum for the main board. Having micropython and BlueTooth on board greatly eased the retrofit and kept costs low.

    The main problem was "how do I connect to the main board with the least efforts ?"

    I chose to use the serial programming/debug port, a personal connector with the 5 required pins to connect the Microchip ICD2 to the PIC16F818. It's a compromise because it makes debugging hard, as the PGC and PGC pins are shared with RB6 & RB7 port pins, but I just needed to make a small adapter board with male pins, and the rest of the main board is left untouched.

    I fortunately have the backup of the source code of the 818 so I could slightly modify it. One board become the source/sender of a pulse and the other receives it. Then it's a matter of interfacing the Micro:Bit...

    For the sender, I chose the Button_A pin, so I could emulate the pulses by hand for the small tests. There's a catch though : the Micro:Bit's button pin is pulled high to 3.3V though 10K, while the PIC has CMOS 5V output. The level shifter is as simple as a dumb SMD diode :-) RB7 can thus only pull down and the MicroBit is protected from higher voltages.

    The ICD port provides 5V and GND and they are also brought to the Micro:Bit, using 3 wires. The Python source code is about 20 lines long, including radio configuration and detecting button presses and releases, though the modifications of the PIC asm code had to be more subtle...

    The receiver is barely more complex, with a dumb transistor inverter providing the level shifting.  A BC550 and a pair of 10K resistors are enough to pull RB6 low when the Micro:bit's Pin0 goes high. I had to slightly modify the PIC's code as well to provide a nice asynchronous "reset" of the player. The Python code counts how many radio messages are received before sending a short pulse to the PIC, providing the desired sequence effect when both screens work together.

    The ICD port was never intended as an extension port, since I planned a parallel system with IDC cables (that proved too cumbersome). Now there is no drift anymore, just as Fred Sapey Triomphe wanted back in the days. Thank you BBC and all the folks  who built all these tools so we all can make cheap and quick hacks ;-)

  • The return of the PPS24

    Yann Guidon / YGDES09/06/2019 at 15:11 0 comments

    Yesterday I received one of the frames for a slight repair and for enhancement. Time for a debrief...

    It's large, quite heavy, but remarkably well preserved. And it's simple. There might be a loose joint somewhere or some oxide on a contact and I'll have to locate and repair it, while also figuring out how and why I made the circuit this way. In the hurry of the delivery, I had to cut some corners...

    Remaking the PCB Could be a solution after all.

View all 2 project logs

Enjoy this project?



Dan Maloney wrote 09/06/2019 at 17:46 point

Reminds me a bit of the recent project by @bitluni. Looks good!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 09/06/2019 at 18:59 point

Yes I've seen the videos :-)

My first RGB array/screen was built years before (2013, at the same time as #Rosace) and I have gained experience with their design (such as redundancy and partitioning, which @bitluni doesn't implement because it doesn't have to run non stop for months or years in demanding environments). For very large scale installations (such as #Mons2015 LED Screen ElectroSuper), I had to develop custom driver systems, such as #WizYasep ... Here this system had to use synchronous LEDs (for budget reasons) and I thus had to develop "yet another system"... I hope to document it here :-)

  Are you sure? yes | no

davedarko wrote 09/06/2019 at 06:53 point

very clean! :)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 09/06/2019 at 18:59 point

Is that a compliment ? ;-)

You haven't seen the other side of the PCB though, there is a Big Mess Of Wires that I have to unravel...

  Are you sure? yes | no

davedarko wrote 09/07/2019 at 06:43 point

why are you hiding such a beautiful beast then? :D the WS2812 part definitely looks mesmerising and clean!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 09/07/2019 at 10:51 point

Hiding ?

Anyway these are not WS2812, it's a 4-wires string, with synchronous protocole (APA102 maybe). Otherwise I would have used a #WizYasep  :-)

  Are you sure? yes | no

Does this project spark your interest?

Become a member to follow this project and never miss any updates