Artnet to OctoWS2811?

Status
Not open for further replies.
In the test I was getting up to 23 universes (universe 0 thur 22) b4 it would frezze from lack of memory ( when I maxed the buffer) I don't have my computer in front of me at the moment to say what I had the teensy set to, the program I am using to output artnet is grand ma 2, atm I'm using 8 lines of 13 LEDs each on its own universe 4 testing but when done testing will add 5 more lines to make 169 LEDs for a full universe but I would like to run 8 universe at 169 LEDs off the 1 teensy board some time in the future.
When the teensy boots b4 it's starts getting artnet all the LEDs go blue.

Will post again with the code I'm using when I can get back to my computer.
 
the blue leds at start up are part of a test method, its void showInit() at the end of the sketch. I put it there so that there was a visual cue that confirms to the user that the expected strip length and total leds being used correct. It then goes into receiving artnet data. You can change this to whatever, even write a method to lights each universe a different colour before receiving starts so that you can visually confirm your expected setup.
 
Ok I have my sketch open but don't have my teensy with me but I think I found my problem after rereading a early post. I didn't change universesize = 30

I had
ledsperstrip at 169
Universesize at 30 (have now changed to 169 and will try it when I get time)
Number_of_channels at 4096 (8uni by 512
Channel_buffer and buff2 at 26000

And the rest hasn't been changed but the Mac and IP
 
Last edited:
i should really sort out the universeSize thing, as this would automatically sort the channel number etc and avoid confusion. The number of channels must equal three times the size of the universe you are sending out, so that the sketch runs through R G and B for each led. The channel buffer size should equal the number of channels. I think that there is comment in the sketch on this.

I suggest starting with sending to just a small part of the array by defining a short strip length to make sure that you are not running into buffer issues. I have not tried to send to a strip of 169 leds long, but you would need to have the number of channels and channel buffer set to 3*169 = 507. I have not tried this. Like I said, start with a small array first and see where it crashes or goes wrong as you increase the size.
 
Last edited:
Nick1802 said:
atm I'm using 8 lines of 13 LEDs each on its own universe 4 testing
Click to expand...
in this instance, your output from the software should be set as universe = 13, and total led array size should be 13*8=104. in the sketch, strip length would be 13, universeSize (were it be used - which it isn't at the moment) would be 13, and number of channels and channel buffer size would be 13*3=39. Your software should output 8 universe of 39 channels if you told it that you had 104 leds of universe size 13.

hope its not too confusing
 
mortonkopf said:
in this instance, your output from the software should be set as universe = 13, and total led array size should be 13*8=104. in the sketch, strip length would be 13, universeSize (were it be used - which it isn't at the moment) would be 13, and number of channels and channel buffer size would be 13*3=39. Your software should output 8 universe of 39 channels if you told it that you had 104 leds of universe size 13.

hope its not too confusing
Click to expand...

sorry it is a little
what i understand from what you said

leds per strip is 13
universesize is 13 (but is unused)
number of channels is 39
channel buffer is 39
and buff2 is 312?

i dont have any leds on me but when i ran that sketch with only 8 universes out putting from the lighting desk it worked fine in serial
but when i uped the universes to cover all my moving heads and dimmers to over 20 it would hit universe 17 and lock up. when i made buff2 to 26000 i am able to get up to 255 with out any lock up
 
Last edited:
nick1802, attached is an updated version of artnet_octows2811. This uses universeSize for automatically setting other functions. All you need to do is change strip length and put in universeSize. you will determine universeSize from your software output settings.

EDIT: sketch removed. use updated sketch in later posts, this one is historical
 
Last edited:
mortonkopf said:
nick1802, attached is an updated version of artnet_octows2811. This uses universeSize for automatically setting other functions. All you need to do is change strip length and put in universeSize. you will determine universeSize from your software output settings.
Click to expand...

thanks Mortonkopf for all your help so far!!!

every thing is working fine but i cant find where its sending art-net universe number = 0!! its in the serial monitor but its not sending it to pin 2 :S. i get art-net universe number = 1 on pin 2 instead :S

i have tried -1 in the start_universe but that didn't work
 
nick1802, in your software (grand ma 2) is there a menu option to alter the universe external start number, try changing this to one rather than default zero, or the other way round (shooting in the dark here, really)? I assume that none of the led strips is showing what you would expect to be on pin 2?
 
Last edited:
When I was doing my testing I was using a program artnetominator on the same network to watch all artnet data. And the desk was sending it to universe number 0, same as the serial monitor was showing.
I feel like I'm missing something every simple!
 
nick1820, i think that your software must be starting at universe number zero, and this is being lost because my artnet code uses the more frequently used universe start number of 1. try changing the line in the artnet_octows2811 sketch from:

Code: 
buff2[i+((incoming_universe-1)*number_of_channels)]= channel_buffer[i-start_address];
and remove the -1
to give:
Code: 
buff2[i+((incoming_universe)*number_of_channels)]= channel_buffer[i-start_address];
again, just guessing as i am on mac so can't test windows software
 
mortonkopf said:
nick1820, i think that your software must be starting at universe number zero, and this is being lost because my artnet code uses the more frequently used universe start number of 1. try changing the line in the artnet_octows2811 sketch from:

Code: 
buff2[i+((incoming_universe-1)*number_of_channels)]= channel_buffer[i-start_address];
and remove the -1
to give:
Code: 
buff2[i+((incoming_universe)*number_of_channels)]= channel_buffer[i-start_address];
Click to expand...

thanks mortonkopf!!! it works great now!! thank you for all your hard work and time on this !!!

again, just guessing as i am on mac so can't test windows software
Click to expand...

the software im using cost over $2k to use as it needs the hardware to unlock universes
 
Now that is an investment. I will put an object in to allow selecting universe start number for zero or one, or any other number, and ref this in the grabbing data code then post up an updated version.
Glad it's all working

EDIT - here is the sketch that makes it all a bit easier (called ver3 )(uses universeSize, and first universe number to allow for artnet output software differences, as described above).
 

Attachments

  • artnet_octows2811.ino
    5.5 KB · Views: 834
Last edited:
I'm not sure I get why number_of_channels= universeSize*3;
Isn't the number of channels the same size as the universeSize ?
 
nlecaude said:
I'm not sure I get why number_of_channels= universeSize*3;
Isn't the number of channels the same size as the universeSize ?
Click to expand...

hi nlecaude, sorry for not responding sooner, I have been 'off-grid'. Yes, exactly, RE pixelcontroller. Happy for anyone else to rewrite the sketch to make it more 'universal'. As you are aware, the *3 issue is because a channel is required for each of R, G and B, (each channel can only hold value of 0 - 255) but number of Pixel is the universe size. Sorry for any confusion.
 
Thanks for the clarification !
I did a new version for myself (hope you don't mind) and cleaned up some small things : https://gist.github.com/natcl/9604245

Mainly:
1) There were 2 buffers, channel_buffer and buff2, I merged the 2, seems to work with only one buffer unless I missed something obvious ?
2) Renamed some variables to be more consistent (CamelCase)
3) The loop that reads the data from the packet uses the dmx buffer length field included in the packet instead of the number of channels
4) Moved some of the print statements to a function for more clarity.
5) Changed UPD buffer size to 530 (as this seems to be the max size of an artdmx packet)
6) Adjusted the packet header size to 18 (from 17)
7) Changed the formula to calculate universe number to be Art-Net 3 compliant.
8) In the main loop that fills the buffer added a check in case we overflow the buffer
 
hey looks great!
what´s the possibility with that code and hardware(teensy 3.1)? maximum of full universes at an average fps (lets say 25fps)?
 
nlecaude, your changes to the code look elegant. There is a good opportunity within the code to make use of opcode values sent within the art-net packets to use mulitple teensy-octows2811 arrays. This would make better use of art-net 3 potential.

Xaver2k - yes, works with 3.1.
 
I don't think anyone tested such a large array yet, the data does come in but it's hard to say the performance without testing first...

mortonkopf: can you elaborate more on the idea of using opcodes to sync multiple teensy ?
 
i could test it with 8 full universes and an half universe, i have pixel construct of about 1450 ws2812 leds
to you think one teensy can handle it?

why do you want to sync teensys if you use it with artnet software?
 
It would really help if you could test ! I don't have enough leds sadly.

I did not explain myself well, I don't mean sync the teensies together, but assign each a different universe (or multiple universes) to each teensy to balance the load. I'm just curious as to which opcode mortonkopf refers too (besides the universe numbers)
 
Status
Not open for further replies.
Back
Top