I'm very sorry then.. Just wanted to ask how to connect ws2815 and what to set the HyperBian alpha7 settings. I also have ws2815, but HyperBian does not have it on the SPI bus. In any case, thank you!
No worries, just wasn't clear what your question was.
Hyperion settings for WS2815 is the same as WS2812.
Hi! What settings have been made for selecting the feed?
Not sure what you mean by that. This topic is only about hardware, specifically level shifting from 3.3V to 5.0V, so no settings are involved.
Hey can you talk about what the latency with this is. I'm currently using
usb capture card and while it works well, the lag between what's on the screen and the LEDs is noticeable enough that it really bother's me.
Most is said here already, no need to add solutions.
Some theory about lag optimization from the notion that lag is caused by the grabber hardware and the Hyperion software.
1) Start with the default automatic settings. If that works for you, leave it as it is. If not, read on.
2) Theoretically, the number of LED pixels that you have in your setup is the minimum resolution needed. So if you have 55 LEDs left and right and 75 LEDs top and bottom, the minimum resolution to capture accurate colors is 55x75. Most grabbers won't go that low, so choose the setting in Hyperion that is best handled by the grabber hardware to get the least lag on the grabber. This is different for each brand so you have to do some digging.
3) Your LED pixels have a maximum data / refresh rate so it's no use choosing a higher frame rate in Hyperion than what your total LEDs are capable of. A single pixel needs a minimum time to set the colors of the individual LEDs and recreate the data for the next pixel. Multiply that time with the number of pixels you have to get the time of 1 'frame'. Times the number of bits per pixels for the maximum bitrate. Divide in a second for the frames per second.
4) Performance of your Pi influences lag as it has to do the calculations. Use the command htop in a terminal window to check performance. If you use the pi only for Hyperion and choose wisely with the above in mind, a Pi3 should have ample CPU cycles to make the necessary calculations without any trouble. If you use it for other tasks as well, htop will show you what process is hogging CPU resources, giving you a starting point to further optimize things. That is however beyond this forum I think.
Hi Refthoom, regarding the USB Grabber you linked, can you advise if the USB output is a 4k signal, and to your knowledge does the Rpi3 have any USB3 ports - i’m thinking not.
I currently have this, which claims to accept a 4K input, however in practice I’ve had to downgrade my SkyTV output to 1080p to the grabber for the Rpi3 to pick it up. This renders the Ambilight mostly pointless as we have a 4k TV ♂️
Thanks!
Hmmmmmmm not sure what you want to achieve. The one that I linked to supposedly has 4k input and output, and grab 1080p@60Hz. This provides more than enough information for Hyperion to be able to control your ledstrips, there is absolutely no need for the pi to grab 4k. And no, the pi3B has no USB3 ports. The pi 4B is the first pi to have USB3. But again, you really don't need that.
I have no clue why you would need to lower the resolution to 1080p for the pi3 to pick it up. In my tests (with a similar grabber to yours but 1080p) I did find that it helps if HDMI is connected first and only after that connect to USB. Then with the Hyperion app, disable and re-enable Hyperion (that stops and starts hyperion deamon). In my setup that delivers the best results. I'm guessing this may be due to the fact that type of grabber is powered by either the 12V from the HDMI or the 5V from USB. When connected to HDMI first it can set itself up to the proper resolution of the connected device. If USB is first connected, it is powered by the 5V first and I guess it defaults to some resolution since there is no HDMI input at that moment.
Please beware that, like I mentioned before, I did not test 4k signals since I don't have those in my setup. Someone else (other forum) stated that it could handle 4k in and out and together with the 'loop' made my decision to buy it and be somewhat future proof.
Hi, I'm currently only 1080p, so this grabber looks like it will suit my needs perfectly, if it supports passing of CEC commands. My wife likes the one remote for all devices, so this is a must. Do you know if it passes through CEC commands? ARC would also be nice, but this I can live without.
I haven't tested that so I don't know, sorry. (CEC doesn't work for my setup because my AV receiver is rather old and doesn't support it.)
It does support ARC on my setup.
Somehow when it says 'loop' I expect the signal to go through untouched. But that's Chinese products I guess ...
I've tested this USB grabber with my setup of Rpi 3B+ with HyperBian alpha7 and it works great. The advantage of this device is that is has an internal HDMI loop so it eliminates the need for an HDMI splitter. Less parts is less clutter, right?
It is powered solely by the USB port's 5V, unlike other USB grabbers that can utilize the 12V from HDMI. Also, unlike the term 'loop' might suggest, as soon as USB power is removed, the HDMI connection is lost.
Just wanted to mention here that as an alternative to the level shifters sold under that name on banggood and aliexpress, you can apply TTL ic's like below. I have tested these on my setup Rpi 3B+ on HyperBian alpha7 with WS2815. The advantage of these buffers over the level shifters is speed and they have built in logic to keep the signal clean.
- Quad buffer SN74AHCT125N
The Rpi output is connected to the input, the Output Enable connected tp GND. The output is connected to the LED strip data line.
- Quad AND gate SN74HCT08
The rpi output is connected to one of the AND gate inputs, the other input is connected to VCC (5V), the output is connected to the LED strip data line.
I also use 1k resistors on all input and output lines as a precaution to spikes and shorts.
Sorry for the lack of updates, I've had a really busy time lately. As far as I'm concerned this thread can be closed/locked.
To update on my last post; With the alpha7 image I had no issues like the ones I posted before. Like described above, I tested three analog grabbers to see if they caused Hyperbian alpha7 to become unstable, which it didn't.
Ah, forgot to mention that, this was with 3 different SD cards.
The first SD card I experienced this with was an 8 GB white label SD card from the store where I bought the Pi. I threw that one in the bin when Etcher kept failing to write to it from different computers (laptop, desktop) because I thought it was defective.
The second SD card is now running in my 'production setup' and it is an 8GB Transcend.
This third and up until yesterday evening last attempt was on my third SD card. It is a 16GB Kingston.
I will try to run it through the same steps later today with the alpha7 image. If the behaviour is the same I will also try to capture some of it on camera and with screenshots.
EDIT: my SD cards all come from reputable Dutch online stores, nothing from Amazon or Aliexpress and the like.
EDIT 11-08-2020 still working on this, don't have much time available atm
What I observed:
- When a USB grabber is connected to the pi that is not recognized by hyperiond, it goes to 100% on one CPU core and the total memory is slowly eaten until no more is available.
- If you wait long enough, something apparently restarts because the memory is freed and hyperiond goes to 0%. Then again to 100% and the memory is slowly eaten again.
- During this process the pi gets more and more unresponsive. It doesn't matter if I use a screen and KB connected directly to the pi or if I SSH into it.
- Also, when the unrecognized USB grabber is connected, the Hyperion configuration web page is unreachable.
The weird thing is that this corrupts the software AND the SD card. No matter if I reboot, power down, remove the grabber, whatever, this erroneous behaviour persists. Furthermore, re-burning the Hyperbian image onto the SD card with Etcher fails. Only after I wipe the SD card with 0s I can re-burn the image onto the SD card. Then everything works as expected.
I have witnessed this behaviour several times the past weeks, as I was trying to get my setup working. In total I have tried 4 different USB grabbers, 3 with analog input, 1 with HDMI input. Only the grabber with HDMI input I got working (after some struggling). It is the small cheap $10 USB stick from Aliexpress that registers as "UVC camera....".
Note1: The grabbers are all recognized by Linux because they show up with lsusb.
Note2: I have used two different pi's and the behaviour is the same.
The last time I tested was tonight and I'm sure it was with Hyperbian alpha6. I'm not sure if alpha7 has this behaviour as well. I know I switched to alpha7 somewhere along the line the last couple of weeks, while working on my setup.
If this is a real bug it must be driving many people crazy like it did me. So please tell me what you want me to show, test, whatever to help you guys find the issue. I could even send you the 3 analog grabbers if you think that helps.
The HDMI Cable which goes to the grabber, could you put it in tv to see if the incoming picture is good, to be sure that the problem is at the usb grabber
Yes, I just checked that, TV picture is normal.
It appears that the hardware startup is of importance for the grabber.
I've been experimenting with my full set of spare parts (Pi, grabber, splitter, cables and a short piece of LEdstrip) on alpha6 and have had different results. With the alpha6 setup and my laptop as HDMI source I got an okay picture grab but the signal to the LEDstrip wasn't good, flickering LED's. Adjusting baudrate didn't help. Later I switched to a dvd player as HDMI source with the same results, i.e. picture good but LEDs not. Then I switched back to the alpha7 setup and the DVD player as HDMI sorce directly. First had this:
No matter what I did software wise, I couldn't get it right. I tried rebooting the Pi but no improvement. Then I shutdown the Pi, unplugged it, unplugged the grabber (which is powered by the hdmi's 12V). Next I put the grabber in the Pi first, then plugged it into the HDMI splitter and then powered up the pi. Now I have this:
This is with size decimation 1, just for testing. With resolution at 720x480, 10 frames/sec and size decimation 4 I get almost no delay. And LEDs are working without any flickering. Also now routing all HDMI sources through my A/V receiver as was intended and all works fine.
My conclusion: No idea exactly what changed and why it works now. I've had the hardware unplugged several times but it seems that the order in which I connected stuff the last time gave the current result.
I plan on ordering a different grabber with an HDMI loop in it and see how that performs and if it is less 'sensitive' to the order it receives power. Will come back here to report on it.
Is there anything I can do (to help) to find the root cause of this strange behaviour?
Thank you for the quick response.
1. Hmmm alright I will give that a try, not today, tomorrow 
2. lsusb does not give much information (Bus 001 Device 004: ID 534d:2109) see screenshots terminal and web config page.
3. not sure what you mean? I have the USB grabber and TV both connected with an HDMI splitter (see photo). It could be the splitter but I switched both outputs and the result is the same. I have spares for all the parts you see in the photo and tested with both leading to the same result, using one SD card to make sure I'm testing hardware only.
Where can I find a log that I can send, maybe that's helpful too?
Screenshot terminal:
From the web config page:
Hardware setup
I've been trying to get this working right for a week now, can't seem to find what the issue is. Help is appreciated.
The issue is that the grabber displays the wrong colours, like below. A black screen shows as purple, a white screen shows a green. It's not an LED issue, those work correctly.
- I've tried different grabbers but the results are the same. This one https://www.aliexpress.com/item/32827676511.html and this one https://www.aliexpress.com/item/4000917130635.html.
- I'm running HyperBian with Hyperion NG 2.0.0 alpha 7
- It's running on a Raspberry Pi 3B without any issues, The Rpi is hardly doing anything as can be seen from the htop screenshot below. I tried Rpi0W and another Rpi3B as well, fresh HyperBian images, issue remains the same.
- I have fiddled with settings but this has not solved this issue.
The only thing i have not changed yet is my HDMI splitter, would appreciate it if anyone shared here if they had similar issues and found them to be related to the HDMI splitter.
