Artnet to OctoWS2811?

Status
Not open for further replies.
ok i will order a teensy and put everything together...
i already made some arduino stuff but i´m totally new to teensy so i might need some help??
how to start with that project just following the instruction from the octows2811 ?
or does someone has a small tut for me?
 
Nlecaude, I think that I have misunderstood the functionality of the operation codes. I was looking at art-address opcode, but need to do some more digging to see if this is the case. Alternative would be for each teensy to only harvest data from predetermined universe numbers into the buffer, and ignore all other universe data as you suggested. This would spread the led number over more teensy and avoid running into max buffer sizes, and speed up pushing the data out to the ws2811 as shorter strips could be used. I wonder whether using an if statement in the routine would slow it down too much?

I did not use the adapter, but wired the wiz net module straight to the teensy, not pretty.
 
Last edited:
hmm are you sure the teensy should take point to that?
i can define this in my software, there i can say which ip adress will get which universes and there i can also remap the universes!
(the remap function is not available in much programs so there should be a possibility to change the start universe in the code, or if possible changing ip, subnet and universe via dmxworkshop?)

1 WIZ820_SD_ADAPTOR Teensy 3 to WIZ820io & SD Card Adaptor
1 OCTO28_ADAPTOR Teensy 3.1 OctoWS2811 Adaptor
2 HEADER_14x1_D Pins (header), 14 pins, 0.1 inch (2.54 mm) spacing, Double Insulator
1 TEENSY31 Teensy 3.1 USB Development Board
2 HEADER_14x1 Pins (header), 14 pins, 0.1 inch (2.54 mm) spacing
2 SOCKET_14x1 Socket, 14 pins, 0.1 inch (2.54 mm) spacing
(the wiz820 is already ordered)
i think this should be all i need?


how do you control more then 8 universes?
multiple universes per pin?
 
Last edited:
Xaver2k said:
how do you control more then 8 universes?
multiple universes per pin?
Click to expand...

universe led number does not have to be strip length, so yes, there will be multiple universe per pin. As an example, I ran 16 universe output to the eight strips, where as a test the strips were each 30 leds long, and each universe numberofchannels was 45 (3* 15 leds - to cover R G & B).

I like the idea of simply altering the start universe number in the code for each seperate teensy, and then adding in variable to count channel number up to so that only those are put into the given teensy buffer.
 
Last edited:
Yup, that's pretty much how artnet nodes work, I'm curious to see how many leds a teensy 3.1 can handle using artnet at a decent fps.
What's for sure is that it's the cheapest way to create an artnet node...
the enttec ode is 275 $ !
 
hmm i have some other artnet nodes that are cheaper if anyone is interested, pm me.

i will order the teensy stuff these days and hope it comes soon ^^
 
Yup, that's pretty much how artnet nodes work, I'm curious to see how many leds a teensy 3.1 can handle using artnet at a decent fps.
Click to expand...
Down the line, a bit of optimising through frame rate testing for a variety of setups would be very useful. For example, when would it be worth the additional cost of additional teensy and cabling hardware. Syncing of multiple teensy would not be an issue as each would only be sending out led updates for its own universe numbers.
For frame rate, I was only testing over my wireless network, when 60*8 led array ran into problems at >15fps. You could run a test on your direct connection with the macair without the full array, but telling teensy and artnet output device that there are many more than there are, and then see when things start to glitch?
 
Yes that's a good idea ! My macbook air is getting a new screen at the apple store (got to love their return policy) but I'll test that as soon as I get it back !
 
So, have run some data transfer tests with different permutations. Using my old macbook connected directly to the ethernet module i can transfer up to about 16,000 led data sets a sec. Above this, the frames are incomplete. This test was done with these scenario:
90*8 leds @ 20fps
80*8 leds @ 25fps
50*8 leds @ 40fps
There was a difference in success when using different universe numbers. I found that using larger universe size and fewer universe was more successful than using lots of smaller universe ( i guess that this is to do with the packet overhead building up). An example was that 50*8leds @ 40fps worked well with universe size of 50, but not with universe of 25 (i.e 16 universe rather than 8). This test was carried out using the Pixelcontroller software for artnet output and the wiznet 820 with teensy 3.1.
 
nlecaude said:
thanks for the test !
What do you mean by 16000 led data sets a sec ?
Click to expand...
sorry for poor terminology. It was a way to describe the 24bits for each led and fact that there is packet overhead.
so, 90ledswide*8ledshigh*20fps = 14400
or, 50ledswide*8ledshigh*40fps = 16000
or, 80*8*25 = 16000
these combinations worked, but any combinations over the 16000 failed

