lost trying to get OLA on Raspberry Pi 2b to drive ws281xs LEDs

[Edward Burch]

Hey everyone, really hoping I can get some help.

I have spend my evening and weekends for the past three weeks, with no luck. I am trying to drive WS2811 LEDs using OLA, it seems like I am going round in circles.

I have tried to start from scratch using Raspbian Jessie, but get stuck trying to add OPC plugin. On the other hand, trying to use the raspbian-ola-0.9.5 image I get errors with node, either trying to run as described at http://x10linux.blogspot.com/2015/08/driving-ws281xs-leds-on-raspberry-pi.html or trying to uninstall and install the latest node.

Is anyone able to control ws281x leds and if so could you advise how I can achieve this? If no one has, any tips or advice on how you would approach this?

I am a "tourist" in the linux/pi world, so it could be simply my understanding on how this all connects together.

Thank you all for your time and any help you can give.

Cheers

Edd

[Arjan van Vught]

Hi Edd,

Using OLA as the DMX sender utilizing ArtNet, you can drive 4 DMX
Universes using the Raspberry Pi ArtNet Pixel Controller. There is no
need to have additional hardware. The WS2811 chip is directly controlled
from the Raspberry Pi SPI pins.

Thanks, Arjan
http://www.raspberrypi-dmx.org/raspberry-pi-art-net-dmx-out

Op 31-12-2016 om 8:31 schreef 'Edward Burch' via open-lighting:

> --
> The Open Lighting Project: open-l...@googlegroups.com,
> #openlighting (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Peter Newman]

You can also use a Fadecandy via OLA (or via OPC) to drive them directly.

If you want to do it with your existing hardware, the Raspbian Jessie build has OLA 0.9.1 I believe, which doesn't include OPC. You could compile OLA on Raspbian Jessie (follow the steps here https://www.openlighting.org/ola/linuxinstall/ ). You could also try the PPA here, which has binary versions of OLA which I believe should work on Raspbian Jessie https://launchpad.net/~voltvisionfrenchy/+archive/ubuntu/ola/+packages .

> open-lighting+unsubscribe@googlegroups.com

[Edward Burch]

Wonderful stuff, I am trying it now. So far not good, going to crack out my "o-scope" to see if SPI is outputting. I thought due to the timing issue with WS2811 (no clock feed, only data) PWM was the only way to go, but the link you sent me has it listed as supported... 

Really would like to only use RPi as hardware. Will let you know what I find. 

Cheers

Edd

[Arjan van Vught]

Hi Edd,

With SPI you can easily generate the data pattern needed for the WS28xx chips. The other signals (CLK, CS and MISO) are just not used. However, the CLK signal is used for the WS2801.

Please bear in mind that 1 DMX Universe of RGB led's will draw 11A/55Watt. You need to have a reasonable power supply.  I have added a spreadsheet here http://www.raspberrypi-dmx.org/raspberry-pi-art-net-dmx-out/technical-details with the details about Ampère/Watt for the DMX Universes.

At the bottom of http://www.raspberrypi-dmx.org/raspberry-pi-art-net-dmx-out/configuration you'll find how to connect the WS2811 to the RPi header. In this example,  the 5 volt from the RPi is used. Hence just a couple of RGB led's can be used.

Greets, Arjan
http://www.raspberrypi-dmx.org/

Op 31-12-2016 om 20:07 schreef 'Edward Burch' via open-lighting:

[Edward Burch]

Update, I see the raw data on the SPI, but I dont see it being suitable to use SPI on WS2811 due to timing issues. Again I was able to control them via RPi 2B using the tutorial here: https://learn.adafruit.com/neopixels-on-raspberry-pi/overview?view=all

So the hardware can control them but linking the software for the interface to be done via OLA seems to be where I am tripping up.

I really don't want to add hardware, but if the Fadecady option is easy to setup and run with then I might go down that route. 

Any thoughts on this? I think OLA is awesome, just struggling to get off the ground with it.

Cheers

Edd

[Edward Burch]

Just saw your reply (after I posted the last). I like to think I have the hardware nailed down (already been annoyed with the voltage drops in the LED strips, but easy to fix).  I have two setups, one 5VDC and one 12VDC both have 40A PSUs.

The hardware link was awesome, my setup is using SPI output, gnd is connected to my PSU ground. the voltage is directly driven by the PSU unit (not the RPi).

The setup I am trying to use is:

RPi 2B

OLA image 0.9.5

1x Universe with:

  - Input ArtNet Universe 0:0:1 priority 100

 - Output spidev0.0, output 0, WS2801 Individual Control, 75 slots @ 1. (7a70:00000101)

I am currently trying to test this using the DMX console, I can see the raw data using my o-scope but it failing to control my LEDs. Is there anything special I need to do to tell the SPI to control WS281x devices?

[Simon Newton]

Have you set the personality correctly? Look under the RDM tab.

Simon

[Edward Burch]

In case it wasnt clear, I am very grateful for help on this. Simon, I had no idea that was there, but looking I dont see an option for WS281 of any kind, see attached snip.

[Arjan van Vught]

Hi Edd,

The SPI is perfect suitable for the WS2811 and all other WS28xx chips. I have an example here https://www.youtube.com/watch?v=M2vCI6YM_U8
Or SPI WS2801 with TouchOSC and the Raspberry Pi here https://www.youtube.com/watch?v=A7M_vuCfeX4

