Having trouble getting my OV64A40 (Owl camera) working with the LAN extension kit on a Raspberry Pi 5. I’m using an 8-9 meter CAT6 cable between the camera and the Pi. Set up dtoverlay=ov64a40,cam1,link-frequency=456000000 in config.txt and when I try to capture an image I get this:
libcamera-still -t 5000 -n -o test.jpg
[0:44:16.068578753] [566375] INFO Camera camera_manager.cpp:326 libcamera v0.5.0+84-79f583c3-dirty (2025-05-06T02:52:19BST)
[0:44:16.099554025] [566502] INFO RPI pisp.cpp:720 libpisp version v1.2.1 981977ff21f3 29-04-2025 (14:13:50)
[0:44:16.180336161] [566502] INFO RPI pisp.cpp:1180 Registered camera /base/axi/pcie@120000/rp1/i2c@80000/ov64a40@36 to CFE device /dev/media0 and ISP device /dev/media2 using PiSP variant BCM2712_C0
[0:44:16.181278477] [566375] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format RPBP
Mode selection for 4624:3472:12:P
SBGGR10_CSI2P,1920x1080/0 - Score: 11359.2
SBGGR10_CSI2P,2312x1736/0 - Score: 9096
SBGGR10_CSI2P,3840x2160/0 - Score: 5359.24
SBGGR10_CSI2P,4624x3472/0 - Score: 1000
SBGGR10_CSI2P,8000x6000/0 - Score: 2476.58
SBGGR10_CSI2P,9248x6944/0 - Score: 3024
Stream configuration adjusted
[0:44:16.181787422] [566375] INFO Camera camera.cpp:1205 configuring streams: (0) 4624x3472-YUV420 (1) 4624x3472-RGGB_PISP_COMP1
[0:44:16.182009941] [566502] INFO RPI pisp.cpp:1484 Sensor: /base/axi/pcie@120000/rp1/i2c@80000/ov64a40@36 - Selected sensor format: 4624x3472-SRGGB10_1X10 - Selected CFE format: 4624x3472-PC1R
[0:44:16.203416832] [566502] ERROR V4L2 v4l2_device.cpp:390 'bu64754 4-0076': Unable to set controls: Connection timed out
[0:44:16.318948077] [566502] ERROR V4L2 v4l2_videodevice.cpp:2049 /dev/video6[19:cap]: Failed to start streaming: Connection timed out
ERROR: *** failed to start camera ***
The camera works fine with the short flex cable that came in the box, but as soon as the LAN extension is in the path it just times out. Anyone seen this before? The bu64754 I2C timeout looks suspicious but I’m not sure what it means.
That bu64754 4-0076 error is interesting - that’s the I2C device for lens control (the BU64754 is a voice coil motor driver for autofocus). It’s timing out before the CSI data streaming even has a chance to start. That’s the first failure point in your log.
Could you share a bit more about your setup? Specifically:
Which Pi 5 model and what OS/kernel version?
Have you tried a different CAT6 cable with the LAN extension kit?
Is the HAT seated properly on the Pi? Some heatsink configurations can cause clearance issues.
Can you try the camera directly on the Pi with a short cable just to confirm the camera itself is good?
About the heatsink - you called it. The HAT physically can’t seat all the way down on the Pi 5 because the heatsink gets in the way. I’ve got it as far down as it’ll go but it’s not ideal.
I tested the OV64A40 directly on a Raspberry Pi 4 with a 1 m flex cable and it does work, but I’m seeing purple stripes across the image. Looks like signal degradation even at 1 m, which doesn’t bode well for longer runs.
I also have a Hawkeye camera - that one used to work on a 2 m CSI cable but has since stopped. When I try it through the HDMI/CSI extension kit it’s hit or miss.
Quick update on the Hawkeye testing with the HDMI to CSI extension kit:
Works on a 1.5 m HDMI cable - captures fine
Does not work on a 2 m HDMI cable or anything longer - same kind of timeout errors
After a few rounds of swapping cables, it’s now stopped working on ALL HDMI cables including the 1.5 m one that was previously fine
Feels like the extension kits are really borderline with anything beyond very short cables. The 8-9 m CAT6 run with the LAN extension kit hasn’t worked once across any of the cameras I’ve tried. Starting to wonder if there’s a fundamental signaling issue over these longer distances.
This is all pointing toward an I2C bus integrity problem over distance, which is actually a known sensitivity with these camera modules. Let me break down what I think is happening:
The bu64754 4-0076 device is sitting on the I2C bus (bus 4, address 0x76) and it’s the first thing that fails - before the CSI data lanes even attempt to stream. The I2C bus runs at a much lower frequency than the CSI lanes, but it’s more susceptible to cable capacitance and signal degradation over distance because it uses open-drain signaling with pull-up resistors.
On a short flex cable the bus capacitance is low enough that everything works. Once you add meters of CAT6 or HDMI cable (even though the extension kit repurposes those for CSI/I2C), the added capacitance rounds off the I2C edges and you start getting timeouts.
A few things to try:
Try a different CAT6 cable with the LAN extension kit - we’ve had the kit working at 10 m on our side, but cable quality (especially twist consistency and conductor gauge) matters a lot for this. Some cables have higher inter-pair capacitance than others.
Double-check your link frequency in config.txt - make sure it’s exactly dtoverlay=ov64a40,cam1,link-frequency=456000000. A mismatch there can compound the timing issues.
Test the Hawkeye directly on the Pi with no extension at all - just the short flex cable, running libcamera-still -t 5000 -n -o test.jpg. This will confirm the camera hardware itself is still good.
For the heatsink clearance problem - you might want to look at a GPIO extender/riser so the HAT can sit flat, or consider a lower-profile heatsink. A poorly seated connector can cause intermittent contact that mimics the distance-related issues.
So I went ahead and bought an Owlsight camera with the LAN extension kit thinking maybe it was a camera-specific issue. Set it up on the Pi 5 with the same CAT6 run and got a slightly different failure:
[0:04:25.494152675] [32687] INFO Camera camera_manager.cpp:326 libcamera v0.5.0+84-79f583c3-dirty
[0:04:25.523751552] [32715] INFO RPI pisp.cpp:1180 Registered camera /base/axi/pcie@120000/rp1/i2c@88000/ov64a40@36 to CFE device /dev/media0 and ISP device /dev/media3 using PiSP variant BCM2712_C0
[0:04:28.536144976] [32715] WARN V4L2 v4l2_videodevice.cpp:2150 /dev/video4[17:cap]: Dequeue timer of 1000000.00us has expired!
[0:04:28.536219718] [32715] ERROR RPI pipeline_base.cpp:1420 Camera frontend has timed out!
[0:04:28.536227810] [32715] ERROR RPI pipeline_base.cpp:1421 Please check that your camera sensor connector is attached securely.
[0:04:28.536233959] [32715] ERROR RPI pipeline_base.cpp:1422 Alternatively, try another cable and/or sensor.
ERROR: Device timeout detected, attempting a restart!!!
Then after a reboot, the camera completely disappeared:
ERROR: *** failed to acquire camera /base/axi/pcie@120000/rp1/i2c@88000/ov64a40@36 ***
And another reboot later:
ERROR: *** no cameras available ***
I’ve done multiple reconnections of everything, updated all packages, same result. The camera registers on first boot after being plugged in, then times out and vanishes from the system entirely until I physically disconnect and reconnect it.
One question that keeps nagging at me: is I2C actually required for the camera to work at all? The timeout errors all seem to trace back to I2C devices, and I’m wondering if there’s any way to bypass that or if it’s a hard dependency.
Yes, I2C is absolutely required - there’s no way around it. The camera sensor configuration, register setup, and lens control all happen over I2C before the CSI data path can be established. If the I2C bus isn’t reliable, nothing downstream works. That’s exactly the pattern you’re seeing.
The sequence in your logs tells the story pretty clearly:
Camera is detected on the I2C bus during probing (Registered camera ... ov64a40@36)
When libcamera tries to configure the BU64754 lens controller over I2C, it times out (Unable to set controls: Connection timed out)
CSI streaming fails because the sensor was never properly initialized
After enough failures, the kernel marks the device as unreliable and it drops off the bus entirely (no cameras available)
On the Owlsight log, the failure looks slightly different - the camera frontend timeout at 1 second - but it’s the same root cause. The I2C configuration likely succeeded just enough for the pipeline to start, but subsequent I2C communication failed mid-stream and the whole pipeline collapsed.
The core problem is that your CAT6 cable’s capacitance is pushing the I2C bus beyond its spec. I’ve sent you a few things via private message:
An alternative firmware package to try that adjusts some timing parameters
A diagnostic script that can test I2C bus reliability at different speeds
In the meantime, if you have access to another brand or batch of CAT6 cable (especially one with a known low capacitance spec), that’s worth a shot. The solid-core vs stranded difference can matter here too - solid-core tends to perform better for this application.
Alright, I’ve done extensive testing now and here’s where things stand:
Direct connection (short flex cables, no extensions):
Both the Hawkeye and OV64A40/Owl cameras work perfectly on a Raspberry Pi 4 with the short ribbon cables that came with them. No purple stripes, no timeouts, solid captures every time.
With any extension kit (HDMI or LAN):
Anything beyond about 1.5 m fails consistently across all cameras and both Pi models
The LAN extension kit with 8-9 m CAT6 has never worked once
Even the HDMI kit that briefly worked at 1.5 m eventually became unreliable
So it’s pretty definitive at this point: the long cable extensions are the root cause of all the failures across every camera I’ve tested. The I2C bus just can’t handle the distance.
For my project I’ve decided to work around it rather than fight it - I’m deploying three separate Raspberry Pi 4s, each with its own camera connected via a short flex cable, instead of trying to run everything back to a single Pi over long extensions. Not the elegant solution I wanted, but it’s reliable. Appreciate all the help diagnosing this.
That’s a solid conclusion, and honestly a sensible workaround given your constraints. The three-Pi approach eliminates the cable-length problem entirely and gives you independent processing at each camera node, which has its own advantages.
To summarize what we’ve learned for anyone else stumbling on this thread:
The I2C bus (used for sensor configuration and lens control) is the weak link when extending camera cables, not the CSI data lanes. The bu64754 device at I2C address 4-0076 is typically the first thing to fail.
Cable quality matters a lot - CAT6 cables vary significantly in capacitance, and lower-capacitance cables can make the difference between working and not working at 8-10 m distances.
The LAN extension kit can work at 10 m with the right cable, but it’s operating at the edge of the I2C spec. Your mileage may vary depending on the specific cable and environmental conditions.
If you’re seeing purple stripes on short cables, that can be a separate signal integrity issue on the CSI lanes - check connector seating and try a different flex cable.
The heatsink clearance issue with the Pi 5 is worth addressing with a GPIO riser if you’re using a HAT - a partially seated connector can cause the same symptoms as a long cable.
Glad you found a path forward with the multi-Pi setup. If you run into any issues with that configuration, feel free to post back.