Artnet to OctoWS2811?

Status
Not open for further replies.
GvB said:
Hi, I have got a stacked up setup with a teensy3.1, an octows2811 breakout and a wiznet ethernet controller. I am trying to get artnet working on my ledstrip. But it doesn't.
The led's work well with the InitTest, so all is wired up okay. I have been trying for a lot of time now to get some artnet signal to reach the led's but in the line something goes wrong.
I have changed the ip address like so: byte ip[] = {2,0,0,101};
I have given the network adapter (IP4) an IP of 2.0.0.100 and subnetmask 255.0.0.0, no gateway.
Using Freestyler or Jinx or DMXControl etc I do not see the node. So in those programs I have tried Broadcasting (255.255.255.255). With "the artnetominator" I see th dmx values changing, but nothing much happens Led-wise. I assume it has something to do with addressing or some kind of reply from the teensy or so. But being new to the matter the concrete wall is getting thicker and thicker and my skull a bit bit bruised

I am looking for some sign of life of the artnet receiver. How can I best test and set the artnet-connection?
Thanks!
Click to expand...

start with a normal ip setup
ip 192.168.1.2
subnetmask 255.255.255.0 (default, you dont have to set it in the teensy)

i also tried with 255.0.0.0 but it took some time
 
also, use the artnetReceive sketch bundled into the IDE. All this does is show on the serial monitor what the teensy is receiving, it will display the number of universe, packets, etc. You can use this without hooking up any leds or using any other libs, so you doing the bare bones check to see if you have the right output from your artnet producer and the correct setup before doing anything else.
m
 
Ah yoohoo! thanks guys. it is finally working. networking is not my cup of tea. In real life aswell as in the virtual world...
 
Hi all,
We've been successfully building another big setup thanks to all the good advices and code found on this thread, and obviously thanks to the power of teensys ! So first big thanks to everybody here !
Here is a video of the setup :

[video=vimeo;115056518]http://vimeo.com/115056518[/video]