Greets, Arjan
http://www.raspberrypi-dmx.org/raspberry-pi-art-net-dmx-out

Op 31-12-2016 om 21:51 schreef 'Edward Burch' via open-lighting:

[Peter Newman]

Hi all,

Arjan I think you're confusing things. The WS2811 don't use SPI as there's no clock line. Which means they're much less well suited to non-realtime OSes (like Linux). When you're saying "Raspberry Pi SPI pins" you mean using the Pi as an overpriced microcontroller, whereas the rest of us are talking about using it as a cheap PC. Using a pair of Pis (one running OLA, one running your bare metal code), is more expensive than a Pi and a Fadecandy, and needs a network and the associated config, rather than just one device plugged into the other via USB.

Edd when you say "but the link you sent me has it listed as supported..." who's link are you referring to?

OLA doesn't currently support any of the non-clocked pixels, but your x10 link you started with looks like it should do the job. Is that still not working even having compiled OLA to get the right combination of OLA and Node on a Pi?

For a summary of other efforts, see here:
https://github.com/OpenLightingProject/ola/issues/578

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

[Edward Burch]

Hey Peter,

The links from Arjan seem to indicate it is possible to control WS2811 via SPI but I defiantly think timing is an issue and makes me wonder if this would also cause reliable issues later on... 

http://www.raspberrypi-dmx.org/raspberry-pi-art-net-dmx-out   - states support for WS2811

http://www.raspberrypi-dmx.org/raspberry-pi-art-net-dmx-out/configuration - states 1 pin control hardware setup (also power, but apart from coupling gnd, I am driving the LEDs via a power supply unit)

I am really open to how to do this, SPI or PWM, I would like to reduce additional hardware, although I will be looking at boosting the signal to 5Vp-p but for testing control now I don't believe this is needed.

Right without getting lost again, here's the summery of what I have gotten so far:

OLA in general: I can see the artnet DMX input channels being controlled, awesome project gents!

WS2811 control

SPI: 

I see the data via O-Scope, but the timing seems off. I have been able to make the first pixel to light up, but its not controlled (colour, number of pixels or even setting to 0.)

PWM:

 1 - I have been able to successfully control them via the tutorial here: https://learn.adafruit.com/neopixels-on-raspberry-pi/overview (not OLA setup). So hardware setup seems good

 2 - Trying to follow the blog post here http://x10linux.blogspot.com/2015/08/driving-ws281xs-leds-on-raspberry-pi.html (OLA using the WS281X PWM support) I have ran into issues:

 2a - using the pre-made OLA image, it seems like I am stuck trying to get the node OPC to run and then I suspect my understanding how to link the native WS281X PWM support

 2b - building OLA on Raspbian Jessie, I think my understanding of building up the setup to include plug ins like OPC, then again my ability to link the native WS281X PWM support.

So the real issue here is the item attached to my HID / keyboard ;) So if anyone is able and willing to take me through the best way forward with this I would be extremely grateful. Worse case I go with external hardware, but it kills me a little to know that it is physically possible, its just this software setup. Time line wise I would like to prove the setup before end of feb.

Cheers gents, and happy new year!

Edd

[Simon Newton]

Ah ok, now I understand what you're doing.

OLA doesn't support the WS281X pixels natively so the SPI plugin is a
red herring. You'll likely want to disable that.

Going OLA --- OPC ---> node -> pixels is convoluted but should work.


I'd focus on getting the node part working first, then get OLA
running, then link the two together.


Follow the instructions from
https://wiki.openlighting.org/index.php/OLA_on_Linux . That should get
you a recent version of OLA installed on your Pi.


Simon

[Peter Newman]

Yes, Arjan is using the Pi like a giant Arduino or other microcontroller, he's running his own code natively on it (rather than on top of Linux), so he's got much more precise control of the timing. In comparison, the other links are cheating, by sending three bytes of data to generate one byte for the pixel, and using that to encode the clock.

You might get away without the level shifter now, but it could be causing you issues possibly. The scope will probably help to confirm that (when you're generating WS281X data).

Or you can follow these instructions, which may be slightly more up to date:

https://www.openlighting.org/ola/linuxinstall/

If you get stuck with either set of instructions, then let us know either on here, or try on IRC where people may be able to give you more instant help ( https://www.openlighting.org/ola/get-help/irc/ )

Alternatively if your other system is already generating ArtNet, and you don't need the OLA functions in the middle, you could just use Arjan's code running directly on the Pi, but he'd need to assist you with that, as it's not something we (the Open Lighting Project) are involved in.

> open-lighting+unsubscribe@googlegroups.com

[Edward Burch]

Hey all,

Right I have followed Simon's advice, right now I seem be unable to control the pixels using the DMX Console.... I some life when trying to control it over the network using ArtNet, but only getting random blinking pixels in a row but after a row and a half.

So what I have done so far:

1 - installed node (v7.3.0) and verified it works

2 - installed OLA (using ./configure --enable-rdm-tests --enable-python-libs --enable-uartdmx --enable-artnet --enable-http)

3 - setup olad to start on boot up

4 - adjusted ola-openpixelcontrol.conf

5 - installed OPC client, successfully ran index.js in /home/pi/opctest/node_modules/node-opc-server/opc-server

6 - configured a universe using the webserver. using ArtNet input and OPC Client 127.0.0.1:7890 as output

Trying to test further, it seems something isnt right with the OPC-Server's rpi-ws281x-native module. I have just tried "sudo node rainbow.js" and "brightness" both seem to be causing simply flickering of the pixels.

So two items here:

1 - should I be able to control the pixels via OLA's DMX console?

2 - any tips on what I can look at regarding the module, or simply why the control is failing? My next steps on this is a) prove the hardware setup is ok and b) compare a working standalone raw signal to this setup.

