So, I think I’ve made it through a big learning curve with regard to Master and Remote FPP setups, and controllers in-general…

First I found out that the Kulp K16A-B controller is fantastic as a stand-alone controller, or as a Remote, but NOT as a Master. For some reason it just has media timing issues that appear to be unresolvable unless they eventually get fixed in firmware or FPP. If you want a very-expandable single-controller to run your whole show (and it likely can)- then it is still a great option. It also works outstandingly well as a Remote.

Update (January 2021):
I’ve heard that this may be a problem with any sort of mixed environment. The problem is likely more on the Raspberry Pi side of things than on any controller. Unfortunately Kulp and Falcon controllers don’t do video/virtual matrixes, which I am using. It is also possible this was more caused by WIFI issues with my remaining NodeMCU controllers, which I was still trying to run off of the Kulp K16A-B at the time.

Along those lines- using it as a Remote means the FM Transmitter option can’t be used. Well- it can, but your visitors will hear a lot of audio glitches. Pixel timing adjustments (due to remote sync) aren’t as obvious as glitchy audio. This also seems to affect the pixel timing as the CPU needs to calculate a jump in the audio file. This meant that I needed to buy a separate FM transmitter and run it off of the new Master controller…

The new Master controller is a Raspberry Pi 3B+ running FPP and almost nothing else. I do have it running my AC and Projector power management scripts through pixel overlay models, as running Remote scripts has proved to be unreliable. (I’ve seen too many people report issues with doing this.) It doesn’t run any pixels or media.

I ended up buying this FM transmitter, which works almost-alarmingly well. The Kulp option’s signal carried for about 4 blocks. The new one goes for a good mile.

The master syncs to my (now) 3 Remotes: K16A-B, Video, K40D-PB (more on this below). I’m using Ethernet to link everything, as…

I have all but given up on WIFI. I am still using it to run my AC prop and power relays, but at least with WLED, even using DDP- it just has too much lag and too many errors. The only things I was still using it for are the 7 SparkleBalls, which play key roles in several of our sequences, and they just aren’t working right. They can be very laggy and lots of dropped/missed cues. There is no consistency either. For example: They might work perfectly for a specific sequence one time, but the next time it runs- they barely work at all. They will even stop working in the middle of a sequence, only to start again at the end.

I’ve tried ALL of the WIFI optimizations suggested in various online forums. Some helped (Hardware, DDP, and channel changes), others made things worse (E1.31 Multicast), but they are still unreliable and have poor timing. This could be a WLED issue, it has a lot of overhead for this application. The latest version of ESPixelStick firmware supports ESP-32 and DDP and may fix some of these problems, but at this point it is just easier to bypass the Node controllers. This should result in a much cleaner show.

For practical reasons to wire up the SparkleBalls for now- I ended up buying a Kulp K40D-PB controller. This is a 40-channel differential sender that runs on the PocketBeagle platform.

This thing is tiny, compared to the K16A-B. The main part of the board (minus the RJ-45s) is about the same size as a Falcon diff. receiver.

I’m wiring the SparkleBalls up this weekend (12/5/2020), which is a big pain in the butt, but I can’t deal with them failing all the time anymore.

Next year I will likely buy more Kulp boards, specifically the K8-PB. It has 8 pixel ports and 3 diff. ports, making it a really good Remote controller option. Distributing them and just running Ethernet and Power seems like a better option than longer pixel and diff. runs. I figure a larger number of controllers running as Remotes should be more reliable long-term than relying on a single controller (and single point of failure) for everything.

If I don’t find a way to scrap WIFI altogether, I will probably just continue to use it to run my relay boards for props and system power. I want to build more relay controllers as I want to work on power management. Right now a large part of my display still remains powered all the time. I want my control boards powered all the time, but not the pixels. This is easier with diff. receivers since they decouple the power from their controller. I’m going to start working with SSRs instead of mechanical relays next year, and will be upgrading/revising my existing relay controllers.