Jetpack r36.4.x v4l2 timing issue with src_ts

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
, ,
1

Hi NVIDIA Team,

We are currently working with the NVIDIA field team regarding a critical blocker in our sensor fusion in Jetpack 6.x. We are posting here to provide the technical problem statement for the engineering team to review.

Platform: Jetson Orin Nano

Software: JetPack 6.2 (L4T R36.4.7)

Problem Description

Our application relies on identifying the precise Start of Frame (SoF) timestamp from the hardware to perform sensor fusion with IMU data. The “Time of Arrival” in userspace is too variable due to kernel scheduling and interrupt latency, so we require a more accurate timestamp.

In JetPack 6.x: The mechanism to retrieve an offset describing the difference between clock monotonic raw and src_ts appears to have been removed or changed. While src_ts still increments in the V4L2 buffer, the boot-time offset relative to the system clock is unknown and changes with every reboot. Without this, we cannot correlate image frames to flight data.

Attempted Solution & Failure Mode

We attempted to implement the fix suggested in this thread: https://forums.developer.nvidia.com/t/how-to-get-the-clock-source-offset-ns-on-jetpack-6/300994

Methodology:

  1. We constructed the offset calculation exactly as provided in the snippet from the thread above (the most recent code response - not the first one).

  2. We captured camera frames via V4L2.

  3. We applied the calculated offset to the src_ts to convert it to CLOCK_MONOTONIC_RAW.

  4. We compared this against the current system time.

Result: The calculation is incorrect. The derived timestamps are consistently 2-12 seconds off compared to CLOCK_MONOTONIC_RAW. This suggests the offset logic provided in that thread is either incomplete or invalid for the current L4T release.

To unblock our deployment, we need guidance on the following for the JetPack 6.x (Kernel 5.15) environment:

  1. What is the sanctioned method to retrieve the tsc_offset or equivalent delta to map src_ts to CLOCK_MONOTONIC_RAW in JP6?

  2. If src_ts correlation is deprecated, what is the recommended path for retrieving precise SoF/EoF hardware capture times on Orin-series hardware?

Thanks, Marc

5

How to check it?

6

Hi @marc100

I have addressed a similar issue by stating that all the sensors use CLOCK_MONOTONIC_RAW.

Particularly, I have obtained the offset of the TSC w.r.t. CLOCK_MONOTONIC_RAW using this function:

uint64_t readOffsetNs()
{
unsigned long raw_nsec, tsc_ns;
unsigned long cycles, frq;
struct timespec tp;

asm volatile(“mrs %0, cntfrq_el0” : “=r”(frq));
asm volatile(“mrs %0, cntvct_el0” : “=r”(cycles));

clock_gettime(CLOCK_MONOTONIC_RAW, &tp);

tsc_ns = (cycles * 100 / (frq / 10000)) * 1000;
raw_nsec = tp.tv_sec * 1000000000 + tp.tv_nsec;

uint64_t offset_ns = llabs(tsc_ns-raw_nsec);

return offset_ns;
}

The TSC timestamp does not match the CLOCK_MONOTONIC_RAW, so you may need to fix that by computing an offset.

Then, for the V4L2, I transform the timestamp from CLOCK_MONOTONIC to CLOCK_MONOTONIC_RAW.

I hope this helps.
Leon

7

Hi,
Please try Ridgerun team’s suggestion. If there is further query, please update the topic and we will check further.

Thank RidgeRun team for providing suggestion.

1 Like
9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

11

Hi,
To avoid overflow we may calculate tsc_ns like:

uint64_t seconds = cycles / frq;
uint64_t remaining_cycles = cycles % frq;
tsc_ns = seconds * 1000000000ULL + (remaining_cycles * 1000000000ULL) / frq;