Detecting LED vs. RGB LED

[dmpayton]

Hey MicroPython folks! I'm in a bit of a pickle of a jam, and could use some help.

I've been working on building IOT air quality monitors with a local environmental nonprofit. We've been using the Wemos C3 Mini (v1.0.0) with the latest MicroPython 1.19.1, and we've distributed about 50 of 'em in Central California.

Wemos recently started shipping a new version of this board, v2.1.0, which is fine, except for the LED differences – the 1.0.0 boards shipped with a single blue LED, while the 2.1.0 boards have an RGB LED, and both boards have the LEDs on pin 7. There's not a lot that's changed in the schematics, other than the antenna and the LED.

On the v1.0.0 boards, I was using the blue LED as a general system status indicator, pulsing and blinking for various tasks and errors. I'm really hoping to be able to use the RGB LED on the newer boards to also indicate air quality at-a-glance.

My code needs to support both versions of the board because OTA updates pull from the same git repo and it feels crazy to run separate builds just to control an LED.

I was hoping to find a way to differentiate between the boards – a version number or something, somewhere in sys, os.uname, esp32, etc – but have come up short. I was wondering if there's some way to, I dunno, inspect the pin to see how it behaves so I can determine the board version and use the right led driver at runtime?

I'm a fair bit stuck on this right now, so any tips, ideas, suggestions or general advice would be super appreciated! Thank you!

[robert-hh]

You could try to set Pin7 to INPUT mode and read back the input value. Maybe there is a difference between the two boards. but chances are low. So the only choice would be to put some kind of configuration file on the board, telling which led to use, or use two different small python scripts to lite up the LED.

[cve2022]

Is the board assembled over a baseboard? If affirmative, depending on what is connected to pins A0 to A5, you could try detecting the board type, as the order of these pins is different. Or you could add some pull-up/down resistor to one of the pins on the boards with the newest module and detecting the level by setting the pin's internal pull-down/up.

[sosi-deadeye]

You could use a simple DIP-Switch to set the hardware-configuration.

[jimmo]

@dmpayton Wow, that's quite a frustrating change!

You would need to test this, but perhaps you could just assume that it's the 2.x hardware and drive the neopixel, but then leave the pin in the state suitable for the 1.x hardware. i.e. When you want to change the LED state, send the appropriate WS2812 signal (using the neopixel module, or machine.bitstream directly), then leave the pin high or low.

I'm pretty sure the WS2812 won't care about the state of the pin being left high or low.

[pdw-mb]

Neat idea! I think you will probably need to set the output low for ~300us before sending a new WS2812 signal in order to avoid the long "1" being treated as the first bit of the next value.

If you were planning to drive the simple LED with PWM rather than on/off, it gets a bit more interesting but I think you could make it work.

[dmpayton]

I really like this idea! I posted an update below with my (current) solution, but I'd love to explore this idea in the future. Unfortunately, I'm using PWM to fade and pulse the LED, so that should be an adventure. :)

[dmpayton]

Thank you all for the suggestions, there are definitely some things I want to try in a future hardware iteration!

@mattytrentini was kind enough to respond to me on Twitter, suggesting to set the pin to output high, switch to input, and time the voltage drop. Here's my implementation:

def led_voltage_drop():
    pin = machine.Pin(7, machine.Pin.OUT)
    pin.on()
    pin.init(machine.Pin.IN)
    start = time.ticks_us()
    while pin.value() != 0:
        continue
    return time.ticks_diff(time.ticks_us(), start)

Open to any suggestions, but here are the results so far:

INFO:main:Wemos C3-Mini: 1.0.0
INFO:main:lead_voltage_drop(): 11587
INFO:main:lead_voltage_drop(): 13487
INFO:main:lead_voltage_drop(): 13731

INFO:main:Wemos C3-Mini: 2.1.0
INFO:main:lead_voltage_drop(): 2617
INFO:main:lead_voltage_drop(): 2726
INFO:main:lead_voltage_drop(): 2628

There's definitely an overall difference between the two, and the numbers appear consistent across a few boards of each version that I've tried. Huzzah!

It should now be just a simple check to get the version:

def board_version():
    # 8,000 is roughly in the middle between the two LEDs
    if led_voltage_drop() < 8000:
        # Usually < 3,000
        return '2.1.0'
    # Usually > 10,000
    return '1.0.0'

Does this seem like a reasonable solution and implementation? I'm newer to EE (my background is mostly web dev), so I don't know if there are any other considerations that should be taken into account here. Is there anything else that might affect the voltage drop duration, causing my code to set the wrong version?

[mattytrentini]

Just a quick note to be wary about strictly relying on behaviour described in the datasheet - there are so many WS2812B clones that all differ in slight ways as soon as you stray from the norm!

[robert-hh]

I just made a test with a neopixel ring.
The WS2812 update when they get a proper pattern. They do not need a reset, and my test code does not apply a reset. And when the LED's are displaying, the reset pulse does not change anything. The WS2812 ignores any longer 1 or 0 level at the input, which does not look like a data frame.

[cve2022]

I just made a test with a neopixel ring.

Would you mind sharing your code? I am curious to test overhere with pico and esp32. Would save me some time coding from scratch.

[cve2022]

Just a quick note to be wary about strictly relying on behaviour described in the datasheet - there are so many WS2812B clones that all differ in slight ways as soon as you stray from the norm!

