Dear @SivaRamaKrishnaNV
Yes, you are correct, we could only reproduce the issue so far, when a lidar is also connected, we consider 20 consecutive successful nvsipl_camera startup attempts as OK.
We also experienced the issue with only 2 cameras, but when we use less cameras the issue occurs less frequently.
The lidar part of the analysis is also strange for us and we do not understand why it could be related. We had similar issues on the old Xavier platfrom and it was related to the network traffic towards the Aurix MCU (Camera Power Control, etc.), but the Orin architecture seems to be different in this regard.
I hope this information is useful, if you have any suggestions how to narrow down the analysis further, please let us know.
Thank you very much for your support!
Best Regards,
Krisztian
Dear @SivaRamaKrishnaNV ,
Meanwhile could you please confirm whether the serializer revision is supported?
We observe the following error messages in syslog, even if the camera works:
MAX96717F: Unsupported MAX96717F revision detected!Supported revisions are: 6
meanwhile the application indicates two serializer versions for each module:
MAX96717F: Revision 2
MAX96717F: Revision 4
Sensor IMX623 Rev 9 RGGB detected!
The camera modules are Smartlead Sunny IMX623 197° BS2S107A-100-03, which are listed under the support sensors for DriveOS 6.0.10+
Thank you for your support!
Best Regards,
Krisztian
Yes. Smartlead IMX623 B2(BS2S107A-100-03) is supported model. I believe you are using the same module.
I heard from other channel that you got some camera driver files for DOS 6.0.11 and looking to test. Just want to confirm, Are you using the default the configuration shipped on DOS 6.0.10 ?
Also, I sent you Private message . Could you take a look.
Dear @SivaRamaKrishnaNV ,
Thank you for the hint, it does not seem to be related to our issue, but I am still investigating it as a possibility.
Meanwhile we have find a workaround to the problem:
- We have tested with different cable lengths on one of our vehicle, where the issue can be reproduced.
- We have found that by extending the cable (i.e. inserting another cable between the quad outbreak cable and the fakra cable) on the B group, csi_link_1 (indexing from 0), the issue vanished.
- As a workaround we simply swapped two cables on the same group.
We will attempt to implement this workaround on the rest of the setups to verify if our assumption was correct and this solves the issue on the long run as well.
I don’t have enough knowledge regarding the hardware details, but does it seem plausible to you that for this specific deserializer the difference between the cable lengths matter?
Thank you very much for your support!
Best Regards,
Krisztian