Hello, This questions may seem very amateur,

Archive FastLED Archive
,
1

Hello,
This questions may seem very amateur, and probably because I am with fastLed but any help would be appreciated. For the things I am talking about I am using APA102 with a teensy 3.2.

My questions-

  1. What does this statement do:
    CRGB leds[NUM_LEDS];
    also, why is it called CRGB, as in why the C, what does that stand for?
    Because I am getting a bit confused by that line. I know I have to use it but I don’t know what it does. Also, is there a reason why I have to state the number of LEDs in there?

  2. If I want to do a very simple thing such as making the first LED on the strip turn red, I would need to do code like this, right:
    leds[0] = CRGB::Red;
    Is that correct?
    It is saying that I want LED 0 to be red?
    Because when I do it, the whole strip, for lack of a better word goes mental. All the lights are flicking on and off quite frantically. I have checked my wiring and that all seems fine, and even the most basic of examples seems to be going nuts. Literally, no idea what is up with it.
    With the dotstar library I use:
    strip.setPixelColor(LED, 255, 255, 255);
    and that works fine. So I am really confused why the fastled library is not working for me :frowning:

  3. For me, I am keen to have very accurate timing, if possible to <10millis, would it be more appropriate to use FastLed or dotstar for this?

Thanks you for the help in advance

Tej

2

  1. CRGB is a Class (where the C comes from) representing a single RGB object, the leading C is a naming convention that I (and others) use. CRGB leds[NUM_LEDS]; creates an array of CRGB objects, one for each led that you have - which is why you have to have the number of leds in there. I would recommend reading up on C and C++ arrays.

  2. You might need to adjust the SPI speed - FastLED defaults to using the fastest SPI speed that it can, but depending on how you’ve done the wiring, you may have to slow it down. https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging describes how to adjust the SPI speed if you need to.

  3. Need a lot more info from you - generally speaking, FastLED is going to be much higher performance than the adafruit default libraries. However, to tell you what you need for the timing that you want, I’d need some more information, like how many leds are you going to be updating? At full speed, the APA102 can do a total of about 750,000 rgb led updates per second, or about 7500 per 10ms, if you’re spending all the CPU time pushing data. Of course, since you’ll want to spend time building your frame (let’s say half the CPU time, so 5ms building the frame, 5ms writing it out) then you’re looking at more like 3750 leds. Though, that’s at the default 24Mhz SPI clock rate. If you have to drop it down to, say, 12Mhz then you’re looking at more like 1875 leds at 100fps, realistically. Note: I regularly use FastLED to drive ~500 leds at 70-150fps doing multiple noise computations per led.

3

Hi, I am actually only assuming that the C in CRGB means ‘Constructor’ but it does kinda makes sense to me that way.

CRGB is a pre-defined structure in the FastLED library. It is essentially defined by 3 bytes: 1 byte for Red, 1 byte for Green and 1 byte for Blue but can also be represented by a single 24 bit value like…

leds[0] = 0xFFAA55; where red = FF, Green = AA and Blue = 55.

When use… CRGB leds[NUM_LEDS];

You are actually creating an array called ‘leds’ of type ‘CRGB’ (remember the 3 bytes structure !) with a size of ‘NUM_LEDS’.

When you use the line… leds[0] = CRGB::Red;

You are saying assign the value of CRGB::Red to the first element of the leds array. Note that [0] is the first element in an array.

From your description, I think that you are just sending data to your leds that is outside of your array size and you are therefore just seeing irrelevant data.

4

@Daniel_Garcia

Thanks for the info guys.
At the moment I am working with 3,000 LEDs and will be looking to move up to about 10,000.
I will give it a go with changing the SPI speed and then get back to you.

Thanks, the both of you :slight_smile:

5

