Camera problems

Yeah same error here. I think they have to fix some libraries but very anoying that the exact same camera does not work with the code Particle supply!

One question - when you say it works, does it autofocus??? I can get still pics no problems, it obeys effect command but seems to ignore the mode-focus command!
FYI: I am using a headless system and XRDP to display pics on a Mac via KDE Plasma re remote desktop. So def not a proper dektop system - but I am thinking to re image and try that way because I think then the encoder/decoder stuff will work as it’s directly connected to the video output hardware. Is that why your having the same issue or is yours a full desktop image?

@Perky It works in the sense that I get a screenshot from the first one and a video from the second, but autofocus didn’t work for either (I actually didn’t attempt to focus in any case - I guess I was hoping it was just … automatic.)

I’m using the Desktop image which installs 20.04. Unfortunately I think I’m stuck at this point unless someone with more experience chimes in!

1 Like

Hey folks - quick follow-up here with a few insights after more testing with CSI camera modules and cables:

2-lane vs 4-lane CSI: What It Means

Most Raspberry Pi camera modules (like the v2 and HQ cameras) use 2-lane MIPI CSI-2, which is fine for their bandwidth needs. Tachyon, on the other hand, is wired for 4-lane CSI via its 22-pin connector, allowing higher-resolution sensors (like the IMX519) to operate at full speed - so, most of our camera drivers require that both the camera module and cable support all 4 lanes without driver change. This is very doable, but its also requires more testing.

Cable Compatibility: More Than Just the Pinout

Although the Raspberry Pi helped standardize the physical connector, electrical performance varies significantly, especially at 4-lane speeds. Common issues we’ve seen:

  • Poor impedance control on flex cables

  • Crosstalk and noise on longer cables

  • Unmatched differential pairs

So while the connectors may look the same, not all CSI cables behave the same, and that’s where things often go wrong. I will say the RPi has some software to control the PHY pins to make them more flexible which have not attempted to touch, but it should not be needed with a pair cable / module.

Our Driver Stack Requires 4-Lane Mode

Our integration with Qualcomm’s qmmf-server assumes 4-lane camera operation, so 2-lane cables and modules usually won’t work out of the box. We’ve seen this cause:

  • Pipeline failures

  • GStreamer hangs

  • “Camera service has died” errors

Even if the module is compatible, the cable or its lane mapping can prevent successful negotiation or initialization.

Arducam Compatibility Testing

We’re currently testing all variants of the Arducam modules with our 4-lane cable to determine which work reliably with Tachyon. We’ll post an update in a day or so with recommended combinations, including a version of our cable available via the eStore.

Cable Chaos…

I was in the Raspberry Pi Store over the weekend and snapped a picture of their growing collection of CSI/DSI cables - they defined much of the ecosystem, but have similar issues and need for their own cables - we’re headed in the same direction: a curated cable offering to reduce setup friction and improve reliability. Good news, these are not expensive!

If you’re running into issues, hang tight - we’ll publish a compatibility list and sourceable cable option soon. And if you’ve had success (or failure) with a particular camera/cable combo, we’d love to hear it - building a shared base of experience here will help everyone.

Final note - I have seen then auto focus issue. There appears to be a bug in the limits for this driver for the I2C range control of the focus module - looking into it!

Thanks again for the feedback!

I received today same Arducam as others and tried the commands others tried. I get the following errors below. Not sure if a camera issue since it says ‘Failed to Open Camera’ vs. others that get ‘Camera Service has Died’.

It looks like the RPi’s Cambridge store? My local RS Components store doesn’t have that level of Pi accessories.

Hi Nick,

I followed the section in Particle Developer for Tachyon for the camera. I recenlty purchased the Arducam IMX519 which is supposed to be compatible, but get errors when running the commands provided in the docs to get a picture.

_____________

ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstQmmfSrc:qmmf: Failed to Open Camera!
Additional debug info:
/Tachyon/build-qti-distro-ubuntu-fullstack-debug/tmp-glibc/work/aarch64-oe-linux/gstreamer1.0-plugins-qti-oss-qmmfsrc/1.0-r0/gst-plugin-qmmfsrc/qmmf_source.c(840): qmmfsrc_change_state (): /GstPipeline:pipeline0/GstQmmfSrc:qmmf

_________________

Is this a known issue and being worked on? I am kind of stuck since I was hoping to use the Tachyon in my robot project. At this point I am not sure if I should move to using the RPi 5 and come back to Tachyon later.

Hi @terracode

Apologies for the trouble. Just to be clear, you are using the Autofocus Arducam IMX519 camera?

Can you share the exact pipeline command you are using?

Can you double check that you have the right camera parameter, ie for CSI1 camera:

gst-launch-1.0 qtiqmmfsrc camera=0 name=qmmf

The docs have CSI2 camera as the default example, and therefore have camera=1 but I think this is not the most common setup. Ill go through and update them to assume CSI1 is the camera being used.

The Qualcomm multi media plugin claims to support autofocus via the focus-mode option. From gst-inspect-1.0 qtiqmmfsrc:

focus-mode          : Whether auto-focus is currently enabled, and in what mode it is.
                        flags: readable, writable, changeable in NULL, READY, PAUSED or PLAYING state
                        Enum "GstCameraFocusMode" Default: 0, "off"
                           (0): off              - The auto focus routine is disabled.
                           (1): auto             - The auto focus routine is active.
                           (2): macro            - In this mode, the auto focus algorithm is optimized for focusing on objects very close to the camera.
                           (3): continuous       - In this mode, the AF algorithm modifies the lens position continually to attempt to provide a constantly-in-focus image stream.
                           (4): edof             - The camera device will produce images with an extended depth of field automatically; no special focusing operations need to be done before taking a picture.

