# IMX219 camera with UNO Q, Media Carrier and App Lab

**URL:** <https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033>\
**Category:** UNO Q\
**Created:** [September 17, 2026, 5:29pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033 "2026-09-17T17:29:16Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![philippe86220](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/philippe86220/32/733778_2.png) [@philippe86220](https://forum.arduino.cc/u/philippe86220)\
**Post date:** [September 17, 2026, 5:29pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/1 "2026-09-17T17:29:17Z")

</div>

Hi everyone,

I have just finished the first version of a small camera project using an **Arduino UNO Q** , the **Arduino® UNO™ Media Carrier** , and a **Sony IMX219** camera connected to `CAMERA0`.

The complete application runs on the Linux/MPU side using **Arduino App Lab 0.10.0**. No MCU code is used.

The WebUI allows manual adjustment of:

- exposure;
- analogue gain;
- full-resolution image capture (3280 × 2464).

The image is captured as RAW Bayer data and processed directly in Python. The application performs bilinear demosaicing, Gray World white balance, shadow correction, moderate contrast/sharpening, and finally generates a JPEG that is displayed in the WebUI.

The project also uses a custom App Lab camera brick with a dedicated container. The camera service communicates with the Linux camera pipeline through `media-ctl` and `v4l2-ctl`.

I tried to make the README quite detailed, especially for people who, like me, are discovering how the different parts of an App Lab application communicate with each other.

The project has been exported from App Lab, re-imported and tested successfully. I have therefore released this first stable version as **v1.0.0**.

GitHub repository:

> **[GitHub - philippe86220/imx219-camera-with-arduino-app-lab: IMX219 Camera with Arduino App Lab](https://github.com/philippe86220/imx219-camera-with-arduino-app-lab)**
>
> IMX219 Camera with Arduino App Lab

Here is an outdoor test image captured and processed directly by the application:

**Exposure: 1042 — Analogue gain: 49**

 ![exterieur](https://europe1.discourse-cdn.com/arduino/original/4X/b/6/d/b6d3bed5e2aa885ec04183beccd9cb4b711c1f4f.jpeg)

This V1 intentionally uses manual exposure and analogue gain.

The next step will be a V2 where I would like to experiment with **automatic exposure and analogue gain control** , while keeping this V1 as a simple and stable reference.

Any comments or suggestions are welcome.

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 18, 2026, 4:54pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/2 "2026-09-18T16:54:30Z")

</div>

Hi philippe86220, great project — this is exactly the setup I'm trying to get working (UNO Q + Media Carrier + camera on CAMERA0), but I'm stuck one step before your starting point.

When I go into App Lab, Settings, Carriers to enable Camera0, it shows "board needs to be updated" and the update action does nothing. I've dug in a bit: apt-get update succeeds fine, apt list --upgradable shows no pending Arduino packages. arduino-app-cli system update --only-arduino --yes reports "No upgradable packages found". Rebooted the board and restarted App Lab, same result. The camera-capable device tree (qrb2210-arduino-imola-camera-rpiv2.dtb) is already present on disk alongside the default one, so it looks like the kernel side is ready, but nothing is selecting it at boot. As a result, /dev/media0 and the /dev/v4l-subdev\* nodes your camera brick depends on never appear, I only get /dev/video0 and /dev/video1, which are the Venus hardware decoder, not the sensor.

My board is on image build 20251024-412, App Lab 0.10.0, arduino-app-cli 0.13.0.

Since you've got this fully working end-to-end, did you hit this same "needs update" gate on the Carriers panel, or was Camera0 already enabled on your board out of the box? And if you did hit it, how did you get past it? Any version info on your side, App Lab or board image build, would help me figure out if I just need to wait for a rollout, or if there's something else going on.

Thanks!

---

<div class="post-metadata">

**Author:** ![ptillisch](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@ptillisch](https://forum.arduino.cc/u/ptillisch)\
**Post date:** [September 18, 2026, 7:30pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/3 "2026-09-18T19:30:21Z")

</div>

In order to make relevant information available to any who are interested in this subject, I'll share a link to formal report @paulrbarnard submitted to the Arduino developers:

> <https://github.com/arduino/arduino-app-cli/issues/660>
>
> \### Describe the problem
> 
> With a UNO Media Carrier attached and a camera on CAME…RA0, App Lab's Settings \> Carriers panel refuses to enable Camera0, showing "board needs to be updated." Clicking the associated update action has no visible effect. There is no actual pending update to install.
> 
> \### To reproduce
> 
> 1. Attach UNO Media Carrier with a camera on CAMERA0 to a UNO Q
> 2. Open App Lab \> Settings (gear icon) \> Carriers
> 3. Enable "external carriers connected to your Arduino UNO Q"
> 4. Attempt to set Camera0 to "type1-2lanes"
> 5. Observe "board needs to be updated" message; clicking the update control does nothing
> 
> \### Expected behavior
> 
> Either a real update is offered that unlocks Camera0, or the Carriers panel's version check should recognize that this image already supports it and let it be enabled.
> 
> \### Arduino App CLI version
> 
> 0.13.0
> 
> \### Additional context
> 
> \## Environment- 
> \- Board: Arduino UNO Q ("Imola")
> \- OS image: Debian 13 (trixie), BUILD\_ID 20251024-412, kernel 6.16.7-g0dd6551ae96b
> \- arduino-app-cli: 0.13.0
> \- arduino-app-lab: 0.10.0
> \- arduino-router: 0.10.0
> \- Accessory: UNO Media Carrier, IMX219-class camera connected to CAMERA0
> 
> \## What I checked before filing
> \- \`apt-get update\` succeeds (network/repo reachable); \`apt list --upgradable\` shows no pending Arduino packages
> \- \`arduino-app-cli system update --only-arduino --yes\` reports "No upgradable packages found"
> \- Rebooted the board and restarted App Lab fully — same result
> \- The camera-enabled device tree blob (\`qrb2210-arduino-imola-camera-rpiv2.dtb\`) is already present on disk (\`/boot/efi/dtb/qcom/\`) alongside the default \`qrb2210-arduino-imola.dtb\`, suggesting kernel-side support for the camera already ships in this image — nothing appears to select it at boot
> \- As a result, \`/dev/media0\` and the \`/dev/v4l-subdev\*\` nodes needed for camera access (confirmed against a working third-party camera brick: https://github.com/philippe86220/imx219-camera-with-arduino-app-lab) never appear. Only \`/dev/video0\`/\`/dev/video1\` exist, which are the Qualcomm Venus hardware video decoder, unrelated to the camera sensor.
> 
> \## Additional context
> This looks similar in kind to #618 (system update not respecting version constraints) — App Lab / arduino-app-cli appears to gate features behind version-constraint logic that can fall out of sync with what a given image build actually supports. Related forum threads:
> \- https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033 (working camera setup, doesn't mention hitting this gate)
> \- https://forum.arduino.cc/t/camera-modules/1408971/29 (references upstream CSI driver work landing for UNO Q)
> 
> 
> \### Issue checklist
> 
> \- \[x\] I searched for previous reports in \[the issue tracker\](https://github.com/arduino/arduino-app-cli/issues?q=)
> \- \[x\] I verified the problem still occurs when using the latest version
> \- \[x\] My report contains all necessary details

---

<div class="post-metadata">

**Author:** ![philippe86220](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/philippe86220/32/733778_2.png) [@philippe86220](https://forum.arduino.cc/u/philippe86220)\
**Post date:** [September 19, 2026, 9:26am UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/4 "2026-09-19T09:26:15Z")

</div>

Hi Paul,

I found the Carriers settings you were referring to. I had actually never used this panel before because I didn't need to configure CAMERA0 manually.

On my working UNO Q, the settings currently show:

- External carriers: enabled
- Carrier type: `media-carrier`
- Camera0: `type1-2lanes`
- Camera1: `none`
- Display: `none`
- System version: `System is up to date`

CAMERA0 was therefore already configured this way when I started working with the Media Carrier. I never encountered the “board needs to be updated” message and never manually changed the device tree or boot configuration.

I also checked my system:

- App Lab: 0.10.0
- `arduino-app-cli`: 0.13.0
- Debian: 13 (Trixie)
- Kernel: `7.0.0-g122c2c22d838`
- Build Version: `20260528-558`
- Release date: `28/05/2026`

The significant difference I can see is that my system image is `20260528-558`, whereas yours is `20251024-412`.

I don't know whether this difference is responsible for the problem, but hopefully it provides a useful comparison for issue #660.

Philippe

 ![Capture d’écran du 2026-09-19 11-15-34](https://europe1.discourse-cdn.com/arduino/original/4X/e/0/5/e0532978541886401f2cc83db29b03704dae6fea.png)  
 ![Capture d’écran du 2026-09-19 11-21-25](https://europe1.discourse-cdn.com/arduino/original/4X/0/b/1/0b1ac52973ab7b650cd0aa4a367fa6286b4aa1fc.png)

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 19, 2026, 10:28am UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/5 "2026-09-19T10:28:46Z")

</div>

That was exactly the problem. I've flashed 558 and now I can enable the carrier and I have an operational camera. So the real problem here is that the "update" button does nothing. It would have been nice if the firmware pane had indicated there was an update available, that would have been a nice clue.

Many Thanks for your help.

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 21, 2026, 12:16pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/6 "2026-09-21T12:16:23Z")

</div>

@philippe86220 I spoke a touch too soon I'm not at the received image stage.

Sensor detection is now fully working (imx219 shows up cleanly via cam -l and media-ctl, all the v4l-subdev nodes are present). But I'm stuck one step further on than before: actually starting the video stream fails.

VIDIOC\_STREAMON returns "Invalid argument" on /dev/video0, reproducible three ways:

- libcamera's `cam` tool, at any resolution (640x480 scaled or native 3280x2464)
- Direct v4l2-ctl streaming on the raw RDI passthrough node, using the sensor's native format (set via `v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=pRAA`, which the driver accepts fine and reports correct buffer sizes back - so it's not a format mismatch)

media-ctl -p shows the pipeline correctly linked end to end (imx219 -\> msm\_csiphy0 -\> msm\_csid0 -\> msm\_vfe0\_rdi0 -\> msm\_vfe0\_video0/dev/video0), but every entity in the topology reports "(0 routes)". That made me wonder if this driver needs an explicit route configured via the newer V4L2 streams/routing API before STREAMON will succeed, even with the static links already enabled - but the v4l2-ctl on my board's v4l-utils build doesn't have --get-subdev-routing/--set-subdev-routing, so I can't test that theory directly.

Since your camera brick clearly gets real frames out via media-ctl/v4l2-ctl, could you share the exact command sequence you use to get from a fresh boot to a successful capture? In particular I'm curious whether you do any explicit routing/streams setup on the subdevs before opening /dev/video0, or anything else beyond the basic link setup that isn't obvious from the README.

Board/software versions on my side: image 20260528-558, kernel 7.0.0-g122c2c22d838, App Lab 0.10.0, arduino-app-cli 0.13.0. Camera0 set to type1-2lanes.

Thanks again for the help so far - getting a lot closer.

Just to add: I'm using a "SHCVHV 8MP PRI Camera V5" module rather than an 'official' RPi camera from Raspberry. I don't think this should be an issue.

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 21, 2026, 12:51pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/7 "2026-09-21T12:51:48Z")

</div>

I've dug a bit more and checked your camera\_service.py and I found the exact sequence you use for the RDI path:

```arduino
media-ctl -d /dev/media0 -V '"msm_csiphy0":0[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_csiphy0":1[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_csid0":0[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_csid0":1[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_vfe0_rdi0":0[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_vfe0_rdi0":1[fmt:SRGGB8_1X8/WxH]'
v4l2-ctl -d /dev/v4l-subdev12 --set-ctrl=exposure=...,analogue_gain=...
v4l2-ctl -d /dev/video0 --set-fmt-video=width=WxH,pixelformat=RGGB
v4l2-ctl -d /dev/video0 --stream-mmap=4 --stream-count=1 --stream-to=FILE

```

I reproduced this exactly (setting format on both sink AND source pad of each subdev, which I'd been missing before, and setting sensor controls before format/stream). That got further than anything I'd tried: STREAMON no longer returns an error at all. But instead of producing a frame, v4l2-ctl just hangs indefinitely - no data ever arrives, no timeout, nothing further in dmesg. I let it sit for a couple of minutes with zero progress before killing it.

Looking at dmesg from that same STREAMON call, I get this kernel warning every time:

```arduino
WARNING: drivers/media/v4l2-core/v4l2-subdev.c:484 at call_s_stream+0xec/0xf8 [videodev]
Call trace:
  call_s_stream+0xec/0xf8 [videodev]
  video_start_streaming+0x104/0x13c [qcom_camss]
  vb2_start_streaming+0x6c/0x178 [videobuf2_common]
  vb2_core_streamon+0xd8/0x1bc [videobuf2_common]
  vb2_ioctl_streamon+0x58/0xa0 [videobuf2_v4l2]

```

My working theory: call\_s\_stream() is what qcom\_camss uses to tell each subdev in the pipeline (sensor -\> csiphy -\> csid -\> vfe) to actually start streaming. If it warns on one of those calls but doesn't propagate that as a hard error, video\_start\_streaming could end up marking the whole queue "started" while silently skipping the sensor's own start-stream call - which would exactly explain STREAMON succeeding with zero frames ever arriving, forever.

Question for you: do you see this same WARNING in your dmesg when your camera\_service starts a capture, even though you do get real frames back? Or is your dmesg completely clean at that point? That would tell us whether the warning is a harmless red herring in your working setup, or whether something upstream of it is different between our two boards despite the identical kernel version.

Happy to share the full dmesg/lspci-equivalent output if useful.

---

<div class="post-metadata">

**Author:** ![philippe86220](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/philippe86220/32/733778_2.png) [@philippe86220](https://forum.arduino.cc/u/philippe86220)\
**Post date:** [September 21, 2026, 3:26pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/8 "2026-09-21T15:26:23Z")

</div>

Hi Paul,

I tested this on my working setup immediately after taking a successful photo with the application.

I don't get the `call_s_stream` warning you are seeing.

I checked with:

```arduino
sudo dmesg | grep -E -i "call_s_stream|qcom_camss|WARNING|streaming"

```

There was no `call_s_stream` warning.

I also checked:

```arduino
sudo dmesg | grep -E -i "camss|csiphy|csid|vfe|imx219|v4l2"

```

The only CAMSS-related messages I have are from boot, including:

```arduino
qcom-camss 5c11000.camss: supply vdd-csiphy-1p2 not found, using dummy regulator
qcom-camss 5c11000.camss: supply vdd-csiphy-1p8 not found, using dummy regulator

```

My camera still captures frames correctly, and there is no new CAMSS/V4L2 warning when a capture is performed.

Since we now have the same system image, kernel, App Lab version and Camera0 configuration, I think it might also be useful if you try running my complete App Lab application unchanged, rather than reproducing the `camera_service.py` sequence manually.

That would give us a cleaner comparison:

```arduino
my UNO Q + my IMX219 + same application = working
your UNO Q + your IMX219 + same application = ?

```

If the complete application also hangs on your board and produces the `call_s_stream` warning, then we would know that the application and command sequence are identical on both sides. The different IMX219 camera module would then be one of the remaining differences worth investigating.

I don't think we can conclude yet that your SHCVHV module is the cause, but testing the exact same application should help narrow this down.

Philippe

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 22, 2026, 1:49pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/9 "2026-09-22T13:49:42Z")

</div>

Update - ran your app exactly as you suggested, plus some other developments since my last post.

First, a board-side update landed: App Lab's example catalog refreshed and now ships an official native "Camera" peripheral (arduino.app\_peripherals.camera.Camera) with a one-line WebUI.expose\_camera() helper - no more needing video\_object\_detection or a custom brick just to get a feed. I tested that first, on its own, with a fresh re-seat of both the Media Carrier and the camera cable. That re-seat did fix a real, separate problem I'd been hitting intermittently: I2C write failures to the Media Carrier's onboard PCA9555 GPIO expander (the chip that controls camera power), which had been causing inconsistent sensor detection. After the reseat, sensor detection has been rock solid every time.

But the actual streaming still fails, even through Arduino's own new official Camera class:

```arduino
ERROR V4L2 v4l2_videodevice.cpp:1998 /dev/video0[12:cap]: Failed to start streaming: Invalid argument
ERROR Camss camss.cpp:429 Failed to start camera platform/soc@0/5c1b000.cci/i2c-2/2-0010 imx219

```

So then I did exactly what you suggested: ran your complete app unmodified rather than reproducing the sequence by hand. I recreated your repo file-for-file on the board (git clone was blocked in my environment, so I pulled each file from GitHub directly and wrote them in - app.yaml, python/main.py, and the full bricks/camera/ brick including camera\_service.py verbatim), and ran it exactly as your brick\_compose.yaml defines it - as root, inside its own Docker container, with the same device mounts.

Result: your exact code, running exactly as designed, fails the same way on my board:

```arduino
VIDIOC_STREAMON returned -1 (Invalid argument)
Erreur capture : Taille RAW incorrecte : 0, attendu 8081920

```

That's a clean result in the sense that it rules out a lot: it's not root vs non-root permissions (your code runs as root here too), it's not a command-sequence mistake on my end (this is your literal file, unmodified), and it's not specific to any one API (I've now hit the identical STREAMON/Invalid argument failure through libcamera's cam tool, raw v4l2-ctl on the RDI path, the newer PIX routing path, Arduino's own new native Camera peripheral, and now your exact working code).

Across this whole process, whenever the sensor is cleanly detected (which it now is, consistently, after the reseat), STREAMON has never once succeeded on my board, on any code path. That points at something board- or kernel-specific rather than anything in your code or mine.

One more variable I'm ruling out: my camera module is an "8MP IMX219 Camera Module, MIPI interface, 200° FOV" (SHCHV brand, fisheye lens variant) rather than a standard-lens Pi Camera Module v2 clone. It identifies correctly as imx219 over I2C, but it's possible the board/lens variant differs enough to matter. I've ordered a different IMX219 module to rule that out and will report back once it arrives.

Many thanks for helping me sort this out.

---

<div class="post-metadata">

**Author:** ![philippe86220](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/philippe86220/32/733778_2.png) [@philippe86220](https://forum.arduino.cc/u/philippe86220)\
**Post date:** [September 22, 2026, 5:52pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/10 "2026-09-22T17:52:59Z")

</div>

Hi Paul,

Just one additional data point: I also tried the new basic App Lab Camera example you mentioned, using `arduino.app_peripherals.camera.Camera`.

On my UNO Q with my IMX219, it works. The camera starts successfully, captures an image, and `captured_image.jpg` is created correctly.

My log contains:

`CSICamera: Successfully started csi:platform/soc@0/5c1b000.cci/i2c-2/2-0010 imx219`

followed by a successful stop of the camera.

So the new official Camera example also gives us the same difference between our two setups: it successfully streams and captures on mine, whereas you get `Failed to start streaming: Invalid argument`.

I think your test with the second IMX219 module will be very interesting.

Philippe

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 23, 2026, 3:06pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/11 "2026-09-23T15:06:57Z")

</div>

This is starting to drive me nuts. Two genuine Raspberry camera turned up today. They are not seen at all by the media carrier. However plugging in to a VentunoQ the camera shows up (doesn't get to the image stage due to a different error). I then tried the two different cameras, two different UnoQ and two different media carriers in all permutations but the cameras simply don't show up. It was at that point I realised the cameras were V3 which have IMX708 not IMX 219. A quick check and I can find no IMX708 support for the media carrier. I'm going to give the project a rest for a few days to clear my head as I'm in stupid mistake mode now.

---

<div class="post-metadata">

**Author:** ![ptillisch](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@ptillisch](https://forum.arduino.cc/u/ptillisch)\
**Post date:** [September 23, 2026, 4:08pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/12 "2026-09-23T16:08:25Z")

</div>

> [@paulrbarnard](#):
>
> A quick check and I can find no IMX708 support for the media carrier.

That is correct. At this time, we only officially support the use of the IMX219 with the UNO Media Carrier and UNO Q.

For the VENTUNO Q we only support the IMX577.

Of course the community is welcome to work to implement their own solutions for supporting additional camera models. However, for those looking for the smoothest path to getting a MIPI CSI camera working with their project, I do recommend selecting the models I specified above.

---

<div class="post-metadata">

**Author:** ![philippe86220](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/philippe86220/32/733778_2.png) [@philippe86220](https://forum.arduino.cc/u/philippe86220)\
**Post date:** [September 23, 2026, 6:55pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/13 "2026-09-23T18:55:20Z")

</div>

Hi Paul,  
If it helps, I can give you the Amazon link for the exact IMX219 camera I’m using.  
This is the one that works with my UNO Q + Media Carrier, both with my V1 application and with the new App Lab Camera example.

> **[Waveshare IMX219 Camera Module, Compatible with Raspberry Pi 5, 8MP, MIPI-CSI...](https://www.amazon.fr/-/en/Waveshare-Compatible-Raspberry-Interface-Resolution/dp/B0CPM292WP)**
>
> Waveshare IMX219 Camera Module, Compatible with Raspberry Pi 5, 8MP, MIPI-CSI Interface, 26.3°FOV, Comes with Pi5 CSI Flexible Cable 200mm, 3280×2464 Resolution : Amazon.fr: Computers

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 24, 2026, 12:26pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/14 "2026-09-24T12:26:49Z")

</div>

Well I pointed Claude at it and I now have images. I may have got there myself but this worked remarkably well.

Here is what Claude has to say about it.  
VVVVVVVVVV

## Update: third-party RPi Camera V2 (IMX219 clone) on UNO Q + Media Carrier: root cause found, workaround streaming

**Short version:** the clone isn't failing in the sensor or the CSI link. When the driver puts it into reset, the clone pulls down the camera I²C bus. The PCA9555 GPIO expander that controls that reset line is on the same bus, so once the camera is in reset, nothing can take it out again. Leaving the reset line out of the device tree fixes it: the clone now streams at full resolution.

### Setup

- UNO Q + Media Carrier, Debian 13, kernel `7.0.0-g122c2c22d838`, libcamera 0.4.0 (simple pipeline + soft ISP)
- Third-party IMX219 camera on camera0, configured with `arduino-linux-config carrier enable media-carrier camera0=type1-2lanes camera1=none`

### Symptom

The sensor probes fine (chip ID is read and `cam -l` lists it), but starting a stream fails:

```arduino
v4l2_videodevice: /dev/video0: Failed to start streaming: No such device or address
imx219 2-0010: imx219_power_on: failed to enable regulators

```

### What's happening

1. At boot, the PCA9555 (0x26 on CCI bus 0) probes, and the imx219 driver powers the sensor, reads its chip ID and then runtime-suspends it. That drives `reset-gpios` (PCA9555 pin 0) low and switches `cam-pwr-csi0` (PCA9555 pin 1) off.
2. With that line low, the clone loads CCI bus 0. After this, a forced read of the expander fails:

```arduino
$ sudo i2cget -f -y <cci0-bus> 0x26 0x00
Error: Read failed

```

3. On stream start, the driver has to write to the PCA9555 to power the sensor up and release reset. The expander doesn't answer (`-ENXIO`), so the sensor can never be woken up again.
4. The PCA9555 appears to keep its latched outputs through a warm `reboot`, probably because it stays powered. After a failure, the next boot starts with the bus already held down, and even the PCA9555 probe fails (`pca953x …-0026: failed writing register: -6`). Only a full power cycle clears it, which is why the fault can look intermittent.

To isolate the reset line, I first made only `cam-pwr-csi0` `regulator-always-on`. The power errors went away, but the stream then failed on the first sensor register write (`Error writing reg 0x0100: -6`), and the expander was again unreachable. So the trigger is the **reset/XCLR line** , not the power rail.

I haven't measured the clone board, so the exact electrical mechanism is my assumption. My guess is that on this clone, the connector's enable/XCLR line also switches the module's own regulators, and an unpowered module drags SDA/SCL down. I don't know why genuine V2 boards don't do this.

### Workaround (tested)

A copy of Arduino's `qrb2210-arduino-imola-carrier-media-camera-imx219-csi0-2lanes.dtbo` with two changes:

```diff
 cam-pwr-csi0 {
     ...
     gpio = <&pca9555 1 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ regulator-boot-on;
 };

 sensor@10 {
     compatible = "sony,imx219";
     ...
- reset-gpios = <&pca9555 0 GPIO_ACTIVE_HIGH>;
 };

```

`reset-gpios` is optional in the imx219 driver. With no consumer, PCA9555 pin 0 stays an input, the line floats high, and the sensor uses software standby (register 0x0100) instead.

I built the boot DTB the same way `arduino-linux-config` does:

```arduino
fdtoverlay -i qrb2210-arduino-imola-base.dtb -o qrb2210-arduino-imola.dtb \
    qrb2210-arduino-imola-carrier-media.dtbo \
    imx219-csi0-2lanes-clone.dtbo \
    qrb2210-arduino-imola-video_sound-usbc.dtbo

```

After a **cold** power cycle, `cam -c1 --capture=10` delivered 10 frames at 3272x2464 with no kernel errors, and the image is correct. It has a green cast, because the simple IPA has no `imx219.yaml` tuning and falls back to `uncalibrated.yaml`.

![First frame from the clone V2 on the UNO Q (uncalibrated soft ISP)]()

**If you try this:** back up `/boot/efi/dtb/qcom/qrb2210-arduino-imola.dtb` first. Also, running `arduino-linux-config` again regenerates that file and removes the change.

### Still to check

- A warm `reboot` still works with the workaround.
- Whether removing `reset-gpios` alone is enough, without `regulator-always-on`.
- That a genuine V2 still works with this overlay (no regression).
- Soft-ISP colour tuning for the IMX219.

### Questions for the Arduino team

1. On the Media Carrier, is PCA9555 pin 0 (`reset-gpios`) wired to the camera connector's CAM\_GPIO/enable pin?
2. Would you accept a new camera option in `arduino-linux-config` (for example `type1-2lanes-noreset`), or would you rather change the default overlay, once the regression checks above pass?

 ![clone-frame9](https://europe1.discourse-cdn.com/arduino/original/4X/a/2/8/a28df9d22565e6f45d569ae52e776934846019a6.jpeg)

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 24, 2026, 12:47pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/15 "2026-09-24T12:47:22Z")

</div>

Claude had me turn power on and off for him/her/it. A 50 year career in engineering, retiring as a VP Engineering, has enabled me to become a remote power and cable switcher for an AI...

## Follow-up: the clone V2 fix is a one-line change

Following on from my earlier post: I've narrowed the workaround down, and **the only change needed is removing `reset-gpios` from the camera0 overlay.** Forcing the power rail on (`regulator-always-on`) isn't needed.

### Minimal fix

Arduino's `qrb2210-arduino-imola-carrier-media-camera-imx219-csi0-2lanes.dtbo`, with this one change:

```diff
 sensor@10 {
     compatible = "sony,imx219";
     ...
- reset-gpios = <&pca9555 0 GPIO_ACTIVE_HIGH>;
 };

```

(If you edit a decompiled `.dtbo`, also remove the matching `reset-gpios` entry under ` __local_fixups__ `, otherwise `fdtoverlay` fails.)

### What I tested

- The boot DTB was built exactly as before (base + carrier-media + modified camera0 overlay + video\_sound-usbc), then I did a warm `reboot`.
- I ran `cam -c1 --capture=10` four times, 8 s apart. Every run gave 10 frames at 3272x2464, with no kernel errors.
- I confirmed the power rail really is switched. The sensor's runtime-PM autosuspend is 1 s, and between runs it showed `runtime_status: suspended` with both `cam-pwr` regulators `disabled`. The last run started from that powered-off state and came up cleanly.
- The previous version (reset removed plus always-on rail) also worked after both a cold boot and a warm `reboot`.

### Conclusion

- Switching `cam-pwr-csi0` (PCA9555 pin 1) on and off is harmless for the clone.
- The fault is caused **only** by the reset/XCLR line (PCA9555 pin 0) being driven low. While it's low, the clone loads CCI bus 0, the PCA9555 on that bus stops answering, and reset can't be released again.
- Without `reset-gpios`, the imx219 driver uses software standby instead, and nothing drives that line low.

### Still open

- Checking that a **genuine** V2 still works with the no-reset overlay. I'd expect it to, because `reset-gpios` is optional in the imx219 driver.
- camera1 probably needs the same change (its reset is PCA9555 pin 2). I haven't tested it yet.
- Soft-ISP colour tuning for IMX219. Frames have a green cast with `uncalibrated.yaml`.

### For the Arduino team

The same questions as before still apply, but the change is now very small. Would you prefer:

1. dropping `reset-gpios` from the stock camera overlays, if you can confirm it doesn't affect genuine modules or anything else wired to pins 0 and 2, or
2. a separate option in `arduino-linux-config` (for example `type1-2lanes-noreset`)?

Also, is PCA9555 pin 0 wired straight to the connector's CAM\_GPIO/enable pin? That would explain why some modules react so badly to it being held low.

---

<div class="post-metadata">

**Author:** ![philippe86220](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/philippe86220/32/733778_2.png) [@philippe86220](https://forum.arduino.cc/u/philippe86220)\
**Post date:** [September 24, 2026, 12:55pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/16 "2026-09-24T12:55:32Z")

</div>

Great result Paul!

And I had to smile at your comment about becoming a remote power and cable switcher for an AI after a 50-year engineering career. 😄

Your follow-up makes the problem much clearer to me. What I find particularly interesting is that you have now isolated the workaround to a single change: removing `reset-gpios`, while the camera power can still be switched normally.

It also explains something that puzzled me from the beginning: how the IMX219 could be detected correctly, yet fail later when starting the stream.

I have learned quite a lot from following your investigation, especially about the interaction between the device tree, the PCA9555 and the camera reset line.

Congratulations on finally getting your images, and thanks for documenting the investigation in such detail!

Philippe

**PS:** Now that your camera is actually streaming, I would also be very curious to see what happens if you run my V1 application again unchanged. When you tested it previously, it never got as far as producing a RAW frame because STREAMON failed. It would be interesting to see what my RAW processing produces with your fisheye IMX219 now.

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 24, 2026, 1:15pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/17 "2026-09-24T13:15:17Z")

</div>

Claude has a final comment 🙂

## Follow-up 2: two clone V2s working (camera0 + camera1)

I've now tested two clone IMX219 cameras at once, one on each Media Carrier port.

### camera1 needs the same fix

camera1's overlay (`…-camera-imx219-csi1-2lanes.dtbo`) has the same `reset-gpios`, on PCA9555 **pin 2** , and it fails the same way with a clone attached. Removing it fixes camera1 too:

```diff
 sensor@10 { /* on cci i2c-bus@1 */
     compatible = "sony,imx219";
     ...
- reset-gpios = <&pca9555 2 GPIO_ACTIVE_HIGH>;
 };

```

I built the dual-camera DTB the same way as before (base + carrier-media + camera0 + camera1 + video\_sound-usbc). It differs from the stock dual-camera DTB only in the two removed `reset-gpios` lines.

### Results

- `cam -l` lists both cameras.
- Each camera on its own: 10 frames at 3272x2464, no kernel errors.
- **Both at once at the kernel level works.** Routed csiphy0 → csid0 → vfe0\_rdi0 and csiphy1 → csid1 → vfe1\_rdi0 with `media-ctl`, then streamed raw SRGGB10 1920x1080 from `/dev/video0` and `/dev/video4` at the same time: ~28-30 fps each, no errors.

### Warning if you use the workaround

**`arduino-linux-config carrier enable …` rebuilds `/boot/efi/dtb/qcom/qrb2210-arduino-imola.dtb` from the stock overlays and silently removes the fix.** The clone then fails again, and after a reboot the board may need a full power cycle, because the PCA9555 keeps reset latched low through a warm reboot. Keep a copy of your modified DTB, and re-install it after any carrier reconfiguration.

### libcamera limitation (not related to the fix)

The libcamera 0.4 `simple` pipeline can only stream **one camera at a time** on this board:

- `cam -c1 -c2` silently starts only one of them.
- A second `cam` process fails with:

```arduino
Failed to setup link 'msm_csiphy1'[1] -> 'msm_csid0'[0]: Device or resource busy

```

The simple pipeline routes every sensor through csid0, even though the hardware has two CSIDs and two VFEs, and it works at the V4L2 level (see above). I'm now checking whether a newer libcamera handles this, or whether it needs a pipeline-handler change.

### For the Arduino team

Given the `arduino-linux-config` behaviour, the most robust fix would be to drop `reset-gpios` from both stock IMX219 overlays (camera0 pin 0, camera1 pin 2), I have confirmed a genuine Raspberry Pi Camera V2 works with the reset fix. I'm happy to prepare the PR.

---

<div class="post-metadata">

**Author:** ![paulrbarnard](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/paulrbarnard/32/1284448_2.png) [@paulrbarnard](https://forum.arduino.cc/u/paulrbarnard)\
**Post date:** [September 24, 2026, 1:37pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/18 "2026-09-24T13:37:48Z")

</div>

@philippe86220 forgot to mention in the previous reply but your app works fine with the fisheye camera.

I really appreciate the help you provided on the way through this

---

<div class="post-metadata">

**Author:** ![philippe86220](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/philippe86220/32/733778_2.png) [@philippe86220](https://forum.arduino.cc/u/philippe86220)\
**Post date:** [September 24, 2026, 2:04pm UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/19 "2026-09-24T14:04:05Z")

</div>

That's great to hear, Paul!  
I'm very pleased that my app now works with your fisheye camera too. Thank you for testing it and for letting me know.  
And you're very welcome — I learned quite a lot myself by following your investigation!  
Philippe

---

<div class="post-metadata">

**Author:** ![ptillisch](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@ptillisch](https://forum.arduino.cc/u/ptillisch)\
**Post date:** [September 25, 2026, 1:39am UTC](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033/20 "2026-09-25T01:39:42Z")

</div>

> [@paulrbarnard](#):
>
> clone IMX219 cameras

Which specific cameras are you using? You can post a link to the product listing you purchased them from if you like.

> [@paulrbarnard](#):
>
> I'm happy to prepare the PR.

Please do!

[Next page](https://forum.arduino.cc/t/imx219-camera-with-uno-q-media-carrier-and-app-lab/1460033.md?page=2)