For now, back to reality, and work.

Thank you all for your help so far. 

Cheers

Edd

[Peter Newman]

Hi Edd,

For step two, I assume you also had --enable-openpixelcontrol in your ./configure options? As otherwise the OPC plugin won't be enabled. Given your comment on step six, I'm guessing you had actually done this.

If everything else was working, then yes, control from the DMX console should work. You can try the old and new web UIs, or ola_dmxconsole the command line tool, which all have slightly different refresh modes, which may play better or worse with the Node opc-server.

If you're having issues with the rainbow and brightness samples from the Node side, that implies that it's the raw driving code likely to be at fault. As Simon suggests, if you can't fix that, then the OLA bit won't ever work.

Have you seen the warning on the top of the Adafruit page "The are some reports that this library does not work with the new Raspberry Pi 2. Be warned that the library is not confirmed to work with the Pi 2 hardware yet--only the first generation Pi is known to work.". Have you run "sudo node rainbow.js 100" for the number of pixels.

Have you also seen the notes here about disabling bits of the soundcard?

https://github.com/beyondscreen/node-rpi-ws281x-native

[Edward Burch]

Very quick update, Peter you helped me find some of my shortcomings.

No idea why the last setup didnt really work, but loading a standalone image made using the Adafruit tutorial I proved the physical setup was sound, so no idea why the last image described above failed. I then built from this standalone WS281x driver image:

1 - installed node (v7.3.0) and verified it works

2 - installed OLA (using ./configure --enable-rdm-tests --enable-python-libs --enable-uartdmx --enable-artnet --enable-http)

3 - setup olad to start on boot up

4 - adjusted ola-openpixelcontrol.conf

5 - installed OPC client, successfully ran index.js in /home/pi/opctest/node_modules/node-opc-server/opc-server

6 - configured a universe using the webserver. using ArtNet input and OPC Client 127.0.0.1:7890 as output

next up is to look at how I can:

- auto start OPC client 

- automate the step of having to hit reload plugins for the OPC to go from server bound to client connected.

I haven't done my homework on these items yet to ask for help yet.

Cheers gents!

PS my shortcomings:

 - I didn't run --enable-openpiixelcontrol but neither did I disable it.... no really sure how the ./configure options are, the help file didn't spell it all out for me and that is what I need at the moment. getting better.

 - and AH "sudo node rainbow.js" <number of pixels>, didn't run stating number of pixels.... but then when I tried it, yup that image was bad, works great now!!!

[Peter Newman]

It could be a subtlety like a change in the way to disable the sound card use of PWM perhaps, which the image has configure (or is old enough to work through the old method).

I assume you mean the Node OPC server (as OLA is the client). You could add this to /etc/rc.local for example.

I expect you need to reload plugins as I imagine OLA is started before Node, so it's then trying and failing to connect to the OPC server which isn't running at that point.

Most of our configure options are enabled by default (which I should have really spotted), I was just confused you'd chosen to enable uartdmx. Please feel free to either propose some improved help text, or even go ahead and edit it. We're always looking to make that sort of thing easier for people, but it can be quite hard to do when you know it inside out.

Personally I'd have hoped the rainbow.js would either run with a default number of pixels, or complain you hadn't told it how many.

[Edward Burch]

Hey guys,

Very excited here, it seems to be working beautifully. Some minor updates:

- running rainbow.js without number of pixels defined does run with a default number. This would explain why I saw a change, but for whatever reason the image I built up was just all messed up on the actual control elements.

- auto start, interestingly I have to start OPC-Server after OLAD, so my /etc/rc.local looks like this:

# By default this script does nothing.

# Print the IP address

_IP=$(hostname -I) || true

if [ "$_IP" ]; then

  printf "My IP address is %s\n" "$_IP"

fi

#For OLAD delay

echo 'Sleep 15 seconds before starting olad'

sleep 15

echo 'Starting olad'

sudo -u pi olad -f --no-http-quit --syslog

#Start OPC-Server after OLAD... it works!

sudo node /home/pi/opctest/node_modules/node-opc-server/opc-server/index.js

exit 0

rebooting this works great, everything boots up and no reload plugins needed... just power on and off we go!

Reason why I enabled uartdmx... well there isnt one, just I saw it on a tutorial. Foolish, but right now it doesnt seem to be causing any issues. I need to get to know the config a little, I like to think I have a good understanding of lighting and hardware terminology. But at the "thiggy" and "Whatcha-McCalls-It" level on unix world. If I can help I will be more than happy to.

Next on the play list (again just talking out aloud without doing my homework), multiple universes to drive my 600 pixel test rig here... or at least try.

Cheers again all!

Edd

 

[Edward Burch]

Second to last update on this one, got it all working (see attached for the "photos or it didn't happen" aspect). Thank you all for your help.

Right to run more than 512 channels (or more than 170 pixels) I did the following:

1- adjusted ola-openpixelcontrol.conf for multiple targets with different ports (in my case a total of 4, to cover 600 pixels or 1800 channels).

2- adjusted opc-server/index.js for multiple listener, one for each target, with only the last listener having render for example:

