We are having trouble with the following issues:
In our project, we are receiving data at 60fps from a device connected via the Jetson TX2’s CSI interface.
30fps for the expected frame rate
Will be.
There seem to be other similar cases, but no useful information is available from them.
We confirmed with TX1 and there is no problem.
It seems that it is caused by the difference in kernel version.
Now, what we know, there is an unknown latency when calling the dequeue ioctrl.
Does anyone know a solution?
Did you probe the sensor signal make sure to output is 60fps?
Thank you for your reply
It was measured. The frequency of the signal seems to be correct.
Also, when the same device was operated on TX1, the frame rate was 60 fps.
The connected device (FPGA) does not handshake. It sends data unilaterally and does not use I2C.
We think there is a problem with V4L2 of kernel Ver4.9.
Do you have any hints?
Thank you for your quick reply.
I will refer to the URL you gave me.
please tell me. What can you expect from trying Clock Boost?
Hello, ShaneCCC
I asked our members.
I’ve tried raising the clock to Max, but it didn’t improve.
We check the kernel log trace.
When receiving one frame of data, V4L2 considers to receive the following five events within 16 msec. But that doesn’t seem to be the case.
Are there any other points to note?
ATOMP_FS
CHANSEL_PXL_SOF
CHANSEL_LOAD_FRAMED
CHANSEL_PXL_EOF
ATOMP_FE
Could you try to increase the V blanking to try.
Thank you for your support.
I don’t understand Vertical blanking.
Does this mean Tegra settings?
Or is it compatible with the device (FPGA)?
It’s the sensor(FPGA) settings
Thank you for your support.
It means changing the Vertical blanking setting of the sensor (FPGA).
I’ll give it a try.
Hello, ShaneCCC
Following your advice, I changed the VBLANK of the sensor (FPGA).
However, it could not be improved.
The details of the changes are as follows.
1920x1200x60Hz
472.8113879us (VBLANK) 59.93950589Hz (Frame Rate)
↓
1920x1200x55Hz
1958.790036us (VBLANK) 55.03739017Hz (Frame Rate)
Is there anything that can be considered from this result?
Also, are there any other measures you can try?
Please give me some advice.
No progress has been made since the last advice.
The following is a summary of our situation.
To define the sensor (FPGA) that connects to CSI as dev / video0
The driver diverted ov5693 and took the same measures as in the forum below.
A sensor (FPGA) was connected using TX1 and TX2 respectively.
Sensor (FPGA) CSI clock frequency is 300MHz
Why you think 300MHz is right
The CSI Line Rate is set to 620Mbps, but the clock is halved to about 300MHz because the data is DDR.
Below are the results of the experiment
Jetson TX1 settings: 1920 x 1200, 60fps, lane 4
Of course, the conditions were set in the DTS file.
As a result of operation, the frame rate became 60 fps. The acquired data is normal.
Then the same experiment with TX1 replaced by TX2
Jetson TX2 settings: 1920 x 1200, 60fps, lane 4
The conditions were set in the DTS file with reference to TX1.
The TX1 and TX2 DTS files have the following differences.
・ In TX1, the I2C settings of the DTS file have not been changed.
・ In TX2, the lane and port settings were changed in the DTS file.
As a result of operation, the frame rate became 30 fps.
And it seems that the acquired data is missing data on a regular basis.
Different, different perspective experiments
We confirmed the operation with the same TX2 and a sensor (FPGA) with the CSI clock frequency changed to 150MHz.
With that setting, the frame rate was halved to 15fps.
As reported in other posts, TX2 has an SOF acquisition cycle of about 33 msec.
Originally, the cycle should be 16msec.
We think that correct capture is possible if the following notification arrives at 16msec intervals.
- ATOMP_FS
- CHANSEL_PXL_SOF
- CHANSEL_LOAD_FRAMED
Four. CHANSEL_PXL_EOF
Five. ATOMP_FE
The DTS file settings may be insufficient.
If anyone can review it, I would like to publish the DTS file.
Also, please suggest another survey item. We will publish the necessary information.
Have update the firmware from below link to get the trace log to analysis.
Hello, Shane CCC
Thank you for your reply.
It was JetPack 4.5.1 that taught me.
We are JetPack 4.4.1. Is it effective?
Yes, this binary should work for both of them.
Thank you for your reply.
Another question.
Please tell me the specific changes.
This binary enable the FS/FE in trace log.
Thank you for your reply.
We have already confirmed that FS / FE is output in the trace log with Jetson Pak 4.4.1.
I don’t think you can see the FS/FE if not apply that.
kworker/3:1-1151 [003] … 220.076277: rtcpu_vinotify_event: tstamp:7024975447 tag:FS channel:0x00 frame:1 vi_tstamp:7024973302 data:0x00000010
kworker/3:1-1151 [003] … 219.404140: rtcpu_vinotify_event: tstamp:7002393520 tag:FE channel:0x00 frame:1 vi_tstamp:7002391211 data:0x00000020
Hello, ShaneCCC
We are in the process of continuing our research,
I noticed this with a CRC error on the TX2.
Will frames with CRC errors be explicitly discarded?
All received frame data has a CRC error detected.
Is there a way to disable the CRC error in the TX2 settings?