I’m making a bike wheel POV display with WS2812-based strips (60/m). I already have the hardware done and can display basic colors and rainbows but I wanted to ask for advice about managing the pixel data for things like bitmaps and patterns and text. Specifically, I’d like recommendations about how to structure my RGB arrays and pump them out to the FastSPI_LED2 library for display. Initially I will just generate patterns on the fly or store maybe one or two images (I am using the Teensy 3.0, BTW). Eventually I’d like to have images stored on a microSD card connected to the Teensy.
Also, does anyone know of any PC software for creating binary RGB arrays out of bitmap images? Something like Adafruit’s SpokePOV software but which can be customized for # of pixels in the column and # of radial pixels and would support RGB pixels. I’d like to use 15 vertical (column) pixels and 128 radial pixels for a total of 1920 per rotation.
Funny you should ask. I’m working on a similar system, except for a poi system. Two pieces of clear tubes with 192 LEDs in each (4x48 pixels), flashing static POV images or text. It started out with code from someone else and they stored rgb values as 0b0rrggbb0 in HEX form and stuffing it in PROGMEM. This allowed for somewhere between 7 to 16 small images (or upwards of 30 on a larger AVR). I changed that.
My system now stores data on an SD card, and I store true RGB values. For now, I wrote a short C++ console application that reads in an image, scales it according to the amount of pixels, then extracts the RGB values for each and every pixel (one column at a time.) I dump all of that in a binary file. Eventually I’ll write an actual interface but that’s a long ways off.
On the Arduino side, I read in 144 bytes for each column (144/3 channels = 48 pixels) and push it out to the string.
It sounds like I should treat my setup as 15-pixel strings (I’ve got 4 per wheel, two on each side separated 180 degrees) that have 128 columns. I want both strings on a side to display the same output to help increase the POV effect at slower rotational speeds. I am also exploring the use of the input capture function of the FlexTimer module on the Teensy 3.0 to keep track of my hall effect sensor and rotational speed without any CPU overhead.
For your setup, do you have 4 separate 48-pixel strings all displaying different information or are they at right angles so you can see it from any angle?
Nope, all four sides show the same thing, which is why I treat it as 48 pixels. So I only need to store 48 pixels worth of data, and just it out to all four sides at the same time. A poi moves and rotates through the air, so having different stuff displayed on each side isn’t going to work very well.
So taking a ‘wheel’ as example, I’m only addressing half of it since it will rotate 180 degrees to the other side anyway (albeit upside down.) It’s harder to treat the full length, although not impossible.
Same reason I’m working on this system I’m doing. The original setup stores small images with limited colors in PROGMEM, and it’s upwards of $1,500 … Nothankyou.
Has anyone compared FastSPI_LED2 to OctoWS2811 on the Teensy 3.0 with the WS2811-based strings as far as speed is concerned? I like the DMA aspect of the Octo library but FastSPI has great color control functions and seems more flexible.
In my application, if the wheel is turning 4 RPS (15-20mph) and I have 128 radial columns, that means I have to update all 60 pixels in less than 2ms. The min time to update 60 pixels @ 800kHz is 1.8ms so I don’t have much time to setup the next output. If you have multiple strings defined when using the FastSPI_LED2 library, do they update simultaneously or sequentially?
I’m working on a similar system, except for a poi system. Two pieces of clear tubes with 192 LEDs in each (4x48 pixels), flashing static POV images or text. It started out with code from someone else and they stored rgb values as 0b0rrggbb0 in HEX form and stuffing it in PROGMEM. This allowed for somewhere between 7 to 16 small images (or upwards of 30 on a larger AVR). I changed that.