Feature request for special LED function

ProffieOS
1

Hello everyone. I am looking for some help with a certain function i’d like implemented for the proffie v3. I was told it might be possible through a custom blade style but it might have to be placed into the OS somewhere.

Basically, I would like an LED (blade) that behaves as a charging indicator. It would be hidden in the crystal chamber and only active when a USB is plugged into the board. Ideally it would be neopixel, but due to how the board works an RGB standard LED might be a must, and that is fine too.

The LED would be off when nothing it plugged in, red when charging, and green when charged.

Let me know if this is something you think you can implement and I won’t mind paying for your time. Thanks!

2

In theory, this is relatively easy to do.
There is a relatively easy way to tell if the board is currently charging.
However, it turns out that the signal that is supposed to tell us if the board currently has power from USB is unreliable. This makes it hard to tell if the board is not charging because it’s full, or if it’s not charging because it’s not connected, which isn’t ideal.

There isn’t a style function for detecting charging yet, but it can easily be added in the “Styles” section of a config file as:

class ChargingFSVF {
public:
  ChargingFSVF() { pinMode(chargeDetectPin, INPUT_PULLUP); }
  int calculate(BladeBase* blade) {
    return digitalRead(chargeDetectPin) ? 32768 : 0;
  }
  void run(BladeBase* blade) {}
};

using ChargingF = SingleValueAdapter<ChargingFSVF>;

Fixing the unreliable USB detection problem is harder. I’ve tried a few times, but since I don’t quite know what causes it, it’s difficult to fix.

3

So technically, if I use this I could have a reliable charging indicator, but not a reliable “fully charged” because it doesn’t know if it’s full or disconnected?

So if I use a single LED instead of RGB I would at least get something that lights up when actively charging correct?

Assuming that is correct, could I use a neopixel and future proof myself so once (if) the detector is fixed I can just adjust the config?

4

Actually the more o think about it, I would probably still use RGB led since that’s on the 3.3v pad and would be active with USB only. To my knowledge, if the kill switch is off, the USB would not power a neopixel properly.

Still, I would wire up the red and green diode, use red for charging, and once (if) the other problem is fixed, I can use the green.

Does this sound right?

5

The 3.3v pad is on when there is USB power or battery power.

Not true. USB can power a couple of neopixels, just not very many.
Also, I’m confused now, this would be an “battery is plugged in” indicator?

Not sure if there is an advantage to doing that. If you use a neopixel you can just update the style if the other problem is solved…

6

Is there a way to direct the board to specify which neopixel gets the power through USB since it’s limited?

Also is there a way to make it so the 3.3v LEDs do NOT get power when plugged in?

The ultimate goal is (proffie v3):
Red - charging via usb
Green - fully charged via usb
Black/off - unplugged (both with and without power from battery)

I think the current problem is the led still lights up even when unplugged from USB but powered via battery.

7

On a V2 board, things that are powered from BATT+ don’t get any power from USB.
That’s not true for a V3 board though, since the charge circuit feeds everything that is connected to BATT+. Normally this is not a problem, because the leds are off while charging. (Note, there is no function that forces them off, people just don’t normally turn them on while charging, since that would defeat the purpose…)

No.

That is correct.

This is doable with the code posted earlier.

This is harder, since it’s difficult to know if the board is plugged in or not.

It may be possible to fudge it a bit, we could for instance do something like:
When charging stops, we’ll check the battery level, and we’ll show the green light until we fall slightly below that level. (Or charging starts again.) The drawback is that even if you unplug, it would show green for a little while.

8

Okay then how do I make sure the pixels/OLED are not on so I don’t have a bunch of accents going when plugged in? I didn’t know this was a change in the v3. I’d like as little on as possible while charging. Ideally just the soon-to-be red indicator, but I have two accents going through 3.3v pad so I don’t think that’s possible based on your recent reply.

Okay I am up to speed on the rest. The fudge method is not ideal nor clean for commissioned installs so I will just do the red for now and hope a “fix” is able to be implemented and send out updated configs at that time.

9

Two accents isn’t going to make any real difference in charging speed, so I wouldn’t worry about it.
Just let the IDLE_OFF_TIME deal with it.

You could also use the ChargingF function above to dim or turn the LEDs off while charging.

10

So your saying with this function I can turn off the pixels while charging. But I can NOT do that for the accent 3.3v leds? or Can I integrate it there as well?

The reasl reason for wanting them off is less the power consumption, and more the visual. I don’t want a ton of flashy lights while its just sitting and charging.

11

Ok, let me clarify.
The function above can control any LED that has a style. It could be a neopixel, a plain LED hooked up to one of the LED* pads, or a low-power LED hooked up to one of the Free* pads.