I tend to agree, things may go awry when we use undocumented features that can change any time for an authentic part, even worse for clones.

[cve2022]

I'm surprised they re-ordered the pins. That seems like an unnecessary breaking change especially if there is no way to read the board version.

My guess is they have some baseboard or shield for which the original pinout of the SPI (left) does not work and that was fixed with the new version (right).

[robert-hh]

Would you mind sharing your code?

See below. I used a SAMD51 board. Pin D13 has a simple LED on the board. So the script fills the neopixels, blinks 3 times the LED, clears the neopixels, blinks the LED three times, ......

import time
import machine, neopixel

pattern = [
    (4, 0, 0),
    (20, 0, 0),
    (80, 0, 0),
    (200, 0, 0),
    (100, 0, 0),
    (30, 0, 0),
    (10, 0, 0),
    (1, 0, 0)]

def run(delay=500, neonum = 24):

    led = machine.Pin("D13", machine.Pin.OUT)
    np = neopixel.NeoPixel(led, neonum, timing = 1)
    for i in range(5):
        for j in range(neonum):
            np[j] = pattern[j % 8]
        np.write()
        for l in range(3):
            led(1)
            time.sleep_ms(delay)
            led(0)
            time.sleep_ms(delay)
        np.fill((0,0,0))
        np.write()
        for l in range(3):
            led(1)
            time.sleep_ms(delay)
            led(0)
            time.sleep_ms(delay)

[cve2022]

I was guessing something in the line of what you described above as the cause of the issue.

On my board, I need to add time.sleep_us(60) to get the LEDs in sync. Would be interested to know what it takes on yours.

With mine, it takes 70us for it to work properly in a consistent way (it fails sometimes with 60).

Adding led(1) to the ESP32 code does not cause the issue with one exception: only the very first pattern, after I stop the running code (with Thonny) and restart it again. The next patterns are OK without the lag.

[pdw-mb]

I'm not familiar with the ESP32, but I can see that the bitstream implementation is quite different and uses a feature called RMT, which I suspect cancels the pin mode of the GPIO pin, so the led(1) call isn't actually doing anything. Try calling machine.Pin(N, machine.Pin.OUT) immediately after np.write() and before led(1).

[cve2022]

I'm not familiar with the ESP32, but I can see that the bitstream implementation is quite different and uses a feature called RMT, which I suspect cancels the pin mode of the GPIO pin, so the led(1) call isn't actually doing anything. Try calling machine.Pin(N, machine.Pin.OUT) immediately after np.write() and before led(1).

FWIW whatever the driver does after the RMT ends transmitting, the LED I added for the tests blinks.

[pdw-mb]

FWIW whatever the driver does after the RMT ends transmitting, the LED I added for the tests blinks.

Ah, I hadn't realised you had a test LED. I guess it can't be that then. Would be interesting to know what the output looks like on a scope. Otherwise, it might be worth doing a crude timing check using ticks_us() to see if the np.write() is noticeably slower on the ESP32.

I had a play with this over the weekend on an RP2040 board, and got it working nicely with PWM, and had two LEDs fading in and out together on the same signal. As you'd expect, max duty cycle is limited by the LED latch time, although for 70us latch time and 1kHz PWM, you can get up to 93% duty cycle, which is pretty usable. It also needs a gap of the latch time inserting before the WS2812B data.

[cve2022]

Ah, I hadn't realised you had a test LED. I guess it can't be that then. Would be interesting to know what the output looks like on a scope.

Here you go. To avoid cluttering the post, I will post few images. The blue trace is from a GPIO I added to synchronize the scope. It is set right before the np.write() and reset right after it:

        sync(1)
        np.write()
        sync(0)

ESP32

The delay between the sync GPIO set and the data stream start is 256us. The delay between the data stream end and the sync GPIO reset is 104us (notice that the yellow trace goes to high level right after it).

Here, one bit of the data stream (notice the 1.25us bit width):

RP2

The delay between the last bit of the stream and the output going high is 10.6us, against the 100+ us of the ESP32.
The bit width is 1.24us, basically identical to the ESP32's

That is it. Nothing much to add so I think it is my last contribution to this topic. 😃 .

PS: just for completeness, test code

It is the same for both ESP32 and Pico, except for the GPIO pins (0 and 1 for the latter).

import time
import machine, neopixel

BR = 5
pattern = [
    (BR, 0, 0),
    (0, BR, 0),
    (0, 0, BR),
    (BR, BR, 0),
    (BR, 0, BR),
    (0, BR, BR),
    (BR, BR, BR),
    (0, 0, 0),
    ]

def blank(np = None):
    if not np:
        led = machine.Pin(13, machine.Pin.OUT)
        np = neopixel.NeoPixel(led, 24, timing = 1)
    np.fill((0,0,0))
    np.write()
    time.sleep_ms(1)

def run(delay=500, neonum = 24):
    led = machine.Pin(13, machine.Pin.OUT)
    sync = machine.Pin(15, machine.Pin.OUT)
    sync(0)
    np = neopixel.NeoPixel(led, neonum, timing = 1)
    led_dly = int(delay/8)
    blank(np)
    for i in range(16):
        for j in range(neonum):
            np[j] = pattern[(i + j) % len(pattern)]
        sync(1)
        np.write()
        sync(0)
        led(1)
        for l in range(8):
            led(1)
            time.sleep_ms(led_dly)
            led(0)
            time.sleep_ms(led_dly)

blank()