OAK-FFC-4P-PoE – Depth FPS dropped from 10–12 to 2 FPS after network change

anees44

Hi,

I was previously getting stable 10–12 FPS (RGB + StereoDepth) with an OAK-FFC-4P-PoE + 4× IMX378 on DepthAI 2.24.

After changing the network (still same 1 Gbps full-duplex link), performance collapsed:

Raw streams (even single camera, heavily ISP-scaled) only reach ~1.5–1.8 FPS
StereoDepth stays around 2–2.8 FPS
Ping is perfect (0% packet loss, <0.5 ms)

I have tested:

Single camera only
Stereo pair only (CAM_B + CAM_C)
Aggressive ISP scaling (1/4)
Multiple power cycles

Same code and same DepthAI version that previously worked at 10+ FPS now gives very low FPS.

DepthAI: 2.24.0.0
Host: Raspberry Pi 5

Any ideas what could cause this after a network change?

Thank You

Oskar-Luxonis

Hey anees44 - this looks like a network-throughput issue rather than a StereoDepth issue, since it also happens with one scaled stream. Could you run the PoE link, bandwidth, and latency tests from our PoE deployment guide? The link should report 1000 Mbps; please also try a known-good Cat5e+ cable and bypass the new switch/injector path if possible.

I’d also recommend updating DepthAI from 2.24.0.0 to the newest version before testing.

Thanks,
Oskar

anees44

Hi Oskar,

I followed your suggestions. Here are the results:

PoE Link Test (poe_test.py)

mxid: 14442C10C1D391D700 (OK)

speed: 1000 (OK)

full duplex: 1 (OK)

boot mode: 3 (OK)

Latency Test (oak_latency_test.py)

Average latency is very good: ~3.2 – 3.8 ms

Bandwidth Test (oak_bandwidth_test.py)

Fails every time. The device crashes with:

Monitor thread ... ping was missed, closing the device connection

Device has crashed. Crash dump logs are stored in .../crash_dump.json

RuntimeError: Communication exception ... 'Couldn't read data from stream: 'xout' (X_LINK_ERROR)'

Real Camera Streams

Even a single scaled ColorCamera (ISP scale 1/4, 320×180 preview) only reaches ~1.6 – 1.8 FPS.

Summary

Link speed and latency look perfect.
As soon as higher bandwidth is requested (bandwidth test or real camera streams), the device becomes unstable and crashes.

I have also tried multiple power cycles. The device sometimes stays in X_LINK_BOOTLOADER state after crashes.

Remaining questions:

Is this most likely a network equipment (switch/injector/cable) issue under load?
Should I try flashing a newer network bootloader?
Any other recommended tests or known issues with this behavior on FFC-4P-PoE + IMX378?

DepthAI: 2.32.0.0
Host: Raspberry Pi 5

Thanks for the help.

Oskar-Luxonis

Hey anees44 - thank you. The link speed and latency are good, but the device fails during sustained XLink traffic. Please send us the crash_dump.json file so we can check the device-side error.

Could you also test with a known-good PoE injector, cable, and direct connection to the Raspberry Pi? Please share the switch/injector models and their PoE power budget.

Please check the network bootloader version first. We can then decide if a bootloader update is needed.

Thanks,
Oskar

anees44

crash-dumps.zip

19kB

Hi Oskar,

Here is the information I have so far:

**Network Bootloader version:** 0.0.28

**Crash dumps:** I am attaching the crash dump files (renamed to .txt / zipped because .json was not accepted).

Unfortunately I do not currently have the exact Switch and PoE Injector model numbers. I have requested them from the client and will share as soon as I receive them.

I will also arrange a test with a known-good injector + cable + direct connection to the Raspberry Pi and report the results.

Please let me know if the crash dumps already show anything useful, and whether we should update the network bootloader from 0.0.28.

Thanks

Oskar-Luxonis

anees44 - the crash dumps show that IP 192.168.0.149 moved between two different MAC addresses. This suggests an IP-address conflict or ARP problem on the new network, which can interrupt XLink under load.

Please check which device uses 192.168.0.149, and make sure the OAK and Raspberry Pi have unique IP addresses or DHCP reservations. Then repeat the direct injector/cable test.

I do not recommend a bootloader update yet. Version 0.0.28 is not the main suspect.

Thanks,
Oskar

anees44

Hi Oskar,

Update after further testing:

Network changes made

We disabled WiFi on the Raspberry Pi (wlan0 is now DOWN).
The Pi previously had both:
- eth0 = 192.168.0.102
- wlan0 = 192.168.0.149
  on the same 192.168.0.0/24 subnet.
After disabling WiFi, only Ethernet remains active.

Results after disabling WiFi

Ping is still perfect (0% loss).
poe_test.py still reports speed: 1000 / full duplex OK.
Latency is still good (~3.5 ms).
Bandwidth test still crashes the device every time with:
- “ping was missed”
- X_LINK_ERROR
- device often returns to X_LINK_BOOTLOADER state afterward.

Other observations

192.168.0.149 is the Pi’s own former WiFi address.
192.168.0.95 is reachable and currently shows one MAC (30:de:4b:15:03:b2).
Real camera streams remain very low FPS (often ~1.6–6.5 FPS depending on the test).
Network Bootloader is still 0.0.28.

Please let us know if the latest crash dumps (after WiFi disabled) show anything new, and whether you still suspect an ARP/IP conflict as the main cause

crash-dumps.zip
28kB

Oskar-Luxonis

Hey anees44 - the latest crash dump shows the same runtime failure after the pipeline starts. It does not show the earlier WiFi/ARP issue, so please also test the OAK with the previous network that gave good results, if possible. If possible also test with a PC instead of Raspi, since they are sometimes causing some problems.

You can update the NETWORK bootloader from v0.0.28 to v0.0.29. Please install DepthAI v3.9.0 or newer for this update, as DepthAI v2.32 includes only bootloader v0.0.28.

Use Device Manager and select Update Bootloader → NETWORK. This updates the recoverable user bootloader. Do not flash the factory bootloader. After the update, you can return to your existing v2 application and repeat the bandwidth test.

The bootloader update guide is here: RVC2 Bootloader

We also recommend migrating the application to DepthAI v3, as DepthAI v2 is deprecated.

Thanks,
Oskar