We have a wireless router in our setup that lives in the attic alongside the Raspberry Pi and pixel controller. This is a Linksys E1000 router (~$50 on Amazon these days), which is the same model we had used as the router for our house for years. This router has proven to be reliable over years of operation and is easy to setup and configure. We tried a cheap newer router model early on in our testing process and ended up returning it because it would drop connections too often.
The wireless router serves a few purposes. First, it lets us log into the Falcon Pi Player and our pixel controller web interfaces without having to crawl up into the attic to plug in a cable. Second, as our display grows, we are adding more and more elements for which wireless control is preferable to hard wiring.
Not being networking experts, we weren’t sure how reliable Wi-Fi would be for controlling lights, particularly during fast sections where the lights are changing a lot very quickly. Having a separate network that is dedicated to Christmas lights made us feel better that our actions wouldn’t interrupt the light show. We did not want to have to choose between running the light show or watching something on Netflix on our laptop!
We currently do not have any connection between the two networks in our home. When we want to interact with the lighting pieces, we simply switch which wireless network our laptop is connected to. It only takes about 10-15 seconds to switch over to our “TwinkleTwinkle” network (yes, we did in fact name it that!). There are probably ways we could bridge our two networks together such that they are isolated for when it matters but can still receive traffic across the boundary when we want. Perhaps we will look into this at some point but having them as two distinct things just has not been a problem and it 100% guarantees that we won’t cause an issue through our internet usage.
IP Address Reservation
In order to keep better track of all of our networked devices, we are using DHCP reservation through our router to assign preferred IP addresses to each device. This is effectively the same as assigning a static IP address to each device, but the configuration lives centralized on the router rather than at each device.
Having a consistent address allows us to configure all of the connections in Falcon Player and have them stay the same even if the router gets rebooted. Again, we are not networking experts and there are probably a lot of things we could do better in this area. Falcon Player likely supports more network functionality than we give it credit for, but our show is working fine as is so we have no intention to rock the boat at this time. As we grow and add more and more elements (particularly wireless ones), we may need to reassess our networking setup and configuration to improve performance.
We have a table tracking all of our reserved IPs, along with other information, on the Channel Output Mapping page.
Wi-Fi Spectrum Channel
One thing to consider if Wi-Fi is going to be used as part of the show is the risk of interference from other devices or other Wi-Fi networks. At one point, both our show network and our home network were using the same part of the Wi-Fi spectrum, which introduces lots of opportunities for collisions and general inefficiencies. We now force our two networks to opposite ends of the spectrum (channel 5 for the show network and channel 11 for the home network) in an attempt to get as much performance as possible from our network.
There are a bunch of free apps out there (for Android at least) for viewing the Wi-Fi spectrum environment around you. We downloaded one that seems to work quite well (Wifi Analyzer by farproc) and it allows us to view both our networks as well as all of the neighbor’s networks around us to see where the spectrum is overloaded and where there might be gaps that we can use.
Unicast vs. Multicast
The one big question we had to answer for our display was whether to use unicast or multicast networking.
Briefly, in unicast networking, you tell the router the destination for the message and it sends it directly and uniquely to that end device. Since this is a point-to-point scenario, it also expects an acknowledgement back from the device and will resend packets several times as needed if that acknowledgement doesn’t come.
Multicast networking is a “publish and forget” style of networking. Here, the same packets are sent to every node in the network and it is up to the receiving client to decide if they care about the data or not. Since the router doesn’t actually know the intended recipient, it does not require any acknowledgement of the data. Since lighting data is, by definition, extremely time sensitive, we really don’t need the acknowledgements and retry cycles that come with unicast. If we miss a packet of data, we don’t want it redelivered; instead, we just want the next packet and we will pick up there.
We use unicast for all of our wired elements since the wired connections are very reliable and it lessens the amount of data being sent across the network. Perhaps multicast would work as well but why rock the boat. Up through 2017, we used multicast for the wireless elements. While this does mean that a lot of data is being blasted across the network, we had found it more reliable than unicast when Wi-Fi is involved. For a detailed explanation of why, see the case study below.
However, in 2018, we encountered additional lag issues after moving universes 6 and 7 to be wireless as well. We don’t really know the root cause but moving all the ESPixelStick Pixel Controllers to unicast solved the problem so we are calling it a win and moving forward with our lives.
The Great Networking Lag of 2017: A Fun and Frustrating Case Study
In 2017, we encountered some interesting lag issues where our wireless elements in the yard would occasionally fall behind in the timing, often by several seconds. Sometimes things would correct themselves and get back in time, but often the condition would persist and worsen at various points in the show. At times, we even saw the wired elements start to have timing issues as well, which was quite unexpected. What made this even weirder was that we ran for about 4 days without any incident before these symptoms started showing up. Finally, after 2 days worth of troubleshooting, we finally traced the problem to a wireless media bridge we had added to the system.
Original Setup
First, some background. The addition of a second Sandevices E682 Pixel Controller in the garage necessitated a solution for connecting to our Twinkle Twinkle network. Unfortunately, the E682 only supports a wired Ethernet connection and the garage and attic are a fair distance away from each other with no good way to run a cable.
So, we searched through our old electronics and pulled out a TRENDnet N300 Wireless 4-Port Media Bridge, (model TEW-640MB). We bought this device 5 years ago to connect our printer to our home network, but never really made use of it. Essentially, it just connects to a wireless network and has 4 ports for Ethernet cables to connect to other devices. This particular device is no longer manufactured but there are other similar things on the market.
We powered the media bridge from the same 12V power supply that powers the pixel controller and provides power injection. The entire setup lives in the corner of our garage on a small shelf. As far as we can tell, the media bridge is sufficiently fast such that the timing of the show is unaffected.
How We Fixed It
After trying several other things like switching the wireless elements to multicast and moving the network to a cleaner part of the Wi-Fi spectrum (both good things but neither sufficient to solve the problem), we finally decided to try bypassing the wireless media bridge to see if that made a difference. Philip climbed up on the roof to reroute the Ethernet cable for the security camera to instead come out of the attic vent, down the roof, and into the garage to directly connect to the pixel controller. This one change worked wonders.
We can’t be entirely sure of what truly fixed the problem but the combination of steps did the trick. It’s unfortunate that we have to have a cable run from attic to garage but well worth it for the reliability that a wired connection offers. We have our wireless connections limited to those places where we really have no other good options, like in the yard and at the various interior windows.
Broomfield Lights 