RGB Brightness after SLEEP_MODE_DEEP

Troubleshooting
1

Hello,
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
SYSTEM_MODE(SEMI_AUTOMATIC);

STARTUP(earlyStartup());

void earlyStartup() {
    RGB.control(true);
    RGB.brightness(1);
    RGB.color(255,0,0);
    System.enableFeature(FEATURE_RETAINED_MEMORY);
}

void setup() {
    RGB.control(true);
    RGB.brightness(1);
    RGB.color(0255,0);
}

loop() {
    // check switches then sleep
    
    System.sleep(SLEEP_MODE_DEEP,2);
}

Any thoughts?

2

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

https://docs.particle.io/reference/firmware/photon/#brightness-val-

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.

2 Likes
3

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…”

4

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?

5

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”

6

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
7

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?

8

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…

9

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

https://docs.particle.io/datasheets/photon-datasheet/#pin-out-diagrams

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

10

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
[/quote]

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!

11

You could opt for a slightly translucent tape/varnish

12

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