Replies: 1 comment 6 replies
-
|
If your observations are correct, it's probably more about HyperSPI, but I have the same setup using HyperSPI, and the grabber shuts down every time the movie ends, the light goes out (the HyperSPI LED driver is off), and then turns back on a few seconds later when the Home Center changes resolution and the Grabber starts working again (and so the HyperSPI LED driver). So, at least I can't replicate these symptoms, unless the problem lies elsewhere for example in your grabber:
240 is the grabber, 255 is no source |
Beta Was this translation helpful? Give feedback.
-
Typically, the problem lies in grounding (or creating unstable ground loops) or faulty LEDs. However, if you replaced the SN74AHCT125N and it works again, it may actually have been faulty, unless you changed something in the connections and you're unaware of it. If the priority is 240 (and the screen isn't black) and the LED driver is working properly in HyperHDR, replacing the capture device doesn't make sense, especially if the HyperHDR effects aren't working either. When that happen you can test the test procedure (last point in the latest blog post and HyperSPI home page) to ensure that SPI communication is established despite the LEDs not working. |
Beta Was this translation helpful? Give feedback.
-
|
grounding was my first bet too and I carefully and extensively checked all grounding circuit from power supply to the ledstrips to esp32/raspberry, I have resolded some cable part too (I was less skilled at the time and did a mediocre job) but only replacing the chip solved it. Maybe I solved some grounding connection doing so and this time the chip will last, only time will tell. |
Beta Was this translation helpful? Give feedback.
-
|
I throughly monitored the incidence of the problem after I upgraded the hyperhdr host and the problem seems gone for good. I could dig deeper to see what packages have been upgraded but I don't have the skill required to analyze the diff and find the culprit. If this will be a mere coincidence (tried to exclude that monitoring it for over a week), I will try to test the hyperspi connection first and I'll let you know, thank you for the prompt support |
Beta Was this translation helpful? Give feedback.
-
|
that was indeed too good to be true: it happened again.
Then I stopped the hyperhdr service as suggested and executed the serial command again
I restarted the service again and the output is the same as above, this time leds turned on (without rebooting, that was a crucial step to bring them on until last time it happened) what could it be? |
Beta Was this translation helpful? Give feedback.
-
|
Im not sure: next time please, just disable and enable LEDs in the remote tab and take logs. But since the led driver was working (after service restart) maybe the video source died? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)
I'm facing a weird behaviour and can't pinpoint the origin. When I restart hyperhdr host it won't pick up captured video, and the ledstrip goes straight to the enabled boot effect color. To make it works correctly I need to restart hyperhdr service on the host and, for some times, it works without problem.
Then, after some hours (can't detect a pattern), where the source was turned off, once I turn it on the ledstrip won't emit any light, altough the hyperhdr live video preview is correctly showing captured video.
To fix this I need to reboot the host and doing so the problems circles again.
here the logs straight after the host boot and after hyperhdr service restart
after boot
after restarting hyperhdr service
System
HyperHDR Server:
HyperHDR Server OS:
Beta Was this translation helpful? Give feedback.
All reactions