Not sure if anyone else out there is using P9813’s and the 2.1 FastLED code, but I thought I’d mention that it’s been working great for me on large-ish strands of pixels (~150-250), but I hooked up a strand of 25 the other day to do some testing and basically couldn’t get any light to show up if I was using HSV values under ~225.
However, I just figured out that if I turn down the data rate to 3Mhz or under (had been using 15Mhz), the short strands seem to work fine.
Testing setup is a teensy 3.1, 220 ohm resistors on clock and data going to a 74HCT245, and 1x25 pixel strand of cool neon P9813’s. I didn’t notice any different with or without the logic converter, but it still seems like a good idea. I also played around with different resistor values and didn’t see any difference (don’t have a scope).
For what it’s worth, I’m just using the P9813’s cause I’ve got 'em. Probably not what I’m going to work with going forward…
Out of curiosity are you using the hardware SPI ports or just an arbitrary pair of pins? (Asking because on a teensy 3.1 it’s possible that the bitbang’d spi output is overdriving the P9813, and I haven’t gotten around to re-adjusting the timing adjustments for bit’bang’d SPI. )
Another thought, if instead of turning the data rate down to 3Mhz, what happens if you add a delay(1) or a delay(2) before calling LEDS.show()? (The other possibility is that there’s some latch/reset delay that’s being stepped on and so you’re updating too quickly with a shorter strand).
Actually - that last idea might be closer to the mark, but for different reasons. If you are pushing frames faster than the cycle rate of the P9813, and they’re low pixel values, you might be updating the P9813 chips before their PWM cycle gets around to the lower light values, leaving them blank.
The WS2812’s have a similar problem, if you update them more than 400 times/second you can get weird effects happening because you’re stepping on the PWM clock. I think i’m going to need to look into specifying what the refresh rate of a chipset is, and force LEDS.show to pause to maintain that rate…
something to think about (for me, that is)
I’m using 11 & 13 for data and clock. And yeah, it looks like your guess is correct, if I put in a delay(1) before the show call, I’m seeing normal behavior.
For what it’s worth, I have a 24 x 24 matrix of P9813 pixels (so 576 LEDs). I’m driving it with a Teensy 3.1, and it’s been working flawlessly with the updated build I got from Daniel (in early February, if I remember correctly). I am not using any resistors - just straight out from pins 11 and 13.
I did see a bit of chaos in the lights running like 75 P9813’s without a resistor, but haven’t played around with it much