However, when you say “3.3v LED don’t get power”, I’m thinking that you mean: “Can we turn off the power on the 3.3v pad on the board”, which is not possible.

But “3.3v LED” can also mean any of:

  • a led where + is connected to 3.3v and - is connected to LED*
  • a led where + is connected to Free* and - is connected to GND
  • a led where + is connected to BATT+ with a suitable resistor to give the LED 3.3 volts.

And for all of these meanings, the style can control the LED.

12

Okay I think I see where the mix up is between my thoughts and what I actually write. Allow me to better clarify. To preface, thank you so much for taking your time walking me through this =)

I am fairly certain my understanding of the current limitations toward my original request:

WANT: LED that is RED when USB charging, GREEN when USB in but fully charged, BLACK when no USB is plugged in.

CURRENTLY POSSIBLE: LED that is RED when USB charging, BLACK in all other states (USB in but fully charged / No USB plugged in at all).

I am content with the currently possible for now. But to take it one step further, I would like to know if the following is possible:

My set up is 2 accent LEDs in control box (red/Green), pixel accent strip (7 pixels), Crystal pixel, OLED, and main blade. The current idea is to add an additional LED or pixel to use as the charging indicator. To my understanding, no problem just use that function.

The “next level” idea, is to instead use an existing LED or pixel for the charging indicator, without losing it’s standard ON/IDLE style set. For example, use the already installed RED accent LED in the control box to indicate charging, but when no USB is plugged in, it will behave normally during ON/IDLE.

This would likely be ideal, but I would only want to implement it if i can ALSO make all the other accent lights BLACK while USB charging. As it is now, it would be too “busy” with all the lights going on their dedicated styles for the idle state, while still having an obvious charge indicator

So the simplified question is: Can I have dedicated styles for ON/IDLE, while essentially having another style parameter override them all to BLACK while USB charging (except the chosen indicator).

13

Yes, the snippt of code posted above lets you do this.

Let’s say you have some style:

StylePtr<Layers<
  Layer1,
  Layer2,
  Layer3,
  Layer4>>()

Let’s say we want to make this green while charging, we would then add a layer like:

StylePtr<Layers<
  Layer1,
  Layer2,
  AlphaL<ChargingF, Red>,
  Layer3,
  Layer4>>()

Now, since I added the layer in the middle, only layer1 and 2 will be “hidden” when charging is occuring. Layer 3 and 4 (whatever they are) will be drawn on on top of the red color when charging. If the AlphaL layer is added at the bottom, then nothing will draw over the red.

Now, if we wanted to make it do something complicated when charging, we can replace Red with any arbitrary style, or we can use Layers<> to make it a stack of layers, like:

StylePtr<Layers<
  Layer1,
  Layer2,
  AlphaL<ChargingF, Layers<
    ChargeLayer1,
    ChargeLayer2,
    ChargeLayer3,
  >>,
  Layer3,
  Layer4>>()

So in this case, ChargeLayer1-3 is shown instead of Layer1-2 when charging.
We can also get fancy with it and add a ChangeSlowly around the ChargingF to make it fade from charging to non-charging and vice versa.

If all you want to do is to make some LEDs black when charging, just replace Red with Black in the layer.

14

Okay, I am going to toy with this. I will likely be back needing some help in “real” use for the config since I usually use fett’s style library, But I want to give it a go myself first.

1st step, add the code in to styles file, then adjust the config styles accordingly correct?

15

Okay I think I am either not understanding the “layers” or how to use the ChargingF style. Here is my simple style:

StylePtr<Layers<Blinking<Black,Green,500,500>,AlphaL<ChargingF, Red>>>(),

And I am getting a whole bunch of errors : Errors - Pastebin.com

16

My fault I think. I got the order of arguments to AlphaL wrong.
Try AlphaL<Red, ChargingF> instead of AlphaL<ChargingF, Red>.

17

Okay that compiled. I will play around with it after work. Thanks!

18

OKay, now the issue is it the function seems to be inverted.

StylePtr<Layers<Blinking<Black,Green,500,500>,AlphaL<Red, ChargingF>>>(),

What this ends up doing, is it blinks green when plugged into USB, and has a steady Red when under battery power with no USB. Technically I can just reverse them, But I would like to know what the issue is so I can implement it into more complex styles.

19

And I also just noticed there is a sort of “artifact” in the green blinking where there is a super brief flash of red every so often.

20

if it’s inverted, it can be fixed by changing this line:

    return digitalRead(chargeDetectPin) ? 32768 : 0;

to

    return digitalRead(chargeDetectPin) ? 0 : 32768;

The blip is probably when the chip is trying to decide whether to charge or not.
Not sure if there is an easy way to get rid of that.