Artnet to OctoWS2811?

Status
Not open for further replies.
Did you look at the different examples in the library ?
What you probably want to do is use the setPixelColor function to set a range of pixels (using a for loop) with the same channel values you get from artnet.
So leds 1-16 would receive channels 1, 2 and 3, leds 17-32 channels 4,5,6 and so on.
 
Last edited:
This is what I have so changed in the initial script and -logically- it should work... but it does not:

for (int i = 0; i < ledsPerStrip; i++)
{
for (int y = 0; y < 13; y++)
{
leds.setPixelColor(y, channelBuffer[(i) * 3], channelBuffer[(i * 3) + 1], channelBuffer[(i * 3) + 2]);
}
}




where y serves as the led number - this in theory should place the value for the first 1 artnet input across 1 neopixel ring containing 12 leds.... or am I incorrect in my assumptions?

The initial sketch worked properly as:
for (int i = 0; i < ledsPerStrip; i++)
{
leds.setPixelColor(i, channelBuffer[(i) * 3], channelBuffer[(i * 3) + 1], channelBuffer[(i * 3) + 2]);
}

This is the from the sample artnetneopixel sketch.
 
The code you're interested in modifying starts at line 66...

https://github.com/natcl/Artnet/blob/master/examples/ArtnetOctoWS2811/ArtnetOctoWS2811.ino#L66

Now.. ok, I have to say this code seems more complicated than it needs to be.. there are two loops.. the first loop copies the DMX values from the data[] (the artnet packet buffer) into channelBuffer[] .. and then second loop calls setPixel for each set of three (red, green, blue) channel values in channelBuffer. And the indexing scheme is a bit more than it needs to be. This whole thing could be written as one much simpler loop. But maybe there's a reason I didn't catch on my first glance...

In any case, if you look at the second loop, at line 74, that's where it does math with "i" (the pixel number) to calculate the channel number that is going to be copied into each color. Instead of doing "channelBuffer[(i" .. if you just changed the i to a zero.. it would simply use the first three DMX channels for all your LEDS.
 
I have to run out right now, but if you tell me how many pixels are in each neopixel ring, and how you want the channels mapped, I'll write you some code tomorrow to replace that second loop.
 
You can try this, this assumes you send 66 channels over artnet (22 rings * 3 colours)
I did not test it but I think it should work

Code: 
#include <Artnet.h>
#include <Ethernet.h>
#include <EthernetUdp.h>
#include <SPI.h>
#include <Adafruit_NeoPixel.h>

// Neopixel settings
const int ledsPerStrip = 352; // change for your setup
const byte dataPin = 2;
Adafruit_NeoPixel leds = Adafruit_NeoPixel(ledsPerStrip, dataPin, NEO_GRB + NEO_KHZ800);

// Artnet settings
Artnet artnet;

// Change ip and mac address for your setup
byte ip[] = {192, 168, 2, 2};
byte mac[] = {0x04, 0xE9, 0xE5, 0x00, 0x69, 0xEC};

void setup()
{
  Serial.begin(115200);
  artnet.begin(mac, ip);
  leds.begin();

  // this will be called for each packet received
  artnet.setArtDmxCallback(onDmxFrame);
}

void loop()
{
  // we call the read function inside the loop
  artnet.read();
}

void onDmxFrame(uint16_t universe, uint16_t length, uint8_t sequence, uint8_t* data)
{  
  // send to leds
  
  // for each ring
  for (int ring = 0 ; ring < 22 ; ring++)
  {
    // for each led
    for (int led = 0 ; led < 16 ; led++)
    {
      leds.setPixelColor(led + (16 * ring), data[ring * 3], data[ring * 3 + 1], data[ring * 3 + 2]);
    }
  }
  leds.show();
}
 
Last edited:
If you want to control both half of a ring independently you would use 44 and 8 instead of 22 and 16 and send a total of 132 channels.
 
Thank you both for your assistance nlecaude and Light-o-matic.

It appears that I attempted to take a very similar approach to your sketch nlecaude. Upon testing, it indeed controls an entire ring with only 3 channels, but will only work at with the first 3 channels. Your suggestion of inputting the altered values to control ring halves, indeed does control half the ring, but I cannot get it to respond to any channel beyond the first 3 of art net (thus only one half of one ring).

Is this somehow a limitation imposed by the for loop within another for loop?

Thanks again!
 
In this example only 1 ring is lighting up. They all respond properly (i.e.. channel 1 full=full red, and so on) but additional rings, or channels beyond 1-3 are unresponsive
 
My apologies nlecaude, your code works flawlessly, it was an error on my side altering the value for the smaller 12 led rings we are using. I failed to alter the 16 in the set.LedColor as well, causing an offset, ultimately pushing the grouping off of the rest of the ring. Upon correcting this, the sketch appears to be working great. Thank you again sir!
 
No problem, below is a version with constants instead of hard coded values which may be easier.

At the top you have
const int numGroups = 22;
const int ledsPerGroup = 16;

numGroups would be the total number of groups and ledsPerGroup is the size of the group.



Code: 
#include <Artnet.h>
#include <Ethernet.h>
#include <EthernetUdp.h>
#include <SPI.h>
#include <Adafruit_NeoPixel.h>

// Neopixel settings
const int ledsPerStrip = 352; // change for your setup
const byte dataPin = 2;
Adafruit_NeoPixel leds = Adafruit_NeoPixel(ledsPerStrip, dataPin, NEO_GRB + NEO_KHZ800);


