add optional support for WS2812 RGB LED, fixes #106
specific indexes in the LED color time sequence are used for:
-
dark separator indicates "start of sequence" (also used for LED init and re-init)
-
color according to indications (3bits encoded via RGB color) (can be extended to show up to 32 indication bits)
-
white separator indicates "start of radiation display" (also works as LED test, white = R on + G on + B on)
-
color according to radiation (repeated, displayed most of the time) dark (unusually low / 0) green (normal) yellow (more than normal) red (much more than normal)
Still working on this, do not merge yet.
rebased on master, fixed some led init issue.
on my hw it still shows wrong colors, maybe a hw issue.
Just had a quick view. This looks quite complex for a simple LED alarm (if that was the case) - and I admit I don't remember what we discussed a year ago 😄
Proposition:
- Simplify to basically calling
indicate_led(or similar) once everypublish - Calculate the color directly from the dose rate, with
- red starting from now existing alarm threshold
- yellow starting from (alarm threshold - 1/factor), to reflect safety margin represented by alarm factor
- Use a more direct color calculation. Example from CO2 alarm see below. This shifts from green over yellow to red, and the handy 256 blocks can certainly be implemented more flexibly to reflect the config.
CO2 color example:
long get_CO2color(int CO2ppm) {
switch (CO2ppm) {
case 0 ... 700:
// 0xGGRRBB
return 0xFF0000;
case 701 ... 956:
return (0xFF0000+((CO2ppm-701)<<8));
case 957 ... 1211:
return ((0xFFFF00-((CO2ppm-957)<<16)));
case 1212 ... 1500:
return (0x00FF00);
default:
return (0x00FFFF);
}
}
The reason why it looks complex is that it is not only indicating one value (radiation), but also some more state infos from.
So I implemented a small state machine to signal more information serially.
Some color computation like you showed for co2 might be useful. I'll try it as soon as my led shows the colors I want.