ATOM Lite with different LED controllers for internal LED?

[XXL-Wing]

Hi,

I have a very strange pheomenon here...
I use an ATOM Lite as temperature monitoring node.
The system status is displayed by using the single RGB LED the ATOM Lite has on its front.

Now here is the story:
The code I have written performs very well on three of my 5 ATOM Lite nodes and shows the correct behavior of the RGB LED (e.g. blinking blue when temperature is below a defined threshold).

Two other ATOM Lite I have behave very strange and do something completely weird with the exact same code.
Different colors, brightness etc. Looks like the controller misinterprets the data sent because it is a different type of controller.

Do different pieces of ATOM Lites have different LED drivers built in? If so what is the correct way to handle this across multiple nodes?

I am using the Adafruit NeoPixel Library for controlling the LED.

thanks in advance
Mike

[ajb2k3]

Shouldn't do as the controller is the ESP32 chip and not a separate device.
Is there a power issue or a source of interference near the misbehaving Atoms?

[mtylerjr]

This wont be much help but about 5 years ago a company I was working for had a product we were developing, with a number of RGB leds on a small custom board. May have been 6812's..

Anyway, they are supposed to work up to 85c, but one of our suppliers in China must have given us dodgy LEDs, or the board assembler let the heat get too high. A significant percentage of the LEDs would either fail and not come on, or would go to some random color after a few hours of our own burn-in test (just powered up, all units hanging on the wall). I forget if we changed led suppliers or board assemblers.

But these LEDs can be temperature sensitive during assembly. I wonder if there was just a bad batch.

I would email m5stack directly, just in case it is a known issue and they need to be replaced.

[XXL-Wing]

All the ATOMS I test on the exact same spot on the table.
The misbehaving ones just show wrong colors and do not blink, whereas the "good" ones behave right.
Exact same code, exact same setup on the table.

Looks like a hardware issue or other LEDs that need different data formats.

[ajb2k3]

@xxl-wing Have you tried swapping the LEDS from the misbehaving units to the good controllers?

[XXL-Wing]

If I try to solder the bad ones off and solder them to the good modules they are for sure broken :-)

[XXL-Wing]

Boiled it down to minimalistic piece of code to avoind any sideeffects...

Here is a link to 2 different Atom Lite pieces running exactly the same software as shown below.
https://photos.app.goo.gl/KBm54aqW5LbtxsWq7
This video shows them side-by-side.....
They dow not in any direction behave at least a little bit similar.....

Any ideas anyone?

This is running on the Atom Lite now:

#include <Arduino.h>
#include <LiteLED.h>

// Choose the LED type from the list below.
// #define LED_TYPE LED_STRIP_WS2812
#define LED_TYPE LED_STRIP_SK6812
// #define LED_TYPE LED_STRIP_APA106
// #define LED_TYPE LED_STRIP_SM16703

#define LED_TYPE_IS_RGBW 1
#define LED_GPIO 27
#define LED_BRIGHT 100

static const crgb_t L_RED = 0xff0000;
static const crgb_t L_GREEN = 0x00ff00;
static const crgb_t L_BLUE = 0x0000ff;
static const crgb_t L_WHITE = 0xe0e0e0;

LiteLED myLED( LED_TYPE, LED_TYPE_IS_RGBW );

void setup() {
myLED.begin( LED_GPIO, 1 );
myLED.brightness( LED_BRIGHT );
}

void loop() {
myLED.setPixel( 0, L_RED, 1 );
delay( 500 );
myLED.setPixel( 0, L_GREEN, 1 );
delay( 500 );
myLED.setPixel( 0, L_BLUE, 1 );
delay( 500 );
myLED.setPixel( 0, L_WHITE, 1 );
delay( 500 );
}