Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add optional support for WS2812 RGB LED, fixes #106 #178

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

add optional support for WS2812 RGB LED, fixes #106 #178

wants to merge 3 commits into from

Conversation

ThomasWaldmann
Copy link
Contributor

@ThomasWaldmann ThomasWaldmann commented Feb 3, 2020 •
edited
Loading

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.

ThomasWaldmann
ThomasWaldmann commented Feb 3, 2020
View reviewed changes
multigeiger/multigeiger.ino Show resolved Hide resolved
multigeiger/status_led.cpp Outdated Show resolved Hide resolved
multigeiger/status_led.cpp Outdated
Comment on lines 79 to 96
if(radiation > 1.0) {
col = red;
} else
if(radiation > 0.2) {
col = yellow;
} else
if(radiation > 0.01) {
col = green;
} else {
col = black;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just hardcoded some values for now. Final thresholds to be discussed / defined.

multigeiger/status_led.cpp Outdated Show resolved Hide resolved
multigeiger/status_led.cpp Outdated
Comment on lines 100 to 104
void indicate(float radiation, unsigned int indication) {
// do nothing
}
Copy link
Contributor Author

@ThomasWaldmann ThomasWaldmann Feb 3, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to this dummy we do not need lots of preprocessor boilerplate code at each place where we call indicate().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There could be also serial output here (if there is no LED / LED is switched off).

@ThomasWaldmann ThomasWaldmann changed the title WIP: add optional support for WS2812 RGB LED, fixes #106 add optional support for WS2812 RGB LED, fixes #106 May 7, 2020
@ThomasWaldmann ThomasWaldmann marked this pull request as draft May 7, 2020 23:12
@ThomasWaldmann
Copy link
Contributor Author

rebased on master, fixed some led init issue.

on my hw it still shows wrong colors, maybe a hw issue.

@ThomasWaldmann
add optional support for WS2812 RGB LED, fixes ecocurious2#106
c5c93d7 
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)
  (dark if there is nothing to indicate)

- 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)
@ThomasWaldmann
remove userdefines.h based LED configuration
959c7e7 
needs to be done by iotwebconf config item.
@ThomasWaldmann
init WS2812 LED from main setup(), more logging
cb23903
@t-pi
Copy link
Contributor

t-pi commented May 16, 2021

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 every publish
  • 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);
    }
}

@ThomasWaldmann
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@ThomasWaldmann @t-pi