Rpicam-hello timeout errors after Raspberry Pi 5 overnight shutdown with IMX519 synchronizer

Hi everyone, I’m running into a weird issue with my setup and hoping someone here can help.

I have a Raspberry Pi 5 with the Arducam Synchronize Module (HAT) and two IMX519 AF 16MP cameras connected. Everything worked fine for about 4 hours of testing, then I powered the Pi off overnight. Next morning, rpicam-hello throws this:

“time out, check camera sensor connector and try another cable.”

This has actually happened twice now. The first time, the cameras randomly started working again after about 5 days. The second time — no luck, they never came back.

What I’ve tried so far:

  • Swapped both cameras for imx708 wide-angle NoiR cameras — same error.
  • Replaced the entire kit: different Raspberry Pi 5, different SSD module, different synchronizer module, different power supply — same result.

At this point I’m kind of stuck. Any ideas what might be going on?

Thanks for the detailed report. Let’s start by ruling out some basics.

First, could you share clear pictures of your hardware connections — both at the Raspberry Pi end and at the camera end? I want to see how the ribbon cables and the HAT are seated.

Second, let’s get a full bug report from the system. Please run these steps exactly as written:

  1. Reboot the Pi.

  2. Download the bug report tool:

    wget -O arducam-camera-bug-report https://github.com/Dion4cen/arducam-camera-bug-report/releases/download/Tool/arducam-camera-bug-report

  3. Make it executable:

    chmod +x ./arducam-camera-bug-report

  4. Run it:

    ./arducam-camera-bug-report

This will generate an “arducam-bug-report.txt” file in your current directory. Attach that file here along with the photos and we’ll dig in.

Okay, I’ve taken the photos and ran the bug report tool. I’ve attached the arducam-bug-report.txt here.

One thing I noticed while running the tool — it seemed to complete without errors, but the camera timeout issue is still 100% reproducible. Every single rpicam-hello attempt fails with the same timeout message.

Thanks for the pictures and the bug report. I’ve gone through them and I think I’ve spotted the issue.

Looking at the bug report data, the Synchronizer HAT board is not receiving power through the Raspberry Pi’s GPIO pins — or at least, not enough power. The HAT appears to be underpowered in your current setup, which would explain the camera timeouts. The synchronizer module needs adequate power to drive both camera lanes, and relying solely on GPIO passthrough power from the Pi 5 may not be cutting it.

Can you try this: connect a dedicated Type-C power cable directly to the Synchronizer HAT board itself (it has its own Type-C power input). Don’t rely on just the GPIO pins for HAT power. Then test rpicam-hello again and let me know if the timeout errors go away.

Alright, I tried connecting an extra Type-C power source directly to the Synchronizer module. Still getting the exact same timeout error with rpicam-hello.

Just to clarify my hardware stack, from bottom to top: Raspberry Pi 5 → SSD Module (middle) → Synchronizer Module (on top).

Should I be using two completely separate Type-C power sources — one for the Raspberry Pi 5 board itself, and a different one for the Synchronizer module? Right now I just added one extra Type-C to the sync module while the Pi 5 still has its own.

Yes, that’s exactly what I meant — two independent power sources. Please use one Type-C to power your Raspberry Pi 5 as normal, and a separate, dedicated Type-C to power the Synchronizer module. The point is to take the HAT power draw off the Pi’s GPIO pins entirely and give it its own supply.

So the setup should be:

  • Pi 5 powered via its own Type-C (your normal Pi power supply).
  • Synchronizer module powered via its own Type-C (a separate cable and adapter).

Give that a go and let me know what you get.

Tested again with the Synchronizer module on its own dedicated Type-C power — completely separate from the Pi 5’s power supply. Still no change, same timeout error.

At this point I’m starting to wonder if the Synchronizer module itself got damaged somehow. Although it’s odd because it worked fine for at least 4 hours before stopping after that first reboot. It’s not like it was dead on arrival.

Side question: does anyone know where I can buy flat ribbon cables with 22 pins on one side and 15 pins on the other? The ones that came with the kit are a bit short for my enclosure and I’d like to try longer ones just to rule out cable issues.

That’s frustrating. Since the dedicated power didn’t resolve it and you’ve already swapped the entire kit once, there may be something deeper going on with the sync module firmware or hardware state.

I’ve sent you a private message with details for scheduling a remote support session — we can connect via remote desktop and I’ll take a live look at the system to run some deeper diagnostics. No point going in circles here.

Regarding the cables: I’ve also PM’d you a link to the 15-pin to 22-pin camera cables you’re looking for (15 cm length). Check your messages.

Thanks — I’m not at the Pi right now (working from home), but I’ll get the remote session info to you tomorrow before the scheduled time.

Update: we did the remote session and it was really helpful. Dion was able to confirm through live diagnostics that the synchronizer module does look like it’s developed a fault. Going to send the sync modules in for further inspection. Will report back once I hear more.

Glad the remote session was productive. Based on what we saw during the live debugging — the cameras and Pi itself check out fine, and the issue follows the synchronizer module even with independent power — a hardware fault on the sync HAT seems to be the most likely explanation at this stage.

I’ve sent you the return/inspection details through private message. For anyone else reading this thread with similar symptoms (rpicam-hello timeout on Pi 5 + sync HAT, especially if it worked briefly then stopped after a power cycle): try the dedicated Type-C power to the synchronizer module first. If that doesn’t fix it, it may be worth reaching out for a deeper diagnostic session.

I’ll update this thread once we’ve had a chance to examine the returned modules.