Maximum Number of Neopixels (RGB/RGBW)?

[codmpm]

Hi @jclement,

nice work. Could you give us more Specs?

• How many pixels are the maximum?
• Sample of how to wire this up?
• Do you use a 74AHCT125 for Level-Shifting from 3.3 to 5V?

Cheers, Patrik

[ctrowat]

I'll chime in with my experience:

• I have run it with 244 pixels on the front of my house. Power consumption is approximately 40W and I am using a PC power supply to provide 5V at multiple points along the LED strip to avoid sagging voltage
• I connect the RX pin of the ESP to the DIN pin of the LED strip using a 180 ohm resistor located at the LED strip itself. +5V and GND are provided from the power supply at many points along the strip. I also use a transistor connected between the ESP and the power supply to turn on the power supply when required, and also a voltage divider from the power good signal to an input of the ESP so it can report when the power supply is on
• I do not use a level shifter. Everything I have read says that they are REQUIRED yet I have had no issues at all driving my LED strip without one

I'll put together a drawing of how the PC power supply is connected to the ESP when I have a few spare minutes, but there isn't too much to it.

[codmpm]

This is great to know, thank you!

I currently have an installation with 1650 RGBW Neopixel driven by an ATMega 1284p for the needed RAM. The Stripe is fed with 10A/5V power supplys every 4-5m. Could you tell how much RAM is needed by the neopixelbus on your Installation with 244 Pixels and how much free RAM there is left on the ESP8266?

I've just followed the Adafruit NeoPixel Überguide. On every power supply input is a 1000µF Capacitor as mentioned. I've already made tests using the level shifter to convert 3.3V logic to 5V - worked like a charm. I'll have to test with 3.3V data input.

And, while we are at it, can someone tell me why the pixelcount ist set to -1?

[ctrowat]

For finding the maximum number of pixels that can be driven you might want to reference the NeoPixelBus project, in their FAQ I think I recall them listing a theoretical maximum of around 3000 LEDs. Since this project does other things the actual limit will be lower but I don't know for sure how much lower.

If I correctly understand the situation 1650 RGBW LEDs is equivalent in memory to 2200 RGB LEDs which would be near but should not exceed the limits of what an ESP8266 can do with NeoPixelBus.

With 244 LEDs I am showing about 34K of free heap on the ESP while running an animation. We have a test strip running 56 LEDs and it typically shows about 37K of free heap.

For power I initially had about 850uF of capacitors at the feed point of the string but since I am powering it with a PC power supply I figure there is sufficient filtering in there for me to not have to worry about it with only an 8A draw.

[codmpm]

Thats exactly what I'm talking about. NeoPixelBus afaik needs one byte per color per (RGBW-)pixel. So this will be:

1650 x 4 = 6600bytes

That's why I'm using the ATMega 1284 as it has 16k of RAM.

The problem now is, and you should correct me, that in the worst case on an animation the doubled amount of ram is needed and I want to know if I can use an ESP for my application as the ATMega is fairly on his limits as I try to do concurent networking.

[ctrowat]

Depending on the mode you use in NeoPixelBus the memory usage gets quite a lot higher. We are using the async UART DMA method, which means it needs to first store the LED data in memory, then decompress it into another section of memory before making the system call to start the UART reading it. When the LED data is copied for the UART to access it via DMA the LED data is expanded 4:1, so first you need your 6600 bytes for raw LED data, then also another 26400 bytes for the decompressed version for a total of 33000 bytes.

See here for more information: https://github.com/Makuna/NeoPixelBus/wiki/FAQ-%237

They list a maximum for RGBW LEDs of 2250 LEDs. Since the animations don't take up much memory I suspect you won't run out of memory with your LED strip but I do wonder how the performance would be as we have not tested with such a long strip. I know the rotate functions in neopixelbus are somewhat bulky which is why I have been working to rewrite some of the animations not to require them.

[codmpm]

Ok, Then my next task is to build some hardware to drive the 1650 pixels and try this out :)

Thank you so much! Many things are clearer now.

[codmpm]

Could you point me out which Pin is RXA as mentioned in the readme? I have an Olimex ESP and some generic ESP12's. Can't find RXA on there neither in the nodeMCU documentation... t

[ctrowat]

Pin mapping is always tough between variants. It's the hardware UART receive pin. We are using NodeMCU V1.0 clones here and for us it is labelled RX^ which I guess got entered as RXA at some point in the documentation. According to this drawing it is GPIO3. Does that help?

http://justjibba.net/content/images/2016/05/NodeMCUPinout.png

[codmpm]

That is more clear... Thank you.

Just stumpled over https://github.com/jclement/esp_lightingnado/blob/master/src/main.ino line 280 which, if I'm right, uses GPIO4. But whith hardware uart GPIO3 should be correct.

[codmpm]

Works! GPIO3 it is with a 220Ω resitor. Which command turns the stripe off?

From the NeoPixelBus example btw:

// For Esp8266, the Pin is omitted and it uses GPIO3 due to DMA hardware use. // There are other Esp8266 alternative methods that provide more pin options, but also have // other side effects.

[ctrowat]

If you send any invalid mode command it will turn the strip off. For now I am using the message "0"

[codmpm]

Already tried this, just stops the animation. But I have to be patient, tried it with RGBW pixels in RGB mode.

Thank you guys for your work. Looks very promising 👍

[ctrowat]

from main.ino:

    case '0': // OFF
      digitalWrite(PIN_PS_OUTPUT, LOW);
      delete(currentMode);
      currentMode = NULL;
      currentModeChar = '\0';
      mqttClient.publish(topic_status_mode, 2, true, "Off");
      strip->ClearTo(RgbColor(0,0,0));
      strip->Show();
      return;

It looks like I was wrong when I said "any invalid mode command" but "0" is definitely coded to blank the strip

[codmpm]

Maybe just confused it with an empty string...

Cheers!

[ctrowat]

To respond to your earlier comment about the pin number in the NeoPixelBus call please refer to the NeoPixelBus FAQ:

https://github.com/Makuna/NeoPixelBus/wiki/NeoPixelBus-object#neoesp8266dma800kbpsmethod

The NeoEsp8266Dma800KbpsMethod is the underlying method that gets used if you use Neo800KbpsMethod on Esp8266 platforms. There should be no need to use it directly.

The NeoEsp8266Dma800KbpsMethod only supports the RDX0/GPIO3 pin.

I suppose the pin argument should actually be omitted in this case but since it is ignored at least it doesn't hurt anything!