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

Thread: How you tell if your system is healthy?

  1. #21
    Join Date
    Dec 2015
    Location
    Blaine, MN
    Posts
    82
    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
    819
    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
    234
    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
    388
    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?

  5. #25
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,600
    Post Thanks / Like

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

    Quote Originally Posted by Jerry-Rigs View Post
    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

    Is that timer driven or just a no delay loop, or will it vary by controller?
    It will vary by controller design. Some of the controllers will show the refresh rate of the pixel strings, and it varies based on the number and type of pixels. That suggests that controller design sends the frames back to back at the speed required by the particular pixel protocol. And it's also a clue that the pixel drive is asynchronous from the sACN data reception.

  6. Thanks Jerry-Rigs thanked for this post
  7. #26
    Join Date
    Jan 2016
    Location
    Ashburn, VA
    Posts
    388
    Post Thanks / Like

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

    jchuchla (and others),
    I appreciate your time indulging and educating me.

    Quote Originally Posted by jchuchla View Post
    That suggests that controller design sends the frames back to back at the speed required by the particular pixel protocol.
    The point of my theoretical Metric Pixel would be for it to be somewhat standalone and not require interaction with the show or controller. A free running pixel frame loop that is decoupled from the input side would prevent my MP from deducing anything useful by itself.

    Quote Originally Posted by jchuchla View Post
    ...at the speed required by the particular pixel protocol.
    I do not have any experience and little knowledge at the pixel protocol level. You imply that pixels require a certain frame refresh rate ("frame" being a complete set of RGB values for all the pixels on that string).

    I was under the impression that, at least with ws2811, the chip would hold a given RGB value as long as it had power. That means there is no "maximum" refresh time. I have seen "stuck" strings where I had an intermittent connection for data but a good connection for power and gnd which would tend to support that impression.

    On the short end, it makes sense to me that the pixel chip takes some amount of time to process and forward data so there is a propagation delay from the start of the string to the end of the string. We can visually see this on really long strings. Since every chip acts independently (I think), it seems it would be possible to send a new frame to the start of the string before the old frame has made it all the way to the end of the string. As long as there is some delay between frames, I don't think there is a fear of the new one catching or overtaking the old one but I imagine that pixel controllers try not to send a new frame until the previous frame has completed. The controller knows the kind of pixel it is driving (and associated timings) and how many there are so it would be able to calculate the minimum refresh time for the string.

    An interesting test (who am I kidding, I am in deep geek territory here. I think its interesting but, well ...) would be to have a long string and slam it with 2 alternating colors. If the controller sends a new frame before the old one is finished, I would see kind of a long marque effect. But I don't know that I could generate a show sequence that would alternate fast enough to produce the effect, even if the controller would even stack frames that way.

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
  •