Output Expander Feature Request: Partial Update

I am looking to use the Output Expander (OX) to drive multiple individual WS2812 LEDs and multiple WS2812 LED Strips inside studio scale models. Some of the LED effects include interior lighting, NAV lights, strobe lights, exterior flood lights, phaser and torpedoe lights, etc.

Looking at the Output Expander protocol and firmware, it appears that the only way to update a channel of LED pixels is to update the entire length of the channel. The OX code takes the data packet and copies the data straight into the specified channel’s internal pixel buffer starting at location 0. Furthermore, all pixel buffer values past the length of the data packet are set to 0.

In my case though, most LED pixel values are rarely changing. But let’s say I want to fire a torpedo. Then I currently would need to resend all the values in the channels LED pixels with only the one torpedo LED pixel value changing.

This certainly works great, but it would be nice if a partial update command was added to the OX protocol. The packet structure would pretty much remain the same with 1 additional field added to specify the pixel offset to start writing the channel’s pixel data. Plus the OX firmware would have to not overwrite the remaining pixels in the channel with 0s.

Does this all make sense?

It makes sense, but the WS2812 protocol involves pushing all the pixels every frame, and I don’t imagine the OX has anywhere to store the current state of all the pixels, at least not when it’s driving a lot of pixels.

When I need a framebuffer, I just keep it in an array:

var FB = array(pixelCount)
FB.mutate(()=>{return array(3)})


export function render(index) {
  Pixel = FB[index]
  rgb(Pixel[0], Pixel[1], Pixel[2])

Thanks for the response. Per the documentation (and confirmed in the firmware source code), the OX actually does store the complete state of all the pixels. It is single-buffered though, not double-buffered. That is why I was a little surprised that a command to modify just a section of the pixels was not already implemented. Seems like a great feature to add since the buffer in the OX is just sitting there to be taken advantage of.

Wow, that’s cool! I think I have one still in bag around here somewhere … haven’t had a large enough project yet!

Should be possible, but doesn’t fit with the way Pixelblaze renders pixels so I haven’t added that kind of feature myself.

All the tools and data is there, would just need to add a command for the partial update.

There’s a tutorial post for getting the compile for the board working.