Group Sync Optimization

Hello! I am running a group of about 10 PBs, each mapped to different sections of an art car, off a primary PB. The patterns are expanded versions of Scruffynerf’s (et al) excellent multimap pattern in which some maps will have audio reactivity and others will not, and we anticipate some sub-patterns may be computationally expensive. We have an on-board router that is no further than 15 feet from all PBs (client mode, not AP mode). All controllers are running v3.60.

We’ve noticed considerable lag with the follower controllers when the primary switches patterns, and many instances when the primary web UI hangs (but patterns still successfully change when pressing the primary’s button. Sometimes it is resolved when I power-cycle the primary controller, but not always. I’ve gone through the forum and have collected some tips for optimization but seeking additional assistance:

  1. We’ll power up each controller one at a time.
  2. Is a 2.4ghz-only router recommended? In my testing environment the 2.4ghz shares an SSID with the 5ghz band but the art car router can be made to be 2.4ghz only if necessary.
  3. Noting @wizard 's comment that syncing can be affected by sensor data. If so, is there any way to limit the sensor data? (we’re only using the lowest four frequencies to affect a single variable)
  4. Is the complexity of the pattern a factor for syncing to new patterns? The Slime Mold Palette pattern is great but concern is it may not work well as one sub-pattern of many if it taxes group sync.
  5. Anything else to mitigate pattern switching lag?
    Thank you!

Using playlists should allow enough time for a pattern code to sync before the transition should occur. Followers load both the current pattern, and the next pattern. Works for shuffle too. But clicking around manually means followers have to get everything before they can run the pattern, and will also pull whatever’s next.

Yes, sensor board data adds to the bandwidth used. There isn’t anything that can be done about that easily, but there are a few tricks. If the leader doesn’t have a SB, it will not send data for it, no bandwidth used, but sensor board data could be sent directly to the expansion header of followers. It might also be possible to add a micro or hack the SB that reduces the update rate and thus reduces bandwidth.

There are several kinds of routers, and some can do some impressive tricks like splitting clients, beam forming, etc. look for signal diagnostics for connected clients and see what kind of signal you are getting. Wires or metal can interfere.

Yes pattern size is a factor, but most are actually very small.

5ghz shouldn’t matter, but there are rare some routers that do something that the esp32 doesn’t like, it won’t hurt to try splitting them just in case but probably won’t help.

Thank you! Can you elaborate on the sending SB data to the followers’ expansion headers and how that can be accomplished?

It’s a serial communication. It can be run with wires, or relayed over some other path, like a secondary network (with some other micro handling it)

In a simple form, you wire up the SB TX line to the RX on several PBs.

1 Like

Gotcha, much appreciated.