configuring octows2811 library for use with 4 16x16 ws2811 ws2812b pixel panels

Status
Not open for further replies.

lynton

Active member
Hi all,

I am attempting to make a wearable 32 x 32 pixel display using 4 16x16 flexible ws2811 ws2812b pixel panels.

For this I have purchased the following hardware :

1 x teensy 3.1
1 X octows2811 adapter
1 x audio adapter
1 x nrf8001 BLE 4.0 bluetooth breakout
4 16x16 flexible ws2811 ws2812b pixel panels

My goal is to connect the 4 16x16 panels using the octows2811 library and to
read video data from the SD card on the audio adapter (and later to also use the audio features of the card).

The panels appear to be the same as a 256 ws2812b led strip shaped into a solid 16x16 square in a zigzag arrangement.

I want to have the 4 panels arranged into a 32x32 grid like so

[a]
[c][d]

and use 4 channels of the 8 available on the teensy one for each panel.

When looking at configuring the octows2811 library the LED_WIDTH setting
seems to assume that a single strip covers at least one row so I can't see a way to configure it for tiled matrix displays similar to the Adafruit_NeoMatrix library

Can anyone suggest a way to configure it for this arrangement, or an easy way to modify the library to achieve the mapping I need ?

Can the teensy 3.1, the audio adapter, and the octows2811 adapter all be stacked on top of each other with headers ?
Do any pins need to be removed or jumpered to do this ( i read something about removing pin 4 for sd card access on the sd card adapter when using the ws2811 adapter )
Will all these cards work together or will some features be disabled or fail with this combination of hardware i.e. are there any conflicting pins on these cards ?

Thanks for any advise, I'm fairly new to all this stuff, so if these questions seem silly they probably are :)


regards
Lynton
 
Hey!
Seems like an interesting project. I can't speak for all of the points you're asking about but in terms of mapping I can tell you how I would at least handle this:


So, when working with led's in teensy's code, you would normally iterate through your led's like this:
Code:
for (int j = 0; j < (ledsPerStrip * 8); j++) {
   leds.setPixel(j, led_r, led_g, led_b);
}


However, that doesn't help you if your led's are wired any differently than zigZags or rows and columns.

The rgb values in your video source might be ordered like this:
[00,01,02,03]
[04,05,06,07]
[08,09,10,11]
[12,13,14,15]

Your led's would be ordered like this (but on a larger scale of course):
[00,01,04,05]
[02,03,06,07]
[08,09,12,13]
[10,11,14,15]

If you then "layed" your LED array ORDER over your VIDEO array order, and pulled each led number based on the SAMPLING order from the video then you would get this:
[00,01,04,05,02,03,06,07,08,09,12,13,10,11,14,15]

It looks like a jumbled mess but it's premapping the led's in a way.
So how would you use this?

Instead of iterating through your led order from above, iterate through your MAPPED order instead:

Code:
mappedOrder[] = [00,01,04,05,02,03,06,07,08,09,12,13,10,11,14,15];

for (int j = 0; j < (ledsPerStrip * 8); j++) {
   leds.setPixel(mappedOrder[j], led_r, led_g, led_b);
}

Obviously handcoding 1024 values in your case would be a giant pain BUT you only need to do it once. I've used this tactic several times in different software but you could probably throw something together in processing to generate this 1 line of code that you could then copy paste into your arduino sketch as an array.

Hope that helps!
 
Hi VideoSound, thanks for responding,

I've noticed that approach before, but the problem for me it that when looking at the Octows2811 VideoSdCard.ino example code.
the video data is read into the drawingMemory and then a call to leds.show() is made. So setPixel() is not used, or at least not directly from the arduino code.

Code:
       if (sd_card_read(drawingMemory, readsize)) {
          // Serial.printf(", us = %u", (unsigned int)elapsedSinceLastFrame);
          // Serial.println();
          while (elapsedSinceLastFrame < usec) ; // wait
          elapsedSinceLastFrame -= usec;
          leds.show();
        }

So I can't see an easy way to configure the library for use with my 4 16x16 panels when reading video data,
To me it appears that to get this work I need to be able to tell the library how my pixel panels are arranged somehow,
or am I missing something ?

Using jinx or glediator LED editors I can create animations, and can display to the panels in my arrangement from a PC
connected to an arduino, so I guess the LED Editors already map the pixels to the matrix arrangements, and send it to the arduino as if if they were one long strip of (remapped) pixels.

The plan is to save the LED editor output to an SD card and have the teensy code read them into the drawingMemory somehow.

Thanks again for replying,

Lynton
 
