search

OpenSourceEBike / TSDZ2_wireless

TSDZ2_wireless
35 stars 11 forks source link

Update ledalert.c #86

Closed 4var1 closed 3 years ago

4var1 commented 3 years ago

power optimisations

4var1 commented 3 years ago

just going to add the disable for 2nd timer

4var1 commented 3 years ago

ok - good to go!

4var1 commented 3 years ago

@casainho thanks!

@rananna - I have high hopes for this - should have zero power impact when nothing being played - then highest power draw obviously when the led is actually lit - but let's see :)

rananna commented 3 years ago

ok, interesting results, here we go, there will be several comment, I will let you know when I am done.

  1. standby current in main loop: startup

Avg current is 76 uA with ANT running - this is good!

rananna commented 3 years ago
  1. deep sleep current: deep_sleep

0.44 uA - extremely good!

rananna commented 3 years ago
  1. now here is where it gets interesting. I play a Red, green Blue sequence, for each of three intensity levels. for the highest LED intensity: RGB sequence-high

current during pwm ~7ma.

rananna commented 3 years ago
  1. RGB sequence for medium led intensity: RGB sequence-med

ALSO, about 7ma!

rananna commented 3 years ago
  1. RGB sequence for lowest LED intensity: RGB sequence-low AGAIN -about 7ma
rananna commented 3 years ago

So, it seems that there is NO power saving from using pwm to decrease led intensity. Most of the power consumption is due to pwm switching, not led dissipation. PWM frequency may have a bigger impact here.

rananna commented 3 years ago

now, on that theory in mind I changed #define LED_PWM_INTERVAL APP_TIMER_TICKS(1) to #define LED_PWM_INTERVAL APP_TIMER_TICKS(10) lots of flicker! RGB sequence-high10

but NO significant decrease in current!!

4var1 commented 3 years ago

very interesting indeed - great work!

However, if i interpret all this correctly - then we keep pwm - but only for the fact it makes a nicer yellow :)

rananna commented 3 years ago

So, just to see I changed #define LED_CLOCK_MS 50 to #define LED_CLOCK_MS 250 of course the sequences play a lot slower. RGB sequence-high250

But no significant change in current!

4var1 commented 3 years ago

are we driving the led pin at the lowest setting - sorry if that's a stupid question. I noticed when I was reading bits of the SDK that the led is just connected to IO pins and they have different drive levels...

rananna commented 3 years ago

OK, that's it for now.

As it is, the current consumption is minimal as it is only when the leds are flashing. Unfortunately, there is clearly NO power benefit to reducing led intensity as it stands now. However,It is nice to have the ability to reduce intensity and make the intensity for RGB consistent. Any ideas on what we might do to reduce the current when the LEDS are on?

rananna commented 3 years ago

are we driving the led pin at the lowest setting - sorry if that's a stupid question. I noticed when I was reading bits of the SDK that the led is just connected to IO pins and they have different drive levels...

Didn't know that. What are the different drive levels, and how do you set them?

4var1 commented 3 years ago

other than the drive levels for the pins that drive the led - i don't see that we can do much else.

The only thing we haven't tried is upping the pwm frequency when the led is on - then you get even shorter pulses... I'd need to make the pwm bitstripes wider too - so they'd be 32 bits wide for a 32Khz timer - then I can do even dimmer... but based on your testing I don't thing that will do anything

I assume there are ways to get the timer above 16Khz....

4var1 commented 3 years ago

are we driving the led pin at the lowest setting - sorry if that's a stupid question. I noticed when I was reading bits of the SDK that the led is just connected to IO pins and they have different drive levels...

Didn't know that. What are the different drive levels, and how do you set them?

let me find it 2 mins

4var1 commented 3 years ago

https://infocenter.nordicsemi.com/topic/ps_nrf52840/gpio.html?cp=4_0_0_5_8_2#unique_524997740

electrical specs for high drive/standard drive - digging out how that applies to led pins

4var1 commented 3 years ago

@rananna and these are the pin mappings to the LED

edit - correct link -

https://infocenter.nordicsemi.com/topic/ug_nrf52840_dongle/UG/nrf52840_Dongle/hw_button_led.html?resultof=%22%6c%65%64%22%20

I can't find the reference now - but I read posts where people were changing the drive settings for the pins that drive the LED...

Hopefully isn't a red herring...

casainho commented 3 years ago

Try to do PWM on a pin without a LED, just an empty pin. 7mA is to much for a no load pin........

4var1 commented 3 years ago

oh and @rananna what happens now if you put the bitstripe to all 1's - how different is that? Hopefully then at least we know we're better than just turning the led on/off with DC...

4var1 commented 3 years ago

I've an idea that might explain why we see same power for all brightness. I'll test in the morning and report back

On Wed, 17 Feb 2021, 22:00 casainho, notifications@github.com wrote:

Try to do PWM on a pin without a LED, just an empty pin. 7mA is to much for a no load pin........

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/OpenSourceEBike/TSDZ2_wireless/pull/86#issuecomment-780882743, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASRDIVSBJYXCMCUQG54NQULS7Q373ANCNFSM4XY64ZYQ .

4var1 commented 3 years ago

Ok - i'm making some changes - but it's taking a little longer than i expected.

My new changes are based on the (wrong) assumption i made that if a pin was already low - that setting it low again would be low cost from a power perspective. From rananna's testing it would appear that is not the case.

I'm adjusting the code so that pin assertions only occur when there is a state change.

However when I made that change - there were other unexpected results - like green would not light with the lower power stripe I'd assigned.

I hope that when I get things sorted - we should be able to clock slower - and also get dimmer/lower power consumption.

4var1 commented 3 years ago

@casainho - i've submitted a new PR - https://github.com/OpenSourceEBike/TSDZ2_wireless/pull/87

@rananna - hopefully you're not bored yet of power testing :)