If a GMSL camera captures through V4L2 but an Argus application fails, preserve the working capture as a baseline and investigate the second path separately. Raw frame transport, sensor controls, mode configuration, and the intended processing stack are related but distinct. A successful file from one interface does not establish support for every other interface.
Record the exact BSP, driver, camera mode, command, and output before changing configuration. Then reproduce the Argus failure with the smallest supported application for that package. The goal is to identify which requirement differs, rather than rebuilding the entire camera chain because one preview command fails.
The GMSL compatibility checklist establishes the proposed hardware and software combination. This article is a runtime evidence checklist for a narrower symptom: that combination has a working V4L2 path, but its intended Argus path is not yet demonstrated.
Define exactly what “V4L2 works” means
Save a bounded capture with the command and effective mode. Verify that the file contains the expected dimensions, pixel format, and meaningful image content. Enumeration, a file with nonzero size, or a preview with unknown conversion settings is weaker evidence than an interpretable capture.
The V4L2 format-negotiation reference distinguishes requested and returned formats. Record the effective result, not only the arguments the application attempted to set. A driver can constrain the request to a supported mode, so the baseline needs its actual output contract.
Keep camera identity separate from node numbering. Record the physical lens, driver-reported endpoint, cable route, and target used. If multiple cameras are connected, verify which sensor supplies the successful file before treating that file as evidence for the failing Argus camera.
Pin software and mode identities
Record Jetson module, carrier revision, sensor, serializer, deserializer, JetPack, Jetson Linux, kernel, BSP package, and camera-driver revision. Note which image or overlay is actually loaded. Preserve installation steps and any local patches without exposing private credentials in a support bundle.
The NVIDIA sensor-driver guide provides mode and control context for r36.4.4. Use documentation matching the installed release; this archive is a concrete reference, not a recommendation to move every system to that version.
For each path, record resolution, frame interval, pixel representation, selected sensor mode, exposure/gain settings where available, camera count, and output interpretation. A comparison between different modes cannot isolate an API-specific difference. If the supported tool chooses a mode automatically, retain its reported selection.
Confirm that the selected carrier and BSP package support the intended capture path. Do not infer Argus support from another carrier or developer kit sharing the same Jetson module family.
Identify the requirement added by the Argus path
NVIDIA’s camera software architecture guide separates direct V4L2 access from Argus and ISP-related processing. It also notes that sensor-control behavior can explain a V4L2-success/Argus-failure case. This is a possible branch to investigate, not a diagnosis for every failed camera.
Ask which path the supplier intends for the sensor’s output. Raw Bayer, processed output, and a sensor with its own processing can have different integration requirements. Obtain the supported application and mode rather than assuming a generic command must work for every image format.
Separate failure stages in the log: camera discovery, mode selection, session creation, streaming, control changes, and output conversion. A failure before capture starts gives different evidence from a stream that begins and then fails when settings change. Keep the first meaningful error with its surrounding sequence.
Use an evidence matrix rather than a parameter sweep
| Check | Working V4L2 evidence | Argus evidence to collect |
|---|---|---|
| Physical camera identity | Distinct target in captured file | Selected camera actually corresponds to that lens |
| Mode contract | Returned format, dimensions, and interval | Chosen sensor mode and expected representation |
| Effective configuration | Driver and loaded board configuration | Applicable mode and camera-module configuration |
| Controls | Settings and capture behavior | Behavior during supported control updates |
| Processing path | Raw or processed output interpretation | Required Argus/ISP integration documented by supplier |
| Failure boundary | Repeatable bounded successful capture | First failing stage and complete relevant log interval |
Change one justified setting between runs and retain both results. Blindly copying exposure ranges, clock values, or mode identifiers from another sensor makes the comparison harder to interpret. Mark unknown configuration fields as unknown until the driver or supplier establishes their meaning.
Where virtual channels are used, compare the selection and mode configuration for the intended API. The versioned GMSL reference distinguishes receiver channel settings and Argus mode identifiers. An otherwise working route can still have inconsistent metadata for the second consumer path.
Reproduce with a supported minimal tool
Close competing camera consumers according to the integration procedure and start from a documented system state. Run the supplier’s smallest supported Argus capture or preview example with the intended camera and mode. Save the exact command, reported selection, logs, and resulting file if one is produced.
The Argus NvRaw documentation describes a raw-capture tool and its mode context. Confirm applicability to the sensor and BSP before using it as a test. Failure with an unsupported tool is not evidence that a supported application path is broken.
Repeat the working V4L2 baseline after the failed test so you can report whether basic capture remained intact. Record restart or recovery actions separately. A successful recovery does not explain the original failure, and a service restart should not be used to hide missing mode or control evidence.
Only after the minimal supported path works should you add recording, conversion, rendering, and the application’s normal workload. This isolates an integration failure from an application pipeline error. Preserve the first stage at which behavior changes, including any difference in image mode or consumer count.
Build a supplier escalation package that can be replayed
Provide hardware identities, software revisions, effective board configuration, mode table, successful V4L2 command and output, failed Argus command, relevant logs, and the failure-stage matrix. State whether the same physical camera and mode were used. Include only data the recipient is authorized to receive.
Ask for a specific answer: is the path supported on this package, which configuration is required, which known limitation applies, or what correction should be validated? The camera documentation and supplied driver notes should identify the supported combination. A generic “camera compatible” statement does not resolve an API-specific failure.
Keep later sensor-fusion qualification separate. A corrected Argus path does not establish shared timestamps with LiDAR; use the clock-check procedure for that requirement. Image transport and acquisition timing need different evidence.
Likewise, use the calibration workflow after camera identity, capture mode, and timing are stable. Save the final working configuration alongside those outputs so a future driver or BSP change triggers an appropriate repeat test.
Frequently asked questions
Does raw V4L2 capture prove that Argus must work?
No. The second path can add mode, control, processing, and configuration requirements. Preserve the raw baseline and investigate those differences.
Should I immediately change the BSP?
First identify the supported release and reproduce the failure with its supported tool. A release change is a different experiment requiring its own baseline.
Is a mode number transferable between applications?
Do not assume it. Record each API’s reported mode and the physical image contract it selects.
What makes a successful repair reviewable?
A supported explanation, one documented change, repeatable capture through the intended path, and preserved before-and-after commands, configurations, and outputs.
