Problem with APA102 and last led in chain

Problem with APA102 and last led in chain.

Hello, I’m testing my new APA102 strip with FastLED and I’m having an issue, the channel order for the last LED in the chain always seems to be wrong. I made a little test that will light the whole strip red, then green, then blue and then black. The last led in the strip starts black, then red, then green, then blue.

Here’s my code:

I also tried lowering the number of leds (say 140 instead of 144) but led 140 behaves the same way.
Any ideas ?

Thanks.

Which version of the FastLED library are you using?
Also, what are you using to control them?

I’m using the 3.1 branch that I checked out last week with a Teensy 3.1

What happens if you set the data rate lower from the APA102’s default?

FastLED.addLeds<LED_TYPE,DATA_PIN,CLK_PIN,COLOR_ORDER, DATA_RATE_MHZ(12)>(leds, NUM_LEDS);

Just tried and it doesn’t seem to change the behaviour…

@Nathanael_Lecaude Just looked into the code I can’t find anything wrong there as it is certainly simple enough.

Try changing in all places from …

i < NUM_LEDS

to…

i <= NUM_LEDS

Well did find something not quite right in the code…

add a delay statement after the FastLED.show(); of BLACK !

Interesting. How small can the delay be and still fix the issue?
What about replacing that last FastLED.show() with FastLED.delay(3), as that calls FastLED.show() behind the scenes.

I still don’t see why the original code didn’t work as expected.

Hi @marmil ,

I actually can’t say that adding that missing delay fixes the problem described as I do not have any APA102 to play with !

Just noticed that missing statement that probably should be there when he actually starts adding code in the loop !!

With the sketch as it is, when setup() is completed he just sits there doing nothing forever… that is probably the longest delay() you could ever have… :wink:

I tried adding delays at various places but it doesn’t seem like it solved the issue.

I also tries running that block of code in the loop but it reacted the same way…

@Nathanael_Lecaude Did you the change I suggested that actually tries to write past the last LED ??

Actually even more simple mod to try…

Change NUM_LEDS to 145 !!

yup that works but it still means there’s a bug somewhere in the apa102 implementation…

@Nathanael_Lecaude Yes I agree with you.

I can’t help more as I have no APA102’s and no Teensy’s. I am a bit surprised that nobody else has seen this.

What version of Arduino / Teensyduino are you using ?

Maybe someone else can help duplicate the problem !

I’m using Arduino 1.6.3 with the latest teensyduino (1.22 beta)
The strange thing is that the other sketch I use which reads pixel data from serial doesn’t have this problem.

That’s interesting, just switched to software SPI pins (2 and 3) and the problem is gone. So there seems to be a bug with the hardware SPI…

Ah, good test Nathanael.
Pinging @Daniel_Garcia !

It would help to know what hardware you are compiling for. Edit. just saw the comment mentioning teensy 3.1 - i’ll setup some hardware here later tonight to check.

The APA102 requires some extra clock line strobing after writing out data to ensure that data propagates all the way to the last led. It sounds like this may not be happening w/hardware SPI for some reason - i’ll need to dig into the why.

Actually - strike that - found and fixed a problem in the APA102 code that would affect when using hardware SPI on the teensy 3 and checked in a fix on the 3.1 branch - pull that and re-test.