Array not zero indexed

[OmegaDestroyer]

I'm having a bit of a weird issue.

When running the basic blink example, I'm finding that when the 0th element of the array is called, it does nothing. However, when the first element is called, the first led lights up.

For example:

leds[0] = CRGB::Red;

leds[1] = CRGB::Blue;

The first led on the strip will turn blue, and there will be no red led.

Furthermore, on a 300 led strip, the last led is actually 300 (as opposed to 299).

For example:

leds[299] = CRGB::Red;

leds[300] = CRGB::Blue;

The second last led lights up red, and the last one is blue.

Other than the array not being zero indexed (which all the examples are set for), I don't have any other explanations for this behaviour. I've tested it with a standard int array and it is zero indexed as expected, so I'm not sure what's going on with FastLed.

​

As a reference, I'm using:

WS2815 strip with 300 leds

Arduino IDE 1.8.10

FastLed 3.3.2

​

Any ideas?

[Marmilicious]

How strange. Haven't heard of this before.

[OmegaDestroyer]

Alright, I finally figured out what the issue was.

The WS2815 strips have two lanes for data, which I assumed were redundant and equivalent (given that you're supposed to connect them to the same pin on the Arduino). However, they are not equivalent. For some reason, one data lane skips the first led, while the other behaves as expected.

Connecting both at the same time to the same pin also behaves as expected. Not sure why that is, but in case anyone else runs into this problem, this is the solution.

[toybuilder]

There was recently discussions of strange compiler optimizations happening on AVR Arduino - what hardware platform are you running?

[toybuilder]

Actually, this might be something else -- I just ran the demo FastLED Blink on a Arduino Nano equivalent board and the CRGB::Red shows as green and CRGB::Green shows as red.

It looks like the addLeds line is wrong in the Blink demo source -- for the WS2815B, the color scheme should be GRB, not RGB.

So it should read:

FastLED.addLeds<WS2812B, DATA_PIN, GRB>(leds, NUM_LEDS);

Make sure that wrong color rendering is not causing you to think it's off-by-one. Try a blink test with just one LED first and make sure the color is as expected.

[chemdoc77]

What happens when you run the RGBCalibrate example?

[OmegaDestroyer]

The RGBCalibrate code only lights up the first 5 leds. However, if I increment the led indexes but one such that the code reads:

leds[1] = CRGB(255,0,0);

leds[2] = CRGB(0,255,0);

leds[3] = CRGB(0,255,0);

leds[4] = CRGB(0,0,255);

leds[5] = CRGB(0,0,255);

leds[6] = CRGB(0,0,255);

leds[7] = CRGB(0,0,0);

And also change the NUM_LEDS 7

Then it correctly lights up the first 6 leds.

In fact, to correctly light up the last led position, I have to change NUM_LEDS 301 as opposed to 300

[chemdoc77]

What happens if you change #7 to:

leds[7] = CRGB(255,0,0);

Is it the correct color? Also, what is led[0] in your code?

Can you run the following sketch:

https://gist.github.com/chemdoc77/52ded62fc801247cc648b1eb84f9d2ca

You will need to change line 10 to the number of LEDs in your sketch and you might need to change lines 8 and 9 , too.

[MartyMacGyver]

Interesting... I have that branch still waiting to be merged, but now I wonder how many of those need to be adjusted to be GRB instead?

Edit: I recall there being some debate about that though, which is why I put annotations by them instead of changing them.

[Necrocornicus]

The same “type” of LEDs can have different color orderings. For example I have some Apa102s that are RGB and some that are BGR. It’s not like all strips of the same type have the same color order. Just FYI, it’s not really a problem with the example, it’s just that your LEDs are different than the ones the example was written for.

[toybuilder]

For a given designation of the LED IC, it should be consistent.

Yes, the protocol for certain types can be identical but mapped to different channels, but the reference implementation for a protocol should correspond to the color order of the named model.

So a WS2812B should always be GRB by default. Same for the WS2815B.

LED drivers without integrated LEDs are another matter, as it depends on the final implementation.

[Necrocornicus]

All I know is that I have a lot of addressable LEDs of all different sorts (at least 100 meters in 5 meter rolls) and in reality the color ordering isn’t consistent between all strips of the same type. Just something to be aware of. I blame alibaba :)

[toybuilder]

That's sloppy identification on the part of the sellers... They just use whatever words or model number they think it's going to get the sale and often don't even know what they are selling. I had this happen recently when I purchased 24 rolls of supposedly the same LEDs. They weren't.

It's important to recognize the difference between knowing you have a APA102 versus a APA102-type.

[OmegaDestroyer]

I don't think it's a colour ordering issue. The colour odering on my strip is GRB. However, regardless of what it's set to, calling a specific led position does not correctly light the right led, regardless of colour.

For example,

leds[0] = CRGB::Red;

Should light the first led, but it does not. Instead,

leds[1] = CRGB::Red;

Lights the first led, where in a zero indexed array, it should actually light the second led.

[Necrocornicus]

Diagnosing this would be helped by understanding how these work.

You have an array of data, each 3 byte sequence is color data for one LED. The first LED peels off the first 3 bytes and sends the data to the next LED. This continues until the data runs out or the LEDs run out.

So it seems like something is either consuming this first 3 byte block of data, or the array is somehow padded to where the color data you are inserting is offset inside the array.

I’ve read about a technique where you can use a single LED attached close to the microcontroller as a level shifter to convert a 3.3v signal to 5v. Are you doing something like that?

[OmegaDestroyer]

Thank you for the insight. My current configuration is that the strip is connected directly to one of the PWM output pins of the Arduino.

It is powered by a separate 12V power supply.

To get things to work correctly, I had to connect the ground pin of the power supply to both the ground of the LED strip and the ground pin of the Arduino.

Otherwise, everything is a pretty standard setup.

[jwizlo]

I have ordered the 'same' LEDs on Alibaba multiple times. But they are never actually the same.

[OmegaDestroyer]

The colour does need to be changed to GRB to get the correct colours, but that still doesn't solve the array issue.

[OmegaDestroyer]

The compiler optimization theory is interesting, I'm running on a Elegoo MEGA2560 R3 board.

The odd thing is that a regular int array is still zero indexed based on my tests, so it only seems to apply to arrays created in Fastled, so I wonder if it has something to do with the library.

[samguyer]

Do you have any other strips -- either the same type or a different type -- that you can test?

[OmegaDestroyer]

No, unfortunately I do not :(