The leds are hidden behind some mirror layer (can't find the english word for that), so most of what you see in the video is behind the camera (the ballons).
The sound was created by someone in our team, so all is driven by midi events.
We have about 8500 ws2812b leds driven via artnet by 11 teensy. The whole thing is split in two parts, each driven by a computer running lightjams (because lightjams has "only" 32 artnet universes).

For this setup I made a few modifications to the orginial artnet code, so I put it here in case the modification might be useful. Modifications include :
- debug mode activation/desactivation (print useful info to serial)
- automatic MAC adress for teensy (taken from another code somewhere on this forum)
- automatic IP assignation (from the artnet universe number, so in the end I only have to specify the artnet universe and all the network thing is done). You provide a default IP, if autoIP is activated the code will keep the three first value and replace the last one with "artnet universe"+1 (to prevent IP 0). This may be deactivated if not necessary.
- maximum DMX channel to read from : for what I remember I had issues with lightjams sending only 510 "useful" channels (which is good with RGB leds) but teensys reading 512. Lightjams assume you might still want to use the 2 remaining adresses for something else than leds, so they are sent. Teensy code reads as much values DMX frame has, so adress 511 and 512 are read if provided. With my code you may prevent teensy from using those adresses. This issue might be only related to lightjams, other softwares allow to set how many channels are sent on a specific artnet universe, so this might be limited to 510.
- I deactivated "frame_received" verification which led the system to hang frequently. I understand the utility of this feature but with lots of artnet values I found it worked better without that verification.

Two things I had been investigating before I end up using lightjams, if someone thinks they are good ideas perhaps we might give it a shot :
- I wanted to try replacing artnet with OSC control. First because I'm a pure data user, and it doesn't proide any artnet interface. I'm aware of OLA but this seems limited to one universe output, which isn't really useful with RGB leds. Second argument, with a basic OSC impolementation, we might drive each pixel in a artnet way, but we could also code much more complex actions like full on, full off, full fade of all controlled pixels, or even light sequences with only one command flowing through the network. This combined with the SD card reader....wow
- I looked for a sACN implementation on arduinos/teensys but didn't succeed. It seems easier to setup than artnet, and a big argument to that is that lightjams would be able to drive 32 artnet universes + 32 sACN ones. So if we have a sACN version, with a 150$ (****ing good) application we might drive as much as 64 universes !


So the code :
/*
This example will receive multiple universes via Artnet and control a strip of ws2811 leds via
Paul Stoffregen's excellent OctoWS2811 library: https://www.pjrc.com/teensy/td_libs_OctoWS2811.html
This example may be copied under the terms of the MIT license, see the LICENSE file for details
*/

#include <Artnet.h>
#include <Ethernet.h>
#include <EthernetUdp.h>
#include <SPI.h>
#include <OctoWS2811.h>

boolean debug = 1; //activate serial printing, !! waits for a serial input to start loop

// OctoWS2811 settings
const int ledsPerStrip = 70; // change for your setup
const byte numStrips= 8; // change for your setup
DMAMEM int displayMemory[ledsPerStrip*6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);

// Artnet settings
Artnet artnet;
const int startUniverse = 27; // CHANGE FOR YOUR SETUP most software this is 1, some software send out artnet first universe as zero.
const int numberOfChannels = ledsPerStrip * numStrips * 3; // Total number of channels you want to receive (1 led = 3 channels)
byte channelBuffer[numberOfChannels]; // Combined universes into a single array
const int DMXmax = 510; // limit number of channels read from each universe (in case the artnet software always sends 512 value)

// Check if we got all universes
const int maxUniverses = (int) numberOfChannels / DMXmax + ((numberOfChannels % DMXmax) ? 1 : 0);
bool universesReceived[maxUniverses];
bool sendFrame = 1;

// Change ip and mac address for your setup
boolean autoIP = 1;
byte ip[] = {192, 168, 0, 26};
char mac_string[20];

//everything on the network needs a unique MAC
#if defined(__MK20DX128__) || defined(__MK20DX256__)
// Teensy 3.x has MAC burned in
static byte mac[6];
void read(uint8_t word, uint8_t *mac, uint8_t offset) {
FTFL_FCCOB0 = 0x41; // Selects the READONCE command
FTFL_FCCOB1 = word; // read the given word of read once area

// launch command and wait until complete
FTFL_FSTAT = FTFL_FSTAT_CCIF;
while(!(FTFL_FSTAT & FTFL_FSTAT_CCIF));

*(mac+offset) = FTFL_FCCOB5; // collect only the top three bytes,
*(mac+offset+1) = FTFL_FCCOB6; // in the right orientation (big endian).
*(mac+offset+2) = FTFL_FCCOB7; // Skip FTFL_FCCOB4 as it's always 0.
}
void read_mac() {
read(0xe,mac,0);
read(0xf,mac,3);
}
#else
void read_mac() {}
byte mac[] = {
0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; // you can find this written on the board of some Arduino Ethernets or shields
#endif

void print_mac() {
size_t count = 0;
for(uint8_t i = 0; i < 6; ++i) {
if (i!=0) count += Serial.print(":");
count += Serial.print((*(mac+i) & 0xF0) >> 4, 16);
count += Serial.print(*(mac+i) & 0x0F, 16);
}
sprintf(mac_string, "%02X:%02X:%02X:%02X:%02X:%02X",mac[0],mac[1],mac[2],mac[3],mac[4],mac[5]);
Serial.println();
}



void setup()
{

//if (autoIP){ ip [4]= ( startUniverse == 0 ) ? 1 : startUniverse ;} //
if (autoIP){ ip [3]= (startUniverse + 1);} //avoid ip 0
read_mac();
if (debug){
Serial.begin(115200);
while(!Serial.available()){;} //if debug, wait until you send something to start the sketch
Serial.print("mac : ");
print_mac();
// for (int i ; i<3 ; i++){
// Serial.print(mac,HEX);
// Serial.print("-");
// }
// Serial.println(mac[3],HEX);
Serial.print("IP : ");
for (int i ; i<3 ; i++){
Serial.print(ip);
Serial.print(".");
}
Serial.println(ip[3]);
Serial.print(numStrips);
Serial.print(" strips of ");
Serial.print(ledsPerStrip);
Serial.println(" leds");
}
artnet.begin(mac, ip);
leds.begin();
initTest();

// 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)
{
sendFrame = 1;

// Store which universe has got in
if (universe < maxUniverses)
if (debug){ Serial.print(universe);}
universesReceived[universe] = 1;

// for (int i = 0 ; i < maxUniverses ; i++)
// {
// if (universesReceived == 0)
// {
// if (debug){Serial.println("Broke");}
// sendFrame = 0;
// break;
// }
// }
/* ICI length serait à 512 mais devrait etre 510, d'ou décalage de deux valeurs. Il lit les valeurs 511 et 512 (qui sont à 0), la premiere
valeur de l'univers suivant est donc appliquée au channel trois. Verifier, les 2-3 dernieres leds devraient etre éteintes
Tester en forçant length à 510 ?
cf. http://forum.pjrc.com/threads/24688-Artnet-to-OctoWS2811/page5 post #119
Tester également de ne pas démarrer à l'univers 0 sur la teensy*/

// read universe and put into the right part of the display buffer
for (int i = 0 ; i < min(length, DMXmax) ; i++)
{
int bufferIndex = i + ((universe - startUniverse) * min(length, DMXmax));
if (bufferIndex < numberOfChannels) // to verify
channelBuffer[bufferIndex] = byte(data);
}

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

if (sendFrame)
{
leds.show();
// Reset universeReceived to 0
memset(universesReceived, 0, maxUniverses);
}
}

void initTest()
{
for (int i = 0 ; i < ledsPerStrip * numStrips ; i++)
leds.setPixel(i, 127, 0, 0);
leds.show();
delay(500);
for (int i = 0 ; i < ledsPerStrip * numStrips ; i++)
leds.setPixel(i, 0, 127, 0);
leds.show();
delay(500);
for (int i = 0 ; i < ledsPerStrip * numStrips ; i++)
leds.setPixel(i, 0, 0, 127);
leds.show();
delay(500);
for (int i = 0 ; i < ledsPerStrip * numStrips ; i++)
leds.setPixel(i, 0, 0, 0);
leds.show();
}
Click to expand...



Once again thanks to all the guys here who made most of the work !
 
This just keeps getting better. Thanks for posting your work. Yeh, the frAme received and other checks can be removed, perhaps two modes could be adopted in the one sketch, validate mode and production mode?
 
Well the "sendFrame" check, while not necessary is still important if you want to be consistent timing wise, otherwise you're not displaying the whole frame at the same time but sequentially... Normally that should not freeze.
 
Thanks niecaude, I hadn't seen the updated sketch, at that time I was soldering some leds somewhere on a lader ;) That's great, I'll give it a try.

@mortonkopf, making frame check an option might be a good compromise. I noticed that only with the full setup, when trying with two teensys at home I had no problem. It was not really a freeze, in fact after initialization some of the first universe would work and the others never display anything, like if they didn't receive all their universes. I had some teensys with 6 universe. Once I desactivated frame check, all worked quite very well, I was surpised how reactive it was. We didn't use video so timing was not so critical, but lightjams would have allowed that
Regarding timing, I saw that artnet sends a sequence number that is ment for consistent display with frame loss tolerance, perhaps there could be an option for using that ? But I'm not sure all the control softwares use it.
 
I just re-read your message and in the case where your software is sending 510 valid values but an actual 512 array, it won't help. It might help in other situations where the dmx frame is smaller. However the removal of channelbuffer might speed things up a little !

Out of curiosity did you play with the SPI speed for ethernet or you left it as is ?
 
Ok so this manual limit in reading might still help, lightjams actually always sends 512 value whatever you use in the frame. About speed I didn't notice any issue but speeder is better !
I didn't change SPI settings, though I had seen the option on this thread. But as everything seemed to work fine I didn't try this.

Regarding channel use there's another thing I was wondering, would it be a mess to have the ability to have the first adress of a teensy inside a universe ? I mean not starting at the 0 adress. On our setup, most of the teensy had 5 ful universes plus something like 300 channels. So the 200 remaining channels are "lost". With lots of teensy this makes quite a lot of unused channels , which led me to having 54 universes when 50 would have been enough to hold all the channels. I've seen sereval times on these forum, and that's the choice we made, that regarding the price of the leds putting more teensy is often a better solution than driving more leds with each teensy, but this leads to this channel loss.
 
Yep, the neopixel lib works, but only with 1 Universe. If I use more than 170 pixels, I get very strange results. (freezing, no output...)
I Use MadMapper for ArtNet Input.

Someone ever tested more than 1 Universe with Neopixel and Arduino?

What will I need for an ArtNet->Ws2811 Setup with a teeny-board?
-> Teeny 3.1, EthernetShield & adapter and the Teensy WS2811 - adapter?

Btw.: excuse my bad english-skills.
 
Last edited:
@Titi, how's the stability of your setup? Mine has a crashing WIZNET module. Usually after 24 hours or so, of working OK (with constant frame updates during the whole time), the WIZNET hangs. It crashes the same way with other network sketches as well, so I'm pretty sure it's not this sketch causing it. I also have eight complete identical setups that have the exact same problem, so it's unlikely to be bad hardware, unless the whole batch is bad... I know that Teensy is not hung because I can reload the sketch but I get no ping response while it appears hung.

So, have you tested your setup stability over time?
 
Yes that's the setup we choose. At the very beginning of the project I wanted to work with arduinos (had never tried teensy, just heard of), but after a few research it became obvious that teensy + wiz820io + octo adapter is better.
I didn't realy make long tests as our setup was running just for one night, and was built the day before. But as soon as it worked we left everything powered for 1 and 1/2 day, and had no stablitity problems until we unplugged all.
5100 might be your issue, while I was doing my first tries with ws8212 I only had arduino and wiz5100 ethernet shield. For what I remember it would hang if I send it too much data (too quick ?).
There's also this sketch, I don't think I tried it but it says 2 universes on a mega
 
Titi:
I'm also curious in why you were using 11 Teensys, given a single board can drive around 4000 leds at 60hz, was it a limitation of the ethernet bandwidth ?
 
Short answer is "because we had them"
Longer answer : we used 11 teensys at least for two reasons :

- that's something you often read on this forum, that is quite true : regarding the price of the leds and power units, teensys are not the expensive part. As we had no experience with teensy and ws2812, and the project was built quite quick (1 month from design to final building, including all orderings) we ordered much more teensys that we needed (15, when 3 could have handled that much leds). I saw that each teensy could theoricaly handle lots of leds, but until you see it in action...

- the main reason is the building design of this setup : the overall is 18m*6m, but it is made of 21 "cells". We had time before the show to prepare those cells, but the final assembling had to be done in one day. So we choose to simplify the wiring as much as possible. The best way was to have two cells on each teensy, one on each octo adapter output. With that wiring, we had all power units and teensys on the ground, so easier to access (for firmware update for instance) and to plug. We made a adapting board that receives one ethernet from octo adapter and power cables, and output to 4 led strips. That way we had no connection between the cells, only from the ground.

And as hopefuly we will work on other setups with that hardware, we now own enough teensys for driving a huge 60000 leds setup, or several ones at different places at the same time.
 
@Paul - there's a video in my first post here, I'm waiting for another video that should show more about building and will post it here asap.
By the way as you are here I think you deserve a special thanks ! Your hardware is quite impressive !
I have another one on my facebook account, I try and put a link here, tell me if it's working. I think it was shot at the same time with another point of view :
https://www.facebook.com/video.php?v=10152924863044134
 
Oh and by the way, as I see it is still in the todo of the octo adpater page, you might be interested by the following : I've done little tests regarding cable length from octo adapter to led strip and had no problem up to 60m, on three different cables connected with female-female adapter. Didn't try longer but I think it would still work.
 
Last edited:
Status
Not open for further replies.
Back
Top