PixelBlaze firmware is not open source? I’d love to get these strips running as well. The white seems a lot brighter than what I could do with BTF WS2815.
It seems like one could adapt the open source Ws2812Adapter here
to support the new strips, but I don’t see a way to replace the running lib. I’m probably not the first one to ask, which is why the offline loads have taken on the file extension stfu
I think nobody has ever stuck white anywhere but at the end before this… and so an if(hasWhite) was just crammed in at the end of the bitfield for this entire line of WS28xx protocols, until now.
Ha, this file extension makes me laugh every time I see it as well. It actually stands for Signed Transfer Firmware Update.
Wizard will likely include WS2814 support in an upcoming release. Based on historical release cycles, I’d estimate 1-3 months.
From what I’ve read on the forums and my discussions with Wizard, the company is concerned about the cost of supporting people experiencing problems on clones or forks, as well as the ongoing commercial viability (and quality). I watched this tragedy happen to the ArduPilot boards.
You can see the list of components and peripherals that are open-source on the github readme. It includes the open source drivers he’s released for the three major pixel protocols. In fact, I think I see some color order and hasWhite stuff in the WS281X adapter (also see this line), though my C++ is not strong enough to look through this and know if someone could essentially contribute WS2814 support.
Despite having been shipped the wrong LEDs from China first (TM1814s) and having to re-order, the rest of my WS2814s will be here in a few days, so I’d love to see this addressed soon. Since the only difference is the color order, it should be a 3-5 line fix.
It’s interesting that some of the converter code is open source. I’m an embedded engineer with the chops to mod that code to work, and would be happy to share the results with the community (as I already did with my graceless hack above), but I’m not clear how the open source part could be combined with the proprietary part for testing. How would that work?
As long as method signatures are not modified, with a little luck, you could drop in a shared object file (.dll, or .so in this case) and replace just the code in that file, but without seeing how the pixelblaze project is laid out, this is just conjecture as it relates to its firmware…
Also, I think you’ll want to have it selectable in the Pixelblaze app’s Settings page (under color order or pixel type), so you’ll need @wizard for that.
If you want to get this working quickly just to experiment, here are a couple of ideas:
First, you can mislead your Pixelblaze a little…
It has no way of knowing that whatever you send out as “RGB” data actually matches what the LEDs are looking for. If you tell the Pixelblaze to send 3 bytes of RGB data to your RGBW strip, it will do so. But the strip will still be looking for 4 bytes per pixel, which means that the first byte of the next pixel from the Pixelblaze will be used as the 4th byte of the previous pixel, and on down the line.
So if you set your Pixelblaze to an appropriate RGB mode and set its pixel count (actual pixel count) + (actual pixel count / 3) to account for the extra W bytes, you can use the function in the forum post below which, given a pixel index, figures out where the r,g,b and w bytes will fall and lets you set them all independently.
Calculate your white value and call your version of rgbw2rgb() instead of regular rgb.
(The function was made to allow independent control of “W” on RGBW strips, but you should be able to get it to work for your strips just by rearranging the order of the input parameters.)
And if you’ve got a Pixelblaze output expander board handy, it does have completely open source firmware, so you can reflash it to put the W byte wherever you need it. I did something related a little while ago. Here’s the forum link:
Aha! These are excellent suggestions, and well timed as my LEDs have just arrived today! I ordered the muxing board and will try the 3-color to 4-color trick when I get home tonight. Thanks!
The end of the year was pretty hectic, but I hope to get a release with support for these soon. It would indeed show up under settings.
The good news is the output expander firmware uses a fully flexible mapping system, any color can be in any position, so any version of the expander should work once the option is added to PB. The PB direct drivers, as you’ve seen, will need a little work. Rather than hack in a special case for swapping W to the 3rd position, I’d prefer to model it more like the expander.
It’s arbitrary that they chose GRWB over GRBW or RGBW, the WS2814 datasheet lists RGBW color order, while the WS2814A datasheet has WRGB. Each channel has the same output characteristics, so they just swapped it around for that strip. That means we could see more color order variants over time.
I’ll still need to reconcile this with the user interface, the combinatorial explosion of options means there would be too many items for a single dropdown, I might just add GRWB there for now to keep it fairly simple, even if the underlying drivers will support more.
Hey Wizard! Thanks for staying on top of this, I know things are crazy all around right now.
I used the 3/4 mapping trick to get direct control of all four colors, but would really like the built-in support to use the 3D mapping, etc., without a bunch of hacks.
I can immediately see the combinatorial problem with the color order/settings. The thing that pops to mind is to have presets for the most common ones, then have some extra custom options for 3 and 4 colors where you can just specify the order directly, like maybe a select box for bytes 1-3(4), etc, like this:
I got the Output Expander firmware hacked for my WS2814As, see the thread below for details.
So when I have the PB and the OE set to RGBW, this is what I’m needing to get the colors right.
Which is:
// Scott Mauer’s hack for WS2814s
// Set your PB and Output Expander for RGBW
// This will re-arrange the colors to be correct
uint8_t or = ch.og;
uint8_t og = ch.ob;
uint8_t ob = ch.ow;
uint8_t ow = ch.or;
So when I have the PB and the OE set to RGBW, this is what I’m needing to get the colors right. I’m not 100 sure which way to read that, it’s either GBWR or WRGB.
There may be some cleaner/less kludgy way to fix the problem, but since this is currently the only LEDS I’m working with, this works for now.
I also have some TM1814s, and now that I grok the OE firmware dance, I might try making something that works with those.
It definitely seem to me that one thing well worth doing is having a custom 4-color order option like the one I suggested above that loads the values in the PB firmware and is simply cut-and-pasted on the OE side. That way people can customize whatever they need without adding tons of permutations and code.
I think I’m seeing WRGB from that code. The pixel data is always sent in RGBW order, and remapped on the expander. The color orders are indexes are where to pull the element from in that RGBW structure.
If you configure color order to RGBW it will have ch.or = 0, ch.og = 1, ch.ob = 2, ch.ow = 3. The position of the letter zero indexed. In other words, no remapping from the packet element order.
Your code would then use these indexes:
uint8_t or = ch.og; // 1
uint8_t og = ch.ob; // 2
uint8_t ob = ch.ow; // 3
uint8_t ow = ch.or; // 0
which makes WRGB when you reassemble it. That matches what I have on my WS2814 strip!
How much rework would it be to stop assuming pixel data is always sent in RGBW order and do some configuration-aware mapping? Do you ever bring on contributors? I get that you want to sell output expanders, but this seems feasible to me. Looks like you really love low level C++, so I will refrain from mentioning accessors – maybe assigning a bit mask on each strip type would accomplish the same with a little bookkeeping…
The latest release supports these, no expander needed. Works for expanders as well.
It’s all configuration aware mapping. The expander has configuration to remap on the fly for any byte order so that the data protocol can standardize on rgb/rgbw.
