HELP! Particle swarm LED lamp

Thread Starter


Joined Mar 3, 2010
I am currently designing a kind of LED matrix that will display a particle swarm (around 2000 particles).

The inspiration for this project is the Random International Swarm Study VI

In this picture one can see that it was built using small PCB boards. The interesting thing is that "columns" of this boards are chained using 3 power/communication lines (to our knowledge, VCC, GND y SIGNAL) and the "cables" are 2.4mm diameter brass rods (this has been confirmed)

I believe that the way they're chaining the boards is using an WS2812 or something similar, because each led in every column is addressable. As I want to implement more complex algorithms and even a bit of AI in the future, this kind of driver is not the best option for me.

Currently I've determined that versatility will be paramount while dimming, controlling the LEDs and implementing some behavioral algorithms that require each particle to have its own memory, rules and overall behavior as a "neuron" (this is different from the original design) Considering that, I've decided that I'll be using an MCU in each board and I already bought 2,500 ATMEGA16/QFN for 0.25USD each (they are currently very cheap in Digikey, starting 0.5 USD for 1-10 pieces batch)

I already made some tests and it is possible to interface 12 boards in a column connected by a 4 feet length brass rod (its diameter is around 0.1 inches) using the MCU UART at 9600bps (up to know at least); that means we are interfacing 12 RX -MCU addressable "slave" lines to a single TX line from a "master" MCU. I am aware UART is designed to be point to point but I am on a budget and the least quantity of components, the better (and also considering I have only one line for communication > VCC, GND, *DSIGNAL <)

1) The first question I would kindly ask to all of you is if you believe using a buffer in the TX line from the controller will allow me to get a faster baudrate. If not, what kind of signal conditioning would I need? I am aiming for the 115kbps baudrate but I am worried about the output current and noise tolerance along the single communication line.

2) If I want to interface more than 12 slaves on the described chain, would it be possible? Imagine each column connects 12 boards, so we will require one MCU "master" for each o them ( we would be talking about 96 independent columns) . The best possible scenario is to at least control 8 columns per "master", that would drop the amount of "master boards" needed to only 12. I am considering using a demultiplexer to demux the TX "master" signal (with a BiCMOS 8 channel demux), but I would also ask all of you if there's a better alternative.

3) For communicating the master boards that control 8 columns each, I am thinking on SPI. I have already read about long distance SPI over RS-422/RS-485, and that would be desirable because this screen must have a refresh rate of at least 60Hz in order to avoid flickering. That means 1Mbps to communicate the masters would be incredible for exchanging about 5Kb of data every 1/60 seconds.

Please forgive my rusty english and that I am not an electronics expert (my BSc. is in robotics and automation and my MSc. is in financial engineering) Thanks a lot in advance for your comments and suggestions.
Just playing devils advocate here but wouldn't an array be easier...

If you considdered each column as a shift register rather than a set of addressible nodes you could mux the columns and shift in on/off as a single bit.
Each node boarad would need to listne when the preceeding bord stopped listening, that could be done just using timing or even an IR trigger between nodes.

Assuming you have power ground and data.
lets say data at 50% of VCC denotes a node off command 100% VCC denotes a node on command and a transition from 0 to 50% or more is a start sequence command.

To activate a column, or columns, pull the data low.
When it is released to 50% or more everything on that bus starts timing, or counting.
Now all you have to do is ensure the correct level is applied when each successive node times out and looks for a state command.

Granted its one way but it is also only a single bit per node on any given bus which of course you can easily mux.

The point is you will only ever send on or off and since you are stuck with a time-slice type protacol you may as well use the time as the address.

I expect you could even read the state if you had nodes pull the bus following a clock edge.

Clock strethcing is another way to go if you dont want to impliment levels and that aproach could be used to increment the nodes intermal count.

Given your physical structure. bus capacitence and reflections are likely to be an issue so the fewer bits you need the better.

I am no expert in this field but I hope this helps none the less.



Joined Jun 19, 2012
Some thoughts:

The high currents demanded by the LED's make grounds very noisy and power distribution is a non-trivial problem.

The MCU-per-node idea is cool, but a nightmare to develop and test.

Standard serial is only 80% time efficient, 2 out of every 10 bits are used for synchronization.

SPI has the best chance for achieving the speed, at the expense of more wires.

The WS2812 approach has a lot going for it, the data signals are regenerated by every chip, so signal integrity is easier to achieve.
The 24 bit data word is a bandwidth hog.

Consider the APA102 part- this part has clock and data, simplifies generating high bandwidth output from an MCU.
Use a whole 8 bit port to output data to 8 separate strings of LEDs, with one clock generated from another I/O line.
That's 8X the bandwidth right there, and easy.