I’ve been trying to use the 4K CSI cameras with the Rock 5C and 5C Lite using the b1 release of Debian with KDE. I have a bunch of issues that I’m not sure how to describe and what useful details to provide. I’m using gstreamer with the pipeline from the docs.
On the 5C there’s the issue of something that I would call image persistence - past frames seem to mix with the current frame, creating a sort of a ghostly effect during movement.
On the 5C Lite, it’s not possible to use a camera at all, since the graphical environment seems to crash/restart in a way - executing the gstreamer command causes a black screen and then throws me back into the log-in screen.
The problem seems to be hardware independent. I tried two different 4K cameras (purchased months apart) with two different cables. I only have one 5C and no 5As currently with me, so I couldn’t check how other boards behave, but I did try things on two different 5Cs Lite and it was the same in both cases.
I’m not a KDE user, so you need to find out how to stop KDE on the modern version.
Anyway, it won’t work on your setup due to a different rkaiq version.
I am on Ubuntu with this kernel:
For now I’m focusing more on the image persistence problem.
I’m trying to see if this is actually an issue with displaying the image or something else.
I also switched to the 5A for now (b18 with xfce).
I’m attempting to use my usual TCP streaming pipeline, but something seems to be missing there.
I’m getting that usual green image problem again.
Opening the preview on the 5A itself (xvimagesink) gives the right colors, but not when I use tcpserversink…
It is usually the 3A hooks crashing or not working.
You can check this with:
Open a new cli instance (or via ssh)
run
sudo systemctl stop rkaiq_3A
now run:
sudo /usr/bin/rkaiq_3A_server
rkaiq_3A_server could be in another location, if so, find it:
sudo find / -name rkaiq_3A_server
Now in some other cli instance, run your gstreamer (first the one that works, then your tcpserversink) and you can see now on 3A cli how the 3A hooks engage and you can draw some conclusions…
Alright… I did what you suggested and ran that server in terminal. In the end I didn’t see anything suspicious or conclusive at all.
It seems there’s a greater issue here…
And I give up… Completely…
Thanks for the will to help though…
I guess Radxa boards just ain’t for me…
Apparently my stupid brain is only capable of using Raspberries…
It’s a shame… I really liked the quality on the 4K cam when it still worked with my 5A last year… Basically all my projects are camera-oriented so if CSI cameras ain’t gonna work, it’s a complete no-go… My last glimmer of hope is the NIO 12L, but that’s still in development in the software department…
And, honestly? About that image persistence problem? I’m starting to become more and more inclined to believe in spontaneous physical degradation of the sensor, rather than software problems. (lol) I know I’m not making much sense right now, but, yeah… At least I can tell myself something that I can understand and pretend that my head doesn’t break down completely here…
P.S. This is what happens with the camera image on the CLI debian on 5C Lite and on Joshua’s Ubuntu on the 5A and the 5C while using mppjpegenc. (I’m only reporting what I’m seeing, just for future reference. 'cause as I said - I’m giving up.)
I would suggest trying/using kernel 5.10 on 5A , as for 5C i don’t think it’s possible to use the camera on kernel 5.10 without a proper patch. I think kernel 6.1 introduced a few more bugs.
Judging by the image you provided i think mpp is to blame. It would be best if you matched kernel version + mpp version + isp version.
Good question. I don’t have enough experience to answer that but the HW people reading this can answer.
I don’t know (it is a trial and error for me), but some people and the board makers have access to the BSP provided by Rockchip, i think you need to be a “customer”. I think you can also buy the Official BSP. Note: This is my opinion.
Regarding this image bug… I tried a plain USB camera on the 5C Lite and the kernel 6 based CLI Debian… I got a lot of artifacts on the screen… Works fine on the 5A.
I heard that the chips that are put in the 5C Lite (RK3582) are just locked, defective RK3588S… So maybe quality control is more lax in their case and the hardware JPEG enc/dec might simply be physically broken? Just a stupid idea though…