var server3 = net.createServer(function(c) { //'connection' listener

  var parseState = 0;

  console.log('client3 connected');

  c.on('end', function() {

    console.log('client3 disconnected');

  });

  c.on('data', function(data) {

    opcparse.parseOPC(data, function(rgb, count) {

      //console.log('rgb count', count);

      for (var i = 0; i < count; i+=3) {

        pixelsUint32[340 + (i/3)] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);

      }

    // ws281x.render(pixelsUint32);

    });

  });

});

var server4 = net.createServer(function(c) { //'connection' listener

  var parseState = 0;

  console.log('client4 connected');

  c.on('end', function() {

    console.log('client4 disconnected');

  });

  c.on('data', function(data) {

    opcparse.parseOPC(data, function(rgb, count) {

      //console.log('rgb count', count);

      for (var i = 0; i < count; i+=3) {

        pixelsUint32[510 + (i/3)] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);

      }

     ws281x.render(pixelsUint32);

    });

  });

});

AND:

server3.listen(7892, function() { //'listening' listener

  console.log('server3 bound');

});

server4.listen(7893, function() { //'listening' listener

  console.log('server4 bound');

});

reboot and bob's your uncle! I am sure there is a nicer way, but it worked for me so far. Now the fun really starts!

Cheers again.

Edd (PS notice its wireless, exactly what I am after!) 

[Peter Newman]

Excellent Edd, although I can't see the photos unfortunately.

If you run:
./configure --help

Then you'll see our current help regards the options available, some is autogenerated for the compiler stuff, and some is our text for the plugins. If you think any of that can be clarified or improved just let us know.

[Peter Newman]

And having posted I've just seen it in the quoted text, very patriotic, although the white and blue don't look very different.

[Stefan Krüger]

Hi Edd,

cool to see a working setup :-)

alternative to rc.local if installed (mostly true on debian based systems nowadays as far as i know) you can use systemd to handle auto-start - with dependency / ordering between the different things :-)
i have done this with olad and other things.
example for olad https://gist.github.com/s-light/fba54aa65b14a1da290f10dfa4e9dcae
and a second example for a python script https://github.com/s-light/OLA_test_pattern_generator/blob/master/systemd_service_script/pattern_generator.service
they are not really linked together.. if you are interested i can look for/write down a better/combined example :-)

some documentation about systemd
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
to do the dependency thing look at  Wants=, Requires=, Before=, After= keywords..

@Peter would it make sense to write some comment in the pixel tutorial (https://www.openlighting.org/ola/tutorials/ola-led-pixels/) or something similar to point out the possible setup to get ws281x working ?

sunny greetings
stefan

[Edward Burch]

Hey Stefan,

Thank you for the suggestion, I will have a read up. Side note, you mentioned about Peter to make some sort of comment on supporting WS281X. I have just filmed a load of raw material in my plans to make a series of you tube videos on all the steps to take a Rpi, OLA and this OPC module to control 600 WS2811 Pixels (example uses Glediator). I plan on adding it to comments on the tutorials I had tried to follow.

I will send links once its posted, may take a few days to edit.

Cheers all again,

Edd

[Peter Newman]

We really want some smart person like yourself to write a little Python script or similar that can do OLA to WS2811 directly Stefan and cut out all the OPC stuff in the middle. I think unfortunately these libraries require root permissions to get access to the DMA timing stuff, so we can't build them directly into OLA.

Stefan, I wonder if we should add an olad systemd config to the repo perhaps, if you feel like opening a PR?

[Klára Juráňová]

Hey Edd,

no matter what I do, I just cannot get it working if more than 2 universes are used for the OPC server. 2 universes with 170 LEDs each work perfectly but when I add 2 more instances of the server in index.js it does not work. That is, only 2 of the servers actually receive any data. It's not that I would forget to render it or set up the driving software in a wrong way (I use Jinx!). For example If I use ports 7890 and 7891 it works, if I use 7892 and 7893 it works. But if I use all of them at once, only two of them actually receive any data (I know that because I have put logs just about everywhere in index.js).

Could you maybe share with me the content of your ola-openpixelcontrol.conf file for the 4 universes setup, that works for you? I am pretty sure I have set up openpixelcontrol.conf correctly as well. Also I get this "server bound" and "client connected" for all 4 instances. But as I said, only 2 of them receive anything...

Thanks a lot!

Dne čtvrtek 5. ledna 2017 5:26:23 UTC+1 Edward Burch napsal(a):

[Peter Newman]

I don't know if I'll be able to help much Klára but if you share your ola-openpixelcontrol.conf people may be able to assist.

Have you tried running tcpdump to see if OLA is sending the data as expected? What does ola_dev_info show? What does olad show if you stop olad and run it as olad -l 4?

[Edward Burch]

I'm away from my laptop, can grab the files tomorrow. From what you discribe it sounds like it can be caused by something in index:

I would check that "ws281x.render(pixelsUint32);" is only used once and on the last server. This means the whole setup will only updat if that server is triggered.

Putting this on say server 2 and 4 will mean the system will render the first two universes and leave the last two blank... it's not particularly nice and rather hacky but that's the best way I've seen this work.

Let me know if this helps,

Edd

[Klára Juráňová]

This is the content of my ola-openpixelcontrol.conf:

enabled = true
target = 127.0.0.1:7890
target_127.0.0.1:7890_channel = 0
target = 127.0.0.1:7891
target_127.0.0.1:7891_channel = 1
target = 127.0.0.1:7892
target_127.0.0.1:7892_channel = 2
target = 127.0.0.1:7893
target_127.0.0.1:7893_channel = 3

I made that up because I found no documentation on how to do this. But I think it's alright because for 2 universes it works...

1) As for the rest of the questions. I will try tcpdump as soon as I found how to do this (will need to google a bit).
2) I don't know where to look for ola_dev_info, I'll try to grep it out...
3) You mean stop the service, and run it again with -l 4 parameter? What should it do? Sounds promising though :-)