@Daniel_Garcia
I know this is a bit of an old topic, but I thought I would ask you for your view here as I have updated at last…
I am now using 3,000 LEDs with the APA102. The refresh time is currently ~32ns per LED when set at 13MHz. If I go to a lower MHz the LED update speed reduces but a red flickering starts up on the strips, and when I go lower than 5mhz, all the lights go mental and very much out of my control. Therefore, I ask, what do I need to do to ‘gain control’ of the LEDs at lower Mhz, is this the route I should be taking to see a refresh rate at 5-10ns?
In addition, I am using the Teensy 3.2, is this the best processor to be using? Do you feel there are any better processors out there to help me refresh quicker, or is this limitation caused by the LED strip? I did have a glance at the BlackBeagle and PIC. However, I was unsure if i was diverting a bit far away when I started looking at PIC…

Regarding power, just to be sure that is not the main issue, I am using 2x 5V, 60A, 300W Meanwell power supplies with power every 5m. So i know i am pushing the limit, and i do have a third which i will be adding on asap.

Thanks
Tej

6

@Tejkaran_Samra in my opinion, injecting power every 5 meters is your problem.
If you can, just measure the voltage at the far end of a 5 meter strip that is lit up brightly and measure the voltage. At any point on the whole length of strips the voltage should never drop below 4.5 Vdc

7

@JP_Roy so maybe inject power every 10 meters or so? Is the red flickering caused by over power then?

8

Hi @Tejkaran_Samra , I strongly suggest you first take voltage measurements at many places in your setup and check that voltage is never under 4.5V and also never over 5.5V.
These numbers are specified by the APA102 manufacturer as the Minimum and Maximum operating voltage range.
Take these measurements under the maximum LED brightness you intend to use. Use this information to decide how to correctly distribute the power to all your LED strips.

I would definitely not inject power every 10 meters, it is most likely to make your problem worse. I would actually recommend injecting every meter if possible or maybe every 2 meters, 3 at most I think.

Start by measuring the voltage at the 2 power supplies. Remember you MUST connect the GND wires of both power supplies together but the +5V wires from both power supplies MUST remain separate !!

The red flickering is often caused by under power due to voltage drop along the strips but in the case of APA102, many here also report problems with clock/data degradation over very long strip lengths. But they report problems when they increase the Mhz and you say your problem is worse when you decrease the Mhz. That is actually very strange but leads me to believe it is a power issue. Did you mean to say that you want to decrease the refresh time !?!?

It is not easy to answer your question about the Teensy 3.2 It certainly can control your 3000 APA102 but every controller has limits and it really depends on what else you need to do apart from updating the LED data at a certain FPS.

9

@JP_Roy
Hi Roy, its been a while and i’ve done bits and bobs here and there. So here goes…

My injection of power is every 5 metres simply because the LED strips come in 5m strips and they are, and I need them to be waterproof.

All the LEDs are powered at 5V. I ordered some power supplies from Alibaba which are 12V. I ordered 12V because I am supplying power from up to 15m away and with 5V the Voltage drop meant it was about 3.5V at the entry point for the LED strips, thus I now have 12V but at the entry point I have a buck converter to reduce it to 5V. So all the LED strips are operating at 5V.
I have tested it with the rainbow pattern and I can operate it at full brightness, and I also tried with plain white as well and all is good. When measuring at the beginning and end of all the strips, the voltage never dropped below 4.90V and was always below 5.0V too.

So onto the problems -eek–The red flickering exists, so if i have the mhz set at 15mhZ, (I assume this is the refresh time? my terminology is not perfect so please do correct me), it flickers but it is not awful, anything below that, so 14 down to 0mhZ, the flickering is so bad some bits just turn into a strobe of multi coloured lights. If I go higher, so 16mhZ+ then there is no ‘redness’ but very slow.

And finally, I only need the fps to be as high as possible, however I feel something is going on that I am now overlooking. More than likely do do with power.
I did 5m, turning on all the lights and it took 0.25s to light up from the first (LED0) to the last (LED149) LED.
However when I do 10m, it takes 0.97s, 15m(2.16s), 20m(3.82s), 25m(5.95s), 30m(8.55s), 35m(11.62s), 40m(15.16s), 45m(19.18s) and 50m(23.65s). It is taking far too long over any distance greater than 5m.

