We are using 2x see3cam_24cug cameras from e-consystems for a stereo camera and have tried synchronizing both using the external trigger pin. Right now we send a 60Hz signal with >10 microsecond pulsewidths (as specified by e-consystems) using an external microcontroller to try and synchronize both at 60 FPS. However with this configuration we can’t get a framerate better than around 30FPS. We don’t think this is bandwidth related because if we run both cameras in master mode, i.e. continuous streaming, we can consistently get 60 FPS out of both. The problem only occurs when we try to sync both using the trigger pin. It is also worth noting that we still only get ~30FPS when only one camera is connected to the agx, and if we connect either of the cameras to another device (e.g. our laptops), we find that we get consistent 60FPS out of it. So this appears to be an issue with how camera trigger is handled by the Jetson, though we are not really sure and looking for any advice.
hello siraajssandhu,
it seems like application level issue,
you may check with Jetson camera partner since you’ve confirm both cameras in master mode could reach 60-fps.
BTW
please also test with below commands to boost all the VI/CSI/ISP clocks.
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
See3CAM_24CUG is supported on the AGX Orin. Will test the given commands for sure too.
But is it application-level if we have tested our app on other devices and been able to trigger at 60FPS with at least one camera? If we replicate this sort of test on the jetson with only one camera we only seem to get 30FPS max out of it via the trigger circuit. Am wondering if this is a driver issue or not, and if so, can it be remedied, because the issue appears unique to the Orin
hello siraajssandhu,
this issue will require our camera partner to do the support, let me add @velmurugan.s here to help you.
We have some updated information, but no solution yet. When we lower our exposure time to anything less than 10 micros, we can get 60 fps out of each camera. However, if we even increase exposure time to 11 micros, we see an instant drop to 30 fps on trigger mode. Again, this issue does not persist in master mode. We are not sure if this is related to some kind of software timeout or especially slow frame read on the Jetson, but any advice would be appreciated.
In trigger mode, the image sensor has certain limitations in achieving the maximum frame rate. In this mode, exposure and readout occur sequentially, whereas in master mode, both processes happen simultaneously. The maximum frame rate in trigger mode primarily depends on the sensor’s configured exposure time and the trigger pulse period.
Attached is an Excel sheet detailing the optimal exposure times, trigger to trigger pulse period and their corresponding frame rates for various resolutions. Please review it and let us know if you encounter any challenges.
After some more testing, we have found that the highest framerate we can achieve with an exposure time of 0.042ms (42us) is 50 FPS, which seems to mostly agree with your Excel sheet. However, we have noticed some curious behavior: if we vary our exposure time by 1 microsecond at a time, we observe drastic changes in framerate. For instance, 54 FPS is achievable with an exposure of 0.029ms (29us) but if we increase this by a single microsecond, 0.030ms (30us), the framerate is halved (27 FPS). We are wondering why the framerate is so sensitive given the margin of 1 microsecond, and if this behavior is expected or not.
Also, this is an issue that is separate, so we can open a new ticket for it, but we have also noticed that when we run our application, the frames are occasionally corrupted (e.g. a frame appears stretched, or black, or has lines across it). The only way to resolve this is to unplug the camera and plug it back in. After we have plugged it back in, the cameras are unresponsive when running our application. They only become usable after running QtCam and checking that both cameras work. Only after doing this is our application able to receive frames from both cameras. We are also unsure why this is the case, and if QtCam does anything to initialize either camera. In our application we configure each camera by using cv::set calls and by directly sending HID packets (for options such as trigger mode). Any advice is appreciated.
Regarding the framerate, yes, this is the expected behavior as exposure and readout operations occur sequentially in trigger mode. If the trigger pulse overlaps with the ongoing exposure or readout period, the image sensor will not recognize the pulse, resulting in a reduced frame rate.
Regarding the application issue, could you please share the corrupted images for our reference? We will review them with our application team to investigate further and provide a suitable solution.
Yes, we have some examples of corrupted images:
normal behavior:
corrupted behavior:
Again, this seems to happen when we run our application and can only be resolved when we unplug the camera and then run qtcam after it has been plugged back in again. So we are not entirely sure what we are doing wrong. Any advice is appreciated.
Hi,
Could you please write to “camerasolutions@e-consystems.com”. Our camera experts will assist you immediately.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.