Thanks!

[Klára Juráňová]

Hello Ed,

Dne čtvrtek 23. února 2017 5:06:01 UTC+1 Edward Burch napsal(a):

I'm away from my laptop, can grab the files tomorrow. From what you discribe it sounds like it can be caused by something in index:

I would check that "ws281x.render(pixelsUint32);" is only used once and on the last server. This means the whole setup will only updat if that server is triggered.

Not really. In my initial post I was really trying hard to explain that is not the case. It's not about rendering (yes, I render it only in 1 of the servers but again, that's not the problem). As I said I have put console.log in all of the servers and server3 and server4 just never recieve anything although they are bound. I can see the data incoming in the web interface in DMX monitor, but seems they are not forwarded to the OPC server even though the TCP connection is alive.
 

Putting this on say server 2 and 4 will mean the system will render the first two universes and leave the last two blank... it's not particularly nice and rather hacky but that's the best way I've seen this work.

Didn't get this. First you say I should put the rendering in only one of the servers (which I perfectly understand) and then you say to put it on 2 servers...
 

Let me know if this helps,

Edd

Thanks!

[Klára Juráňová]

1) As for the rest of the questions. I will try tcpdump as soon as I found how to do this (will need to google a bit).

I have set up 3 channels, that is ports 7890, 7891 and 7892 and set the universes to forward to these ports. All the servers are bound and clients connected. Still only on the first two ports (server functions) the logs report a traffic. The third one is silent. Now when I run tcpdump, it looks there IS traffic for 7892 which makes no sense to me...

12:17:09.499854 IP localhost.46956 > localhost.7890: Flags [P.], seq 21156:21672, ack 1, win 683, options [nop,nop,TS val 39086 ecr 39082], length 516
12:17:09.501952 IP localhost.7890 > localhost.46956: Flags [.], ack 21672, win 6964, options [nop,nop,TS val 39086 ecr 39086], length 0
12:17:09.512246 IP localhost.37881 > localhost.7891: Flags [P.], seq 21156:21672, ack 1, win 683, options [nop,nop,TS val 39087 ecr 39084], length 516
12:17:09.515304 IP localhost.7891 > localhost.37881: Flags [.], ack 21672, win 6964, options [nop,nop,TS val 39088 ecr 39087], length 0
12:17:09.524064 IP localhost.41816 > localhost.7892: Flags [P.], seq 20125:20641, ack 0, win 683, options [nop,nop,TS val 39088 ecr 39085], length 516
12:17:09.528216 IP localhost.7892 > localhost.41816: Flags [.], ack 20641, win 6964, options [nop,nop,TS val 39089 ecr 39088], length 0
12:17:09.540620 IP localhost.46956 > localhost.7890: Flags [P.], seq 21672:22188, ack 1, win 683, options [nop,nop,TS val 39090 ecr 39086], length 516
12:17:09.542705 IP localhost.7890 > localhost.46956: Flags [.], ack 22188, win 6964, options [nop,nop,TS val 39090 ecr 39090], length 0
12:17:09.552956 IP localhost.37881 > localhost.7891: Flags [P.], seq 21672:22188, ack 1, win 683, options [nop,nop,TS val 39091 ecr 39088], length 516
12:17:09.556102 IP localhost.7891 > localhost.37881: Flags [.], ack 22188, win 6964, options [nop,nop,TS val 39092 ecr 39091], length 0
12:17:09.565396 IP localhost.41816 > localhost.7892: Flags [P.], seq 20641:21157, ack 0, win 683, options [nop,nop,TS val 39093 ecr 39089], length 516
12:17:09.568187 IP localhost.7892 > localhost.41816: Flags [.], ack 21157, win 6964, options [nop,nop,TS val 39093 ecr 39093], length 0
12:17:09.580487 IP localhost.46956 > localhost.7890: Flags [P.], seq 22188:22704, ack 1, win 683, options [nop,nop,TS val 39094 ecr 39090], length 516
12:17:09.582579 IP localhost.7890 > localhost.46956: Flags [.], ack 22704, win 6964, options [nop,nop,TS val 39094 ecr 39094], length 0
12:17:09.593056 IP localhost.37881 > localhost.7891: Flags [P.], seq 22188:22704, ack 1, win 683, options [nop,nop,TS val 39095 ecr 39092], length 516
12:17:09.596068 IP localhost.7891 > localhost.37881: Flags [.], ack 22704, win 6964, options [nop,nop,TS val 39096 ecr 39095], length 0
12:17:09.605349 IP localhost.41816 > localhost.7892: Flags [P.], seq 21157:21673, ack 0, win 683, options [nop,nop,TS val 39097 ecr 39093], length 516
 
So looking at the dump, all 3 ports are getting data but inside server3 no log is triggered.

> 3) You mean stop the service, and run it again with -l 4 parameter? What should it do? Sounds promising though :-)

