Has anyone experienced lag with the Espixelsticks? I was running fine and then tonight I noticed the Espixels were lagging, everything else seemed fine. What is the cold rating on these?
New for 2016: Getting my ESPixel network to function, 4 HDPE Pixel Arches, Pixel matrix on tree trunks. PIXELS!!!
Gotham Beat Productions LLC
Since the season is pretty much over I was planning on upgrading them to v2.1 and seeing how things go. I'm also wondering if the lag is linked to their relative uptimes as I don't remember the lag being present when I first set up the show this year.
@jchuchla did you determine that e1.31 over wifi works better with multicast vs singlecast via personal experience? That's a bit surprising.
I have no experience with the espixelsticks (hoping to obtain some this year), but have supported many corporate wireless installations as well as ran my show wireless this year. I had instances of lag across all elements (all are wireless) and upon checking one of my items received signal strength ranged anywhere from -69 to -78 dbm depending on the time of day, weather conditions, etc. (most times was at -72dbm). I did not have a dedicated wireless AP but did have a dedicated wireless SSID for the lights.
-72 dbm is border line for reliable (consistent) operation. I moved the wireless bridge for this item to a location closer to my ap where signal averaged around -65dbm or better and did not experience lag again. I will say this was only 1.5 weeks of consistent operation with no issues after I moved it so it could have not been the smoking gun it appeared to be. However, I had multiple issues up to that point each week. My show was setup for unicast and this situation can cause a larger problem if using unicast as it will drag the entire show down instead of just one element as I would think would happen with multicast (I have never used multicast wireless).
I relied upon my wireless controller to tell me what it saw the devices signal as but you can use a wifi analyzer on your phone to give you a good idea. Do keep in mind that inside an enclosure around electronics is not the same as just checking signal in the location before you place your items so I would suggest you double check after installation if possible.
When you think about it, it really makes a lot of sense. First of all, WiFi is highly unreliable on a packet by packet basis. The only reason most WiFi applications work well is because things get retransmitted fast enough and as many times as needed to get it to you when you need it. There's not much data in the average HTTP request, which is the vast majority of WiFi uses out in the wild. If a webpage loads slowly, that's ok. The data is still relevant when it gets there. It's more important in this case that the data arrives intact so the page renders correctly.
Most things that are sent via multicast are intended to be used by multiple devices at the same time. This could be video broadcast streams, audio paging, lighting control or network control and discovery messages. What they all have in common is that they are one way. These applications don't need any information back from the receiving device. In a few cases (like mDNS discovery), messages do get returned, but via a different method. Another thing they have in common is that the timely delivery of data is more important than the accuracy of the data. Most of these applications involve situations where the data is irrelevant if it's late (audio, video, lighting streams) or will be repeated again at a regular interval anyhow. So the error correction just adds overhead that isn't needed, or is actually detrimental to performance. That last part is what we're seeing with unicast sACN transmission.
Packets are going to drop just the same in either case, but on multicast, it doesn't stop to resend it. It just drops it and continues with the next packet. Chances of seeing the missed frames in your show are much lower than seeing the wrong frame. With unicast, every transmission needs to be acknowledged as correctly received, and if it gets a NAK (not acknowledged) or nothing at all, it'll try a few more times to send it, thus putting the next data later in the queue.
The ESPixelStick firmware reports current connection strength so no need to use a wifi analyzer on a phone (which will be rough anyway. Most new phones have more than a small ceramic antenna). One of my ESPixelSticks is about 8 feet from an access point and another is about 12 feet from a different access point. That should be negligible distance and I still see lag. I'm not convinced it's an issue with the wifi network itself. I don't see lag on the wired side and I'm running 25ms timing. I'm almost wondering if I'm overloading the ESPixelStick itself.
I'm pretty familiar with networking and the like so we'll see what my tinkering yields.
Unicast is a 'one to one' communication like an email with a read request. You send it to one person and check that they have read it, if not you can send it again and again untill you decide they are no longer receiving your emails and you stop sending them all together. Sort of in terms I understand.
The implications of the two are:
Multicast; would be ideal if it wasn't for the fact that the controller has to check every packet that arrives to see if is for it. Think of a communal post box (letters) where you have to check every letter to ensure that you get all of yours but this taks time every day.
Unicast; has advantages and disadvantages. You have your own post box (letters) so no need to check through lots of mail, but the post man may from time to time put your mail in the wrong box. You have a cunning way round this, every time you receive a letter you send a quick reply to the sender to say you got their letter. Fool proof!
Lets see, assume a letter takes two days from sender to receiver and our time frame (FPS) is five days:
Multicast; sends a letter (mail shot) with some instructions every five days. Once you have been down to the mail box and sorted through all the post, which is a pain and takes quite some time that you could be doing other stuff. If after all this you have mail you carry out the new instructions, if not you continue with the last instruction (packet lost) until you get a new one in five days.
Unicast; sends a letter (to you) with some instructions every five days. You check your post box, have mail, reply to the sender and implement the instruction. Cool but when it goes wrong.
You check your post box, have NO mail, DON'T reply to the sender and continue with the last instruction. Ok so thatís only the same as Multicast. But because Unicast expected a reply after four days (2 days post to you & 2 days post for a reply) Unicast sends the same message again. This time when you check your post box, you have mail, reply to the sender and implement the instruction, but you are now 4 days behind multicast.
One bad packet time line:
Both multicast and unicast senders send first new instructions.
First new instructions in transit.
Multicast doesn't receive first new instructions and continues with the last instruction.
Unicast doesn't receive first new instructions and continues with the last instruction.
Unicast sender doesn't receive a reply from Unicast so it send the first instruction again.
Multicast sender sends a second new instruction.
Unicast receives the first new instruction, implements it and sends a reply 'recieved'.
Multicast receives the second instruction and implements it.
Unicast sender receives the 'received' and send the now late second new instruction.
Unicast second instructions in transit.
Multicast sender sends a third new instruction.
Unicast receives the second new instruction, implements it and sends a reply 'received'.
This makes unicast look bad but its horses for courses and it depends what you want to do. In an ideal world we would have a protocol that had all the advantages of unicast (your own post box) but without the need to reply to the sender to say you had received the letter (multicast) before the next one was sent.