favorite RGB LED effects?

Posted on
  • Hi all, at the 33c3 event we have a working Espruino LED Matrix with 13x13 pixels and one button to switch patterns so far. Current code is here (alpaca() displays a logo):


    What are your favorite LED effects? I would love to testdrive / showcase even more of what it can do :-)


  • current status is "we'll rewrite it in c, the interpreter is too slow for effects"

  • Actually what I did successfully (with an Espruino pico - not a puck) was this:

    • have two LED strips with about 20 LEDs each on two separate pins
    • have a hall effect sensor to a third pin
    • Pico + Strips powered by 4 x AAA rechargable batteries (so about 4,8V)
    • built into a bicycle wheel

    The software:

    • the time between two passings of the magnet are measured.
    • the whole time is divided into about 30-40 slices
    • for each slice a different color pattern is pushed to the two LED stripes

    -> POV effect with JS interpreted Espruino!
    Call that too slow... ;-)

    (just uploaded a picture and video; the flickering is mainly from the phones camera. Looks quite steady with your eyes)

    2 Attachments

  • @ChristianW

    looks great.

    Doing things custom to the resources many things work where brute force methods fail.

    The lights or the breaks look like bright and dark spokes. Are the breaks / darks spokes from when the data is transferred to / through the LEDs?

    4 strips - 2 times 2 in parallel - interlaced could provide a (almost) contiguous wheel or disk, could it?

  • @allObjects thanks.
    The dark spots are simply the interference of the rotation with the shutter speed of the iPhone cam.
    As I said: with human eyes it looks nearly like closed circle.

    The more strips you take (I had only two) the better it looks even for slow rotation speeds - but also needs more CPU power.
    I doubt the Pico would be capable of much more strips and/or speed - however I never tried it out on a real bike (yet) to see where the maximum is.

    What actually doesn't work flawlessly: using a second timer to update the text in the graphic buffer dynamically. Every time you operate the buffer takes some CPU cycles from the update timer and you have a big gap in the picture for a fraction of a second.

    I have attached the sourcecode of this demo in case anyone is interested.

    1 Attachment

  • Ic. Did clearly not take into account the strobe effect that the CAM produces... usually it is the light that creates the strobe effect. ;/

    What it makes to the 'naked-eye-cam' is all what matters! ...and there it is perfect.

    I glanced over the code. I assume it writes out lines... that means, that the text has to be vertical, is it?

    Next thing is to see this powered by a dynamo... the old style of a knurled-friction-on-tire-dynamo... Don't know the voltage range... it was running 6V incandescent bulb... for sure it was AC... a bridge rectifier, a resistor in-line and a Zener limiting to PICO max supply voltage... may be buffering with rechargeable battery could balance it out and allow special effect below a particular angle velocity...

  • I glanced over the code. I assume it writes out lines... that means, that the text has to be vertical, is it?

    Sort of.
    Actually the picture buffer stores 50 lines (should have named that "spokes" or "columns" to make it clearer).
    The g Graphics object takes care of the mapping. From g's side the picture is drawn horizontally.
    The point is to have each "spoke" ready to be pushed out to the LEDs as an array in function refresh() just after choosing which spoke it actually is at that point in time/revolution.

    Next thing is to see this powered by a dynamo...

    Would be nice, but I don't think so. It's not trivial to get the power from the fixed dynamo/fork to the rotating wheel. The batteries would last for hours anyway - and besides that it isn't even legal on German roads, so why push it any further?
    It was just an experiment - a proof of concept for me.

    PS: just found another picture of an old-fashioned digital camera with some longer shutter time.
    It doesn't show the nice rainbow colours as nicely, but you get a better impression of the whole frame.

    1 Attachment

    • P1040479.JPG
  • Perfect!

  • That looks amazing, and you've got a pretty high resolution out of it too!

    Since it's basically single-threaded it's going to be difficult to handle the graphics updates nicely. I guess you could just turn the lights off for one whole rotation while you did the work.

    Looking at the code, I reckon you might be able to get it faster using Graphics.createArrayBuffer instead of createCallback. You could then use g.setRotation to make the orientation such that each row of the backing ArrayBuffer was actually a column - and then when you went to render it you could just use new Uint8Array(g.buffer, width*3*column, width*3) to get each column - it references the array so doesn't actually copy any data.

    I'm sure it'd still delay the sending of a few columns, but it might not be as noticeable.

  • Thanks Gordon - totally missed your post.
    Currently I was working on the next project already, but I feel like trying your suggestions out.

    Good Idea to blank out during updates. And also the thing about array handling which may be the most time-critical aspect in the setup.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

favorite RGB LED effects?

Posted by Avatar for user69728 @user69728