Here’s how to hack your way to custom timings.
When you select 333/667ns in the UI, this is sent over the websocket to tell Pixelblaze the change:
{"dataSpeed":3000000}
That uses a bit timing of 1/3000000, or about 1/3rd of a microsecond, roughly 333ns.
Likewise, when you select 286/571ns, it sends this:
{"dataSpeed":3500000}
Which is 1/3.5 microseconds.
These translate to zeros or ones in the WS2812 protocol. Zeros have a single bit time and for ones, it is doubled.
You can send almost anything you want, but you may have mixed results and might cause instability if you go too far off. For example, if you go too low, you risk taking forever to send out pixel data, and that might make all kinds of things unhappy and unresponsive. Perhaps setting it to 10 pixels or something for initial experimentation would be wise.
To send a custom value, you can use one of the helper functions used in the interface, by opening your browser JavaScript console and entering something like this:
sendFrame({dataSpeed:3500000, save: false})
“Hey wait, where’d this ‘save: false’ stuff come in?” I hear you asking. Most config settings save by default, but there’s a flag that can be set to override that, and if you do end up with a bad value that breaks things horribly, its best that it isn’t committed to the config permanently. You can take that out (or set to true) once you are certain it’s working.
Of course if you save a value the UI doesn’t support, it won’t know how to update the settings dropdown when you reload the interface.
For those curious, I’ve open sourced my driver here:
The version used in V2 has a fast, buffered mode and a slow unbuffered mode.
It is based on a similar approach used in some other WS2812 drivers. It uses a hardware UART (serial port) in the esp8266 because it provides a hardware buffer, packing 2 bits per byte sent to the UART. The 128 byte UART buffer can store 32 bits of WS2812 packed information, enough for an entire RGB or even an RGBW pixel!
The original WS2812 protocol is quite picky, and will glitch if there is too much of a delay between bits/bytes. EmpIrically, the latch time was found to be as little as ~6 microseconds! Thats a problem on systems like this that borrow CPU time to handle WiFi things. Later WS2812b and WS2813, WS2815 and possibly many clones improved on this by raising the latch time to 250µs.
The unbuffered option stretches out the bits to give more time to render pixels, but complex patterns may take too long, causing glitches. Thats why there is a buffered option, which can also run a faster data speed by default, but can’t render pixels while data is being streamed out like the unbuffered option can.
The utility of the unbuffered version is kind slim, so most of this configurability isn’t in V3, which uses a fixed timing that has broad compatibility, but runs at a fixed speed.
