A little update update from me as well.I put the SD card with the original image on it back into the pi and set it up and everything works again. I have another pi that I did the same setup to run a p 10 panel but this one is driving a colorlight card and that one's working perfectly on the new image. It looks like there's something going on with the new image and the pi hat.

I took the Pi 3 that had Version: v1.x-master-122-g1e88034b (master-v1.x branch) running that was largely locked up with the Gateway Time-Out, and re-imaged the SD card. This got it working again, but again after several changes, it started locking up again. Pulled it out and again re-imaged the SD card. This time I kept a log of everything that I did.

To sanity check my panel power & connections, connected other Pi 3 to same Pi-Hat.Version: v1.10-27-g259bc38 Worked perfectly - both from Channel output testing and bridge mode from LOR S5

Reset Network Preference in LOR back to the semi-locked up Pi. The status page shows traffic on all 36 universes, but unable to get the lights to come on - either from channel test mode or via bridge mode from LOR.

ok good to know, so should I lean towards grabbing a Linsn board or hold off and the Colorlight will be optimized to the same or similar packets? I know someone mentioned (may have been you) that the Linsn ones are a little more of a pain being it goes by Mac address and so on

I would stick with the ColorLight if it is working for you. The main reason I mentioned that is in case you try to do anything else with the system such as E1.31 or you try running 25ms sequences.

The MAC address issue isnít that much of a pain but it is one more setup step you have to deal with.

I am planning on ditching a bunch of my LOR stuff and getting Falcon controllers (F48 and a bunch or receiver cards) running sequences at 20ms, will that be effected? also adding a second screen so I will have 2 Pi's and 2 color lights running 108 panels total

ok good to know, so should I lean towards grabbing a Linsn board or hold off and the Colorlight will be optimized to the same or similar packets? I know someone mentioned (may have been you) that the Linsn ones are a little more of a pain being it goes by Mac address and so on

I would stick with the ColorLight if it is working for you. The main reason I mentioned that is in case you try to do anything else with the system such as E1.31 or you try running 25ms sequences.

The MAC address issue isnít that much of a pain but it is one more setup step you have to deal with.

I converted a pi that I have hooked up to a 3x3 P10 panel setup with Ron's octoscroller.I have everything up and running and configured and it's receiving packets but no matter what I do I can't get the panels to work. I'm trying to run it in bridge mode from Xlights.

I converted a pi that I have hooked up to a 3x3 P10 panel setup with Ron's octoscroller.I have everything up and running and configured and it's receiving packets but no matter what I do I can't get the panels to work. I'm trying to run it in bridge mode from Xlights.

Most professional fixtures are going to be more than $1000. You can also check out https://www.usedlighting.com to see what used movers you can find. eBay is probably going to be your best bet for finding something under $1000.

If you are going for the Beam look, keep in mind that there has to be something in the air for the light reflect off of to create the beam of light. Proís use Hazers to put a fine haze or mist in the air. With running these outside, itís really hard to keep a man made haze in the air. If there isnít anything in the air you really just see the light at the fixture lens and on the object that the beam ends up hitting. Not saying donít do it- Movers are cool, just want you to be aware of this.

the 384 was what fixed it, I had it on 192 being that was "real" amount of pixels from left to right but I see now that I needed the pixel count of the entire panel and then FPP takes care of it all, THANK YOU!!

Great. One thing to keep in mind is that this is the equivalent of sending 128 universes of E1.31 since the ColorLight protocol uses one packet per LED row. This is why I need to optimize the ColorLight code to use the same sendmmsg() call that Dan added to the E1.31 Channel Output when he optimized the E1.31 code. This is where the Linsn receiver actually can be more optimal since it packs the data into large packets, so it can send fewer packets than rows.

ok good to know, so should I lean towards grabbing a Linsn board or hold off and the Colorlight will be optimized to the same or similar packets? I know someone mentioned (may have been you) that the Linsn ones are a little more of a pain being it goes by Mac address and so on

That usually means that some of the current being sent out of the supply is going to ground rather than returning on the common line. It only takes a few mills of that to cause a GFCI to trip. Dirty boards with a little condensation on them can cause that to happen and where it will not stop the supply from working, it can cause a GFCI to see it as an issue and trip.

The reason I asked is that the primary to secondary transformer windings should isolate the grounds. When I check resistance (power off) between AC input and dc outputs, it is high resistance. That should prevent gfci tripping from your dc loads.

Sent from my SM-G955U using Tapatalk

Yes, it should and under normal conditions, that is exactly what it does. But many of these supplies do not have the line and common directly connected to the transformer with no other components between them. Even the transformers are not always perfect and can leak primary current to the core under high moisture situations and the core is usually grounded.