@proventusnova
test_10.zip (11.2 MB)
I have attached the raw data here
hi @proventusnova ,
Any further thoughts?
Hello @spavan,
Sorry, this week has been a bit crazy with some of the projects we are currently working on.
I checked the file you shared and I found it a bit strange, I had to set endianness to big endian to be able to see something which still looked weird, here is the result:
However, when I test the very first image that you shared, I can use little endian and the image looks better:
That being said, I find it interesting that with nvargus you managed to get good results.
If you see the image with nvargus, what do you see? Can you share a screenshot?
regards,
Andrew
Embedded Software Engineer at ProventusNova
Hi @proventusnova ,
thanks for the results , I would like to give few clarifications on the test.raw and test_10.raw files .
- test.raw file which i shared initially line_length =3952 with RG12 but in case of test_10.raw it is 5500 with RG10.
- Currently the display is little busy so i could not capture nvargus image but it is little brighter than the test.raw image you shared with good clarity .
Few questions from my side for my future reference
a) What process or software did you follow to convert raw images to visible format .
b) Can you explain more on endianness (both little and big )you used,how ,where to use it and its impact ?
Hello @spavan,
Got it, thanks for clarifying.
It is still very interesting to me that 5500 line length works, given that the documentation points to 3958 to be the correct value. However, if you are running 10bit tests on nvargus successfully, then I would believe it is safe to say that the driver is doing it job as intended.
To answer your questions:
a. For seeing the images in visible format I am now using PixelViewer it is a great tool.
b. As per the endianness, it is the order in which data is stored, in the case of an image, is the order in which pixel data is stored. While playing with the images you shared, I found that I needed to change endianness in order to see something on test_10.raw
Now that you are at this point, what is next for you @spavan ?
regards,
Andrew
Embedded Software Engineer at ProventusNova
Thanks @proventusnova ,
-
Can you share any resources for me to explore more on endianness, can you provide any simple example where you played relates to test_10 raw file? Since I could not get any way to view raw files I think this would help me in future, can you please elaborate on this concept, I’m interested to learn.
-
Still could not stream with v4l2src gst command although after making the changes you suggested (RAW10 changes link)
Hi @proventusnova ,
any resources from your side?
hi @proventusnova ,
please let know if you have any inputs .
Hello @spavan,
Sorry, this week I have been focused on a few customer projects.
To be completely honest, it is unusual to play with Endianness when it comes to image capture. It is not a usual configuration, and we don’t have specific resources on the subject.
You could review the register configuration for something related to that, however, I ran a quick search and did not find anything on the data sheet about endianness configuration.
Now, when it. comes to the issue with v4l2src, it is estrange that after applying the changes to the element for it to support 10bits you are still seeing issues.
You could try increasing GST_DEBUG, maybe we can see something interesting.
GST_DEBUG=3,GST_CAPS:6 gst-launch-1.0 -v v4l2src ! fakesink
regards,
Andrew
Embedded Software Engineer at ProventusNova
hi @proventusnova ,
thank you so much , it’s been a great learning from you related to v4l2 driver.
sorry i have got into another task related to Serdes which is on priority .
have you came across this error when i use serdes with GMSL protocol and while running nvgstcapture-1.0
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
This error tell unable to capture frame data from the sensor.
You can confirm by v4l2-ctl and get the trace log to check the error.
imx477_logs.txt (6.7 KB)
these are the logs i found some issue with CRC
I saw this topic
Version : R35 (release), REVISION: 4.1, GCID: 33958178, BOARD: t186ref, EABI:aarch64
Board Jetson Xavier NX
sudo apt-cache show nvidia-jetpack
Package: nvidia-jetpack
Version: 5.1.2-b104
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 5.1.2-b104), nvidia-jetpack-dev (= 5.1.2-b104)
but i have three images in bootloader which one should i replace ?
camera-rtcpu-sce.img
camera-rtcpu-t194-rce.img
camera-rtcpu-t234-rce.img
camera-rtcpu-t194-rce.img for Xavier serials.
i have changed the deserializer hardware so got rid of the above error and i could see this error sometimes
if there are any library updates i missed can you share the library files necessary for this version 35.4.1?
Camera node 1
Output Strean W 1920 H 1000
seconds to Run
Frame Rate- 59.999999
GST ARGUS: Setup Complete, Starting captures for o seconds GST ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected, continuing.
CONSUMER: ERROR OCCURRED
ERROR on bust by /GstPipeline:capture_native_pipeline/Gstbin:cap_bin/GsTNvArgus
CameraSrc:nvarguscamerasrco: TIMEOUT
debug Infor Argus Error Status
GST ARGUS: Cleaning up
**Ressage: 00:41:18.8111 <matn14744» Capture completed
**Hessager 08:41:18.8511 14795» Camera application will now exit
Please verify the sensor streaming stability by v4l2-ctl first.
can you share the commands ?
Try below command.
v4l2-ctl -c bypass_mode=0 --stream-mmap
i could see the below stream
v4l2-ctl -c bypass_mode=0 --stream-mmap
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
imx477_logs_timeout.txt (68.6 KB)
the attached are the error logs with dmesg log as below
[RCE] ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] "General error queue is out of sync with frame queue. ts=3461401121568 sof_ts=3461425448288 gerror_code=2 gerror_data=400060 notify_bits=0"
hi @ShaneCCC , any clue from the logs attached