Camera issues on 5C and 5C Lite

#1

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.

Any ideas as to what’s going on?

#2

I have no issues with CLI on Rock 5C and Rock 5C-lite (kernel 6.1).
It looks like KDE issue (panthor or mali).
You can try this:

  • stop KDE Desktop
    in the old times, it was something like this: sudo /usr/sbin/rckdm stop

  • in the CLI (could also be via ssh):

    ./rkisp_demo -d /dev/video11 -w 640 -h 480 -v 1 -c 1000

rkisp_demo.zip (121.1 KB)

#3

Probably not a KDE issue, since I also tried Joshua’s Ubuntu on the 5C and the image persistence problem remained.

I’ll try your method tomorrow and report if it works.

#5

Alright, I’m back. Right now I’m trying to do what you said on the 5C Lite, but…

This returns command not found. Then I tried running the program you attached…

It complained about librga being missing, but after installing it from apt, there’s this error.

./rkisp_demo: symbol lookup error: ./rkisp_demo: undefined symbol: rk_aiq_user_api2_abayertnrV30_SetAttrib, version CODEABI_3.8

There’s probably still something missing when it comes to libraries or something…

#6

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:


Good luck!

#7

One more thing if you could spare another minute…

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…

gst-launch-1.0 v4l2src device=/dev/video11 io-mode=4 ! videoconvert ! video/x-raw,format=NV12,width=1280,height=720 ! mppjpegenc ! tcpserversink host=192.168.0.95 port=8000

#8

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…
#9

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…

#10

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.)

obraz
obraz.png1402×878 51.4 KB

P.S.2. Is it possible to use Radxa 4K camera with Raspberry Pi 5?

#11

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.

#12

I tried every combination.

That’s… what I said…

Why aren’t they matched out of the box though?
How do I even know what mpp and isp versions I have and where to find the right ones?

Sorry. I know I’m annoying…

#13

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.

I usually keep an eye on these places:




1 Like
#14

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…

#15

In the 5C lite, you usually get 2 broken encode/decode VPU cores, out of the 4 total (2 enc and 2 dec).

If you get 2 encode or 2 decode cores broken, you are out of luck and your board can’t do one of the activities.

The chip in the 5c lite is really a lottery drawn one. If there are more than 2 broken, I think you can replace it.

#16

I see…

Yeah, I knew about CPU cores and GPU, but I did not know about the VPU…