Neopixel library quirks

klimbot · February 25, 2021, 11:26am

Hi all,

I’ve run in to some issues working with the neopixel library with different hardware, but same ESP32 main board. I’m using the WS2812E versions of the ‘Neopixel’ LEDs. The issue I’m having is the classic bright green first LED.

Originally I thought it was a hardware issue as I was powering the LEDs at 5v but using 3.3v logic, but since I’ve tried a logic level converter and am seeing the same issues.

Couple of things I’ve noted:

I’ve tried the same FW on different two different esp32 dev boards, one works well the other does not. I’m not using either dev board anymore but my own custom one, and I’m having the same issues.
With the dev board that wasn’t working with with MOS library I’ve been able to use an Arduino library that has the LEDs working as expected. Same thing here for my custom dev board - works with the Arduino lib but not MOS

Unfortunately I don’t have a scope to be able to check the signal, but seeing as I’m using the same hardware I’m guessing waveform shape is probably OK. It’s probably timing issues I’m guessing.

Some things to note between the MOS Neopixel library and the Arduino NeoPixelBus library:

Both use bitbang to talk to the LEDs
The Arduino lib uses portENTER_CRITICAL when bitbanging.
MOS lib does not use anything special when bitbanging
Link to the NeoPixelBus lib where the bitbang happens
Link to the Neopixel lib where the bitbang happens

I’d appreciate any suggestions on what to look at next, my thought was maybe enable/disable interrupt during bitbang but I’m just guessing. I’m not too experienced here.

Thanks

scaprile · February 25, 2021, 1:19pm

Did you happen to connect an oscilloscope and observe the signal ?
If you have a custom board and you did not pay enough attention to trace routing, you might encounter all sorts of strange stuff. The mOS lib might working faster than the other and just putting that in evidence

klimbot · February 25, 2021, 8:59pm

Unfortunately I don’t have an oscilloscope. Might be time to by one.

I doubt it’s a routing issue because I can change libraries and it works. Thats the most frustrating bit.

Interesting, I did note that the arduino library was working at a higher resolution that the mOS lib (at least double) and so I’ve been wondering if that might be causing me issues.

@scaprile do you have any thoughts on disabling interrupts during the bit bang operation?
I’ve attempted to add it with no success:

void mgos_neopixel_show(struct mgos_neopixel *np)
{
  mgos_gpio_write(np->pin, 0);
  mgos_usleep(300);
#if MGOS_ENABLE_BITBANG
  mgos_ints_disable();
  mgos_bitbang_write_bits(np->pin, MGOS_DELAY_100NSEC, 3, 8, 8, 3, np->data,
                          np->num_pixels * NUM_CHANNELS);
  mgos_ints_enable();
#endif
  mgos_gpio_write(np->pin, 0);
  mgos_usleep(300);
  mgos_gpio_write(np->pin, 1);
}

scaprile · February 25, 2021, 9:27pm

It is quite likely that mgos_bitbang_write_bits() is already taking care of what is needed to keep timing and system stability (in fact it is already disabling interrupts)
The library works OK as far as I know, unless you are able to actually see what is not working, I can’t guess, it works for me.

klimbot · February 26, 2021, 9:03am

What type of LEDs are you using? Are you interfacing directly with the LEDs or do you have an LED strip?

missed that

klimbot · February 26, 2021, 9:48am

While I don’t have a real scope, I forgot I had one of these that I never really used. While it’s not been good enough in the past to really show anything other than yes/no this thing is working, it may be good enough here:

From Arduino library:

From mOS Neopixel library:

Now to work out what to do about it…

klimbot · February 26, 2021, 11:01am

So the mOS demo C app for Neopixel works as expected, with the waveform looking like this:

The only difference I’ve seen after loading/checking the waveforms multiple times for the mOS apps with either my code or the demo neopixel code is the large spike at the start. Seeing as the first pixel is the one thats set green constantly I guess maybe it makes sense that this is the cause of the issue?

scaprile · February 26, 2021, 1:34pm

Unfortunately I don’t know the answer beforehand because I didn’t have the need to check the datasheet and understand the protocol. If I would bet, it is likely.

Are you using/setting your pins for other purpose ? (That could explain your “spike”) Are you missing an initialization somewhere ?

Regarding the hardware, 3x0.5 = 1.5; that thing looks like someone is draining too much current from the I/O (if my guessing can somehow approach an educated guess, as I don’t know where that measurement came from).

klimbot · February 26, 2021, 9:16pm

I might eat my words, but I think this is an artefact of the poor sampling rate of my device. This signal should definitely be close to 5v, here is the circuit I’m using to convert the 3.3v signal to 5v:

I think there might be something here… when I mess with the T0L/T0H/T1L/T1H values and add more to them than what I calculate is required I start to see something closer to what the Arduino is putting out (but still the annoying spike):

Only thing I can think to do now is to start cutting features out of my project and hope to find where things start working again. Since the base example project is working

scaprile · February 26, 2021, 10:01pm

Your voltage conversion circuit works as long as the capacitance (traces + LED(s)) is small enough to be charged to the proper logic level before the shortest pulse ends; and as long as the load does not cause a considerable drop. If you expect to get a decent pulse train with proper timing out of that… YMMV.
That “scope” doesn’t seem to be exactly an ally… but your spike looks long enough to be taken as a logical 1.

klimbot · February 26, 2021, 10:16pm

I’d generally agree, but I guess I feel like I can make software changes and it works reliably so can’t be that far off. And I’ve had the same problem persist over multiple dev boards and chips.

Might be time to take out that other dev board I mentioned that used to work while the other one did not and have a look at whats happening with that now.

I know right. Might be time for shell out for a real scope

klimbot · February 27, 2021, 12:18pm

And the plot thickens…

Seems as though there is something strange going on the more “load” I apply to my project.
If I run the base neopixel demo the device functions as expected, but as I add more libraries to the mos.yml I start to see the first LED go green at the start of the sequence of operation. Seems as though adding the http-server lib causes it repeatedly.

The most interesting part is though that if rather than just turning the LEDs on or off once in a blue moon but instead I poll them on/off they do exactly what they should be doing. Hard to explain, but basically this video is of the device running a cyclic on/off of the red colour and then me pressing a button that is supposed to change to on/off of the yellow colour. You can see that when I press the button (yellow colour LEDs) the first LED goes bright green.

I’ve borrowed a real scope from a friend, and interestingly the signal doesn’t seem to be hitting 5v. Might need to check my circuit again…

nliviu · March 1, 2021, 12:41pm

The test point is before or after the level converter?

You can try to use the led_strip example from esp-idf which uses the RMT peripheral instead of the neopixel library.

klimbot · March 2, 2021, 8:58am

Great suggestion @nliviu, looks like I missed that the Arduino library I was using had switched to RMT under the hood for ESP32 by default

klimbot · March 9, 2021, 9:32pm

Can confirm RMT is working well.

Not sure what the right way is to properly include ESP-IDF code in mOS, but I clone the repos and added to the path.