Stereo camera hat not on the I2C bus: enable i2c_vc

Your 5 MP stereo hat passes the still-image test, then the depth demo dies on its first I2C call. You have reseated both camera ribbons, mounted the hat directly on the board, installed the library the readme names, and proved the header bus healthy with another device — and sudo i2cdetect -y 1 still scans empty. The wiring is fine and the hat is fine. Its two sensors hang on a second I2C controller, the VC bus i2c0, which the Raspberry Pi 4 ships with switched off; the bus you enabled is i2c1, and the hat never touches it. This guide shows you how to read the error, turn the VC bus on with one line in /boot/config.txt, and confirm the two sensor addresses appear.

Read the error: a missing device file, not a dead camera

The demo's first output carries the whole diagnosis:

Could not open file /dev/i2c-0' or /dev/i2c/0': No such file or directory
I2C check functionality fail.
init_camera: Unexpected result

A missing /dev entry means the kernel never created the device: the controller behind that bus number is switched off in configuration. The other two lines are consequences — the I2C self-check fails, so camera initialization reports an unexpected result. A wiring fault behaves differently at every layer: the device file exists, the scan runs, and individual addresses either stay unanswered or error during the probe. Sort every I2C failure by its layer first:

• Device file missing → the controller is disabled. Fix it in configuration.
• Device file present, scan empty → wrong bus, or a wiring fault on that bus.
• Device file present, probe errors → the physical link: ribbon seating, length, power.

The first row is where a stereo hat bring-up almost always lands, and the rest of this guide stays there.

Your isolation steps already proved where the fault is not

Three of the checks you ran are worth keeping in the record. Reseating the ribbons and remounting the hat changed nothing, which argues against a connector fault. The empty scan of i2c-1 is a complete page, every address unanswered, and it proves the tools work end to end: drivers loaded, i2cdetect functional, the bus electrically idle. The other I2C device you attached to the header answered and ran on that same bus, which clears the host side of i2c1 entirely.

Two steps were unrelated by construction. The wiringPi package is a GPIO library, not a bus switch, and the libatomic.so.1 preload on the demo command satisfies a runtime dependency. Neither can create a device file, so neither could have changed the outcome. Nothing was wasted: the same three checks, pointed at the right bus number, are exactly how you will confirm the fix below.

The two I2C controllers, and which one the hat uses

You enabled the first row and scanned it: right tool, wrong bus. The stereo hat routes both sensors' control lines to the VC bus, the controller the firmware uses for camera and display control, and the parameter that exposes it ships off on every image. Nothing on the hat ever touches i2c1, which is why a healthy bus with a working test device still scanned empty.

The passing still capture belongs to a different code path. raspistill drives the sensor through the firmware's own control channel and never opens a /dev/i2c node, so stills work while every userspace I2C call fails. The depth demo controls the sensors from user space and needs the bus exposed as a device file — that is the entire gap between your two results.

The fix: one line in the boot config

1. Open the boot configuration: sudo nano /boot/config.txt. On the newest OS images the same file sits in a firmware subfolder of the boot partition; edit whichever copy the system actually reads.
2. Add the parameter on its own line, next to the other dtparam lines: dtparam=i2c_vc=on.
3. Save and reboot: sudo reboot.
4. List the buses again with ls /dev/i2c-*. The VC bus now appears next to i2c-1 — on the images this demo targets it carries the number the script asks for and shows up as i2c-0. Newer kernels number the firmware bus differently; the entry that appeared is your bus, whatever number it carries.
5. Scan it by that number: sudo i2cdetect -y 0. The two sensor addresses replace dashes in the table, and the demo clears its I2C check.

The header bus is untouched: the parameter adds a controller rather than moving yours, so an RTC or sensor module already running on i2c-1 keeps working.

Worked check: reading a scan as 128 answers

A full i2cdetect page prints addresses 0x00–0x7f as 8 rows × 16 columns = 128 slots. Before the fix there was no VC bus to scan at all; the empty page you captured on i2c-1 was 128 unanswered slots — a complete, electrically healthy bus carrying zero devices, a result about the bus and not about the hat. After the fix, the same command on the VC bus answers at the sensor slots: one per camera, because each camera on the stereo pair keeps its own control address (a hat that shares one address across the pair shows one, and its readme says so). Then rerun the demo from the stereo_depth_demo folder: the I2C check completes, and init_camera: Unexpected result disappears with its cause.

When the bus is up but the demo still fails

Past the bus check, the remaining failures split into three layers, and each has its own write-up:

• Addresses appear but frames never arrive. The sensors are detected; the MIPI data path is the suspect now. The sensor detected but frames time out guide separates I2C success from streaming failure.
• The scan errors mid-probe. A value such as -121 points at the physical link — ribbon seating, length, power — rather than at configuration. The I2C error -121 on a camera sensor probe guide walks that link.
• The camera never appears at all, not even for stills. That is the device-tree and interface layer, above any bus question: start with the MIPI camera not detected: I2C bus and device tree checks guide, and use the CSI camera V4L2 no such device error guide for the interface-enable step.

Bring-up order that avoids the trap

Run a hat bring-up in this order and a failure surfaces in one step instead of five:

• Collect every boot-config line the hat's readme names before the first boot. The i2c_vc line is in there because the sensors need it, not because it is historical.
• Enable both controllers deliberately: the header interface through raspi-config, the VC bus through its config line. They are independent switches, and enabling one tells you nothing about the other.
• After each config change, run ls /dev/i2c-* and write down the bus numbers. The number is the contract between your scan command and the demo.
• Scan each bus before starting the demo. An empty scan on the hat's bus is a wiring result; an empty scan on any other bus carries no information.
• Treat the still capture as a sensor test only. It exercises the firmware path and proves nothing about userspace buses.

When to skip MIPI entirely

If the hat is a prototype and the deliverable is a machine, moving the cameras to USB3 removes the layer this article repairs altogether. A USB3 camera enumerates from its own USB descriptors when plugged in: no overlay, no device-tree bus numbering, no boot-config line, and a driver stack the camera vendor maintains. You trade the short ribbon for a standard C-mount or CS-mount lens mount and a cable that reaches across a machine instead of across a board.

Compare candidates in the board-level cameras category, filter by resolution, shutter and mount in the camera finder, or assemble the whole chain in the camera configurator. For the full selection method, the board level camera selection for embedded vision machines guide covers host and lens matching, and the board camera evaluation checklist for inspection systems covers the bench tests to run before you commit. More bus-level bring-up material sits on the systems topic page, and if you would rather send a parts list than configure one yourself, contact the team.