How to re-invoke cam_fsync_program_abs_start_value?

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.10.0
DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
2.1.0
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Issue Description

What I want to do is to continuously output fsync at the beginning of every second on the Drive AGX Orin Devkit using the PTP domain.

Below is what I have attempted on the current Devkit to achieve this:

First, to synchronize PTP with TSC, I configured the MGBE2_0 interface to operate as an automotive slave and used the NVPPS API NVPPS_GETEVENT to obtain the time when PPS and TSC coincide.

Next, to utilize cam_fsync_program_abs_start_value introduced in Drive OS 6.0.8.1, I changed the fsync-groups status from “disabled” to “okay” in tegra234-p3710-0010.dtsi, computed the TSC value for outputting the first fsync at the start of the second, and set it using the -F option of nvsipl_camera.

However, when outputting camera images at 30 Hz, although there is no issue initially, I observed that after one hour, the fsync appears approximately 2.3ms too early. This discrepancy causes problems with sensor fusion.

This issue was already mentioned in the thread below:

Regarding the last comment:


the problem can be alleviated by defining a pattern that covers 3 periods of the 30 Hz, with 2 periods at 1,041,667 x 32 ns and 1 period at 1,041,666 x 32 ns.

Is there any plan to implement this in Drive OS 6.0.10, as it hasn’t been implemented there either?

Otherwise, cam_fsync_program_abs_start_value can only be called once after powering on the Orin Devkit and cannot be reconfigured. This is evident from the error returned when specifying the -F option of nvsipl_camera for a second time:


nvsipl_camera: ERROR: Failed to program and start fsync signal for group: 0 with status: 3

Is there any way to reconfigure cam_fsync_program_abs_start_value?

Additionally, in Drive OS 6.0.10, the following functions were newly added to NvCamFsync.h:

  • cam_fsync_stop_group

  • cam_fsync_reconfigure_generator

Although there aren’t any specific release notes mentioning these additions, I assume they were provided as a workaround for the above issue. However, when I tried using them, they returned CAM_FSYNC_UNSUPPORTED and could not be used.

Finally, the binary fsync_debug mentioned in:

is not found in Drive OS 6.0.10. Could you please let me know where it can be obtained?

2

It is documentation issue. Fsync_debug is not part DRIVE OS 6.0.10.

3

I understand that fsync_debug is not included in 6.0.10.

Is there any way to re-invoke cam_fsync_program_abs_start_value ?

I would like to know either a method to prevent deviation from PTP time when continuously outputting the camera at 30Hz for an extended period.

Or a way to reconfigure cam_fsync_program_abs_start_value after stopping the camera once.