I’m starting to prepare Burning Man 2025, particularly totem and costumes for my crew.
I have quite some experience with Pixelblaze and as usual it looks like the best solution for (not only) our needs, but I am facing some “ease of use” issues, which are not critical for me but will be for less trained users, especially in a festival setting.
Idea behind this request: I will develop a PCB+3D print case assembly I can easily connect to power + LED and including a power switch (to isolate the battery from the rest) + a few buttons to fully control patterns without using the phone (big no-no in festival).
Each member has its own, and the idea is of course to sync when the crew is together.
Here are some issues I’m having with sync:
Currently when syncing PB, the host controls identical pattern and luminosity. But clients might want lower or higher local luminosity (due to different types of LED used, or simply light tolerance). The brightness limiter in settings does not allow this dynamically.
Button control of the host pattern does NOT transmit to clients: massive issue if I want to use it to change the color or send a strobe for example.
When synced to a PB in AP mode, it’s impossible to access the client PB, for example to unlink for a while (if a client wants to go standalone for a while for example). Have to reset the whole wifi settings with the button, then do it again later when i want to sync again. If we use a portable wifi access point, it’s easier but see next point.
If the host (PB AP or Wifi AP) disappears on a side quest, nobody can access/change pattern their own PB anymore without resetting wifi (annoying).
I’ve read a bit about ESP-Now that might help with this whole Host/Client issue ?
My suggestions:
Degrade wifi settings:
… Try to connect to client
… If not detected, try to connect to another client ? Pre-recorded list ?
… If no client detected after 30s for example, switch to AP mode (maybe re-scan for client at intervals ?)
… Allow to switch easily between recorded client list and AP mode without deleting settings or having to reset the PB with the long press ?
Allow access to settings from within a pattern of:
… AP/Client switch as above ?
… solo/follower status if in client mode ?
… luminosity master
… Some “synced-declared” variables received from a host ? That would allow when following to get for example color/luminosity/sound from host to all clients even if the host presses a button, but would still allow each client to override this by pressing their own button ?
Finally, as I understand Electromage team is probably busy with other priorities and I could maybe be able to adapt, is there a roadmap somewhere of functionalities/products in development ? I would particularly like to know if the Pico with Sound Sensor and Gyro is still happening, as Pixelblaze + Sensor board does not have a gyro and is quite “bulky”, and Pico does not have sound sensor (deal breaker !).
Last question: is there a CAD drawing of PB, Sensor Board and Pico where I can get all dimensions to develop a fitting PCB with buttons/maybe other sensors + 3D Print case ?
EDIT: found it here pixelblaze/V3 at master · simap/pixelblaze · GitHub
Hi @hololit,
I don’t have a roadmap shared. I’m currently working on some projects for PixelLights, and expect that these cool things will be shared more soon, but nothing that hits in any of your points above.
For your items:
That’s a good observation. I think that a checkbox in settings, similar to how follower sensor boards are handled, that would basically ignore leader brightness would technically “fix” that but everyone would still need to get in the interface to change it. Another idea would be to use a pot on an analog pin on the PB, with a small bit of code to read it and adjust brightness accordingly. That would allow easy brightness control, wouldn’t have to open the interface, and since the analog values read are local, everyone gets to control their own devices. This is so often a requested feature, even for non groups, that adding top level support is high on my list. When implemented you wouldn’t need to add code to each pattern to achieve this, it would just be a setting to pick which analog capable gpio to use, and possibly some settings to fine tune how it works.
The main button changing patterns should sync. But I think you mean additional buttons wired up to gpio. Sensor board values can be synced. So buttons and pots on the 5 analog inputs could be used, though syncing SB does add a lot of bandwidth so may not work well with a lot of followers and iffy WiFi. I do have plans to add a way to sync other data to/from followers.
3 & 4. I hear you on this. Another often requested feature that is in higher on the list. Currently a follower that has lost the leader will fall back to local patterns and playlist, and can switch patterns via the button, so the idea there is that the solo follower can still switch things up. But getting into the interface is a pain.
Espnow is great for some things, but fairly low bandwidth compared to a regular WiFi connection. It’s not a drop in replacement, but it would allow for a more ad hoc connectionless sync group system.
I could configure all PB to max luminosity and each of them handles luminosity separately with its own GPIO and never using the master as a workaround indeed. I can live with that.
I will have a look if I can share the SB values. It’s very important as I want to use the leader changing the color with GPIO input to reflect on followers. Else the syncing is limited to app use which is a big no-no on the playa
What about the “revert to AP” in case no host is detected for some time ? I can’t imagine having to reset the PB every time i need to switch… Do you think that would be doable ?
Thank you. Will we see anyone from the Electromage team on the playa this year ? I’d like to come say hi (even help a bit if you need) if you guys are not too busy.
That is how V2 used to work, but it caused a lot of problems and made it much harder to figure out how to connect to it as AP would appear to randomly appear and disappear.
I think a dual mode client + AP could work, but there’s a few things that would have to be worked out there. Could also have a mode where you hold the button to switch, similar to enabling WiFi when disabled on startup, but ideally it would reconnect once in range.
Syncing works with UI controls, and those can be controlled via websocket without the app. You could have another ESP32 act as the physical “remote” that connects to the leader’s AP, then uses websockets to manipulate the control values. A few people have done that kind of thing before.
There is an arduino library written by @hbeck that I’m going to help maintain, I haven’t started testing it, but it’s worth checking out. It looks like it covers quite a lot, and has some APIs for UI controls.
Speaking about an external wifi AP, I guess you have a bit of experience on it as I’ve seen a few of your projects. Do you have a recommendation for a low power one ?
This one seems to eat about 2.5W, I’m wondering if I can go any lower.
I’ve used tp-link TL-WR802N which looks similar. I haven’t measured the power, but it’s usb 5v and under 1A. If I get some spare time I’ll see what it draws. My guess is it is in the same ballpark as the one you listed.
Claude says that if that helps. No idea if it’s correct or not hahaha:
Let me compare these two routers’ power consumption by examining their technical specifications and design differences.
The TP-Link TL-WR802N typically consumes around 2.5W of power during normal operation, while the GL.iNet GL-MT300N-V2 consumes approximately 1.5W. This difference in power consumption stems from several key factors:
First, let’s look at their processors. The TL-WR802N uses a Qualcomm QCA9533 processor, which is slightly more power-hungry due to its higher clock speed and architecture. In contrast, the GL-MT300N-V2 employs a MediaTek MT7628NN processor, which was specifically designed for low-power operation in embedded devices.
The radio configurations also play a role in power consumption. The TL-WR802N operates purely on the 2.4GHz band with a single antenna, but its radio chipset draws more power to maintain signal strength. The GL-MT300N-V2 uses a more efficient radio design that achieves similar coverage while consuming less energy.
Another factor is the power supply design. The GL-MT300N-V2 incorporates more modern power management circuits that help reduce energy waste during idle states. The TL-WR802N, while still efficient for its class, uses a slightly older power management architecture that isn’t quite as optimized for minimal power draw.
In this pattern, imagine a bunch of people wielding Pico+ LED swords:
H: Each sword’s colour is determined by the next wielder’s motions.
S: Someone has a browser open to the Leader PB web UI to control everyone’s saturation.
V: Everyone controls the brightness of their own sword via a GPIO knob.
// Writes to global variables are sent to the master at a tunable frequency.
// Last writer wins. No built-in consensus algorithm.
// The master broadcasts the latest value at another tunable frequency.
var global.Hue = array(nodeCount)
// Only the leader can write and broadcast this variable at yet another tunable frequency.
// It's read-only for followers.
var leader.Saturation = 1
// Normal device-local variable set from local GPIO
var Value = 0
export function render(index) {
hsv(
global.Hue[(nodeId() + 1) % nodeCount],
leader.Saturation,
Value * (index/pixelcount)
)
}
export function beforeRender(delta) {
global.Hue[nodeId()] = something_interesting(delta, sixAxis)
Value = analogRead(GPIO_PIN_BRIGHTNESS)
}
// This function only executes on the leader
export leader function sliderSaturation(v) {
leader.Saturation = v
}