Beiträge von WiredRacing

Zitat

you can also do that (normally) in WebUI but you have to be logged in as expert, in top right of webpage change user from standard to expert.

Oh fantastic. That explains so much. (if the dev is listening, perhaps "settings level" is not a great descriptor of what's behind that link)

Zitat

I'd try to change FPS in video grabber to let's say 30 and resolution - as low as possible.

Not sure at which stage you're recommending this (as the problem has been solved). Initially I was already at 720x480 and 5FPS. Low/High CPU usage (nor Core-Count either) wasn't causing the bottleneck as reported. Once I changed the encoding method, it performed great, even at 60fps (and 40% CPU utilization). The 20fps I'm at now seems to be the sweet spot for responsiveness while keeping the load down, for this capture device.

So ultimately the 'problem' articulated here was directly related to my choice of capture device falling behind due to the encoding method YUYV (default or chosen by some element in Hyperbian) not being as efficient as MJPEG is *for my capture device*. Which is a pretty common one - MACROSILICON - idProduct 2109.

The only thing to try now is reverting back to the Pi Zero W and seeing if it will perform just as well.

Just a post to mark the thread as resolved. Thanks!

So, changing "encoding" to "MJPEG" worked! Great response now! Thank You!

(For others, for reference, changing max_usb_current=1 (and rebooting) didn't change anything)

HOWEVER... CPU utilization jumped up to 38% and I see in the log the FPS is set to the configured 5, but then immediately to 60!

Here's what's in the config json (I had to export, edit the 'encoder' and re-import) for that section

"grabberV4L2": {

"available_devices": "USB Video: USB Video",

"blueSignalThreshold": 0,

"cecDetection": false,

"cropBottom": 0,

"cropLeft": 0,

"cropRight": 0,

"cropTop": 0,

"device": "/dev/video0",

"device_inputs": "0",

"enable": true,

"encoding": "MJPEG",

"flip": "NO_CHANGE",

"fps": 5,

"fpsSoftwareDecimation": 0,

"framerates": "5",

"greenSignalThreshold": 100,

"hardware_brightness": -11,

"hardware_contrast": 148,

"hardware_hue": 0,

"hardware_saturation": 180,

"height": 480,

"input": 0,

"noSignalCounterThreshold": 200,

"redSignalThreshold": 0,

"resolutions": "1",

"sDHOffsetMax": 0.46,

"sDHOffsetMin": 0.4,

"sDVOffsetMax": 0.9,

"sDVOffsetMin": 0.1,

"signalDetection": false,

"sizeDecimation": 4,

"standard": "NONE",

"width": 720

},

and here's what the log shows

2021-11-02T22:28:54.074Z [hyperiond V4L2] (DEBUG) (Grabber.cpp:141:setWidthHeight()) Set new width: 720, height: 480 for capture

2021-11-02T22:28:54.074Z [hyperiond V4L2] (INFO) Set new frames per second to: 5 fps

2021-11-02T22:28:54.075Z [hyperiond V4L2] (INFO) Set image size decimation to 4

2021-11-02T22:28:54.075Z [hyperiond V4L2] (INFO) Set flipmode to NO_CHANGE

2021-11-02T22:28:54.314Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:151:init()) Set device (path) to: USB Video: USB Video (/dev/video0)

2021-11-02T22:28:54.314Z [hyperiond V4L2] (INFO) Set new frames per second to: 60 fps

2021-11-02T22:28:54.314Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:488:init_device()) Set device input to: Camera 1

2021-11-02T22:28:54.316Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:614:init_device()) Set resolution to width=720 height=480

2021-11-02T22:28:54.317Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:631:init_device()) Set framerate to 60 fps

2021-11-02T22:28:54.317Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:739:init_device()) Pixel format=MJPEG

2021-11-02T22:28:54.326Z [hyperiond V4L2] (INFO) Started

Any idea's on changing the framerate (I suspect this is why the CPU utilization is so high)?

