@JP_Roy I guess I don’t get the idea behind the termination 100 ohm resistor you mentioned… where does that go and what does it do? Thanks.
@Tom_Morrow
You said… “I thought the100 ohm resistors before the strip were for impedance matching to avoid reflections distorting the signals.”
You also said… “so I think it makes sense to add the 100 ohm also near the strip itself.”
Note that you said it not I…
I repeat… I would not add any resistor !
Have a look here at the explanation for impedance line matching…
In their specs sheet for the OCTOWS2811, PJRC states: “The adaptor features a 74HCT245 buffer chip and 100 ohm impedance matching resistors.”
I only mentioned the 100 ohms termination resistor that would be required to ‘match’ the source impedance of 100 ohms of the OCTOWS2811 board.
Hi @Tom_Morrow ,
Curious where you are now with this troubleshooting…
-
Did you fetch the latest FastLED 3.1 ?
How did that go ?? -
In your original post you state that… “I was able to test my Ray Wu Aliexpress APA102 strips through Teensy 3.1 and Octo board with the Adafruit Dotstar strand test code and everything worked fine.”
That would suggest a FastLED library issue and not a hardware related fault. Can you elaborate more on the results with the Dotstar strand test code ?
I have not used the APA102 myself yet but I was considering my next LED project to be Teensy3.1 and APA102 based but I see a number of weird reports of flickering and corrupted data and would prefer to see a clear resolution of these issues before I go and empty my pockets.
Best regards, JP
Thanks JP Roy . I think I was already on 3.1 even when I thought I was on 3.0. When I compile I get the message
#warning FastLED version 3001000
That means I’m on 3.1 right?
At any rate everything seems stable at 12Mhz, except the very last pixel. It does seem to be a software problem with FastLED (or possibly my code if there’s something I’m missing about the loop indexes). That last pixel seems to get old data, perhaps from a previous show(). I’ve worked around the issue by simply pretending there is one more pixel on the strip so the bad pixel falls off the end. E.g. for a 144 LED strip I set NUM_LEDS to 145, or for two meters of those I set it from 288 to 289.
It doesn’t appear to be a hardware problem since it’s always at the end of the chain no matter if the chain is 1 or 2 strips.
I do find that any values above 12Mhz, things become unstable and I get many flashing or bad pixels like in the video above. E.g. 13Mhz is bad. But with 12Mhz and below just that bad end pixel. Changing the teensy clock rate from the arduino menu doesn’t make a difference.
Anyway, the upshot is these seem plenty stable for me adding an extra pixel to the array. So I’ve been spending my time on the hardware mounting issues.
I have read that some people have had problems where they got bad last pixels because they didn’t write the end packet after the last pixel, and my understanding is that fails to transfer the clock to the last pixel. I’m not ready to dig into the FASTLED code, but perhaps some FASTLED developer who is reading this could verify that they are writing an extra frame after the last pixel.
Thanks @Tom_Morrow ,
Here’s a nice blog that goes into great detail about the APA102 data stream requirements…
Notice this comment…
" The recommended end frame length of 32 is only sufficient for strings up to 64 LEDs. "
I think you have a reasonable solution by adding a ‘dummy’ (or more) LED(s) worth of data at the end !
Interesting blog entry. I decided to test out what they said in the blog about needing more extra frames for greater than 64 LEDs. Strangely using FASTLED I found the opposite: for 64 and above LEDs I needed one dummy LED, while for slightly less than 64 LEDs I got not one but two “bad” LEDs on the end without dummies. All this was done on my 144 long strings.
I also found that I only need one single dummy pixel on the end even for seven meters connected, for a total of 7*144 LEDs. So something strange is going on but it doesn’t seem to be what that blog said. Unless FASTLED is already compensating for the issues raised in that blog but incompletely.
I went back and made my Adafruit_dotstar library test do the same thing I was testing with FASTLED, and lo and behold I got the end-pixel problem, and it was more like the blog said: With 64 pixels I didn’t get any bad end pixels, but with 72 I got 1 bad end pixel, with 144 I got two bad end pixels, and with 7*144 I got 15 bad end pixels. In all cases I could solve by just adding dummy pixels. The reason I didn’t see these problems previously with my adafruit test was that the chase pattern wasn’t conducive to noticing those bad pixels.
So now I’m theorizing FASTLED probably is compensating for the issue mentioned in the blog post, but just has an off by one error somewhere. At any rate, I’m satisfied that adding dummy pixels on the end is a good workaround for me.
@Tom_Morrow Good detective work !!