OctoWs2811 Video with software other than proccessing

Status
Not open for further replies.
C

cat

Active member
Hi Paul,
Thanks for the octo library, its great :)
I'm trying to control my board from vvvv, I'm not really that skilled at textual programming, I use vvvv, a node based environment.
I'm trying to work out how to replicate the movie2 serial in vvvv, and I can control the pixels, and even control 1 pixel, but I can't work out how to format the serial commands so that I can control colour in a meaningful way...
I've captured the output of movie2serial, by echoing the serial data over udp in processing, and I can see that the first 3 bytes control the config, as they should, but the next 24 bytes seem to control the colour in a strange manner!
I've initially tried convert RGB values into a 6 byte Hex code and sending that (based on http://en.wikipedia.org/wiki/Web_colors converting RGB to hex section), but there are definitely 8 bytes per colour so I know thats wrong!
I've tried converting integers to raw bytes and sending that, but from what I'm seeing in the udp echo, it looks like the values are changing a bit like binary, but not binary, could explain how they are encoded?
Maybe you explain how a raw image is converted to serial in a little more detail? I'm sorry if this is a bit basic, but I've never used processing before, and can't seem to work it out!

My ideal solution would be to hack the octo library so I could send RGB values as hex, one byte for each colour or each pixel which should give me 8 bits per channel, and I see on the octo page it says you can send colour as RGB255, but can't work out how to do that either!
Ultimately I'd like to be able to use Ethernet and send artnet, but even udp of the serial as it is now would be good (Octo uses a pin that the ethernet would normally connect to, so is this even possible?), in fact at the moment straight connection via serial would be enough!
Hope you can help!
Thanks

Chris
 
I guess what I'm asking is why are we sending 24 bytes for the colour, rather than 24bits, and what format is the colour encoded in?
 
The data format is the raw bytes that gets sent directly to the 8 LED strip.

So each 24 bytes is 8 pixels. Each pixel in one of the 8 bits across all 24 bytes. The first 24 bytes are the last pixels on each strip, where bit 0 is the 24 bits for the LED at the end of the first strip, bit 1 is the 24 bits for the LED at the end of the second strip, and so on.

In the movie2serial code, you can see the code reads 8 pixels and converts all 8 to this "transposed" format.

Code: 
      for (int i=0; i < 8; i++) {
        // fetch 8 pixels from the image, 1 for each pin
        pixel[i] = image.pixels[x + (y + linesPerPin * i) * image.width];
        pixel[i] = colorWiring(pixel[i]);
      }
      // convert 8 pixels to 24 bytes
      for (mask = 0x800000; mask != 0; mask >>= 1) {
        byte b = 0;
        for (int i=0; i < 8; i++) {
          if ((pixel[i] & mask) != 0) b |= (1 << i);
        }
        data[offset++] = b;
      }
 
Chris, this took me a while to get my head around too when I first started digging in to it. Don't think of the 24 bytes as normal RGB color values, they're not. An RGB color value is 24 bits which are normally placed right next to each other in 3 bytes. That's not what happens here. The OctoWS2811 library works by pushing data directly out to memory mapped DMA pins, which means when you output a byte it shows up as signals on 8 Teensy pins, which correspond to 8 different strips. So each byte of data is 1 bit of a color value for 8 different strips. So your RGB color values get stretched across 24 bytes and interleaved with RGB color values for all of the other strips too. It looks something like this:

Code: 
Strip 0:  0               0               0               0               0               0               0               0
Strip 1:    1               1               1               1               1               1               1               1
Strip 2:      2               2               2               2               2               2               2               2
Strip 3:        3               3               3               3               3               3               3               3
Strip 4:          4               4               4               4               4               4               4               4
Strip 5:            5               5               5               5               5               5               5               5
Strip 6:              6               6               6               6               6               6               6               6
Strip 7:                7               7               7               7               7               7               7               7

          0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 

         |----byte 0-----|----byte 1-----|----byte 2-----|----byte 3-----|----byte 4-----|----byte 5-----|----byte 6-----|----byte 7-----|

The above just shows 8 bytes, so it would correspond to just the Red portion of an RGB color value. The Green and Blue values would be laid out subsequently in the same fashion. See how a 24 bit color value becomes 24 bytes because each bit of the color is interleaved with the corresponding color bit for all the other 8 strips.

Hope that helps,
Edwin
 
Thanks so much guys!
I wish I'd asked the question sooner instead of trying to work it out for myself! I have an initial version working turning values into control messages for the leds I'm going to try and optimize it and then try to get video converted to raw in the same way, that may or not be possible with vvvv, when I'm done I'll post it...

Any thoughts on whether I could udp into the teensy, ie is it possible to connect the ethernet board and the LED's at the same time, it would mean loosing the frame sync pin, but I wouldnt need that for artnet anyway, they should just update as soon as they get data.
 
Status
Not open for further replies.
Back
Top