Oh, nevermind, I was able to choose 10 (a bit of a notable delay) but then 20 seems responsive enough and it kept the MPJEG setting (even though it's not there in the web configurator).

CPU is now at 20%, I think I will try moving back to the PiZero.

I suspect "5" wasn't a valid value for this device using MJPEG and that's where the jump to 60 came from.

tl;dr - tried SPI because I thought perhaps PWM is just too slow in terms of response, however once I finally got the LED's to respond, a couple seconds later they just started flashing. I suspect it's because I can't find solid info on SPI wiring.

Video:

Core Elements:

Raspberry Pi4

HyperBian 2.0.0-alpha.11

WS2812B Strip (5m, 300led's, configured to use 256)

Power:

PSU is a PC Power supply (temporary to get this working, but 5V rail claims 45A)

Red and White from the strip (separate from the 3 wires) are connected to the PSU, in this case the Pi4 is powered separately because I don't have spare USB-C cables to cut up)

Wiring:

Green (Data) from WS2812B connected to pin 19 (GPIO10 / MOSI)

White (GND) from WS2812B connected to pin 6 (GND)

Hyperion Setup:

Controller Type: ws2812spi

SPI is on in config.txt (and it's been rebooted)

I tried this with spidev0.0 (both are listed in /dev)

Had to change the Baud Rate from the default (3000000) to 5000000 before the lights would represent the colors on screen. However within seconds, the lights just started flashing, constantly, On/Off every 100/200ms or so (see video above)

I was wondering, perhaps I have to take the end of the strip data wire and route it to MISO (GPIO 9)? No idea. Most stuff I found involved 4-wire strips with a wire going to SCLK (GPIO11) though some posts seemed to claim they moved from PWM to SPI by just moving the data wire to MISO.

How should this be wired up?

So I first tried this on a PiZeroW, but seeing the slow response (despite plenty of CPU headroom), I tried a Pi4. Same results.

First off, here's what I'm seeing:

tl;dr - how do I reduce the 'lag'?

Details:

HyperBian 2.0.0-alpha.11

Controller Type: ws2812x

GPIO 18

DMA 10 (and I tried 5, no difference)

PWM Channel 0

Hardware LED Count 256

Capture Device Res: 720x480,5 FPS, 4 Size Dec.

Capture Device is this -

LED's: WS2812B (5 wires on each side, 2 power and gnd and then 3 (Red/Grn/Wht) on each end) -

Wiring/Cables:

Barrel Female - PC PSU (temporary but plenty of amps), 5V and GND off 4 Pin Molex

Barrel Male - Positive (MicroUSB +, Start of LED Strip Red, End of Strip Red) - Negative (MicroUSB -, Start of LED String White, End of Strip White)

HDMI Splitter is powered separately (for now) via 5V micro USB, 2A. 4K HDR in, Scale down to 1080 out to Capture Device

Green (Data) from start of LED Strip -> GPIO 18 (Pin 12)

White (GND) from start of LED Strip -> GND (Pin 2)

Not connected: Red from start of LED Strip, Red/Green or White wires from end of LED Strip.

Notes:

1. With the PiZero I use the MicroUSB, with the Pi4 right now because it's USB-C, I'm powering it separately. Same behavior regardless of Pi.

2. Hyperion is running under root (this was needed)

3. Set audio off in config.txt (no difference in response between it being on, or off in my case)

4. At the moment, I'm using the full 5m/300LED strip, but only 256 on the strip (just didn't want to cut it if I have to return them), the remaining LED's don't light up (as expected)

5. No difference in response when I didn't have the tail end of the strip +/- connected to the PSU.

6. Currently running no resistors or caps... seems to be several out there with better response that I'm seeing without doing any of that. As I'm not trying to power the strip off the Pi (it doesn't have the current anyhow).

7. FWIW, the Live Video preview in LED Layout Preview looks terrible, massively desaturated.. is this by 'design'? Clearly it's getting more color detail than it shows here because the strip does set the right (close enough, haven't bothered calibrating yet) colors.

I've seen other videos of people claiming to do this same setup, even in a PiZero and video of their setup looks more responsive.

Could this be a problem with the capture card (or the scaling to it)? Any ideas on how to test if it's the weak link?