16 thoughts on “Ping Pong Ball LED Wall Display

  1. 40 ATmega48s 240 LEDs? I can’t read the site to understand their reasoning, but wouldn’t a bit of multiplexing have helped here. I mean, an ATMega48 has quite a bit of IO already.

  2. Multiplexers would slow it down, but I don’t see it slowing it down that much, especially considering how the processors must have to communicate with each other. So I also don’t understand why they did it this way…

  3. Bunch of amatuers…. They could have easily doubled the amount of pixels and it’s not even in color….

    BTW.. If your at a party…. no one cares who Made your piece of shit display….

  4. I have to say I dont understand the 40 Atmega chips either, there are like 20 pins available on each chip so could have easily used 12 chips rather than 40… Without any multiplexing… All I can think of is that it avoids having driver chips since you can probably draw that much current with no issues from a single chip.

  5. there would be a perceptible flicker if you tried multiplexing 240 LEDs. they were probably also worried about being able to power all of them.

    but…one atmega48 per 6 LEDs? i can’t read it, but the site mentions something about PWM. I didn’t seen fading or anything like that in the video though.

  6. Ahhh, there are 6 PWM channels on the chip, hence each LED is dimmable to 255 different levels.

    I have no idea why that is useful for the display shown but I guess they wanted that as a feature!

  7. Well… I see, you all wonder, why we used 40 AVRs.
    The main reason are the hardware-PWM-channels.
    Every LED is 8Bit dimmable. You can see it at the very beginning of the Video, the “falling” stripes are fading in and out.
    We also have a very cool “wave-function” (unfortunately not on the video), where the LEDs are faded pretty impressively. (waves travelling over the display) The software for controlling the LEDs is still very young, so there is plenty of room for improvement (using more fading etc.)
    Multiplexing would have been too complicated to get it not flickering, so we decided to use 40 AVRs. This also has the advantage, that the picture will never flicker due to interrupts. The AVR manages the data transmission while the hard-PWM is running and won`t get disturbed. If we implemented software-PWM, it could have had disturbances.

    Greets from Switzerland

  8. This is the proper place to insert the following remark: we need fabsy to join #hackaday, the idlers are starting to turn gay without any females around. Only Queen Sierre can save us.

  9. @mario

    What about software PWM?

    I’ve got a 16MIPS PIC driving 100RGB LEDs (300 LEDs…) with 8bit PWM at just under 15FPS with simple multiplexing. Uses a full 8bit wide port and two or three misc. I/O ports.

    40 uC is WAY overkill IMO.

    Nice job though, it looks like it works.

  10. @jack

    The only thing I have at the moment is a thread I started on SFE forums to ask a few questions to get started. It’s been quite a while since I’ve posted goods there though. I plan on making a full write up once I finish the darned thing.

  11. I can imagine just using the 10-bit PWM outputs but it should still be possible to do hardware PWM in combination with a little bit of multiplexing. Setting the common output inside one of the timer interrupts to synchronize with the PWM frequency. With POV, the required current is not linear.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.