V4l2_buffer timestamp starts at 0, not MONOTONIC_RAW

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Platform specs:
NVIDIA NVIDIA Jetson Nano Developer Kit (L4T 32.7.4)
Camera sensor: IMX477

Hi, I have followed camera_unit_sample found under .../jetson_multimedia_api/samples/unittest_samples to implement a simple app to transfer frames to user space. Our application is very time sensitive and needs precise timestamps from the camera sensor. From my understanding the v4l2_buffer’s timestamp should be based on CLOCK_MONOTONIC_RAW, but it starts from zero.

From two consecutive frames running at 30 fps the field timestamp looks like this (after VIDIOC_DQBUF):
timestamp { tv_sec: 902, tv_usec: 617000}
timestamp { tv_sec: 936, tv_usec: 98000}

The timestamp of the first buffer received is exactly equal to 0.

Each v4l2_buffer has flags set to exactly 0, which might mean V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN according to this: 3.6. Buffers — The Linux Kernel documentation

According to other threads ( 159220 among others) the timestamp can be calculated using offset_ns but no matter what the timestamp is completely off.

Running v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=10 -d /dev/video0 --verbose stops at VIDIOC_STREAMON: ok and gives no further information.

Any ideas on what to check?

4

hello callemannen97,

FYI, JetPack 4 Reaches End of Life.
you may see-also Topic 159220 for VI drivers to capture frame and store the timestamp with TSC.

5

Hi Jerry, thanks for the response.

From my understanding TSC was patched in to the vi-driver a while back. Doesn’t 4.6.x include that? I.e. does 4.6.x’s camera driver not support any “correct” timestamping?

6

hello callemannen97,

is it only 1st buffer had such issue? as you’ve request several buffers by --stream-count=10.

7

It’s the first buffer received by our application. Running v4l2-ctlin the form of my original post does nothing. After running v4l2-ctl, dmesg gives this:

[29618.718838] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 0
[29618.752475] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 1
[29618.786138] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 2
[29618.819257] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 3
[29618.852532] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 4
[29618.886722] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 5
[29618.919393] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 6
[29618.952493] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 7
[29618.986103] vi 54080000.vi: tegra_channel_error_status:error 20022 frame 8
8

hello callemannen97,

I double your sensor streaming correctly, since it looks the error 0x20022 has caused by these two errors.

int tegra_csi_error(struct tegra_csi_channel *chan, int port_idx)
{
...
        val = cil_read(port, TEGRA_CSI_CIL_STATUS);
        err |= val & 0x02;
        cil_write(port, TEGRA_CSI_CIL_STATUS, val);

        val = cil_read(port, TEGRA_CSI_CILX_STATUS);
        err |= val & 0x00020020;
        cil_write(port, TEGRA_CSI_CILX_STATUS, val);
9

I noticed that, I just don’t know what to make of it, do you know what it means and if it is somehow connected to the timestamp being off?

I am going to install JP 4.6.4 through SDK Manager instead of writing to SD card like I did first and see if that makes a difference.

10

Reinstalled our Jetson Nano with JP 4.6.2 and error persists (which should have been expected since no changes was made to the affected kernel code for those versions).

Something I got reminded of is that the IMX477 (provided by Arducam) is not usable with a fresh install of JetPack. The solution is to run their installation script (found here) which installs the necessary driver.

Could this be the culprit of the faulty timestamp and the v4l2-ctl errors? @JerryChang

11

you should also check with Arducam to confirm releases/download/v0.0.3 is adapt with JP-4.6.2 as well.

12

We found the source of the problem. The wrapper library libv4l is not entirely reliable, which for our case led to the timestamps being erroneous. The solution was to instead interface with the camera directly with ioctl instead of through libv4l.

I have no idea if later versions of JetPack address this, and you will have to decide internally if the code samples under unittest_samples that rely on libv4l need to be checked. @JerryChang

14

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