Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: Jumbled output

  1. #11
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,390
    Post Thanks / Like

    Default Re: Jumbled output

    Quote Originally Posted by mrGrumpy View Post
    As I recall, you could only do 1 universe with Unicast. Did that change with Flash v3-1
    I don't think that was ever a limitation. not that unicast is a good idea in the first place, but it's been supported on the ESP as long as I can remember.

    There was a bug before 3.0 where only the first multicast universe would send IGMP subscriptions, but that was fixed in 3.0.

  2. #12
    Join Date
    Jan 2015
    Location
    Folsom, CA, USA
    Posts
    1,639
    Post Thanks / Like

    Default Re: Jumbled output

    No, Jon, not supported prior to FlashTool RC 3.0 for sure. Although Shelby talked about a fix, I never heard word it got done. Until today, I had not tested after Flash RCv3.0 - however, just tested 3.1 and unicast will do more than I universe now . . . will change those back to Multicast now that test is over.
    In Lights Therapy

  3. #13
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,390
    Post Thanks / Like

    Default Re: Jumbled output

    I guess I just don't remember the pre 3.0rc versions all that well. I know I have one still running 2.x, but it only has 10 pixels on it. I know it's worked since 3.0rc, which is the majority of the mainstream life of the espixelsticks anyhow. The thing that's not making sense is that I know multiple multicast universes didn't work before 3.0rc2, so if multiple unicast didn't work either, how did anyone get any more than one universe out of it back then? I know it was done, I had some running that way myself.

  4. #14
    Join Date
    Nov 2016
    Location
    Washington State
    Posts
    135
    Post Thanks / Like

    Default Re: Jumbled output

    Ok I have actually got Multicast working in Vixen, and I have also realized I was incorrectly counting universes and was short 1. My Trim Prop (lights around doors and windows) is 552 channels so that is 2 universes and I had it as 1. I reconfigured Multicast in vixen and tested as working. now I am exporting from vixen again and I will test multicast in FPP

  5. #15
    Join Date
    Nov 2016
    Location
    Washington State
    Posts
    135
    Post Thanks / Like

    Default Re: Jumbled output

    Prop output is now correct using FPP. Pretty sure it was the missing universe. Multicast is laggy and stuttering. Need to work out my network, but Unicast is working perfectly for now.
    Thanks for the help.

  6. #16
    Join Date
    Jan 2015
    Location
    Folsom, CA, USA
    Posts
    1,639
    Post Thanks / Like

    Default Re: Jumbled output

    Hmm....Multicast is no issue for most. Check to see if you enabled Multicast in ESP
    In Lights Therapy

  7. #17
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,390
    Post Thanks / Like

    Default Re: Jumbled output

    Whenever you see multicast stuttering on wifi, there's only two things that can be causing it. 1) there is more multicast traffic than can be sent out from the AP with the given multicast data rate, or 2) unicast traffic is buffering and retrying and delaying the interval. A multicast packet cannot in itself cause delays at the access point. But it does get lower priority than any and all unicast traffic.

    Remember to think of the network as a whole. Don't get stuck on just the sACN traffic. All traffic counts in the equation. Even just having the web interface open on the ESPixelStick is generating additional traffic, and that traffic is unicast.

    Also remember that you're not building a general purpose wifi network for this, you're creating a specialized network for a specific purpose and specific data requirements. So things you don't give any thought to on a typical general purpose network can play a significant role in this particular specialized case.

    Multicast traffic is sent out from the AP at a data rate that's the lowest common denominator rate that all clients can handle. So it's determined by the client with the poorest connection at any given time. If you have one client on the AP with a low signal and it has negotiated a 2mbps data rate, that will be the data rate of all of the multicast sent from that AP. For this reason, it's important to make sure you have a good strong signal strength to all client devices. This behavior can sometimes be overridden or altered on some WAPs, but not all, and the terminology and process to adjust it will vary by model. The nanostations can be tweaked for this but it goes well beyond the web interface to get it done.
    If you have any clients in sleep mode (that cell phone in your pocket you used for testing?), then that number is discarded and it becomes the minimum rate possible since sleeping devices can only receive at the lowest possible rate. So keep any devices that can use power saving mode off of the network. This typicially includes cell phones, laptops, tablets, anything with a battery.

  8. #18
    Join Date
    Nov 2016
    Location
    Washington State
    Posts
    135
    Post Thanks / Like

    Default Re: Jumbled output

    Currently only my ESPs are on my PixelStar Ubiquity network. save for a couple of smart switches that I know I need to move to my DeathStar network.

  9. #19
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,390
    Post Thanks / Like

    Default Re: Jumbled output

    The best way to know for sure what traffic is on your wifi is to use a WiFi packet analyzer with a wireless nic that supports monitor mode. This will let you see all of the traffic on your wifi network. From there, you can start to manage things better.

    To see some of the relevant stats on the AP, you can SSH into the WAP and use some common utilities. make sure to SSH in from the wired side of the AP so you can be sure your diagnostic PC isn't itself causing extra traffic on the WiFi side.

    use the command:
    Code:
    iwconfig ath0
    it will produce something like the following:

    Code:
    ath0      IEEE 802.11ng  ESSID:"MySSID"  Nickname:""
              Mode:Master  Frequency:2.452 GHz  Access Point: xx:xx:xx:xx:xx:xx
              Bit Rate:57.777 Mb/s   Tx-Power=23 dBm   Sensitivity:0/0
              Retry:off   RTS thr:off   Fragment thr:off
              Encryption key:F3E2-40E6-7AB5-2653-B6E5-6E84-XXXX-XXXX [3]   Security mode:open
              Power Management:off
              Link Quality=30/94  Signal level=-66 dBm  Noise level=-95 dBm
              Rx invalid nwid:1116931  Rx invalid crypt:0  Rx invalid frag:0
              Tx excessive retries:0  Invalid misc:0   Missed beacon:0
    Key things to look for here
    Retry should be off
    Power Management should be off

    Bit Rate should be on the higher side. If it's not greater than 36 then there's issues that need to be addressed.

    Tx excessive retries should be 0 or very close to it. if it's not, that needs to be addressed.

    If you're seeing lag, you'll probably be seeing the Missed Beacon counter going up. Every time the beacon is missed, the multicast data will be late. This is usually caused by excessive retries causing the delay in the beacon.

  10. Thanks tecnageek thanked for this post
    Likes tecnageek liked this post
Page 2 of 2 FirstFirst 12

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
  •