led driver with pulse width modulation

l'm looking for an easy solution to drive with the arduino board ~60 leds controlled from VVVV via arduino. each led sould be dimmable individually ...
i think the software side is not that big problem (beltram did this wicked tutorial http://www.progetto2501.com/b/tools/Arduino/)

but how to get more PWM pins?
a very easy (and espensive) solution would probably be to use arduino as dmx interface and buy an dmx multiplexer ... but then you have this huge 19" box :frowning:
in the led driver tutorial you use unfortunatelly this philipp chip which has no PWM :frowning:

i found this site from the MIT disco dancefloor dudes http://web.mit.edu/storborg/ddf/index.html
they do something similar, but as far i can see from their documentation, they have just PWM in 16 steps :frowning:

so folks any hints?

grz Mr Bene Fit

Hej,

make the following count:

60 LEDs x refresh speed of 50 times/second = 300 bits/second

in other words: if you want to make 60 LEDs change light intensity individually, you don't need to use PWM, you just need to refresh their status about 50 times each second, that is enough to trick the human eye. Then you decide how many of those 50 times the LEDs should be on or off

You should use the MAX7219 that allows this high speed, and you will only need 3-4 pins from the board (normal digital I/O)

More questions?

/David

hmm, i'm a bit skeptic ... but i gonna try it at the weekend.
actually i wanna visualize with the leds music. so have to tween (smooth) all the time between different brightness levels. i'm not sure if your "trick" works for instance, if you have three changes within a 1 sec ... but anyway going to test your concept ... will post my experiences.

thanks

bene fit

dear benedikt/bene_fit

still in basel?

here is a quick and dirty solution for you.
Not happy about a chip? build your own!!

The atmega8 processor that sits in the arduino board has a number of advantages:

  1. if bought in quantity costs about 3 EUR
  2. has 3 PWM outputs at 8bit resolution (more than this doesn't make sense)
  3. has an hardware serial port.. this means that it receives data eve while you're doing
    something else in your code.
  4. can be run from an internal 8MHz clock that in some cases is stable enough to have
    reliable serial communication.

if you program an atmega8 with some code (maybe written in arduino directly) you can build your own
serially addressable 3 channel pwm controller.
if you put one of these in each pixel with the addition to 3 power mosfets you can
make a nice RGB pixel that can drive big LED spotlights

for example farnell has the ZXM61N03F from ZETEX at 0,3 EUR each... each one of these drives
1.2 amps continuous and 7 amp impulsive current. not bad.

so up to now we have 3 EUR + 0.9 EUR + 1 EUR for random passive parts = 4.9 EUR in parts
let's imagine we build a pcb for these modules... a propotype run with one of my manufacturer costs about 350/400 EUR for 3 panels. with these we can make for sure at least 100 pcbs. 400/100 = 4 EUR

so our running cost is now 8.9 EUR per module.. we'll need to add connectors to make it easy to mount and wire up... let's say 3 more eur...
total about 12 EUR per pixel.

now we need to imagine how these guys can communicate with each other. there is a nice protocol called RS485 that uses a twisted pair cable to connect a lot of devices up to hundreds of metres of distance. depending on the speed and lenght of cable you can hook up a lot of devices to the same 2 wires.
the DMX devices use this protocol at the hardware level to communicate.

something like the LMS485CNA is sold by farnell at 0,82 EUR for more than 10 pieces.
(max485 and 75176B are also popular RS485 interface chips).

now with this setup you can connect quite a lot of of these RGB dimmers on the same shielded cable.

theoretically the budget is about 15 EUR a piece excluding the LEDs and assembly.

let's look at the software now.

we need to immagine a simple protocol to use with this....why a protocol? because we are going to
spit out a lot of data that has to reach the right pixel in order to work properly. being able to address each pixel individually helps because between each change we can send data only to the pixels that are actually changing and skip the ones that do not need to change.

DMX could be implemented but it might be tricky directly in arduino. we could settle for a simple protocol.
the software could working like this
we send the address of the pixel we want to change followed by the 3 values of the RGB levels.
in order to make it super easy for the code to recognise addresses from values we will use ascii codes to specify the values and codes from 128 to 255 to address the pixel.

this give us 127 addresses

void loop() {

read serial port
is the number more than 127 and the number == to my address?
read 6 bytes more (3 values represented in hexadecimal ascii)
convert the 6 hex codes into 3 bytes
set the pwm lines to these values

}

essentially this does it.

on the computer side we can use an arduino board connected to the USB connector and plugged to an RS485 transceiver. the computer could send the pixels that have changed to arduino which will push them to the bus.

the address can be specified either by adding 7 dip switches to 7 pins and program it in binary. or
use a special packet which will specify the address the board needs to assume and the microcontroller will store it in its eeprom ( a non volatile memory that sits in the microcontroller)

this is it mr benedikt, you owe me a dinner now :))

massimo

a little addition about speeds
if the cables are fairly short, say less than 30/50 metres
I think the serial speed could be pushed to 115200 which is supported quite well by arduino at 16MHz.

since we push 1 + 6 bytes per pixel this means 70 bits per pixel (yes every 8 bits you need to add 2 more bits, the start and stop bit)
imagine that we have 100 pixels and we want to refresh them all at once (the worst case scenario) this means
70 * 100 = 7000 bits

not if we divide 115200 bits/second by 7000 bits we'll see how many times in a second we can refresh the display 115200 / 7000 = 16,45 this should realistically give us 10Hz refresh rate. you can do pretty good stuff at tha speed especially if you enhance the software that runs on the microcontroller and make it deal with fading from one colour to the other (this avoids you having to constantly refresh the colours)

have fun

massimo