RGBW neopixel leds #1807
Replies: 23 comments
-
Posted at 2019-02-07 by @allObjects There is always the fallback solution
@gfwilliams showed me when I had issues (w/ 2v01), see x by y w/ 24 bpp Graphics buffer visualized with neopixel string (conversation), post #7, where colors were off and unexpected pixels showed... The fix is/will be in for 2v02+ |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by Robin Thr 2019.02.07
The above needs clarification as WS2812b are Neopixels, while RGBW are most likely SK6812 Neopixel LEDs. Subtle naming convention. Either one or the other, but not RGBW WS2812b Leds 32 vs 24
Well yes and no. While the Neopixel library referenced using the require instruction does work as described right out of the box illuminating with color, if and only if, the array referenced is in the correct RGB format. If true Neopixels were what was tested, then the output would have been GRB not RGB. > 'If the number of LEDs is divisible by 3, or you pad it' Did you mean the referenced array is three times the size of the equivalent number of Neos in the strip? > 'and create a writeRGBW method' What exactly will this function do? Is the intent to individually address each Neo by way of an array offset or something of the sort? 32 bit data variant? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by AkosLukacs Ok, there are more things to RGB / RGBW leds that I knew :) The "RGBW WS2812B" Leds are from banggood. So maybe the seller knows what exact chip it usess...
produces green, red, blue, and three "white"s. Not visible on the image, but the uC is at the green side. But the library throws an exception if I try to write a single RGBW pixel, because the array length is not divisible by 3:
My
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by @allObjects ...either a separate module or and extra parameter could help with that, I guess. But there is more to it. Did you give the approach as described in post #2 a shot? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by Spocki Back in the days where there was no neopixel module we did this with send4bit(). I had no problems with RGBW led pixels. The pixels are SK6812 with three variants RGBNW (natural white), RGBCW (cold white) and RGBWW (warm white). I used them for a bike lights project. If you add plastic lenses to the chips, they get quite bright ;-) Edit: there's a RGBW neopixel library at Adafruit. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by AkosLukacs Thanks for the comments! I guess didn't make it clear: it's working fine. Sorry for the confusion! Just couldn't find any info in the docs or in the forum (TIL forum search doesn't search in message bodies). Not knowing the proper chip type didn't help either. So I thought just post what I found. Just to find out later, that info was already posted in different threads. These are nothing new after all... @allObjects Didn't try, because it is working with But now I know more about these LED chips, thanks everybody! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by Spocki Here you go. 0b0001 and 0b0011 are approximations of the timings for logical 0 and 1 in the WS2812B/SK6812 spec sheets. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by @gfwilliams
I'm afraid that only works on STM32 - not nRF52s :)
I know - I believe it can be turned on via a checkbox (I think?), but the default is off which is kind of confusing! @AkosLukacs there's absolutely no reason why what you're doing is a problem. I wouldn't add a specific However I just had a quick poke around and the nRF52 code is nontrivial to change and would potentially cause problems if we did that - so for now I have just documented the need for rounding up. I do eventually want to merge this mass of different code. It's basically all doing the same thing (with the exception of the crazy hard-coded one for Wio LTE) so I could make the code that created the bit patterns common - and at that point I'd like to remove that 3 byte limit and also add the ability to invert the signal (to allow 5v logic level output using just a single transistor and resistor). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-08 by @allObjects ...to finish @spocki 's comment
relative to the baud rate SPI is set up. In @gfwilliams 's fall back sulution (see post #2): 3200000. Because: 3200000 / 4 = 800kHz as specified to be the max speed (of today) neopixel strings can be driven. See data sheets:
Surprisingly - or not - the timing specs do not match exactly... but most of the time stay within each other's tolerances...: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-09 by Robin Fri 2019.02.08 Thank you @AkosLukacs for the source and image from #4 above. @spocki thanks for the trio variant summary: RGBNW (natural white), RGBCW (cold white) and RGBWW (warm white) AkosLukacs, how did you determine that quad Uint's were needed, as the BangGood page specifies RGB+White and also indicates (while incorrect) WS2812 (tripplet Uint's), which you (array divide by three) have proven can't be - see what follows. If a S.W.A.G.'d guess, then it appears you may have gotten lucky there, even though you were led to believe you received WS2812 *Did anyone else observe the inconsistency?* From image in #4 the output as explained is from right to left: (reversed here) Green : Red : Blue : Yellowish White : Bright White : RGB White Spec sheet SK6812 shows RGBW which can't possibly be
Can't be these either ref: RGB WS2811 or BGR APA102 > https://cdn-shop.adafruit.com/product-files/1378/WS2811.pdf > https://cdn-shop.adafruit.com/datasheets/APA102.pdf So, do we have yet another mis-represented Asian knockoff, or a spec sheet that is incorrect and we now need to search for yet another variant to contend with? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-09 by @allObjects The commonly used neopixels are async ones with only 4 function pins: GND, 5V, data_in and data_out. Then there are these sync one with 6 function pins: GND, 5V, clock_in, clock_out, data_in and data_out... and with that a totally different protocol. First is time critical because it derives the 0 and 1 from the time differences when the signal changes 'within the bit',. the second one does clock for latching. and is less to not at all time critical... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-09 by AkosLukacs @gfwilliams I think checking for 3 or 4 byte length, and throwing an error if the array length doesn't match the expectation is a valid. I guess 99% it's a programming error. Ran into it myself when messing with these LEDs. :) @robin Well, there are four colors per chip, so trying 4 bytes per pixel felt a good guess. Add some trial and error, and got them working. (Edit: I was wrong, same behavior on the STM32) Regarding RGB / GRB: There is something that looks strange in the NRF driver
The first color in the struct is I will try it with an STM Espruino tomorrow. Or simply it's banggood, the item and description is not expected to match perfectly... @allObjects Yes, mine are async ones. 4 pins on the LEDs, and the strips have 3 wires: GND, VCC, and Data in. Data out on the other end, and no clock signal. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-09 by Robin Sat 2019.02.09 While I would have someone with more compiler level skills answer this (I'm an end user like yourself) in detail, I am able to suggest the following:
Yes, annoying isn't it. Their description of WS2812b is an error as you found out.
The beauty of C/CPP is the ability to use pointers to access items. The structure above allows for the definition of the three color items, and as you were on the right track, just needed to get to the usage part to see how that structure is implemented. Those three items therefore, can be used in any order as can be seen by: Using the link you provided NRFDriver in #13 above, but use the and now my understanding of 'C' is now in question as from line L75 those colors are bit shifted. Am I getting Javascript and C/CPP/C# muddled here, as I always believed the order of a structure definition didn't set the order of the data. Anyone able to clarify here? As you can see, the above module is for the nRF devices using I2S The following is for STM using I2C hardware SPI @gfwilliams passed along this link some time ago for the Neopixel source:
but the only reference searching GitHub turned up
which does perform a byte reorder, but why is this in the WioLTE file? Neopixel !== GPS
Is it possible there is a suitable Neopixel plug that is to fit into the I2C pin connector on that board? e.g. This board has multiple other uses than that shown? I was unsuccessful at locating the source file that contains how the byte order appears for stm32_neopixelWrite()
My understanding is that to keep the data ordered, it is assumed that it will be RGB to keep the mental model accurate, and left up to the implementer (us) to provide the byte oder to the setup array for |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-10 by @allObjects Visualizing the neopixel timing specifications... and comparing different providers and the SPIX.write4(... option:
Times are to scale. Numbers are times in [us]. The protocol is quite smart and self-reconditioning takes place between the pixels (by the built-in circuitry). The fat blue and fat orange lines show the exact specified values. The respective fine lines are combinations of minim and maximum allowed values - tolerances - cumulated/cascaded:
SPIX.write4(... w/ 3.2MHz baud rate and writing of 0b0001 and ob0011 for the actual 0 and 1 bit come darn close to spec using only 1/3 and 2/3 of the tolerance... Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-11 by AkosLukacs @robin Of course I was wrong about the wrong order in the struct. Same behavior (GRB) with STM32. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-11 by @gfwilliams I think the mention of r/g/b in the struct for nRF52 is a red herring. It just takes sets of 3 bytes and pushes them out in order. Depending on what pixels you use red may not actually contain the bytes for red. It's another reason why it'd be nice to create just a simple, single bit of code for creating neopixel bit patterns that got shared across all devices. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-03-21 by AkosLukacs Just a note: all the "pixels" I got recently work flawlessly with 3.3v controllers. No diode to drop the supply voltage, no nothing And all of them are GRB or GRBW. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-03-21 by @gfwilliams Wow, thanks for letting us know. That's really interesting - makes sense that they'd have made something though! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-03-21 by @MaBecker
Can confirm this for btf lighting products too |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-03-23 by Robin Fri 2019.03.22
A month ago, I put together a table of datasheets reference to help answer the color byte order of this family of multi-color LEDs
Again we have a web page indicating (incorrectly) the chip used in their strip offering as in GRBW from #18 above. The images appear correct, as the yellow tinge phosphor is present, but that then means this strip can not be a WS2812, as there isn't the 'W' component for the byte array of a WS2812 as there isn't the yellow phosphor marking either. (web page offering title is incorrect) when making a purchase, caveat emptor @AkosLukacs did you by chance locate a datasheet for this GRBW SK6812 variant? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-03-25 by AkosLukacs Yes, saw that, but didnt't want to spam that thread, since I have no datasheet. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-03-25 by @allObjects @robin, world has become fluid... over time... unfortunately... and specs are often not as concise as we like, nor do images always match text and vice-versa... and more so reality... (If I'd have ordered RGBW as catalog / image(s) show and receive RGB only or worse, it is return on cost of merchant. Ambiguous catalog entries w/o free return just do not turn into order entries). In @AkosLukacs ' referenced item though, description, image, and text in merchant's context imply RGBW and 32 bits to send to make it right! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-03-26 by Robin Mon 2019.03.25
Ahhhh @allObjects, I thought you were with us here. Please re-read #1, #18, and my #21 @AkosLukacs points out GRBW as does the output #1 shows this also. I agree with that and thus point out the advertiser WS2812B error as there isn't the white component in that device. 24 bit. So is a 32 bit SK6812 variant, not WS2812B > 'I can try to desolder one' No need, unlikely to result in part number. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-07 by AkosLukacs
(edited with some clarification) Just got a strip with "RGBW WS2812B" Leds from banggood. The good news is, the neopixel library it just works! If the number of LEDs is divisible by 3, or you pad it.
For example (on MDBT42Q module):
produces green, red, blue, and three "white"s.
But the library throws an exception if I try to write a single RGBW pixel:
Tried to dig into the c code, and create a
writeRGBW
method, initially I thought it's just checking for different length :) But that rabbit hole is a bit deeper with all the device specific drivers...@gfwilliams you have done a great job documenting the build process, had a custom build for the MDBT42Q module in a couple of minutes!
Do you plan to modify the library for official support? Or just add the workaround to the docs?
Beta Was this translation helpful? Give feedback.
All reactions