OAK-D IoT-75 SPI demo error

YLH

Hello Luxonis Support Team,

About one month ago I purchased an OAK-D IoT-75 from Luxonis, and I’m currently trying to validate SPI communication using your official resources.

What I’m doing

I’m using the official demo spi_in_passthrough on the host side.
I downloaded and used the required SPI library and related files from:
- luxonis/depthai-spi-librarytree/main
My goal is to run the official SPI passthrough / echo flow to confirm the SPI link is working properly.

Issue / Error
During the demo, I repeatedly get the following error message on the host:
[SPIIn(0)] [error] Failed to parse incoming message, check if depthai-shared commit match between Host and SPI library. Dropping message

This looks like a protocol / version mismatch (depthai-shared commit mismatch) between the host and the SPI library side. However, I’m confident that I’m using only Luxonis official code and repositories, so I’m not sure how a mismatch could happen.

My questions

Is there a recommended release tag or commit that I should check out for both host code and the SPI library to ensure compatibility?
Are there any known issues or required steps (build flags, submodule commits, or dependencies) that commonly cause this parsing failure?

If you need any additional logs (host console output, device MXID, depthai version, or the exact commit hashes I’m using), I can provide them right away.

Thank you for your help.

Best regards

OskarSonc

Hey YLH - this error almost always means the SPI “message schema” (depthai-shared) used by your host DepthAI build doesn’t match the one used by the SPI firmware/library side, so the host can’t decode the incoming packets.

Since OAK-D IoT-75 (IoT line) is community-supported/as-is and I don't have a lot of knowladge on this, there isn’t a maintained compatibility matrix. The most reliable path is to use the archived end-to-end reference (esp32-spi-message-demo) and build it with its pinned submodules (git submodule update --init --recursive), then run the matching host example from the same “era” (avoid a newer pip DepthAI wheel). Also note the ESP32 demo was tested with ESP-IDF v4.1, so using a different IDF can introduce ABI/packing issues. You can also search this forum a bit since I saw there are some older posts about this device...

Thanks,
Oskar

YLH

Hi OskarSonc

Apologies again for following up, and thank you very much for your previous guidance.

Following your recommendation, I switched to DepthAI 2.15 and built the ESP32 side strictly using ESP-IDF v4.1, trying to match the original demo environment as closely as possible.

However, during testing with a minimal RGB preview pipeline (ColorCamera → preview → XLinkOut), I am observing the following behavior:

The RGB camera is detected correctly.
Frames are continuously received on the host.
But each frame is a constant image (min = max, std = 0).
The brightness value changes slightly (likely AE reacting), but there is no spatial variation in the image.

Example:

$$
PRE min=64 max=64 std=0.00
PRE min=67 max=67 std=0.00
$$

This suggests that the ISP is outputting a constant buffer rather than actual scene data.

Additionally, when testing the MJPEG encoder path, I am not consistently receiving valid JPEG frames.

For comparison, I also tested using DepthAI 2.29 with USB-only communication, running my own trained YOLO model on the device.

In that setup:

RGB preview works normally.
The model runs correctly.
USB streaming of frames and inference results is stable.

So the hardware itself appears to function properly under 2.29.

Given this, I am wondering whether there might be some subtle incompatibility or initialization difference in 2.15 (especially considering the IoT-75 line and its archived status), rather than a hardware issue.

I would kindly like to ask:

Do you recall whether the original SPI demo on OAK-D IoT-75 was fully validated for sustained RGB streaming?
Was the demo primarily intended for message schema validation rather than full camera pipeline usage?
In your experience, is 2.15 still the most appropriate version for SPI-era testing on this device, or might another specific version be more stable?

I completely understand that the IoT line is community-supported and archived, so I just want to better understand the intended scope and realistic expectations for this hardware.

Thank you again for your time and support.

Best regards,
YLH

OskarSonc

Hi @YLH ,

Thanks for the detailed update. Your USB 2.29 result suggests hardware is fine. My knowledge is really limited, but investigated a bit for you.

IoT-75 SPI demos were mainly validated for protocol/message transport, not robust sustained RGB streaming quality. So your constant-frame behavior on old SPI stack can happen even when the camera is healthy.

If you want the closest known-compatible SPI setup, pin exactly:

depthai==2.15.3.0
esp32-spi-message-demo 7b9184cc5c165b70935f45e661cd6caa03da67dd
depthai-spi-api 5b179bdea978d100ce33ec85f3244456077096b5
depthai-shared 648d4c1ae6dd8c6dc1540721a8960a85de3b761d
depthai-spi-library 0658c664ba079407e541fad8091f0eaa9b4fe6ea
ESP-IDF v4.1

But can't say for sure this will work as intended. If you want something reliable with no extra work, I would suggest switching to OAK device that is fully supported.

Thanks,
Oskar