octo basic test + first pixel

Status
Not open for further replies.
C

camilozk

Active member
Hi!

I am trying the octoWS2811 library for the first time with the "basic test" sketch in it is working fine. Nevertheless, the first pixel is not responding correctly. I tried putting a 470ohm resistor to the data line and it still doesnt work correctly. The first pixel is either off or displaying a random color.

Also wanted to ask, after uploading the "basic test" sketch, the on board LED from the teensy is off. I would have expected to see it always on. is that the case or there is something wrong with the led?

thanks!
 
The LED is not a power LED, it's on pin 13, so shows whatever pin 13 is up to. If code doesn't use pin 13 (or has it on for very short periods) then it'll be dark.

Is your problem the first pixel of the first row, or is it first pixel of every row?
 
I am interested in this thread since I believe I am having the same problem. In my case, it is the first LED in each row. The Basic Test program seems to ignore the presence of the first led in all eight rows. Changing the ledsperrow value confirms that row 2 is being seen as row 1. I have no intention of hijacking the thread, just adding data to it. My LED on Pin 13 remains off.
 
thanks for the clarifications on the on-board led.

about the faulty first pixel, I only had time to try it out with one led strip, so I can only talk about this case, but it is interesting to know that in jparisse´s case, he is experiencing the same in the first pixel of each row. I am curious how this continues...
 
Looks like there is something amiss for the row zero send, but a sanity check is to use fast led or adafruit neopixel libraries and fire them at the strips (set appropriate LEDpin for the strip number you want to test) will prove that your zero pixel can work. Suspect some digging will find the there off by one error crept in somewhere but haven't gone digging for it yet since my neopixel hardware is several time zones from me at the moment.
 
GremlinWrangler said:
Looks like there is something amiss for the row zero send, but a sanity check is to use fast led or adafruit neopixel libraries and fire them at the strips (set appropriate LEDpin for the strip number you want to test) will prove that your zero pixel can work. Suspect some digging will find the there off by one error crept in somewhere but haven't gone digging for it yet since my neopixel hardware is several time zones from me at the moment.
Click to expand...

I will give that a try this afternoon. Below is a photo of the test bed I set up. The first LED of each strip (bottom row) randomizes at each power on.
 

Attachments

  • IMG_1211.jpg
    IMG_1211.jpg
    84.7 KB · Views: 280
Also potentially useful here, do you have any markings or ordering information on what these LEDs actually are? There are several flavors of similar but not identical serial LEDs around. Since the LEDs reshape the signals as they pass through it's not impossible that there is something amiss with the timing of the first pixel, which it reshapes and then passes on correctly.
 
The LEDS are fresh from SparkFun and labeled as WS2811. I seem to recall that they have a "direct drop in replacement" and perhaps that is what was in the bag. I will look to the strip itself to see any identifiers.

I loaded up test files with Neopixel and FastLED libraries and ran each test on each pin (16 tests). All led strips work individually on each library.

Thanks...
 

Attachments

  • image1.jpg
    image1.jpg
    97.3 KB · Views: 243
  • image2.jpg
    image2.jpg
    81.3 KB · Views: 319
Thanks for taking the time to run the strip tests since that pretty much nails this as something to do with OctoWS library and how it sends the first block of data. Since if I'm reading the data sheet right the scheme is that each pixel grabs the first 24 bits of data and then latches it, passing all future bits along until 'display' is sent when they all update. So something is stuffing the first block sent.

Pending answers from the code an interim option is https://github.com/FastLED/FastLED/wiki/Parallel-Output

This loses some of the parallel processing performance that OctoWS library gives, but if you are just driving lots of pixels, without needing to extensively pre process them may get you where you need to go without having to untangle what has changed in the OctoWS DMA source code.
 
Great! Thanks for the reference... I use FastLED in other projects and I did not know about parallel processing code. I will definitely go that route since my requirements are low (8 strips). Hmmm... Does this also mean I can use more than 64 LEDS per strip? I bet it does... ;)
 
Octo supports 1000s of LEDs, main limit is refresh rate being fixed per pixel so a 500 LED strand can never be better than 60hz refresh. That's the main advantage of the Octo library since while bits are being clocked out you can have the next frame being processed.
 
I don't know how I got a 64 LED per strip limit in my head but I did. I read back all the literature I've read so far but I can't find it... :) Thanks for the help... I hope camilozk gets his problem resolved too.
 
ey people!

got back home and am now trying things our again. I have just connected 4 strips (5 pixels each) to the 4 data lines from the 1st ethernet cable. Launched the BasicTest and I see now that the first pixel in each strip is nos working correctly. see https://www.youtube.com/watch?v=eZYNPW8TDq0&feature=youtu.be

The strips were as well tested individually with neopixel and fastled and they do work correctly.

I got a bit lost in the thread: did you @jparisse sorted out your first led problem?
 
Leo,

The problem seems to be with the native OctoWS2811 library. A workaround is to use the OctoWS2811 from FastLED. Check out 'Examples/FastLED/Multiple/OctoWS2811" in the Arduino IDE. You will find working sketches for spreading animation across the 8 (or more) strips in different manners (parallel, one long strip, etc.). As I understand it, the limitation is video.

I got the FastLED multiple library to work easy and fast. I am going to go back to play with video over with the native OctoWS2811 library and live without the bottom row until things get fixed.

Let us know how the FastLED multiple library works for you.

Jeff
 
thanks for your message jeff

I have just uploaded OctoWS2811Demo from the FastLed library, and I am very unsure if what I see is what I should...

The first pixel of every strip is either off or has a random fixed colour. Then, I see the last 3 pixels of the first strip fading colors, as well as the last 2 of the second, the last of the third, and no led fading colors in the 4th strip. All the other leds are fixed in red.

#define NUM_LEDS_PER_STRIP 5
#define NUM_STRIPS 4

https://youtu.be/Dq4aTv_CoYc


These are my first steps with Teensy and Octows2811. My first idea is to try to control the strip with a software that is called Vixen Lights, from a project I found online (http://www.technikfreak.ch/2015/09/26/digitale-weihnachtsbeleuchtung-selbst-gebaut-teil-1/). Then, lets see where does it take me from there :)
 
I am a little bit puzzled...

I have just been able to have running the configuration explained in the link that I posted in my previous post, with teensy + octows2811 + vixen lights, and everything runs perfectly expect for the fact that the first pixel seems to not even exist for the system. Pixel nº1 in the software is the 2nd pixel in the system, and the first real pixel is either off or fix in a random color...
 
I am getting the same problem with OctoWS2811 just as you describe and show in your video.

You do not need the OctoWS2811 LIBRARY to accomplish your task. The FastLED OctoWS2811 Demo uses that library and that is where the problems arise... Notice #include<OctoWS2811.h> in the code? That is the offending library. The OctoWS2811 HARDWARE is still useful for distributing animation code to arrays of strip and can be used without the library.

Load up the FastLED ArrayofLedArrays sketch and define your pins:

Strip Pin
0 2
1 14
2 7
3 8
4 6
5 20
6 21
7 5

Make sure you also describe the LedsperStrip in your code.

You will see two "for" loops in the example code. One indexes the strips (0-7) and the other indexes the pixels in the strip 0-NUMLEDS).

Each Christmas Star can be an array and each pixel in the star can be an array. You can direct different animation effects to each individual star. Sounds like a fun project and you gave yourself enough time. ;-)

Jeff
 
Hi, long time reader, first time poster.

Some friends and I have been using octows2811 for about a year now, and it's always worked great for us. Last night, while flashing some new test code on a new display we're building, I came across the same first pixel problem others are mentioning in this thread. I ran several of the examples and all of them had the same behavior. I even tried the FastLED multiple examples, but couldn't get the first pixels to illuminate.

We're using a custom 3 LED 12V pixel from Ray Wu (aliexpress), running a ws2811 chip. They've worked fine for us in the past, and an old board I'd flashed from my old machine was able to drive them properly. The current version (Arduino 1.8.2 with Teensyduino 1.36) is showing this behavior. The first pixel of each strand is dark, but the rest of the strip behaves as expected. Very bizarre. Rearranging the strips proved that the LED was fine. Swapping to an old teensy with older code proved that the whole physical display is fine.

Things were working fine in Arduino 1.6.12 with Teensyduino 1.34. I haven't had a chance to dig into the changelogs, but it appears that this is a regression.
 
I'm having the same issue with the following examples:

FastLED/Mutliple/ParallelOutputDemo
FastLED/Multiple/OctoWS2811Demo
OctoWS2811/BasicTest

Running the FastLED/DemoReel100 example without the Octo library doesn't cause issues.

Thanks.
 
Hello All,

Not sure, but I may have an idea as to what's going on here. WordSemi (manufacturer of WS2811/2812 chips) have silently changed the timing of their chips going forward. The main change is the reset interval timing. See below:

https://blog.adafruit.com/2017/05/0...led-has-been-revised-will-require-code-tweak/

This new timing is actually the same as for the newer 2813 pixels. Luckily, newer versions of the Octo library have already added support for 2813 timing, but you must change your pixel config to use it. In my case, the following:

const int config = WS2811_GRB | WS2813_800kHz;

Could someone who is having this issue try changing the config in the test sketch and see if this changes anything? If not we can move on to the next idea.. :)

Cheers!
 
ey!

I tried it and my first pixel is still off in every row.


changed this:

const int config = WS2811_GRB | WS2811_800kHz;

for this:

const int config = WS2811_GRB | WS2813_800kHz;


thanks for being there.-
 
Couple of questions:

is WordSemi the only manufacturer of WS2811/2812/2813 chips?

I saw that the price of 2813 is almost the double as the 2812. Do you think this will stay like this for very long?
 
Dang! Well it was worth a shot. As far as I know WorldSemi is the only manufacturer of proper WS2812 etc. chips. (therefore the WS) There are knockoffs that are practically identical. I know of the SK6822 and there are probably others floating around. Could well be that you have some..

Everything that I've got my hands on so far works with the OctoWS2811 library. But also maybe something has recently changed that broke something. I am currently running Arduino 1.6.12 and teensy 1.34

I would try to downgrade to these versions and see if it fixes things..

2813 should be slightly more expensive than 2812, but definitely not double the price
 
Status
Not open for further replies.
Back
Top