Not sure whether I did it right but it does not help (and also for some reasons starts sending trash to UART) even though there is no output device configured for any of the inputs.

As for the index.js this is the relevant part:

var server = net.createServer(function(c) { //'connection' listener
  var parseState = 0;
  console.log('client connected');
  c.on('end', function() {
    console.log('client disconnected');

  });
  c.on('data', function(data) {
    opcparse.parseOPC(data, function(rgb, count) {
      //console.log('rgb count', count);
      for (var i = 0; i < count; i+=3) {

        pixelsUint32[i/3] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);
      }
      console.log('server 1 data');
      //ws281x.render(pixelsUint32);
    });
  });
});

var server2 = net.createServer(function(c) { //'connection' listener
  var parseState = 0;
  console.log('client2 connected');
  c.on('end', function() {
    console.log('client2 disconnected');

  });
  c.on('data', function(data) {
    opcparse.parseOPC(data, function(rgb, count) {

     
      for (var i = 0; i < count; i+=3) {
        pixelsUint32[170 + i/3] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);
      }
      console.log('server 2_ data');
      //ws281x.render(pixelsUint32);
    });
  });
});

var server3 = net.createServer(function(c) { //'connection' listener  

  console.log('client3 connected');
  c.on('end', function() {
    console.log('client3 disconnected');
  });
  c.on('data', function(data) {
    opcparse.parseOPC(data, function(rgb, count) {

      for (var i = 0; i < count; i+=3) {

        pixelsUint32[340 + i/3] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);
      }
      console.log('server 3__ data', count);
      ws281x.render(pixelsUint32);
    });
  });
});


server.listen(7890, function() { //'listening' listener
  console.log('server bound');
});

server2.listen(7891, function() { //'listening' listener
  console.log('server2 bound');
});

server3.listen(7892, function() { //'listening' listener
  console.log('server3 bound');
});

 

Thanks!

[Peter Newman]

Hi Klára,

The ola_dev_info command should just be installed when you installed ola, so if you just run ola_dev_info on the command line it should give you some output. See http://docs.openlighting.org/ola/man/man1/ola_dev_info.1.html for more info.

Edd was trying to say it will render when it sees the command, and therefore ignore the info after that.

From the TCP dump it certainly looks like OLA is sending the data as intended. You could print a more verbose log, but given it's sending the same size on all ports it seems fine. Your ola-openpixelcontrol.conf config looks sane too. If you stop and start olad it should update the config file if you'd done anything inappropriate or missed any parameters.

Sorry, for the -l 4 thing, what I should really have said is start OLA via the init script or however it's normally run, find the relevant command with ps aux | grep -i olad, then stop olad, and run the same command with -l modified to 4, or appended if not currently present on the command line, but tcpdump has most likely ruled out OLA anyway.

Can we see your console log when running that JS code then please? Can you add the "console.log('rgb count', count);" lines for each server please.

The only thing I'd wonder, based on https://github.com/bbx10/node-opc-server/blob/master/opcparse.js#L87 is what happens if you set your channel to zero on each client in OLA and just keep the port different. That's rather a stab in the dark though.

[Edward Burch]

Hey Klára,

Interesting issue look forward to hearing whats causing it, I was giving an example before what might happen if rendering was exicuted more than once. Anyway this is what I have on my setup here.

ola-openpixelcontrol.conf

enabled = true
target = 127.0.0.1:7890
target_127.0.0.1:7890_channel = 0
target = 127.0.0.1:7891

target_127.0.0.1:7891_channel = 0
target = 127.0.0.1:7892
target_127.0.0.1:7892_channel = 0
target = 127.0.0.1:7893
target_127.0.0.1:7893_channel = 0

and for my index.js:

/* jslint node: true */
'use strict';
var ws281x = require('rpi-ws281x-native');
var NUM_LEDS = parseInt(process.argv[2], 600) || 600;
var pixelsUint32 = new Uint32Array(NUM_LEDS);
ws281x.init(NUM_LEDS);
var GAMMA_CORRECT = true;
// ---- trap the SIGINT and reset before exit
process.on('SIGINT', function () {
  ws281x.reset();
  process.nextTick(function () { process.exit(0); });
});
var opcparse = require('../opcparse.js');
var net = require('net');
var server1 = net.createServer(function(c) { //'connection' listener
  var parseState = 0;
  console.log('client1 connected');
  c.on('end', function() {
    console.log('client1 disconnected');

  });
  c.on('data', function(data) {
    opcparse.parseOPC(data, function(rgb, count) {
      //console.log('rgb count', count);
      for (var i = 0; i < count; i+=3) {
        pixelsUint32[i/3] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);
      }

     // ws281x.render(pixelsUint32);

    });
  });
});
var server2 = net.createServer(function(c) { //'connection' listener
  var parseState = 0;
  console.log('client2 connected');
  c.on('end', function() {
    console.log('client2 disconnected');
  });
  c.on('data', function(data) {
    opcparse.parseOPC(data, function(rgb, count) {

      //console.log('rgb count', count);
      for (var i = 0; i < count; i+=3) {

        pixelsUint32[170 + (i/3)] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);

      }
      //ws281x.render(pixelsUint32);
    });
  });
});
var server3 = net.createServer(function(c) { //'connection' listener

  var parseState = 0;

  console.log('client3 connected');
  c.on('end', function() {
    console.log('client3 disconnected');
  });
  c.on('data', function(data) {
    opcparse.parseOPC(data, function(rgb, count) {

      //console.log('rgb count', count);
      for (var i = 0; i < count; i+=3) {

        pixelsUint32[340 + (i/3)] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);
      }
      //ws281x.render(pixelsUint32);
    });
  });
});
var server4 = net.createServer(function(c) { //'connection' listener
  var parseState = 0;
  console.log('client4 connected');
  c.on('end', function() {
    console.log('client4 disconnected');

  });
  c.on('data', function(data) {
    opcparse.parseOPC(data, function(rgb, count) {
      //console.log('rgb count', count);
      for (var i = 0; i < count; i+=3) {

        pixelsUint32[510 + (i/3)] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);
      }
      ws281x.render(pixelsUint32);
    });
  });
});