// Group settings
const int numGroups = 22;
const int ledsPerGroup = 16;
// Artnet settings
Artnet artnet;
const int numberOfChannels = ledsPerStrip * 3; // Total number of channels you want to receive (1 led = 3 channels)
byte channelBuffer[numberOfChannels]; // Combined universes into a single array

// Change ip and mac address for your setup
byte ip[] = {192, 168, 2, 2};
byte mac[] = {0x04, 0xE9, 0xE5, 0x00, 0x69, 0xEC};

void setup()
{
  Serial.begin(115200);
  artnet.begin(mac, ip);
  leds.begin();

  // this will be called for each packet received
  artnet.setArtDmxCallback(onDmxFrame);
}

void loop()
{
  // we call the read function inside the loop
  artnet.read();
}

void onDmxFrame(uint16_t universe, uint16_t length, uint8_t sequence, uint8_t* data)
{  
  // send to leds
  
  // for each ring
  for (int ring = 0 ; ring < numGroups ; ring++)
  {
    // for each led
    for (int led = 0 ; led < ledsPerGroup ; led++)
    {
      leds.setPixelColor(led + (ledsPerGroup * ring), data[ring * 3], data[ring * 3 + 1], data[ring * 3 + 2]);
    }
  }
  leds.show();
}
 
I'm working on OctoWS2811 version 1.2. The only technical change is switching to DMAChannel.h, so OctoWS2811 can play nicely with other DMA-based libraries.

Should I include one an Artnet examples? Is this one ok to also include with OctoWS2811 v1.2?

https://github.com/natcl/Artnet/blob/master/examples/ArtnetOctoWS2811/ArtnetOctoWS2811.ino


Also, should I include Artnet with the Teensyduino 1.20 installer? Is it open source? (I didn't see any license info)
 
hi Paul,
you can use it, I'm not too license-savvy but I'd be more than glad to see it shared to others. I mostly took bits of code in this thread (mostly by mortonkopf) and made a library out of it to make it easier to use for different use cases.
Let me know if you want me to change some things.
 
It'd be incredibly helpful if you could add license info. This one is the simplest and most permissive (the only thing people aren't allowed to do is try to sue you).

http://opensource.org/licenses/MIT

Just copy that text in a big comment at the top of each file, and put your name and 2014 into the first line. Add a link to your github page and/or this forum thread, probably right after that first line.

Some people worry a lot about licenses. I don't (usually). There just needs to be something, so PJRC has permission to put it into the Teensyduino installer.

@mortonkopf, if you're still here, is the MIT license ok for the code you wrote?
 
Thanks, that info really helps ! I'll wait until tomorrow morning to see if it'a ok with morton and then update it. Code from virtualdave and mortonkopf are mainly in the example files (with some modifications by me) not in the library per se.
 
Hi Paul, nlecaude, yes still here. I too totally believe in sharing the love (i mean code). the code is derived from ideas and examples of small stepping stones, like you chaps I agree with MIT also.

Also, still here and really enjoying the the new directions being discussed, but caught up in LED projects supporting performers for a while, so no radio contact.
all the best
 
Last edited:
Looks good.

I just tried to create a fork (to prepare a small pull request), but github's website doesn't seem to be fully functional right now.

Could you add a quick comment at the top of each of the 5 examples? For each one, just the description that's already in README.md and "This example may be copied under the terms of the MIT license, see the LICENSE file for details" would be perfect. Normally, I'd just do this and send a pull request... if the github site were cooperating.
 
I've read through every page in this thread, and I've got to say thanks for all the development on this code / library!

I've got got a pretty huge led display project going with my teensy 3.1 running the octows2811 library with each pin supporting a "strip"(panel) of 480 neoPixels for a grand total of 3,840 led's on a teensy( I know that's pushing it rather far! )
Using serial communication from Touch Designer on pc thus far has been fine in smaller tests, but when the teensy is set to receive the full 3,840 led's worth of data, touch can only push that out through serial at 15-23 fps. Not bad for what it is, but not good for the application.
Processing can push it out a bit faster at 35-48 fps but that's with out receiving any data from elsewhere.

I'm wondering with all the latest optimizations that have happened with this new library, if it could possibly support that many led's any better than using serial communication?

Thanks for your input!
Regards
 
I've never done tests with that many leds but from what I understand USB will be faster than artnet...
Using Artnet you could however use several teensys and an ethernet switch and set each ternsy to listen to a different set of universes...
 
Yeah it seems like I'm going to have to attack this from the angle of splitting up the workload before sending it.. multi threading or, like you said sharing the load between more teensy's.
 
Many people have tested the USB speed at less over 1 Mbyte/sec, which is more than needed for 3840 LEDs.

I personally tested the OctoWS2811 VideoDisplay example with 4320 LEDs with 30 Hz video.

Other protocols and poor coding can add overhead. Especially on Windows, sending data in small chunks has a terrible impact on bandwidth. Here's some tests I did about a year ago. MacOS was dramatically faster when tested with inefficient transmitting code.

http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html

All 3 operating systems are about the same when you send data in large blocks.
 
Paul,

I actually had the exact same experience with a previous project using the exact same hardware setup, except transmitting from a mac, and using Processing as the intermediary. Touch Designer seems to have a limit to the size of a packet of data, for some reason keeping it at 255. Processing doesn't require this packet to be split up, so it makes perfect sense.

I have a few other questions but I know this thread is about artnet so I'm going to leave it that way and start a new one :)

Thanks!~
 
Status
Not open for further replies.
Back
Top