To date we haven't considered power consumption n the badge. Our goal is for the badge to run for 80 hours on 3 AA batteries to that it survives DEF CON. All software and hardware work has been to address functionality and to build the best hardware we can. Now that the badge is becoming more and more real it was time to address power consumption.

Until this week, the badge has been running at full 72mhz even during delays for animation and waiting for user input. This created a relatively constant load of about 70mA. Based on the STM32F103 datasheet 40mA of that was simply going to the MCU. We are also powering the RFM69 and 4 WS2812B LEDs.

This week we implemented a low-power delay function into the badge that drops the clock frequency down to 6 mhz temporarily. This is the slowest we could reliably get the MCU while still maintaining the RFM69. It's only being used by the Matrix animation but the other delays will soon be switched.

Not bad.

These results are far from scientific as we are not doing a great job at isolating variables. The values were measured as peaks on a multimeter and may have been when the RFM69 was handling packets in the background. The 100% White Glow test was by far the worst case we observed while measuring the badge. Values typically hovered around 69-70mA without the LEDs on.

What's interesting is that by varying the LED brightness from 100% to 40% we are able to save about 33 mA or 8.25 mA per LED (we're using 4 on this design). 40% looks great so it is now our default brightness.

Next steps are to optimize the remaining code, especially any code that blocks for user input, disable unused peripherals, and to try to put the MCU into a deeper sleep waiting for interrupts.