Ok - if the tilde ~ is defining a lowest to highest range, then the numbers still come out good for the current PIO code
Ok - if the tilde ~ is defining a lowest to highest range, then the numbers still come out good for the current PIO code
I’ve seen this on some datasheets before, they use it instead of a hyphen, so it means shortest to longest.
You’d think the low would complement the high, and this is the case on older WS2812 datasheets, but not our newer Bv5 ones
That T1L time is very odd then, and by calculation is not correct for the PIO timing.
The Pico T1L pulse time calculates out to 375nS, and this is shorter than the defined T1L time on the WS2812Bv5 sheet of 580ns.
I guess that there may be some little leeway somewhere as the Glowbits definitely work !
I just tried tweaking the frequency value in the spreadsheet to see if there is a useful setting that brings the timings fully into spec. … short answer No.
So it would need to be a rejig of the PIO instructions, jumps, and delays to ‘get it right’, and probably different classes for Glowbits and the older neopixels.
“Unfortunately” is the word here. You would find that this “CRO” (or just oscilloscope these days as the “CR” or “Cathode Ray” part is long gone) is the most useful instrument on the workbench. The modern digital device will measure almost anything you want except for resistance and a couple of things requiring a multimeter. For instance if measuring a pulse train you can display on screen P-P V, Max V, Min V (wrt ground), Period, Frequency and Duty Cycle very easily. Once you get used to using it you will wonder how you managed without.
If you are doing a fair bit of developing or experimenting getting one of these instruments is highly recommended if you can afford it, although these days a pretty fair instrument is not that expensive. Although nice, you don’t need an all bells and whistles 4 channel 200MHz instrument. 2 channels is handy though. I have a very modest 2 channel “Atten” brand with a bandwidth of just 25MHz and I find that pretty adequate. The secret is recognising any limitations. As a matter of interest I believe that for the novice user the lower bandwidth is preferable as with the high bandwidth instruments the user can see and worry about things that do not matter and are actually introduced by things like the earth clip on the probe in the wrong place or earth lead being too long introducing ringing etc which disappears when the probe disconnected.
If you can, get one. As I said if you are going to dabble in electronics extensively you won’t be sorry.
Hi Murray and all.
Just wanted to loop back with some tests (I’m doing a Neopixel/GlowBit project and thought why not)
PS: Very interesting notes on the code though!
I may have stitched you up here, in previous tests 120ohm always worked for me though it might have been luck, depending on the resistors tolerances…
I replaced the 120ohm with a 220ohm (between the Pico and LLC and experienced the ape… erratic patterns coming through.
I don’t have a scope either but speculate that the transistor isn’t completely turning off causing the odd pattern.
I also did confirm the behaviour with this circuit.
I was big time wrong on putting resistors on the MCU side, a 220-120 ohm resistor inline from HV - the Din pin of the first Neopixel.
Possible explanation/reason it should go on the HV side
No scope either here so speculative on the transistor.
With the resistor divider on the HV side the benefit of inline current resistance is still present:
When logic high - each side is pulled up with the transistor, the LLC is in a non-conducting mode (high-impedance puillup), low chance of damaging the pin
logic low - the transistor conducts, if there is significant line-capacitance the voltage will go negative, damaging the pin. The inline resistor should minimize ringing(very much depends on the wire used)
Hi Liam et al,
I have the gear back from the event now, and will try changing the resistor values and position again to see if it behaves better/differently … watch this space —> <—
We gotta nail this down
This topic sparked a bit of interest, thanks for sharing your findings!
Interesting findings regarding the PIO timings, that spreadsheet is excellent!
I’ve had success with both Neopixels (WS2812B, and SK6812) and Glowbits(WS2812Bv5) with the default Pico code, there would most definitely be some tolerance built-in, though it is frustrating that it isn’t all documented.
Electrically if you’re after the most robust and long-lasting solution I’d go with something featuring a comparator and/or amplifier rather than just a FET/transistor with pull-ups.
There are a few options in the Core range, just be sure to look for a triangle in the block diagram of the datasheet:
- 74AHCT14 - Logic Level Inverter / Level Shifter | Adafruit ADA3877 | Core Electronics Australia (note the inverted logic)
- TXB0104 Bi-Directional Level Shifter - TXB0104 | Adafruit ADA1875 | Core Electronics Australia
The comparitors have a high enough input impedance such that the pin on the microcontroller wont be damaged and boosts the logic level, still keep that resistor close to the Din pin on the Neopixel.
@Liam120347 's solution should work perfectly for Maker projects
Running some tests now and going to borrow a 20MHz oscilloscope tonight.
I have setup the links like this now
pin 18 --------- LV – HV ----- 120R -------> Glowbits
pin 19 --------- LV – HV ----- 120R -------> Neopixels
pin 20 --------- LV – HV ----- 120R -------> 3W RGB LEDs
The Glowbits use the default state machine SM0, the neopixels use SM1, and the 3W LEDs use SM4 (ie in the other PIO block)
At the moment - the Glowbits still work 100%, the neopixels ‘seem’ to be behaving better visually, and the 3W LEDs are still only lighting up the first 3, and appear to lockup at a high intensity, instead of obeying the commands to drop intensity (using Brenton’s modified library), and also ignoring the command to display the ‘black’ colour …
I can lockout any of the initializations and associated execution code by grounding any of the following:
- gpio2 - disable the Glowbits
- gpio3 - disable the neopixels
- gpio4 - disable the 3w LEDs
so I can run any of the arrays independently without any interference for other state machines. This code has been present throughout.
More results after tonight …
hmmm and will also run the standalone test code soon also without any of the other code from the event system … PiicoDev rangefinder, MP4 player, and occasional bursts on the second core.
Standalone test code results - note I have placed the test run inside a 5 cycle while loop
- Glowbits - 100% as expected
- neopixels - works… but they flicker. I can see the test patterns running along the pixel string, but I see a lot of flickering throughout the string. Visually I think that they are flickering simultaneously but I would not put money on it, it is hard to watch 30 pixels at the same time.
- 3W Leds - If I said that they ‘start the sequence’ and then choke up - this would be the best description I can give. At the end of the run they should be off (colour BLACK) but they are still on. The best result with these is 2 (sometimes 3) LEDS lit, an initial colour change in the lit LEDs, then either twitchy flickering or frozen on a colour.
FYI these are he arrays in use (NB the 50 unit string has been cut down to 30 pixels, and there are 4 off the 3W LEDs in that system)
p.s. there is a single 1000uf 10v cap across the 5volt and ground rails at the voltage feedpoint to all the LEDs
And an interesting followup - If I run one of the three test routines, and then a different one, the results go haywire - le I just ran the 3w LED run, then ran the neopixel test and it has gone awry.
Pixels locked on, bad sequences etc
Doing a clean run from powerup - the neopixels behave as previously described.
These 3W LEDs, how many are in the string. They are 3 W each and you would not want too many running before you run out of puff with that 5V 4A converter. Might be why you get part way along your string and stop. Each led at 3W would be 0.6A so as the description on Core web site says you should allow at least 0.5A per LED. You say you are running about 25% (I think I saw that somewhere) but if a PWM system is used to control brightness which I strongly suspect is the case Your AVERAGE current will not be as high but your PEAK current will be 0.6A and this is what your supply has to cope with. So I very much suspect that you are simply running out of puff.
Devices in the system
- 1 off Pico
- 1 off Piicodev Range sensor
- 1 off PiicoDev Cap sensor
- 1 off DFR0768 MP3 player
- 1 odd 3V3-5V level shifter
- 4 off Glowbit sticks (total 32 LEDs)
- 1 off neopixel string (30 pixels long)
- 4 off 3w LEDs
all powered through the 4A 5v buck converter (20 W capable, heatsink mounted)
From some measurements (on the bulk 12v input side) - with everything enabled, the input current to the buck converter is just under 1 Amp == about 12 watts.
Last full system run actuals: 0.73A peak, 9.4W peak with Glowbits, neopixels and 3w Leds enabled and lighting up.
Currently (sic), I am not cutting off power to each Led array, just the state machines are not initialised and thus no active control signal.
I will setup a way (not too messy I hope) to be able to completely power down the deactivated arrays to see if the ‘standby / quiescent’ power draw is affecting things.
Ok quick test - I unplugged 3 of the 3w LEDs, and ran the main program - same overall result …
More testing tomorrow - have a meeting to go to.
As a matter of interest how did you measure the peak current or have you managed to get hold of an oscilloscope. I think it would be outside the scope of the average workshop without one.
I have an inline power meter that I use with my 12 v amateur radio gear. Gives me V, A, Watt (now) , peak, W peak etc
Have borrow oscilloscope for tests tomorrow.
That will not be fast enough to measure peak current. At best it will be measuring some sort of average
You will need a 0.1Ω resistor (Jaycar have them) in series with the power line. The down side here will be the voltage drop at higher currents. A better option may be a meter shunt. These should be marked with Milliohms or Millivolts per Amp. It does not matter which side of the power line it goes in. The negative or earthy side might be best and safest. Best if you can remove the mains connection from the oscilloscope, I have a short (300mm) length of mains extension with the earth disconnected from one connector and the earth wire hanging out so it is obvious. Connect the oscilloscope across this resistor and measure the voltage peaks then calculate current. If you can’t disconnect the mains earth make sure you insert the shunt or resistor in the ground side of the supply and connect the oscilloscope earth clip to the negative or battery side of the shunt. If your 12V supply and your set up is isolated from mains earth you should be OK. Don’t let the case of the oscilloscope touch any of your set up just in case.
While you have this instrument connect it across the 5V and see what is happening there. If the supply is not coping you will see the 5V sag in rapid reductions if it can’t supply the current. The 4A capability of your buck converter might just be struggling a bit.
I have a couple of 5M strips of neo pixels I used for Xmas lights driven by Arduino Pro Mini and I use a 5V 14A power supply and have not looked like having a problem. A supply of this size is not too many $$ and for running LEDs etc is a good investment.
The metering device used on the 12 volt supply side is linked below.
Note that the system built was powered by a 12 V AGM battery on a Scout camp. 240 V power was not accessible, and I was budget limited. Initial design had separate 4A 5v buck converters for the individual Neopixel and 3w LEDS, in addition to a supply for the pico.
Calculations indicated that I should be able to supply the required power (with PWM limits as mentioned) from the 20W available from a single converter.
The assumption was that it would act as a hard supply (no sag), but if it was actually soft, then your comments could hold true. Testing continues.
Unfortunately, I think there are a few things fighting you(us now ) at the moment, don’t let that discourage you though!!
I was able to replicate the weird patterns with a 5V 6A mains switchmode supply by powering the Pico through Vsys and Vbus (far more noticeable with Vsys) - everything runs fine from USB, and voltage levels on a DMM are acceptable to run the strip both on USB and supply power.
I still reckon its got something to do with the FET’s though, I’ll try and get my hands on a scope and help nut this out!
I’ve ordered a couple of 74AHCT125 - Quad Level-Shifter (3V to 5V) - 74AHCT125 | Adafruit ADA1787 | Core Electronics Australia to see if that helps
NB: Busted a couple of Pico’s trying to make too much happen at once, relearnt lesson 1 of troubleshooting, add one thing, test and repeat…