server1.listen(7890, function() { //'listening' listener
  console.log('server1 bound');

});
server2.listen(7891, function() { //'listening' listener
  console.log('server2 bound');
});
server3.listen(7892, function() { //'listening' listener
  console.log('server3 bound');
});

server4.listen(7893, function() { //'listening' listener
  console.log('server4 bound');
});
// gamma = 2.2
var GammaLUT=new Uint8Array([0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,3,3,3,3,3,4,4,4,4,4,5,5,5,5,6,6,6,6,7,7,7,8,8,8,9,9,9,10,10,10,11,11,11,12,12,13,13,14,14,14,15,15,16,16,17,17,18,18,19,19,20,20,21,22,22,23,23,24,24,25,26,26,27,28,28,29,30,30,31,32,32,33,34,34,35,36,37,37,38,39,40,41,41,42,43,44,45,46,46,47,48,49,50,51,52,53,54,55,56,56,57,58,59,60,61,62,63,64,66,67,68,69,70,71,72,73,74,75,76,78,79,80,81,82,83,85,86,87,88,89,91,92,93,94,96,97,98,100,101,102,104,105,106,108,109,110,112,113,115,116,118,119,120,122,123,125,126,128,129,131,132,134,136,137,139,140,142,143,145,147,148,150,152,153,155,157,158,160,162,163,165,167,169,170,172,174,176,177,179,181,183,185,187,188,190,192,194,196,198,200,202,204,206,208,210,212,214,216,218,220,222,224,226,228,230,232,234,236,238,240,242,245,247,249,251,253,255]);
function rgb2int(r, g, b) {
  if (GAMMA_CORRECT) {
    return (GammaLUT[r & 0xff] << 16) | (GammaLUT[g & 0xff] << 8) | (GammaLUT[b & 0xff]);
  }
  else {
    return ((r & 0xff) << 16) | ((g & 0xff) << 8) | ((b & 0xff));
  }
}

 I hope this help mate,

Edd

[Edward Burch]

 what happens if you set your channel to zero on each client in OLA and just keep the port different. That's rather a stab in the dark though.

you might be onto something there, I didn't realized I had set all to 0... 

[Peter Newman]

I can't believe we managed to post at exactly the same minute Edd!

From reading between the lines on the code, or at least half skimming it, I wonder if the LED count gets set to 0 if it's not <= 1 and the fact it's <= would explain why two work, but no more.

[Klára Juráňová]

Thanks to both of you, changing the channel to 0 for all of the ports in ola-openpixelcontrol.conf solved the issue. It is as I said, I had to completely guess what are those settings supposed to do as I found no documentation for that.

I have also reworked the index.js so that it is more flexible and reduced the code duplicity. I attach it here in case anyone finds this helpful:

/* jslint node: true */
'use strict';

var ws281x = require('rpi-ws281x-native');

var NUM_LEDS = parseInt(process.argv[2]) || 100;

var pixelsUint32 = new Uint32Array(NUM_LEDS);

console.log('NUM_LEDS: ');
console.log(NUM_LEDS);

var ledsInUniverse = parseInt(process.argv[3]) || 170;
var universeCount = parseInt(process.argv[4]) || 1;

ws281x.init(NUM_LEDS);
var GAMMA_CORRECT = true;

// ---- trap the SIGINT and reset before exit
process.on('SIGINT', function () {
  ws281x.reset();
  process.nextTick(function () { process.exit(0); });
});

var opcparse = require('../opcparse.js');

var net = require('net');

function LEDServer(ledCount, serverIndex) {
  this.ledCount = ledCount;
  this.serverIndex = serverIndex;
 

  this.srvFunction = function(c) { //'connection' listener  
    console.log('client%d connected', serverIndex);
    c.on('end', function() {
      console.log('client%d disconnected', serverIndex);

    });
    c.on('data', function(data) {
      opcparse.parseOPC(data, function(rgb, count) {
        for (var i = 0; i < count; i+=3) {

          pixelsUint32[ledCount*serverIndex + i/3] = rgb2int(rgb[i],rgb[i+1],rgb[i+2]);
        }      
        if (serverIndex == (universeCount - 1)) ws281x.render(pixelsUint32);
      });
    });
  };
}

var ledservers = new Array(universeCount);
var servers = new Array(universeCount);

for (var i = 0; i < universeCount; i++){
  ledservers[i] = new LEDServer(ledsInUniverse,i);
  servers[i] = net.createServer(ledservers[i].srvFunction.bind(ledservers[i]));
}

for (var i = 0; i < universeCount; i++){
  servers[i].listen(7890 + i, function() { //'listening' listener
    console.log('server%d bound', i);

  });
}

