Hi,
I have a driver for Omnivision OV7251 camera that works great on the Jetson TX2 platform but has a problem on the Xavier NX that I don’t know how to solve.
The device probes fine and I get an image from the sensor but the image has dark horizontal lines across the whole frame.
Because this is a monochromatic sensor, I’m using the following command to get an image:
v4l2-ctl --set-fmt-video=width=640,height=480,pixelformat=Y10 --stream-mmap -d /dev/video0 --set-ctrl bypass_mode=0 --stream-skip=10 --stream-count=1 --stream-to=image.raw
I have included a screenshot of the image I get.
In the dts, camera is configured as a one lane DPHY without discontinuous clock and no dpcm. I have tried playing with line_length, mclk_multiplier, pix_clk_hz to no avail.
The same configuration works great on the TX2.
Does anybody have experience with a problem like this?
Thanks in advance! Regards, Nikola!
Screenshot 2021-02-11 at 16.47.32|690x431
Could you attach the raw file here to check.
Here is the raw file that contains one frame. I have also uploaded the kernel trace and the output of the dmesg. The raw file is not the same as the screenshot in the original post but it shares the same problem.
dmesg.txt (470 Bytes) image.raw (600 KB) ktrace.txt (43.1 KB)
What’s format select to read this raw by 7yuv?
I’ve just downloaded 7yuv and it seems to me that 10bit monochromatic is not supported. I have used vooya to view images since it is free. I set it to single channel color, data container is single integer, container is 16bit wide and bit depth is 10bit. Also, I have used this Matlab script to view the images:
fileID = fopen('image.raw','r');
file = fread(fileID, [640, 480], 'uint16');
file = uint16(file);
file = file';
for i=1:640*480
file(i) = bitshift(bitand(file(i), 0b1111111111000000), -6);
end
imshow(file, [0, 1023]);
Basically, the image file is not encoded in any way, 10bit data from the sensor is placed into 2 byte containers. From my experimentation, I’ve got the best results by bit shifting every two bytes by 6 bits to right. You can see from my original post that I just saved the Y10 pixel format straight into the file.
The image I process in this way from the TX2 is great, the problem is occurring only with the NX.
What’s the format for the v4l2-ctl --list-formats?
It’s RAW10?
Could you modify the vi5_formats.h to modify the T_R16 to T_R16_I the same as vi4_formats.h to verify.
TEGRA_VIDEO_FORMAT(RAW10, 10, SRGGB10_1X10, 2, 1, T_R16_I,
RAW10, SRGGB10, "RGRG.. GBGB.."),
Hi, I’m sorry I couldn’t reply sooner but this does not seem to be the solution. I have tried out R32.5.0 and R32.5.1 today on a new NX board and the problem still exists.
When I do v4l2-ctl --list-formats I get the format that I have defined in the DT. I have tried different formats but in the end it doesn’t make any difference if I treat the output image as a RAW file.
Also, I have implemented the T_R16_I in the vi5_formats.h file and it didn’t make any difference.
I check the RAW by 7yuv get this result. Looks fine for this?
Hi ShaneCCC,
The image you have posted contains the dark lines that I have talked about. I have cropped and marked your image to point out our problem.
When I posted my previous reply, I tried all versions of L4T after and including 4.9 and this problem keeps occurring on every try, both on the NX and the Nano. At the same time, we have no problem on TX2, using the same driver and matching DT settings (I have changed only the necessary port names and numbers).
This is something we see both when making a raw image using v4l or streaming the video with argus.
Could you try configure OV7251 output test pattern to confirm.
Interestingly, there are no lines in the frame when using the test pattern. Here are two frames taken by the same camera, streamed over the local network with gst. The only difference is the test mode enabled.
Wow, could you consult with sensor vendor if any REG setting can help on this kind of problem.
Also if any others output size setting to verify.
Hi ShaneCCC,
I’ve sent a message to the sensor vendor. I’m not feeling very optimistic about them answering me.
I have cross checked my mode table with the one from the driver in the official linux distro on the same kernel version as the current L4T to find that the only differences are in the framerate settings. All of the other settings are the same and correspond to datasheet.
The only thing that bugs me very much is that the identical driver works flawlessly on TX2. Of course, the test pattern now introduces even more confusion.
Could it be signal interference cause that?
I thought the same at first but we are using almost the same hardware the whole time and we have no problem with the test pattern, so that rules out interference.
Could you try different output clocks or adjust the mclk to check.
Our oscillator is soldered to the camera board and the freq can’t be changed, it’s always 24 MHz. In the DT, since I’m testing on Nano at the moment, I have set mclk_khz = "24000"; and selected these clocks:
clocks = <&tegra_car TEGRA210_CLK_CLK_OUT_3>;
clock-names = "extperiph1";
mclk = "extperiph1";
clock-frequency = <24000000>;
Wouldn’t changing these values brake vi?
This clock wouldn’t break the VI.
You can try disable this clock to try.
Hello,
I have tried reducing the clock freq with no visible difference. When I disable the extperiph1 clock there is a slight delay between the moment I initiate the stream and image appearing but nothing else.
Hi @drndarevicnikola ,
Did you solve this issue?
I also meet this problem now, could you share anything?
It will be very thankful!
