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.
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
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 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)
Neopixel string lit but totally failed to display anything correct
3w RGBs failed to light at all
I have gone completely off neopixels !
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.
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 )
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!
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
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. 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
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
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.
Cheers
Jim
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))
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 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 3.2.2.1 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.
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 ???
)
Ain’t technology wunnerful, expecially when it bites you!