I have added focus-mode=continuous to the pipeline (ie gst-launch-1.0 -e qtiqmmfsrc camera=0 name=qmmf focus-mode=continuous) but its not immediately clear that the camera driver is working with this parameter. Ill work with our upstream vendor to figure out the autofocus behavior.

Hi @sbrust I am using the Arducam IMX519 on the main camera (CSI) port and not the DSI/CSI port. I am using the instructions commands that were in the Tachyon docs under Camera. I also tried the commands that users said worked (kind of) for them.

Yeah it seems to ignore the commands, accepts them as valid but no effect.

I’ve done some extensive research on this issue as the main reason I have the Tachyon was for high speed steroscopic computer vision and this camera allows the focus to be set at set focal lengths.
Yeah I used Claude to help because it’s way faster at scanning docs/web pages and did come up with some very interesting findings, maybe some of this will help?

Particle Tachyon IMX519 Auto Focus Bug Report

Summary

Particle Tachyon IMX519 camera auto focus is completely non-functional due to missing device tree configuration for the lens motor hardware.

Hardware Configuration

  • Device: Particle Tachyon

  • Camera: IMX519 with auto focus lens

  • Expected: Auto focus should work via qtiqmmfsrc focus-mode parameter

  • Actual: All focus commands silently ignored

Root Cause Analysis

:white_check_mark: Working Components

  • IMX519 sensor fully functional (captures images)

  • Camera subsystem properly configured in device tree

  • qtiqmmfsrc GStreamer element accepts focus parameters

  • Lens driver module exists: qcom,lens_driver

:cross_mark: Missing Components

  • NO lens motor device tree configuration

  • No device tree nodes for focus/lens/AK7375

  • qcom,lens_driver loaded but not bound to any hardware

  • qtiqmmfsrc focus commands parsed but not executed

Technical Evidence

1. Camera System Working

dmesg shows:
sensor_id:0x519,sensor_slave_addr:0x34
CAM_STOP_DEV Success, sensor_id:0x519

2. Lens Driver Exists But Unbound

$ find /sys -name "*lens*"
/sys/bus/spi/drivers/qcom,lens_driver
/sys/module/camera/drivers/spi:qcom,lens_driver

$ ls -la /sys/bus/spi/drivers/qcom,lens_driver/
# Directory empty - no bound devices

Any further progress on this camera Autofocusing issue guys???
I know you have a lot going on - just curious at this point :slight_smile:

@Perky

I bought a Raspberry PI 5 last week and tried the Arducam IMX519 and had the autofocus issue as well. I couldn't get the cam to work at all on my Tachyon. I found Arducam had beta drivers that fixed the issue for me on RPi 5. I wonder if same drivers will work on Tachyon. I will shift back to Tachyon after new dist update is released.

Can you run this command and share the output with me?

gst-launch-1.0 -e qtiqmmfsrc camera=0 \
! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 \
! qtic2venc ! h264parse ! mp4mux ! queue \
! filesink location=/home/particle/video_snapshot.mp4 \
--gst-debug=qtiqmmfsrc:LOG

Do you see any devices under /dev/video?

I apologize for the difficulties here, im going to be looking at the camera compatibility this week and making the documentation a little clearer.

1 Like

Apologies again for the slow reply.

I see your report about autofocus not working on the imx519 camera. I think your findings are accurate as far as I can tell. I do see in the driver from our BSP vendor there is some mention of the AK7375 actuator but there is no explicit connection of it in the device tree. Ill ask our vendor if this is intentional or not.

@sbrust

I moved the camera to my other SBC for development until the Tachyon software and docs mature a bit more.

Understandable - mine is now on the RPI 4 and works perfectly!
@sburst - Any chance of me (engineer) helping out here with a little more info regarding the Qualcomm/kernel drivers?
I know there are so many issues to work through on a massive project like this but would love to help out. :slight_smile:

Sorry I have been away for a bit. Life and stuff… good to see there is still action going on here. @mrlambchop - email sent.

It’s also great to see that there is an obvious direction to go towards to get the problem solved even if it isn’t a quick fix, knowing where to make the fix is better than blindly guessing!

Ditto on both of the challenges above. I tried the ArduCam IMX708 with the ArduCam UC-376 cable, (missed this thread before purchasing) then tried the IMX519 and ran into the auto-focus issue as well. A couple additional things I tried (heavily assisted by Cursor running on Tachyon) I tried to create a manual focus script with keybindings with no luck. Cursor says:

-The AK7375 actuator hardware exists in the system (at /sys/devices/platform/soc/ac4a000.qcom,cci0/ac4a000.qcom,cci0:qcom,actuator0)

-The power regulator (regulator.78) is disabled and the system won't let us enable it manually

-The kernel modules are incompatible with your kernel version (5.4.219 vs 5.10.x)

Before I purchase more incompatible hardware, is there anyone that has recommendation for a (decent quality) USBC webcam that is working for them with the Tachyon?

1 Like

@sbrust
Hi Scott,
It’s been a while since the last update. Do you have any update on a fix for the imx519 autofocus not working? Thanks.

I purchased an imx519 last week. As per the comments from other owners, imx519 autofocus works great with Raspberry Pi (5, Pi Zeros 2W). Hopefully you, your dev team and vendor can come up with fix soon.

Also, Does Particle plan to support the Raspberry V3 (imx708) camera any time soon?

Cheers!

1 Like

We are currently testing a patch for the IMX519. We will provide an update once validation has been completed.