// gamma = 2.2
var GammaLUT=new Uint8Array([0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,3,3,3,3,3,4,4,4,4,4,5,5,5,5,6,6,6,6,7,7,7,8,8,8,9,9,9,10,10,10,11,11,11,12,12,13,13,14,14,14,15,15,16,16,17,17,18,18,19,19,20,20,21,22,22,23,23,24,24,25,26,26,27,28,28,29,30,30,31,32,32,33,34,34,35,36,37,37,38,39,40,41,41,42,43,44,45,46,46,47,48,49,50,51,52,53,54,55,56,56,57,58,59,60,61,62,63,64,66,67,68,69,70,71,72,73,74,75,76,78,79,80,81,82,83,85,86,87,88,89,91,92,93,94,96,97,98,100,101,102,104,105,106,108,109,110,112,113,115,116,118,119,120,122,123,125,126,128,129,131,132,134,136,137,139,140,142,143,145,147,148,150,152,153,155,157,158,160,162,163,165,167,169,170,172,174,176,177,179,181,183,185,187,188,190,192,194,196,198,200,202,204,206,208,210,212,214,216,218,220,222,224,226,228,230,232,234,236,238,240,242,245,247,249,251,253,255]);

function rgb2int(r, g, b) {
  if (GAMMA_CORRECT) {
    return (GammaLUT[r & 0xff] << 16) | (GammaLUT[g & 0xff] << 8) | (GammaLUT[b & 0xff]);
  }
  else {
    return ((r & 0xff) << 16) | ((g & 0xff) << 8) | ((b & 0xff));
  }
}

There are 3 parameters to this function
argv[0] - number of leds in total
argv[1] - number of leds in 1 universe
argv[2] - number of universes (the last one does the rendering stuff)



Dne pátek 24. února 2017 3:34:04 UTC+1 Peter Newman napsal(a):

[Klára Juráňová]

The google groups engine seems to have messed up my post and I cannot see any way to edit the post so once again:

3 parameters:
argv[0] - number of LEDs in total
argv[1] - number of LEDs in one universe

argv[2] - number of universes

[Klára Juráňová]

I give up...

[Peter Newman]

The settings are documented for OLA here (or in ola_plugin_info or the web UI), but the requirement to use a particular channel is between the OPCparse code and your JS code.

https://github.com/OpenLightingProject/ola/blob/master/plugins/openpixelcontrol/README.md

Your code seems to be rendered correctly here:

https://groups.google.com/forum/#!original/open-lighting/BxlK8_drkcw/z-EuDdx4DQAJ

On Thursday, 2 March 2017 17:59:19 UTC, Klára Juráňová wrote:

I give up...

[Wolfgang]

Hi all
When I start my Raspberry with OLA I can find the WEB-UI at
"http://<myadress>:9090".
But I can not control a single channel.

Then I select "Stop OLA" in the WEB-UI and confirm.
Next I start the OLA daemon on my Raspberry with "olad -l 3"
Now everything works as expected.
=====
Tried tons of things. There must be a simple solution to get things right.

I think of a script that 'Stops OLA' and start it again, but "sudo
/etc/init.d/olad stop" seems not to work.

What can I do? ( How can I stop OLA at the prompt ?)

Thank you for helping

Wolfgang

[Peter Newman]

Hi Wolfgang,

We're going to need some more information please.

Are you trying to use an IP based protocol for control of your lights?

Does OLA show the correct patch before you restart it?

What error or output does "sudo /etc/init.d/olad stop" give?

What network interface does your Pi have?

[Wolfgang]

Hello Peter!

Sorry for the delay, but I had some trouble with my LAN.

After fixing that, everything is normal now. I think I had a bad setup, so sometimes there was simply no connection possible using my LAN.

No everything works as expected!

Sorry for wasting your time!

Wolfgang

--

[Wolfgang]

Hello Peter!

Sorry for the delay. The reason for the delay AND the troble with OLA was a malfunction of my LAN.

Everything is well now!

Sorry for wasting your time!

Wolfgang

Am 12.03.2017 um 23:17 schrieb Peter Newman:

--

[Peter Newman]

Excellent, glad you sorted it.

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

[Michael Muck Kremtz]

Has anyone seen those Youtube videos he was talking about?

It would be so nice to have a step by step run-through from an empty Rpi to an up to date OLA System capable of driving WS2811 Pixels! 😍

Edd in January 2017:

[Adam Davies]

Evening,

Another latecomer here I'm afraid! Whilst my post about controlling LEDs via ArtNet and MCP23S17 chips is on-going I am doing this for work. We're looking to have a Raspberry Pi Zero act as an ArtNet > SPI converter for WS2812 pixels.

I have OLA working absolutely fine and understand I'll need to go via OPC into Node and then out to my pixels but does anyone have any up-to-date documentation or tutorials or example code? OLA works fine and I have my OPC conf file configured but all the articles linked above now throw out errors as they're so old. I have node installed but seem to have hit a brick wall as I've never used node before and unsure what I need to do next?

Thanks

Adam

[Peter Newman]

Hi Adam,

I'm not really a Node expert, but what errors do you get and which docs/tutorials are you following? Is it just throwing warnings which newer Node is finding in their code?

If you only want Art-Net to WS2812, you could also use the Pi Zero as a microcontroller using Arjan's bare metal code (assuming it supports the Zero) and do it within that.

Sorry Michael, I think I missed your post before. I'm not aware of where Edd's videos went if they weren't posted on here.