I'm too lazy to do the calculations for byte transfer rate, and it seemed more useful to express the boundary in amount of led changes in a sec

also, another issue would be starting to get into strip length update rate issues for longer strips, as each ws2811 pixel has a fixed time delay along the chain, which start to add up in total
 
Last edited:
Ah ok got it !
That's interesting. I wonder if PixelController being in Java could be a bottleneck.
I'll do some tests with max, I only have 192 leds so seeing the problems might be more difficult.
 
nlecaude said:
Ah ok got it !
That's interesting. I wonder if PixelController being in Java could be a bottleneck.
I'll do some tests with max, I only have 192 leds so seeing the problems might be more difficult.
Click to expand...
I spread my pixels over the eight pins to pick up issues, as it was the data going through to the last pin that was being corrupted.
 
I just did some testing and I've seen similar results.
My test setting was a bit different, I had 3 rolls of 150 leds so 450 in total.
I used NeoPixel because for some reason OctoWS2811 did not like those strips.
I drove the 450 leds from Max using 3 universes. (first 2 universes use the full 512 channels)
I was able to control 341 leds before it would glitch at 44fps
Strange thing is that 342 leds starts using 3 universes and that's where it starts to glitch, wonder if there's some weirdness here....
But it seems as though I have results similar as yours as 341 leds * 44fps =15 004 which is not far from the 16000 figure you came up with.

If I have time I may try doing the same test over serial to see if I get better results. I'm surprised I would have expected better results...
 
Also, in my case I noticed that when I start sending a third universe, I don't get any more packets from universe 0.
 
nlecaude, I have issues with your version of the sketch not sending all universe correctly to leds. I will have a look and see whether it is me forgetting to set a parameter correctly, or something in the revised code. Seems to behave like a buffer issue.
 
Last edited:
I made some further testing and I don't think it's a buffer issue. If I comment the leds.show() function, I receive all the universes and the sequence number is correct. I have the feeling that as more data gets received, leds.show() takes more time to process and we begin missing udp packets... Not sure how we could optimize this...
 
Wow I just realized I wasn't using the Ethernet library at full speed... new tests to be done soon.
I also think it might be better to buffer all incoming universes before sending to leds, more on this soon !
 
nlecaude said:
Wow I just realized I wasn't using the Ethernet library at full speed... new tests to be done soon.
I also think it might be better to buffer all incoming universes before sending to leds, more on this soon !
Click to expand...

yes, using a buffer for all leds is how I set up the original code that I found to work with many leds and universes ;)
 
I'm not sure I understand your code then, unless I'm mistaken you still update the leds for each packet received ? (which means universes aren't on sync)
 
nlecaude said:
I'm not sure I understand your code then, unless I'm mistaken you still update the leds for each packet received ? (which means universes aren't on sync)
Click to expand...
The code had all universe going into one large buffer from the interim buffer, so that the send to leds call was made only at the end when all universe had been placed into the buffer. The universe number was used in the for loop to send the address to the correct location before placing the next set of led values in tot the big buffer
 
Hmm is this the code that was posted on page 5 ?
Because from what I see the 3 for loops are executed at each packet read which means that each universe is sent at a different times to the led :

Code: 
//read incoming universe and put into buffer
       for(int i=start_address;i< number_of_channels;i++) {
            channel_buffer[i-start_address]= byte(packetBuffer[i+art_net_header_size+1]);
          }

      //------put into the right part of the display buffer----//
      for(int i=0;i<number_of_channels;i++){
         buff2[i+((incoming_universe-first_universe_number)*number_of_channels)]= channel_buffer[i-start_address];
         }       

      //------send to leds----//
       for (int i = 0; i < ledsPerStrip*8; i++) {
       leds.setPixel(i, buff2[(i)*3], buff2[(i*3)+1], buff2[(i*3)+2]);
       }      
      leds.show();

Let's say you receive a packet that is universe 1, in the first for loop packet buffer will get filled with that universe, then in the second for loop it gets placed in a larger buffer at the correct position, then it gets sent to the leds. so if you were sending a total of 3 universes, the first one would have already been sent to the leds...
 
I did more testing, using 492 leds on a single pin (with neopixel)
By modifying the code to wait until it gets all the universes (3 in this case) before calling leds.show() I was able to go at 220fps (!) If someone has a large array I can send the Max patches and code I used, would be nice to test with more !
 
Status
Not open for further replies.
Back
Top