Pixelblaze v2 power consumption when controlled by FireStorm using WiFi?

UPDATE: found some estimates online while researching this question, see below (worst case estimate, 300 mA)

I am hoping to use PBs to both drive some six 1-2 meter APA102 (“dotstar” style) 60 led/m strands, and additionally to drive a much larger 20-26 meter web of the same type of strands. In all cases I was planning to run power to the PB from a common source, not to use the current passthrough to power strips FROM the PB.

So at a minimum, 7 PBs & independent strands (but I may trying breaking down the web into separate cascades instead of running lots of power lines in parallel and figuring out some kind of logic level amplifier - the https://www.tindie.com/products/EssenceEng/fajardo-led-data-isolator/ ?).

My question is this: ideally my 7 PBs will be remain constantly connected to the wifi network hosting the FireStorm server, but each board will be mobile so will probably end up dropping off the network from time to time, or encountering poor signal throughput.

Given unreliable be desired wifi connectivity, what is a worst-case upper limit estimate of the power consumption I might expect from each PixelBlazeV2 board independant of the the power consumed by the attached LED strands? I couldn’t find the power figures in the docs, maybe I missed it (I know nothing about ESP8266 yet, but imagine most users here already are familiar w/ ballpark estimates).

Answers from quick googling:


power consumption of ESP8266 in different states - table by Espressif_Kelly / bbs.espressif.com/


to quote from Thorsten von Eicken / jeelabs.com:

As mentioned in the first episode, the esp8266 consumes close to 200mA peak when transmitting, which is a lot of power. The key to reducing the power of Wifi systems is to turn the radio off, and then to also turn the processor off in addition.

The 802.11 standard has had a power save mode for a long time that is built on the periodic beacons sent out by access points (APs). Each AP sends out a beacon announcing itself typically every 100ms. In addition to announcing the presence of the AP the beacon can carry “TIM” flags that tell associated clients whether the AP has queued a packet for them.

To be precise, the waking-up does not happen for every beacon at the standard 100ms interval. Instead APs have a “DTIM” setting that determines for how many beacon intervals the AP queues packets. A popular setting is 3, which means that packets are queued for 3 intervals, i.e. 300ms, allowing clients in power save mode to wake up only every 300ms to examine the beacon.

The trace shows that the esp8266 often is in low power idle mode and wakes up very briefly at least every 300ms to check the beacon for waiting packets. Sometimes there must be a packet and it turns the receiver on for approximately 100-200ms before it goes back into power save mode. The average power consumption depends on how often the AP has a packet for the esp-bridge.

The esp8266 and Espressif SDK implement an even lower power state called “light sleep” where the CPU is switched off and the chip consumes 0.6mA. In this mode it wakes up either from a timer or an external pin change. The documentation is not very clear but it appears that waking up on an incoming character on the UART is not possible in this mode, making it difficult to use with the esp-bridge.

Follow-up question: any advice regarding FireStorm wifi AP configuration to balance connectivity with power-saving features?

In particular Thorsten von Eicken / jeelabs.com mentioned that

  1. 802.11 wifi APs send out an announce beacon that contains TIM flags, if necessary, telling which clients to wake up and recieve packets, and

  2. the frequency of this beacon can be varied, typically between 100 - 300 ms.

What is a reasonable configuration for 10 PixelBlaze clients connected over wifi to a FIreStrom server?


The 300ma figures would be for short bursts, for an average figure closer to 60-100ma. I haven’t tested power consumption under really poor conditions, but the 300ma figure sounds OK for a worse-case number, depending on what you are using it for.

Usually the power draw from PB is dwarfed by the LEDs.

Firestorm remembers the last command and will normalize any PB reconnecting after dropping. I haven’t tried it in extensively poor wifi environments or with moving targets, so I’d be interested to know how this works for you. From what you describe, I’m imagining bikes or art cars or something.

The sync timing happens once a second, and compensates for jitter. Commands sent from Firestorm to Pixelblaze are sent immediately as soon as the server receives them, at least to the OS/network stack. This is all very low bandwidth, and not incredibly latency sensitive, so I would expect any common configuration to work well.

I don’t usually dig much deeper than that (unless somethings broken), so I’d be interested to know about your findings there too, if you get into optimizing for a lot of commands or really poor wifi.