The reason I feel is power related because I changed to the 12V power supplies, in the past i used the Meanwell LRS-350-5 and I could light up 100m in about 12s, this one is obviously going much slower. Am I missing something really obvious? Would the power supply and buck converter be doing something? Or is ir something else? I can show you the code if that would help, but my code has not changed, so I don’t think it is that.

Thanks for the help and sorry for an essay!

Tej

10

@Tejkaran_Samra , Ok, since the voltage does not drop below 4.9 Vdc anywhere in your setup, you have effectively dismissed my initial assumption that you had a power distribution issue. Great work !!
I would describe the 15 Mhz as your clock rate or data rate, not your refresh rate. I understand ‘refresh rate’ to be FPS which is the number of times in a second that you can update all the LEDs data in your setup.
Now I am confused with your problem description specially with the fact that lower clock frequencies behave worse than higher clock frequencies and specially your statement: “… so 16 Mhz+ then there is no ‘redness’ but very slow.” How can the faster clock be slower ???
Note that, I am not the best person to help you with APA102 clock rate issues (actually something that many here within this forum have complained about) as I have never used them myself in any build, only the WS2811/WS2812 types. One solution to clock instability that I have read about is to change the actual CPU speed on the Teensy from 96Mhz to 72 Mhz but I do not know if that will do anything but worth a try.
I also do not understand it when you state… " I could light up 100m in about 12s" !? Are you describing a whole animation time here or the time it takes for your LEDS to simply turn on !? Read the comment from Daniel Garcia above, you should be able to turn on all your LEDs, even 10,000 LEDs in much less than a second !
I suggest that you repost your issue again such that others with more APA102 specific experience can participate. I would also suggest that you post your code on github.

11

“And finally, I only need the fps to be as high as possible, however I feel something is going on that I am now overlooking. More than likely do do with power.
I did 5m, turning on all the lights and it took 0.25s to light up from the first (LED0) to the last (LED149) LED.
However when I do 10m, it takes 0.97s, 15m(2.16s), 20m(3.82s), 25m(5.95s), 30m(8.55s), 35m(11.62s), 40m(15.16s), 45m(19.18s) and 50m(23.65s). It is taking far too long over any distance greater than 5m.”

Can I see the code that you’re using to test this? I have a suspicion about what you’re doing in here. If you are lighting the leds one at a time, and then lighting the next one and counting the time from when you light the first led until you light the last one, you have two multiplicative effects happening to your time.

If that’s what you’re doing, then when you go from 5m to 10m, two things happen:

  • The time it takes to write each frame doubles (because you’ve gone from 150 to 300 leds)
  • You are writing out twice as many frames.

This means there’s a 4x multiplier over your original timing (0.25s to 0.97s tracks to this).

When you go from 10m to 20m, you have that 4x multiplier happening again (which, again tracks to the numbers you’re reporting above). 20m to 40m, again, another 4x multiplier in time. Etc…

At 50m, at 30 leds/meter, to light each led in sequence in 1s is going to be 1500fps, and since each frame is 1500 leds, that’s 2.25 million rgb led updates/second. Given that each apa102 requires 32 bits of data to be written, you’re looking at a data rate of ~72Mhz to be able to maintain that - which is 3-4 times higher than I’ve seen anyone pull off with the APA102.

Your timings tell me that you’re running at closer to 3Mhz, which tracks to if you’re bit-banging as opposed to using hardware SPI.

