When to Use MultiSync with Falcon Controllers?

[trains+lights]

This is my first year with xlights and FPP! I'm using multiple F16V5s, one Pi 4 acting as the "Player", and one Pi 4 acting as a "Remote." The Remote Pi is being used for a TV display. Currently, the entire network is using a wired connection as wifi won't work for my particular setup.

If I understand correctly, MultiSync can be used to send sync packets over the network (wired or wirelessly) to Falcon controllers which have a local copy of the .fseq on a micro SD card. My understanding is that this can be done without a Player Pi but please correct me if I'm wrong. The main advantage is that wired connections aren't needed and a wifi connection is stable since the only network traffic is the sync packets. This can also be done over a wired connection.

Alternatively, you can use a wired connection where the Falcon controllers do not have the .fseq locally and instead all data and sync packets are sent from the Player Pi.

In what scenarios would you want to use the MultiSync setup? I eventually want to expand to several more controllers so would the MultiSync setup be better for me in the future (since less network traffic is needed)? Or if I cannot use wifi, there is no benefit to MultiSync and it's simpler to use the normal connection between a Pi and a Falcon controller over E1.31?

[JonD]

Placing the Falcon in remote mode is supposed to work, but not many people use this feature and you will not get much feedback/support with issues.  I tried pretty hard to get the Falcon V4 series to work in remote mode last year.  I have a lot of songs, change them often, and the transfer time was miserably slow.  David Pitts suggested I was never going to be happy with it.  If you have a smaller show that does not change the entire season, it might be a solution for you.

There are a few people that will install a Pi in the Falcon controller box.  The Pi is placed in remote mode that receives multi-sync packets wirelessly, and then feeds the data to the Falcon via lan ethernet port.  If you need to use wireless this would be the path I would recommend.

There is a lot of latency with wireless and you would likely have a lot of timing issues if you tried to run a show directly over wifi.  With multi-sync the data is stored locally on the SD card and does not need to be transmitted.  Only thing transmitting is small data packets on what to play and timing info.  Multi-sync can be used wired or wireless.

Multi-sync is good for people wanting to get away from running ethernet cords to each controller.  If you wanted to control your neighbor's house across the street, or if you had an area between your house and sidewalk where you already had electricity and did not want to run an ethernet cord as a trip hazard.  If you had very large show covering a lot of area.

A lot of people use multi-sync and are very happy with it, but a direct ethernet cord to each controller is typically the simplest and most trouble free option.  I have just under a couple dozen controllers and get along just fine running over the lan. 

[trains+lights]

Thanks for the reply! It's great to hear some real-world experiences about MultiSync. I have some ideas about a wireless show in the future so I'll definitely consider MultiSync for that.

But for now, it sounds like my current method of Player Pi and E1.31 network will suit me well. I think I also read somewhere that MultiSync drops the framerate down to 20 fps (while I prefer 40 fps).

[Poporacer]

It's great to hear some real-world experiences about MultiSync.