The issue here is to minimize the amount of data manipulation, because the more code you put between your stream and the drawmemory, the lower the FPS gets. So probably the best way is to encode the stream in the LED layout format, that way you can retain the max FPS and leave the processing to the program that saves the file to the SDCard.
The you don't have to worry about the mapping in the teensy.
 
Ahhhh , thankyou jonnyfp.

I think I understand now, as long as the LED editing software can display onto the panel arrangement correctly then the captured output will be already mapped to my matrices and the Octows2811 library will not need to do anything extra to reorder the pixels.

I think I was confused after looking at the adafruit NeoMatrix library where you pass panel configurations to the constructor, but I guess this is only for use when the pixels are not already ordered correctly.

So all I should need to do is to plug my 4 16x16 panels of 1024 pixels into the first 4 octows2811 teensy pins 2, 14, 7, 8 and set ledsperstrip=256
i.e. configure for 2048 pixels but only use the first 1024 that will be in the Glediator output file which will already be in the correct order.

Or more efficient but messy alternative would be to cut the panels in the middle and hook it up 8 x 16 x 8 panels.

I all seems so obvious now :)

I have one more concern with powering, I read all the documentation on teensy powering and cutting VUSB pads etc, but I gather that cutting is only necessary if using exernal power and USB power at the same time. I am still a bit nervous about this though,

So if I use the same regulated 5V supply to drive the 1024 LEDs and power the teensy AND make sure that the external supply is NEVER connected at the same time as the USB is this safe ?

thankyou,

Lynton
 
It's all about refresh rates as well so don't go putting everything just on one channel. So For example if you have one string of 1024 leds arranged in you 32x32 grid, then it will take 1024 clock cycles(This is not the case, but made simple for this explaination) to serial out all the data to all the LED's.
However if you can put 4 parallel strips with 256leds on each then it will only take 256 clock cycles to output the data, hence your refresh rate goes up and you can have smother animations.
Go to 8channels or even 16 and you can up the refresh rates even higher.

As for not cutting. Yes that is safe. Just don't do both. The only concern is if you do hook up the Teensy to your PC when the teensy is also powered by the regulator then you will most likely see that your PC shuts itself down, at worse you will blow up your PC's USB controller or PSU.
 
It's all about refresh rates as well so don't go putting everything just on one channel. So For example if you have one string of 1024 leds arranged in you 32x32 grid, then it will take 1024 clock cycles(This is not the case, but made simple for this explaination) to serial out all the data to all the LED's.
However if you can put 4 parallel strips with 256leds on each then it will only take 256 clock cycles to output the data, hence your refresh rate goes up and you can have smother animations.

Yes the 4 panels I have are rigid 16x16 matricies,
Just so its clear please allow me to reiterate :

The panels appear to be the same as a 256 ws2812b led strip shaped into a solid 16x16 square in a zigzag arrangement.
I want to have the 4 16x16 panels arranged into a 32x32 grid like so

[a]
[c][d]

so my plan is to have each panel on 4 separate channels using the first 4 octo pins i.e pins 2, 14, 7, 8 for A,B,C,D respectively and set ledsperstrip=256
using 4 channels , one for each panel.

The LED software will premap the pixels in this arrangement so nothing needs to be done in the teensy code utilizing the octows2811 library,
I should just be able to read in the data from an sd card, memcpy to the displaybuffer and call leds.show().

As I am only using 4 of the possible 8 channels the buffer will be twice as large as really required but this will still work although less efficient than if
I used all 8 channels.

Go to 8channels or even 16 and you can up the refresh rates even higher.

I could cut the signal line on the panels in the centre to make 8 16x8 panels but would prefer not to cut them, so just plan to use 4 of the 8
channels.

The teensy has 8 channels I believe, so to get 16 channels 1 would require 2 teensy controllers as there are only 8 on each is that correct ?

Sorry to be so verbose, I just want to make sure I am on the same page understanding this.

many thanks again for your advise.
 
I can't find the forum entry but I believe a member got 16channels working. The DMA is capable of moving 32bits at a time, now I can't see how he managed to get it all on one port, in fact I can't believe that he did, PORTC is the only one with 12bits accessable, so not sure. Anyway I digress.

The buffer will be the same size as the Octolibrary will use all 8 channels. Just that the top 4 will be unused or black.
 
I have one more concern with powering, I read all the documentation on teensy powering and cutting VUSB pads etc, but I gather that cutting is only necessary if using exernal power and USB power at the same time. I am still a bit nervous about this though,

No need to be nervous. It really is a very simple step, and in the end much safer, just a couple of scores with a fine blade. the link can be quickly reinstated with a small solder dab if needed.
 
Status
Not open for further replies.
Back
Top