It really would be helpful if you posted your code (http://gist.github.com or pastebin, not here, please).

12

@JP_Roy
Thank you for the help, really do appreciate it. I would love to be able to help you with anything, although I feel like you are more knowledgeable in this area than I am, however if you ever need me for anything seriously do not hesitate to ask.

@Daniel_Garcia
You got it correct in that I am lighting up one at a time, I will post to GitHub tomorrow morning as I am just going to sleep(in from UK) and I’ve never posted to Github…
Do you think it can go considerably quicker?

13

Do i think what can go considerably quicker? If my description of what’s going on is correct, what’s slow here is your animation - you’re driving 1500 leds at 65fps at the moment - but as I mentioned, I suspect you are using software SPI to drive the APA102’s, not hardware. For 1500 leds, you should be able to get up to 100-200fps if you run the hardware SPI at 12Mhz. maybe 300 or 400 if you can drive the hardware SPI at 24Mhz - though, as many folks here have discovered, attempting to drive APA102’s at high data rates causes its own set of problems.

For < 10ms timing, you want a minimum of 100fps. (Each frame is 1500 leds, each led is 32 bits, so that’s 48,000 bits per frame - at 100fps you need a data rate that’s at least 4.8Mbps assuming you’re spending 100% of your time pushing led data, since i’m assuming you’d want to spend some of your CPU time building the frame data to push out to the leds, it’s more like a minimum of 10Mhz. This is really all just pretty simple/straight forward math).

All that said, however, there is a limit to how much I can help you further without seeing your code, as I can’t rule out the possibility that there’s something you’re doing in there that’s exacerbating things.

14

@Daniel_Garcia
I understand what you are saying, but I don’t know how I am controlling via software as opposed to hardware. Could you elaborate on this? Or link me in the right direction (I will do some Google/FastLED research whilst I wait for your reply)

My code is here (https://gist.github.com/Tejkaran/7b87619eddcdb9f3072eb5bb503b507d) - if you think there is a way to better or if I am doing something which is hindering the speed, then I am open to hearing what you have to say.

15

So, you’re defining the data rate incorrectly - see the difference between my line 16 here - https://gist.github.com/focalintent/78eb3411de3b879c8600ff276a000470#file-lighting-up-one-by-one-L16 - and yours (you should also look at https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging again ) - but this is why when you would set that number lower it was messing things up - also, the number that you used directly (without passing it through the DATA_RATE_MHZ macro) corresponds to a roughly 1.5-3Mhz data rate on the teensy 3.x

16

ah ok, thank @Daniel_Garcia
I have sorted that out now…such a small error!
however the red lights/strobing of multi coloured lighting is now coing up at fasted speeds (>8Mhz). Is there a reason for this?

17

Hi @Tejkaran_Samra , as I mentioned before, I do not have any hands-on experience with the APA102. The RGB LED things I have built so far would not have benefit enough from the higher frame rates (FPS) or the faster PWM frequency and the WS28xx are still typically a bit cheaper and bit easier to assemble (3 wires is just simpler to deal with than 4 wires in complex assemblies)

That being said, I have had a few ideas that would definitely require the use of the APA102 devices and I have been motivated to follow the problems reported within this forum regarding using higher clock rates in projects that had a considerable amount of LED (1000 and more…)
I do not claim to have the definitive answer to this issue but will give you my conclusions to the best of my understanding…

Each APA102 regenerates both the data and clock. The clock -in signal is actually just inverted out within each device, no other manipulation is done with the clock signal. It would seem that the clock signal is degraded after each device ever so slightly such that the cumulative effect of this may even become visible in the LEDs at the far end of long strips.
Faster clock/data rates makes this problem worse. Longer strips makes this problem worse. The problem is more apparent in strips, I guess due to the inherent trace impedance of very long parallel traces. Possibly, some strips perform better than others but that has not been verified clearly.
So conclusion, if you are using strips, there is probably not much you can do to eliminate the flickering problem at the far end of strips apart from lowering the clock/data rate.

18

@JP_Roy @Daniel_Garcia
With the clock signal being degraded, what is the cause of this, and is there any way to reduce the degradation in any way?
Because it would suck to come so close and fail here!

19

Have you heard of any rumours of methods which may help?

20

I have not - I divide things up into shorter strips so I can use a higher data rate on each - you’ll have to experiment with your wiring and setup to find the data rates that work for you.