There are thousands of people using the MultiSync over Wi-Fi without a problem. I even know of a few people that went to wireless because the rabbits and squirrels would chew through the network cables (for some reason they wouldn't touch the power or pixel cables).
My show is all Wi-Fi with 7 Wi-Fi based controllers and one F16V4 with a Pi as the bridge from the Wi-Fi to the Wired F16. 
There was even a person that had a park with 73 Wi-Fi based controllers and they worked without a problem for him.
I have seen a few people that have had problems with MultiSync over Wi-Fi and it usually was due to not configuring the controllers correctly. There are some consumer grade routers that don't handle MultiSync via Multicast, but you can use Unicast as an option.
You do need a decent Wi-Fi signal to your devices.

[JonD]

I think I also read somewhere that MultiSync drops the framerate down to 20 fps

I can't think of a technical reason why the frame rate would need to be reduced over MultiSync.  MultiSync would just be telling the controller what and when to play.  If the fseq files were rendered/saved at 40fps, I would like to think they would play at 40fps.  I glanced through the documents and specs and did not see anything suggesting that the frame rate would be reduced, but I could have missed something.

[darylc]

I think it's more about the controller CPU only be able to do 20FPS when reading from SD card v's 40FPS when receiving DDP/E1.31.

Personally I have no interest in multisync at all, until I have wireless power I'm happy to run network cables to my controllers and avoid needing to upload sequences to each controller etc.  Much easier just to have everything on 1 FPP running on a Pi4 etc.

[JonD]

I think it's more about the controller CPU only be able to do 20FPS when reading from SD card v's 40FPS when receiving DDP/E1.31.

Interesting.   When I was playing with MultiSync all my sequences were saved at 40fps.  So does the FPP connect process just render the sequences at 20fps instead, or does the controller drop packets?  Where does the reduction happen?

[tbone321]

I doubt that it has anything to do with rendering as I use Multisync for both Halloween and Christmas and render at 40 FPS and have NEVER used FPP connect so nothing would be re-rendered.  Does it really slow down to 20 fps or are just the sync packets being sent out at a 20 fps rate?  There is not much to a sync packet but I suspect that the processing of them puts a bit of a load on the players.  

[JonD]

I doubt that it has anything to do with rendering as I use Multisync for both Halloween and Christmas and render at 40 FPS and have NEVER used FPP connect so nothing would be re-rendered.

Most FPP devices are ran off SD cards.  If it was an SD card bottleneck... FPP itself could not support 40fps.  Maybe they are implying that the Falcon controllers will only play 20fps in remote mode?  I use my F-Tester as a test light string these days.  I would like to think I would have noticed it display a 20fps frame-rate when I was playing last summer, but I could have just missed it.  David and Keith have never mentioned this in the past, but I guess I never asked them either.  Not at all suggesting this is not the case, but seems odd this is not documented anywhere.   

I still would like to think that MultiSync in general supports 40fps and a Pi could be used as the remote instead of the controller as a workaround.  Hopefully someone in the know will enlighten us. 

[JonD]

I think I also read somewhere that MultiSync drops the framerate down to 20 fps (while I prefer 40 fps

I reviewed the Falcon specs, the Falcon manual, and the FPP manual.  I was not able to find anything that suggests that multi-sync will reduce the frame-rate.  There could be something to this, but I think I would question it until someone confirms.  You could always reach out to Pitts and see what he says about the matter if you are ever interested in pursuing this more. 

[dkulp]

There are different ways an SD card can be addressed/wired as well as different speeds that they can be clocked at.   The Pi and Beagles use 4 bit wide data path.  However, most embedded things like the ESPixelStick and likely the various controllers (Falcon, Genius) use a single data line.   That alone would make the FPP devices be able to handle things a lot faster.  However, the clock from the CPU to the SD card also matters.   The Beagles (being a lot older) use a slower clock than the Pi 3B+ (which is even slower than a Pi 4) which is why the Beagle hits about a 20MB/s limit whereas the Pi3B+ gets about 30MB/s.    The clocks on the embedded processors are WAY slower which results in MUCH slower read times from the SD cards which can easily account for some of the problems.   Some of the other devices (ESPixelStick and Genius controllers) don't have the memory and CPU speed to handle the compressed sequences either and thus have to transfer a lot more data off the SD card than FPP does which also doesn't help.   The Falcon v4/v5's can at least use the zlib compressed fseq files.  

[trains+lights]

I think I also read somewhere that MultiSync drops the framerate down to 20 fps (while I prefer 40 fps

I reviewed the Falcon specs, the Falcon manual, and the FPP manual.  I was not able to find anything that suggests that multi-sync will reduce the frame-rate.  There could be something to this, but I think I would question it until someone confirms.  You could always reach out to Pitts and see what he says about the matter if you are ever interested in pursuing this more. 

I'm fairly certain it was a forum post I read which, to your point, might not be accurate! Not trying to spread misinformation but I agree I did not see this in the manuals I read either.