Driving neopixels using the glowbit library on a pico

Hi all,

Is there some ‘magic’ settings to successfully drive neopixels ? I have having very mixed success with them. Did follow the Adafruit uber guide to set them up.
And they are all objects of Stick.

stick = glowbit.stick(numLEDS = 32)  #default pin and sm
neo = glowbit.stick(numLEDS = 50, pin=19, sm=1)
led3w = glowbit.stick(numLEDS = 4, pin=20, sm=2)
  • work ok then stop working
  • work ok then start to display random / incorrect colours
  • just do random stuff
  • only light up first few leds even though the number is correct
  • seem to ignore colour info, just show white on the first few
  • odd flickering of the ones that are lit

NB the Glowbit seem to do the right thing …

Glowbits on default pin 18, sm 0
Neopixel string on pin 19, sm 1
3watt neopixels on pin 20, sm 2

Even if trying to run one set only, with the other objects not created, still having issues


Hi Murray,

I just had a refresher read through the datasheets, software should be the same between GlowBits and any other WS2812b (Neopixel).

It sounds like it might be hardware - the Glowbits accept down to 3.3V consistently but the older chips not so much, if you have a logic level converter I’d try boosting the level to 5V and see if that works.

These seem like symptoms of the logic-level/power supply

These few sound like it might be grounding - would it be possible to grab a photo of your setup Murray? I’ll see if I can replicate it on my end :slight_smile:


Hi @Liam120347
I am using a level shifter 3v3 → 5v on the data, and all LEDS are powered on 5V. And there is a common ground buss for the pico and all the LEDs

I will dig up a photo asap - (family tea ATM)



Hi Murray,

Sounds like it should be working, another quick validation would be to test the ‘raw’ WS2812b code for Pico: How to use WS2812B RGB LEDs with Raspberry Pi Pico - Tutorial Australia


HI Liam,

I will try that code tomorrow
Here are some pix … Data from Pins 18-20 (gry,wht,blu), 3v3 power on orange wire from Pico,
PiicoDev Cap sensor and MP3 player in the middle, Level shifter and power buss (5v and Gnd)

Closeup of level shifter side. Orange is 3v3, yellow is 5v

Closeup of the 5v power buss side. Power entry on the right, all power to pico, and the LEDs though this. All grounds tied here.

Power is from a 12v → 5v 4 amp buck converter, LEDS running at ~ 25% power most of the time.


Update: Ran the test code …

  • Glowbits 100%
  • Neopixel string lit but totally failed to display anything correct
  • 3w RGBs failed to light at all

I have gone completely off neopixels ! :nauseated_face:

Not enough time to test and develop … overall better solution would probably had 3 Picos - each only concerned with their own LED system, and a master pico / pi to control the lot … and time to develop each system standalone first.


Hi Murray,

I think I may have spotted it - the resistors inline with the HV side of the logic level converter will create a voltage divider with the pull-ups built-in (one ‘section’ from the LLC below)

It’s been a while since I’ve read the Uberguide but I recall making the same mistake a few times (from recent designs and experimentation the resistors go between the Pico pin and LV side of the LLC, limiting the current from the pin to not burn them out)

Defs worth breadboarding something before going to a soldered protoboard/PCB (speaking from experience :frowning: )
Another quick test you can do is, define the Pico pin as an output and make it HIGH then test the closest point to the LED Din pin as possible (for the older ones if you’re getting more than 3.5V I’d say its something odd, above 3.5V and that should be reading in as a logic HIGH)

You got this Murray, I’m keen to see what you’re making!


Hi Liam,

Unfortunately it is past the time to fiddle more as the gear is being packed tomorrow, and I have just done the load of ‘main.py’ to the pico, with it working as good as it gets… I (might) get a chance to cut and shut the wires and reinstall the resistors but I that is a very tentative maybe …

From what you have said you think I should go from this (A) to this (B) … quick ASCII art follows

(A) pin 19 --------- LV – HV ----- 470R -------> neopixels …

(B) pin 19 ------ 470R ----- LV – HV --------> neopixels …

Interesting discovery though, the pullup and the ‘strongly suggested’ resistor ‘close to the neopixels’ from the uberguide, creating a voltage divider and defeating the overall purpose of the level shifter.
:upside_down_face: Ain’t technology wunnerful, expecially when it bites you!


Hmmmm … That discovery might explain something similar that a friend experienced where a signal ‘mysteriously’ became intermittent/dodgy after working well in test when checked with his CRO, but which failed when the controller was linked via a level shifter to the high voltage side actuators. It was a ‘bigger’ upshift than here and a custom but similar level shift circuit … I believe they had to go to opto-isolators and a completely different approach. At least he had time :slightly_smiling_face:


From the uber guide - the resistor is there to “help prevent voltage spikes” …

Is the resistor necessary if using a level shifter??? I can think of answers on both sides yay and nay …



Hi Murray,

