@wizard, arranging multiple maps in 3D is one of those things that might make some flavor of Pixel Teleporter interesting again, since it already has most of the required plumbing. I’ll have to do some thinking about how that might work.
1 Like
confirmed work with one as AP and another connected. Awesome work, Ben!
1 Like
This. Is. Amazing!
V3.40 is a whole new level for Pixelblaze! Confirmation from this tester, six displays are now synced perfectly and five of them are completely wireless. Even the two Picos with no sensor boards are right on cue to the music. Firestorm is great, but this update is superior and for low-techs like me, so much simpler. Also love the new dropdown for the leader.
Thank you @wizard for all your hard work!
3 Likes
Very exciting News! Looks like I’ll be putting an order in for a couple more pb’s. 
1 Like
Late to the party… 
This looks great and I can’t wait to give it a go, even with only two PB that I can sync (time I got one or two more then). But it will have to wait - I have holiday this weekend, and a display already to run next weekend (this side of the pond, some of us are putting lights up for the coronation of King Charles III).
1 Like
YAY this is amazing news and a great development !! Cant wait to try it out.
1 Like
Amazing ! Can’t wait to try it !
1 Like
Wow, this is incredible! I haven’t had a chance to try it, but is it possible to not share sensor board data from the leader to the followers? I have an application that requires each PB follower to use it’s own accelerometer data. Thank you for all of this!
1 Like
Each follower can choose which set of data to use for the accelerometer, sound, light, and group of analog inputs. So that way you can for example share sound from the leader but still use local accelerometers.
3 Likes
Does the new sync feature support syncing of timers when both connected to the same wifi? Having issues with that right now, all patterns are changing together but when I enable the timer only one goes off and both timers are set the same. Maybe I’m missing something?
1 Like
@PB43VER Yes, it synchronizes each device’s calls to time().
Pattern math involving adding up timers based on delta can be a little less consistent in patterns between the various controllers in your group, especially if they have fairly different numbers or types of LEDS, so the frame rates are different between the devices in your group.
Did you mean something else when you say timer, like the scheduled on/off times in Settings? If so, no, those remain independent. If you’re having trouble, be sure that all devices have the same Time Zone set in settings.
1 Like
This looks awesome! Sync aside this is so nice even for managing patterns on a fleet of pixelblazes. A couple questions:
I still don’t grok that mapping code. If each PB has the same mapping function and you aren’t using nodeId than how do the different PBs have different mappings?
Can this still work if you’re using a router? Will you see all PBs connected to the same router in the list of peer devices?
Each Pixelblaze can have its own pixel map. Using the fake pixel trick, you can divvy up the world coordinate space across multiple individual pixel maps. Or use the nodeId() in pattern code with the coordinate transformation api.
If you have the exact same map on each Pixelblaze and don’t use nodeId() in pattern code, then they render the same stuff.
Yes, this works on a network you host, or with a Pixelblaze in AP mode. The leaders and solo Pixelblazes, or anything that isn’t following another PB, will show up in the status dropdown menu, so as long as you know/guess the IP of one PB, you can find the others. On a leader you can see it’s followers from the same menu in case you want to jump over to them for setting changes, etc.
This isn’t so much pattern management, as obviating the need to manage patterns while in a group. The patterns from the leader are used, and the patterns that are installed on the followers doesn’t change and isn’t needed/used at all unless they leave the group.
One benefit of this is you can have an XL with tons and tons of patterns as the leader, and can use smaller storage Pixelblaze followers which will still follow along with anything the leader does without needing to store everything.
4 Likes
This isn’t so much pattern management, as obviating the need to manage patterns while in a group. The patterns from the leader are used, and the patterns that are installed on the followers doesn’t change and isn’t needed/used at all unless they leave the group.
So on pattern change the leader will send the pattern code out to the follower pixelblazes over the network? Regardless this still gets rid of the step where I have to copy the pattern to all my pixelblazes in my network before checking to make sure everything looks good. Huge improvement in the development loop!
Each Pixelblaze can have its own pixel map. Using the fake pixel trick, you can divvy up the world coordinate space across multiple individual pixel maps. Or use the nodeId() in pattern code with the coordinate transformation api.
Ah yes ok this is the same thing I do. Cool to know you can use nodeId() in the pattern code though, that makes it a little less manual to do the mapping on each Pixelblaze.
1 Like
I tried to use this nice feature by connection two PB with each other (on in AP Mode one in client).
I found them both when I am connected to the network (one as *4.1, the other as *4.3), but both PB doesn’t find each other - I can not choose any mode within group settings.
Some advice for me?
Try power cycling them. There may be an issue if the PB recently switched Wi-Fi modes.
Thanks, as easy as it sound that’s solved the problem. 
Ok, I’ve been recently trying to set this up and I’ve run into a problem. I have 4 PBs running together, with 3 following one that has a sensor board. This works mostly fine. However, when I try to update variable remotely via Zranger’s python client, I am only able to update the leader variables. They don’t propagate to the followers. If I run all 4 on the same network with none as followers, I can control all of them at once, but then they can’t share sensor data. Is there any way to both share sensor data and exported variables?
Controls are replicated, but exported vars are not. It’s kind of like poking into the memory of the script and each node has its own memory.
You could send the vars to each node.
At some point I will add a way to replicate any data around that you want.
The issue with sending data to each node is that the followers disappear from the network so I can’t detect them any more.