Troubleshooting Lagging, Stuttering, Buffering, Freezing or Glitching on HolidayCoro Controllers (HinksPix PRO, AlphaPix)

Troubleshooting Lagging, Stuttering, Buffering, Freezing or Glitching on HolidayCoro Controllers (HinksPix PRO, AlphaPix)

PROBLEM:  My AlphaPix or Hinkspix controller exhibits the following problems:
  1. When a sequence of data is coming from a sequencing application such as xLights, Light O Rama or a Falcon Pi Player the data
    1. Stops, then starts again after a period of time (buffering or stuttering)
    2. Skips parts of the sequence
    3. Stops playing for some period of time and then restarts
  2. This does not apply when using the Hinkspix Pro when playing sequences from the built-in SD card
BACKGROUND:  DMX (or sACN or E1.31) is a synchronous protocol.  This means that at the millisecond the data is output by a device, it is sent to a controller, then turned into pixel data that then turns on pixel data.  There is no function within the DMX specification to allow for "buffering" of data - this just is not possible.  Because DMX is synchronous, this means that anything between the point where the data is created (sequencing software, Falcon Pi Player, Console, etc) and where it is consumed (pixel controller), there can be no delays or buffering or otherwise the data will exhibit lagging, buffering or dropped data.  All HolidayCoro pixel controllers adhere to the DMX standard and have ZERO buffering in their design.  In Fact, the Hinkspix and Alphapix do not have enough memory to "store" DMX data for buffering, the memory is only sufficient to ingest E1.31/sACN/Artnet data and then convert it to the pixel protocol - e.g. 2811, etc and send it out to the pixels.  So it is impossible for the pixel controller to induce lag.

SOLUTION:  There are many layers that DMX data needs to pass through from the source application to the controller and those are listed below along with possible causes:
  1. Source Application or Console - When an application is running on a non-Realtime platform like Windows, MacOS or Linux (Falcon Pi Player) which have the ability to run multiple applications at once, the OS must "switch" between applications and if another application is "hogging" the CPU, this will result in delayed output of data from the application.
    1. Recommendation - Test from another physical device or computer.  Test using a different application on the same physical device.  Turn off any "antivirus" application that might be "checking" the applications output.
  2. Firewalls on PC - By their nature, a firewall "inspects" the network traffic and can induce delays, that while fine for asynchronously browsing the internet, cause serious problems when they delay DMX packets going to a device outside the PC.
    1. Recommendation - Turn off the firewall while testing.
  3. Network Cables or Poor Network Functionality
    1. Wired networks - Poor quality network cables can result in inconsistent network data transfer.  We have seen network connections that "link" up but still either don't or have so many errors that data is lagging.
      1. Recommendation - Test using a factory made network cable directly from controller to PC source with as short of a distance as possible.  If you personally made the cable and unless you have a $1,500 network cable tester - assume your cable is bad not matter how good you are a making network cables up.
    2. Wireless networks - NEVER NEVER use wifi as part of a network to send DMX data.  We have an entire article on why wifi is not a good choice for sending data.  This applies if ANY part of the network from PC to controller is wifi. 
      1. See:  https://support.holidaycoro.com/portal/en/kb/articles/wireless-networking-options-for-e1-31-and-e1-11-controllers
  4. Network Infrastructure (switches, hubs, router/modems) - Any device between the PC and the controller can induce problems and we have seen hundreds of variations of this.  This includes everything from filtering to QOS - if there is a device between your PC source data and the controller - REMOVE IT for testing purposes - no matter how sure you are that the device is not "messing" with the traffic or how well it is configured, the only sure way to determine if it is the root cause is to remove it from the network chain. 
    1. Recommendation - Run the shortest network cable from the source PC directly to the controller.
  5. Conflicting Devices - While rare, we have seen cases where there are duplicate IP addresses of the controllers IP that then "duke it out" trying to maintain their IP address as the primary.  T
    1. Recommendation - Run the shortest network cable from the source PC directly to the controller.
  6. Overwhelming the Controller with "monitoring" Traffic - Pixel controllers do not have extremely powerful CPU's and they also do not have firewalls or other things that would prevent external "attacks" against the controller.  So effectively, it is possible to DOS (Denial of Service) a controller either by sending ICMP packets (PING command) or excessive HTTP polling requests to the controller.
    1. Recommendation - Turn off any "monitoring" in applications like FPP (see this article:  https://support.holidaycoro.com/portal/en/kb/articles/alphapix-evolution-network-disconnects-when-used-with-fpp-falcon-pi-player).  If you have Home Assistant or other applications that "PING" check devices to see if they are on or off the network, turn them off.