Unfortunately without doing a lot of measuring there isn’t really a clear coverall answer.
The voltage spike that it mention is caused by a fast-rising/falling signal and line capacitance, in general its definitely good practice but the value should be considered project to project (470 might be a bit much, I like to add a 120ohm after the MCU pin to make sure it doesn’t burn out the pin, the strip itself is easy to replace, there miiiight be a clamping diode internally on the GlowBit’s???)

Oooooooooh yeah

And unfortunately that is the project killer, its a bit late for this project - but Zack Freedman’s videos are a godsend IMO: https://youtu.be/72a85tWOJVY


Hi Liam,

Had time to hack out the 470R resistors AFTER the level shifter, and install 120R resistors BEFORE the level shifter.
Result with test script:

  • Glowbits - still batting 100
  • Neopixel string - working slightly better, but still missing commands
  • 3w LEDs - working somewhat now, but like the neopixels missing commands - especially the led3w.pixelsFill(0); led3w.pixelsShow() to turn them OFF!!!



Hi Liam,

Great video :slightly_smiling_face:

Thanks for all your help - photos etc of the Borg cube in action in situ sometime next week … also I will finish (soonish after that) the project write up


Not all programable LEDs are the same. Neo Pixels may use an older LED.
The data sheets show minor timing differences between variations of LEDs. (0.05us to 0.2uS)
This may not seem like a lot, but when the serial data is over an number of LEDs it could miss time bits. Hence some LEDs work others do not.

Adafruit Arduino libraries work with Neo Pixels in every case I have tried not necessarily with Glowbit.
The Python libraries work with Glowbit not with Neo Pixels.

You would need to use different software drivers for the Glowbit and the Neo Pixel.
That’s my conclusion from what is in this post.


PS I should try some of this, I have the parts, would be interesting.


Hi James,
That would explain a lot ! Especially with the 50 pixel string … it does run now with the change to the resistor placements but (to put it politely) goes somewhat ape… during attempted updates. I will try to detail the ‘patterns’ in the project writeup.

I wonder if the PIO statemachines fix is ‘just’ a simple change to the frequency setting - this is the setting from the test script (and the glowbit.py library), but I suspect that it may be a different instruction timing step sequence …

sm = rp2.StateMachine(0, ws2812, freq=8_000_000, sideset_base=Pin(PIN_NUM))



WS2812 Datasheet

WS2812B Datasheet

The ‘B’ version is 800kHz exactly for a 0 and 1. In fact they are just opposite of each other.
The other version is 869kHz for 0 and 769kHz for 1.

The Arduino Neo Pixel library uses assembler code to write 8 bits each time with delays in between.
The Python Glowbit library uses assembler but … I don’t really understand what it is doing, my programming skill is not up to that level.

If the Neo Pixels use WS2812B LEDs they really should work with the Python code.
But the products Core Electronics lists for Neo Pixels state WS2812 5050 LEDs.
The Glow bit ones list WS2812B.

Unsure if this is relevant, I was just looking for something as to why the Neo Pixels don’t work properly.



Hi Jim,
Interesting difference, and odd as well. And if the timing needs to be incredibly precise then there could be a start point …

FYI I will be out of touch until Monday ( on Scout Camp with the Borg Cube and it’s wacky LEDs )

I need to learn more about the Pico PIO system and the statemachines



Hi Liam, James, and Jim,
I have done some digging … and some hopefully accurate understanding of RP2040 PIO calculations w.r.t. the differences between required timings for the WS2812 and the WS2812B versions of the RGB leds i.e. neopixels vs Glowbits

The T1, T2, and T3 values are from the 3 versions of code I looked at - the Glowbit library, the test code from How to use WS2812B RGB LEDs with Raspberry Pi Pico - Tutorial Australia
and section of the Raspberry Pi Pico C/C++ SDK manual (which I suspect is the original source of truth).

Hopefully this screen shot shows it all … .the timing for the older WS2812 leds is way off… and I have tried adjusting the values for T2 and T3 to see if I can get into spec - but no. At least one value still falls out of range.
I think that a new neopixel formula and PIO code is needed. I am not up to that ability yet.


Hi Murray,

Brenton did a short dive into PIO in the video linked below, I found it super useful when using PIO to get around a PWM limitation on the RP2040:

If you have any questions, I’ve written a bit of PIO assembler for a project, so let me know if you need a second set of eyes on your code :slight_smile:

Do you have access to an oscilloscope or logic analyzer to confirm your timings are coming out as expected?

@Liam pointed out to me that you may have missed the v5 designator on our GlowBit products, datasheet below:

Lemme know if this gives you more questions :slight_smile:

1 Like

Hi James,

Interesting video from Brenton - more PIO training for me … and confirmed the freq=xxxx value actually sets the PIO to operate at that frequency (assumed from other doco, but not yet found the absolute statement, given that the C/C++ code is very different w.r.t. this value setup)

Unfortunately I dont have either tool (CRO or analyzer) sigh… just trying to crunch numbers

Hmm on page 3 of the datasheet, I believe that the T1L value is incorrect ?!? Should it not not be like 220ns~380ns ?? And is the tilde ~ their form of +/- range? Or are the values the shortest to longest allowable values ???

Murray T