RGB Brightness after SLEEP_MODE_DEEP

I’m developing a battery-backed application where my Photon wakes up from sleep periodically to check the state of a couple of switches before going back to sleep. I do not need the internal RGB LED, however it appears that RGB.control(true) does not get me access to the brightness or color early enough in the wakeup process to prevent a single bright flash of white light every time the device wakes.

Here is a code snippet that illustrates my problem. The STARTUP and setup codes try to do the same thing but that was just debugging to prove each setup area was getting called.

// don't automatically connect to the cloud


void earlyStartup() {

void setup() {

loop() {
    // check switches then sleep

Any thoughts?

AFAIK, the brightness setting should be persistent.
Have it set once should cause it to start of in that brighness next time.


So try setting RGB.control(false) after you dimmed the brightness and see if the term “persists” refers to a system restart or only for that one session.


Thanks! I’ll take a look when I get home tonight. I have read the quoted section a number of times and never interpreteted it as you are suggesting. I read it as “this setting persists [even] after RGB.control() is set to false…” instead of “this setting persists [only] after RGB.control() is set to false…”

I can confirm that this is not working for the above scenario. Adding RGB.control(false) does not persist the setting in my configuration. I’m running firmware 0.6.0 and still get a bright white flash at bootup, regardless of brightness settings… brightness during operation after the initial bootup is working as expected. New bug?

Too bad :weary: Thanks for checking!
But for your battery life this shouldn’t matter too much 10mA over 100ms should be neglible - but still it would be nicer to have a way to keep that setting at least retained across deep sleep phases.
Maybe not a but, but worth a “proposal-issue”

You could use a hot air rework tool to remove the RGB led if you really want to get rid of that power consumption.

At 10ma x 100ms it would take approx 36,000 wake sessions to consume 10mAh from the battery so probably not worth pulling that LED off :smile:

1 Like

Thanks all. It seems like an oversight in the firmware perhaps, I’ll look into proposing an enhancement… but I took a look at the source code last night expecting to see a relatively linear and straightforward implementation of a simple RGB controller, however it appears at first glance to be anything but.

As for my options now, I could certainly take a destructive approach, but obviously that is sub-optimal. For my application the light is just an annoyance… intended to be a bedside remote switch for home lighting with the RGB LED used as a status light, the bright white flash lights up the entire room, making it more than just a little bit annoying.

I’m willing to put in some effort to work on the firmware, but I am a bit lost. Conceptually, it could be as simple as making the initial brightness a “retained” variable, any ideas where to start?

edit: out of curiosity, where are you getting the 10ma x 100ms estimate from?

Looks like down in the UI_Timer_Configure function in hw_config.c there is a bunch of stuff configuring the PWM outputs. Looks like the initial configuration is to set up the PWMs as all high (or low?) by default, but I can’t decipher the low level functions. Thinking this is the key, channel 1, 2, and 3 appear to be the red, green, and blue channels for the RGB output.

/* PWM1 Mode configuration: Channel 1, 2 and 3 */
TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_PWM1;
TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Enable;
TIM_OCInitStructure.TIM_Pulse = 0x0000;
TIM_OCInitStructure.TIM_OCPolarity = TIM_OCPolarity_Low;
TIM_OCInitStructure.TIM_OCIdleState = TIM_OCIdleState_Reset;

TIM_OC1Init(TIM1, &TIM_OCInitStructure);
TIM_OC1PreloadConfig(TIM1, TIM_OCPreload_Disable);

TIM_OC2Init(TIM1, &TIM_OCInitStructure);
TIM_OC2PreloadConfig(TIM1, TIM_OCPreload_Disable);

TIM_OC3Init(TIM1, &TIM_OCInitStructure);
TIM_OC3PreloadConfig(TIM1, TIM_OCPreload_Disable);

Help! In just about over my head and drowning…

As you said, it was an estimate, but a rough one.
According to datasheets it’s actually less than 2mA ((3.3V - 2V) / 1k + (3.3V - 3V) / 1k + (3.3V - 3V) / 1k) (Vorward drop RGB 2V/3V/3V) and an oszillograph of the flash shows it’s more like 30~40ms with a duty cylce of 66% - so I was way over.

Instead of 1mAs we are looking at more like 40~50µAs :wink:

BTW, the timer responsible for the RGB LED is TIM2 channels 2, 3 & 4


One non-destructive workaround for the annoying flash used by others was to use a black sticky tape or nail varnish to cover the LED

Great analysis. Thank you[quote=“ScruffR, post:9, topic:27909, full:true”]
One non-destructive workaround for the annoying flash used by others was to use a black sticky tape or nail varnish to cover the LED

I had planned my design around using the internal LED as an indicator, so complete blackout is undesirable. I may just download the whole source tree and then poke around locally. Good stuff, thanks!

You could opt for a slightly translucent tape/varnish

Yes that’s a good point. Or a dab of opaque hot glue. Hadn’t considered the manual dimming, which is an obvious choice.