Use of LEDs

[francesco-vannini]

The RGB LEDs also don't seem to provide too much of a different light when displaying orange or red, I would assume this is true for many of the colour combinations you could achieve. Maybe worth rethinking what can these LEDs can/should actually do or be used for by possibly providing only combinations that will make sense and not the full spectrum of RGB combinations. When running down the battery it turns on the red LED when < 50% (looks more like orange). No change when charge level drops below 15%. I suppose you cannot differentiate between orange and red with this 3-color LED. Description of red (level < 15%) in the hardware README to be deleted?

[shawaj]

Is there an actual practical reason that we can't have the full spectrum? Maybe we need to use software pwm or something

[francesco-vannini]

The reason is simply that with this type of LED you really cannot distinguish Orange from Red let alone other more tenuous shades of Red for example. I think these LEDs are good for Red, Green and Blue, their dimmed versions, whatever blinking version but nothing too elaborate, certainly not worth investing time in a full colour picker like the one you see on graphical tools. Most probably a predefined set of configurations that we know make sense and are actually visibly defined. Colours: Red, Green, Blue, Purple, and a few more Brightness Everything else could be left open on the API so that someone really keen to get Orange instead of Red can still do it in code as well as choosing behaviours like blinking, etc.

So to answer your question there is no other practical reason aside from the typology of LEDs chosen.

[shawaj]

RGB is RGB. You can get the full spectrum of colours by either using the PWM functionality or controlling intensity of each colour.

The colour picker and general configurability of the LEDs is something we promised. So even if it doesn't work especially well I would like to include it.

I honestly can't see why it wouldn't work...

[tvoverbeek]

Have you tried it? The position of the individual color leds in the housing makes this (= any color) nearly impossible. For instance giving the green led a lower value than red makes the green led invisible.

[shawaj]

I don't have a PiJuice ATM so no!

But sure, I understand what you're saying but we still ideally need to give the options, even though they may not work well.

But from the other thread it appears this is already implemented just not when you are using the LEDs for battery indication as you said.

I guess the colour might "mix" better with a diffuser.

On 18 Jan 2018 20:53, "Ton van Overbeek" notifications@github.com wrote:

Have you tried it? The position of the individual color leds in the housing makes this (= any color) nearly impossible. For instance giving the green led a lower value than red makes the green led invisible.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/43#issuecomment-358745379, or mute the thread https://github.com/notifications/unsubscribe-auth/ADNCumU0tmbCzypP5psBv88csbQHOyBWks5tL5M7gaJpZM4RimxC .

[mmilann]

Color mixing is not linear because of LED driver implementation where all 3 LEDs share same current limiting resistor and than LED with lowest voltage (red) can dominate for same pwm duty circle. This can be enhanced by software using linearization look-up tables or similar derived experimentally.

[tvoverbeek]

@mmilann Thanks. Would not worry about it now. This (for me) is a minor issue which can wait till later.

[shawaj]

Agreed. It's a nice to have - one for a bit further firm the line once the core stuff is sorted

[shawaj]

*down

[francesco-vannini]

Absolutely not a major issue at all, just noted things down for reference and discussion really

[shawaj]

Yeah, better to have it to remind us than not :-)

[shawaj]

@wikipedia555 do you think this is something we can implement in future versions?

[ryanteck]

Is it woth updating the guide to state that you can't see the difference between 50% & 15% or is the 50% state un-programmed?

During some more testing I don't notice any orange state at all.

[tvoverbeek]

@ryanteck It is controlled by the RGB settings for D1. Orange is both R and G on. With R=60, G=60 you do not see a difference (See milans explanation in an earlier comment). Try with R=60, G=80, B=100 for D1 (CHARGE_STATUS). Then there is a difference between "pseudo orange" and red. With the default settings you do not see a difference. Caveat: I am slightly color-blind

[ryanteck]

The only issue is, if maybe we could instead then have either a different middle colour or adjust to say Green for 100-21, and red for 21-0.

Primarily because it looks red from such an early stage it looks like it's almost faulty. Or maybe we could adjust the documentation?

As for orange being a tricky colour I understand (My PC has quite a few RGB lights and Orange never looks quite right).

I'll do some playing around after this test I'm doing with my Pi Juice Zero is done and see if I can get something that looks orange enough for it to be different.

[GekoCH]

would it be possible to set the range by our self so that we can have a green led for 20-100% and only a red one below 20%? Or is this already possible by using a custom code somewhere?

[rdragonrydr]

I've personally found the LED settings 50/55/60 work well for R/G/B myself to see all the colors clearly.

That said, I too would love to be able to more easily customize crit low/low/high/charge colors, myself...