Error CAPTURE_STATUS_NOTIFY_BIT_CHANSEL_NO_MATCH when streaming small sized frames

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

On Jetson Orin AGX, when streaming relatively small sized frames (e.g. 1024x64, no blanking) occasionally some frames get dropped with the error CAPTURE_STATUS_NOTIFY_BIT_CHANSEL_NO_MATCH. The sensor is the IMX636 with a custom driver.

The number of dropped frames increases when choosing a low power mode (e.g. 15W) or when opting for even smaller frames.

How is it possible to achieve lossless data transfer under these conditions?

2

*** Please note that this reply is generated by LLM automatically ***

To address the issue of dropped frames and achieve lossless data transfer on the Jetson AGX Orin, we need to consider several factors that might be contributing to this problem. The error message CAPTURESTATUSNOTIFYBITCHANSELNOMATCH suggests a mismatch between the channel settings, which could be related to the sensor configuration, driver settings, or the CSI interface.

Given that the sensor is the IMX636 with a custom driver, here are some potential steps to troubleshoot and optimize the setup:

  1. Verify sensor configuration: Ensure that the IMX636 sensor is properly configured to match the frame size and format (e.g., 1024x64) you are trying to capture. Check the sensor’s datasheet and configuration registers to confirm that it is set up correctly.
  2. Check driver settings: Review the custom driver settings to ensure that they are compatible with the Jetson AGX Orin’s CSI interface and the IMX636 sensor. Verify that the driver is configured to handle the desired frame size and format.
  3. CSI interface configuration: Confirm that the CSI interface is properly configured to handle the frame size and format. Check the Jetson AGX Orin’s documentation for CSI interface configuration guidelines.
  4. Power mode and clock settings: When operating in low power modes (e.g., 15W), the Jetson AGX Orin’s clock speeds might be reduced, which could impact the CSI interface’s performance. Verify that the clock settings are adequate for the desired frame rate and size.
  5. Virtual channel configuration: As the Jetson AGX Orin supports virtual channels, ensure that the virtual channel configuration is correct and matches the sensor’s output. This might involve configuring the CSI aggregator and the VI muxer.
  6. Frame rate and exposure settings: Adjust the frame rate and exposure settings to optimize the capture process. If the frame rate is too high, it might lead to dropped frames. Similarly, if the exposure is too short, it might result in underexposed images.
  7. Buffering and synchronization: Ensure that the buffering and synchronization mechanisms are properly set up to handle the frame capture and transfer process. This might involve configuring the DMA (Direct Memory Access) settings and the synchronization primitives.
  8. Firmware updates: If the custom driver or the sensor’s firmware is outdated, it might be causing compatibility issues. Check for firmware updates and apply them if necessary.

To achieve lossless data transfer, consider the following:

  1. Increase the buffer size: Increase the buffer size to accommodate the frame size and format. This will help reduce the likelihood of dropped frames.
  2. Implement error correction mechanisms: Implement error correction mechanisms, such as checksums or CRCs (Cyclic Redundancy Checks), to detect and correct errors during data transfer.
  3. Use a more robust communication protocol: Consider using a more robust communication protocol, such as PCIe or USB 3.0, which might offer better error correction and reliability features.
  4. Optimize the system’s power management: Optimize the system’s power management to ensure that the Jetson AGX Orin has sufficient power to handle the capture and transfer process.

By following these steps and considering the factors mentioned above, you should be able to achieve lossless data transfer and minimize dropped frames on the Jetson AGX Orin.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

hello michael.joscht,

let me double check.
is it the same sensor output active dimension with 1024x64?
or.. you’re calling 2D converter to downscale the original IMX636 capture frames to this small dimension?

6

Here some background: The IMX636 is an event sensor that outputs frames with variable frame sizes. But Jetson does not support that. Therefore, we use an FPGA based custom board in between that converts to fixed sized frames. Ideally, we want the frame size to be as small as possible in order to reduce latency.

7

hello michael.joscht,

it’s device tree for hardware configuration, you’ll need to have identical settings for sending the stream properly.
anyways, what’s the latency you’ve expected?

8

Hello JerryChang

the device is tree is configured correctly (identical to transmitted CSI-2 frames). In general, the pipeline is working. We just loose some frames as described above.

Our target is to have a latency of approx. 1ms (i.e. frame rate of 1000 fps). Currently, we have have two lanes at 1500 Mbps each. Therefore, to reach our target, the frame size should not be too large (maximum 1024x256).

My suspicion is that the maximum possible frame rate depends on the workload inside the Linux kernel since the VI device driver needs to create capture requests (that are sent to the RCE) quickly enough. If there is no capture request ready, the CHANSEL block within the VI pipeline generates the above mentioned no-match error.

9

hello michael.joscht,

FYI,
here’re the test result with JP-6.2/r36.4.3 on Orin-NX + IMX477.
Framerate30 → G2G latency delay about 128ms
Framerate60 → G2G latency delay about 96ms

please refer to How to get MIPI-CSI camera delay under the 100ms? - #17 by ShaneCCC

10

Hello JerryChang

the frame rates under this link are much smaller (60 fps) than what we want.

Is it feasible to reach frames rates up to 1000 fps?

11

hello michael.joscht,

as you can see, the G2G latency took ~96ms with 60-fps camera sensor.
in theory, it may reduce 15ms with your 1000-fps camera sensor, it still need 80ms for buffer transmit and internal processing.
besides, we’ve never test high speed camera sensor above 240-fps.

13

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