Page 37 of 41 FirstFirst ... 273536373839 ... LastLast
Results 361 to 370 of 403

Thread: ESPixelStick - E1.31 WiFi Pixel Controller

  1. #361
    Join Date
    Jan 2015
    Location
    Gainesville, FL
    Posts
    190
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by cengiz View Post
    Hello there,

    Where to download this update.
    http://forkineye.com/
    Going on 3rd year with pixels. - Running (3) E682's (20) ESPixelSticks - 4250 Pixels - Vixen - Falcon Pi Player - http://www.facebook.com/GainesvilleXmasLights


  2. #362
    Join Date
    May 2007
    Location
    Robbinsville, NJ
    Posts
    1,521
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    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?
    Michael



    New for 2016: Getting my ESPixel network to function, 4 HDPE Pixel Arches, Pixel matrix on tree trunks. PIXELS!!!
    FACEBOOK: https://www.facebook.com/GothambeatProductions?fref=ts

    Gotham Beat Productions LLC

  3. #363
    Join Date
    Jul 2007
    Posts
    87
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by michaelc View Post
    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?
    I have seen lag pretty consistently. Depends on what part of the show for me. It seems like when there's a lot going on the wifi will bog down and the espixelsticks will lag (sometimes several seconds) behind. Doesn't seem to be consistent either. The wifi should be able to handle the rate (dedicated network, multiple APs, directional antennas, good signal strength, etc etc).

    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.

  4. #364
    Join Date
    Oct 2008
    Location
    Evansville, IN
    Posts
    292
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    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.

  5. #365
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    6,135
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by wingrunr View Post
    @jchuchla did you determine that e1.31 over wifi works better with multicast vs singlecast via personal experience? That's a bit surprising.
    It actually started a few years ago when people were starting to use WiFi bridges to send data to their traditional pixel controllers. I started doing my research into the specifics of the protocols involved at each level of the stack and discovered the details about the behavior of multicast and unicast transmissions at the radio level. So when I got involved in the early ESP R&D, I already had this knowledge in my back pocket.
    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.

  6. #366
    Join Date
    Jul 2007
    Posts
    87
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    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.

  7. #367
    Join Date
    Oct 2008
    Location
    Evansville, IN
    Posts
    292
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by wingrunr View Post
    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.
    My entire show would freeze at the exact same time so our issues are slightly different and mine are likely similar to what jchuchla posted about below. This appears to be different than what you posted. I look forward to your findings.

  8. #368
    Join Date
    Jul 2007
    Posts
    87
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by jchuchla View Post
    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.
    I don't know the specifics of the e1.31 protocol on the wire, but why would it want reliable UDP on unicast and just use normal UDP on multicast?

  9. #369
    Join Date
    Dec 2011
    Location
    UK S80 postcode
    Posts
    1,017
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by wingrunr View Post
    I don't know the specifics of the e1.31 protocol on the wire, but why would it want reliable UDP on unicast and just use normal UDP on multicast?
    Hi, multicast is a 'one to many' communication like putting something on Facebook. You send a communication out to lots of end users, but you don't need to know who, even how many there are or most importantly even if they have seen it.

    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:

    Day 1.
    Both multicast and unicast senders send first new instructions.

    Day 2.
    First new instructions in transit.

    Day 3.
    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.

    Day 4.
    Unicast sender doesn't receive a reply from Unicast so it send the first instruction again.

    Day 5.
    Multicast sender sends a second new instruction.

    Day 6.
    Unicast receives the first new instruction, implements it and sends a reply 'recieved'.

    Day 7.
    Multicast receives the second instruction and implements it.

    Day 8.
    Unicast sender receives the 'received' and send the now late second new instruction.

    Day 9.
    Unicast second instructions in transit.

    Day 10.
    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.

  10. #370
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    6,135
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by wingrunr View Post
    I don't know the specifics of the e1.31 protocol on the wire, but why would it want reliable UDP on unicast and just use normal UDP on multicast?
    It has nothing to do with e1.31. And it has nothing to do even with UDP vs TCP. This is an 802.11 wifi thing. It's not at the protocol layer, it's at the transport layer. That's a lower level mechanism that's in play regardless of the protocol and application layers on top of it. This is something we have no control of from our side of the picture. It's inherent to how WiFi works. So long as we're using regular WiFi equipment , it's something we need to work with.

Page 37 of 41 FirstFirst ... 273536373839 ... LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •