Page 3 of 3 FirstFirst 123
Results 21 to 24 of 24

Thread: How you tell if your system is healthy?

  1. #21
    Join Date
    Dec 2015
    Location
    Blaine, MN
    Posts
    77
    Post Thanks / Like

    Default Re: How you tell if your system is healthy?

    All I would like is an FPP plugin that pings all my controllers at the start of a show (maybe at each playlist repetition) and email me if there is a down controller. Occasionally one of my pixel sticks or variants thereof would freeze and the only clue was stick on lights, or unresponsive lights. Of course that would also work for a GFCI trip as controllers on that line would be dead.

    Wish I had the smarts or time to build something like that! I seem to recall someone making a script to do this but haven’t been able to find it.


    Sent from my iPhone using Tapatalk

  2. #22
    Join Date
    Dec 2012
    Posts
    806
    Post Thanks / Like

    Default Re: How you tell if your system is healthy?

    Quote Originally Posted by th182 View Post
    All I would like is an FPP plugin that pings all my controllers at the start of a show (maybe at each playlist repetition) and email me if there is a down controller. Occasionally one of my pixel sticks or variants thereof would freeze and the only clue was stick on lights, or unresponsive lights. Of course that would also work for a GFCI trip as controllers on that line would be dead.
    This will be much easier once we update the fppd REST API to expose the “downed controller list” that fpp uses. You could easily make a cron job to check the list every minute and send out an email if needed. I can’t remember if Dan was looking at that but I have been wanting it so I may do it if he doesn’t.

  3. #23
    Join Date
    May 2016
    Posts
    189
    Post Thanks / Like

    Default Re: How you tell if your system is healthy?

    Quote Originally Posted by sporadic View Post
    At one time I was entertaining the idea of an onboard current monitor that you could correlate with show data to determine if a string goes out. Power injection kills it though.

    Sent from my Moto G (5) Plus using Tapatalk
    Could you add fields for entry of power injection information (PSU voltage/current and location of the injection point) and use that to establish a “system-wide” baseline? I assume that your original concept would rely on detected change in current to determine if a string was using current (and therefore was live).

  4. #24
    Join Date
    Jan 2016
    Location
    Ashburn, VA
    Posts
    344
    Post Thanks / Like

    Default Re: How you tell if your system is healthy?

    I have 2 goals,
    First goal is the connectors.
    Second is
    Quote Originally Posted by jchuchla View Post
    If all you're concerned about is data transfer across the connector, then your 4th train of thought is the most appropriate. It could be a dual channel scope. One channel on each side of the connector. You'll be looking to compare the waveforms from each channel. Knowing how to interpret the differences requires a bit of knowledge, but recognizing a that there's a difference is easy.
    ...
    But really, aside from changes in environmentals, the differences across the connector will remain rather constant. There's not much need to monitor it over time. Spot checks would be sufficient.
    Yeah, the 2 channel scope approach makes a lot of sense to me ... but I don't have the equipment or know how to use it. How much would an adequate scope cost? If anyone else has the gear, I can supply the connectors.

    Second goal is detecting excessive lag time especially in wireless setups. This comes from comments made a different thread.

    Quote Originally Posted by jchuchla View Post
    All of the current pixel controllers will refresh the entire string of pixels on every update.
    Useful to know. Thanks.

    Quote Originally Posted by jchuchla View Post
    For any reliable results, you want your monitoring system to be out of band from the system you're monitoring. IN other words, don't use the same network to carry diagnostic data as you're using for the data you're monitoring. They really should be isolated systems, decoupled as much as possible.
    Agreed, I am thinking data logging to SD card.

    Quote Originally Posted by jchuchla View Post
    Trying to read the data at the end of a pixel line against data sent from a controller is going to require intimate knowledge on how the controller's firmware works. Some are synchronous, some are asynchronous. For example, the last time I looked at the 681 firmware was baco around version 2. But I bet it's still similar. The processes that collected sACN data from the controller and the process that drives the pixels are completely decoupled. The listener part listens to the sACN data coming in, and stuffs it into a buffer. The pixel drive part just loops thru the buffer constantly refreshing the pixel string. So you have no correlation (except for perfect world math) between data frames received vs pixel frames sent. This is an asynchronous design. Each controller make and model may do this differently. it could be the opposite where the controller only refreshes the string once per received packet. The way to know which way is to send the controller some data and then stop. Then within a minute or less, unplug the pixels and plug them back in. If they come back to where they left off, it's constantly refreshing. If they don't come on, or come on to something other than before, then it's probably only one refresh per data packet or a synchronous design.
    Hmm, I wasn't thinking of the controller design. So, even though the show player is sending updates at some frame rate, the receiving pixel may not be in step with it because of how the controller works.
    When you say
    Quote Originally Posted by jchuchla View Post
    The pixel drive part just loops thru the buffer constantly refreshing the pixel string.
    Is that timer driven or just a no delay loop, or will it vary by controller?

Page 3 of 3 FirstFirst 123

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
  •