You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stand the camera on the desktop and check the preview, the preview screen mess up randomly even I do not move the camera.
I have no idea about the problem.
Steps to reproduce the behaviour
Connect OV9281 camera and modify config.txt file:
camera_auto_detect=0
dtoverlay=imx290,clock-frequency=37125000
reboot
Preview the camera with the command: libcamera-vid -t 0
That form of corruption is indicative of multi-bit errors on the CSI2 bus resulting in a packet (line) of image data being dropped.
CSI2 can detect and correct single bit errors in any packet, but only detect multi-bit errors - see section 9.5.4 "Applying ECC on RX Side" of the CSI2 spec.
Dropping a line corrupts the Bayer pattern. Red and blue become green, and greens become red and blue, hence things tend to go pink/magenta. A second multi-bit error in the same frame results in a second line being dropped and the colours go back to normal (although the image is now shifted up by 2 lines).
Who is making the image sensor you are using?
I have seen no image corruption issues with either Vision Components IMX290 or IMX327 sensors, nor Inno-maker IMX327.
Unicam does report bit error status values, but they currently aren't logged or accumulated.
In UNICAM_STA:
UNICAM_CRCE denotes a CRC failure.
UNICAM_SBE is single bit errors (corrected).
UNICAM_PBE is parity bit error.
UNICAM_HOE is a higher order (ie multiple bit) error.
These correspond to the decode scenarios described in the spec section 9.5.4.
It may be useful to check these bits when UNICAM_STA is read in unicam_isr, and incrementing stats stored in struct unicam_device. unicam_log_status can then dump those out when triggered via v4l2-ctl --log-status or similar.
Describe the bug
Stand the camera on the desktop and check the preview, the preview screen mess up randomly even I do not move the camera.
I have no idea about the problem.
Steps to reproduce the behaviour
camera_auto_detect=0
dtoverlay=imx290,clock-frequency=37125000
Move objects
Device (s)
Raspberry Pi 4 Mod. B
System
OS and version:
Raspberry Pi reference 2021-10-30
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 288b21fc27e128ea6b330777aca68e0061ebf4fe, stage4
firmware version:
Oct 29 2021 10:47:33
Copyright (c) 2012 Broadcom
version b8a114e5a9877e91ca8f26d1a5ce904b2ad3cf13 (clean) (release) (start)
kernel version:
Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
Logs
No response
Additional context
A test video is attached for reference.
https://www.youtube.com/watch?v=vo_iYaIBGrw
The text was updated successfully, but these errors were encountered: