Raspberry Pi 5 is the primary host platform. Raspberry Pi Compute Module 5 is also supported, via the official Raspberry Pi CM5 IO Board. Note that a different FFC cable is needed for that path; see the cable question below. Pi 4, CM4, and non-Raspberry Pi SBCs are not supported. AI HAT+ requires the PCIe FFC connector that exists only on the Pi 5 and the CM5 IO Board, and HAT+ specification compliance is tied to Pi 5 power and ID handling. See the Sixfab AI HAT+ overview for the full compatibility statement.

A different cable than the one shipped in the AI HAT+ box. AI HAT+ ships with a 30 mm 16-pin FFC cable sized for the Raspberry Pi 5. The Raspberry Pi CM5 IO Board's PCIe connector uses a different pin pitch and length, so the bundled cable does not fit. Source a CM5-compatible PCIe FFC cable separately before assembly. [NEED FROM SIXFAB: exact CM5 IO Board FFC cable spec (pin pitch, length, end orientation) and a recommended SKU or vendor. If Sixfab plans to offer this cable, add the Sixfab SKU here.]

Only the Raspberry Pi 5 and the official Raspberry Pi CM5 IO Board are supported and tested. Custom carrier boards built around the Raspberry Pi 5 SoM or the CM5 module are not validated by Sixfab. AI HAT+ does not connect through the 40-pin GPIO header; it relies on the PCIe FFC link, the HAT+ EEPROM ID interface, and the PCIe power-enable and reset signals on the host side. A custom carrier that exposes a compliant PCIe FFC connector, the matching 3.3 V rail, and the PCIe reset signal may work in principle, but Sixfab does not certify or troubleshoot that path. For OEM and embedded integration on a custom carrier, contact Sixfab to discuss engineering services. See the Pinout & GPIO page for the FFC pinout your carrier would need to match.

Same PCB, different NPU silicon. The DX-M1M variant runs at 25 TOPS at INT8 precision with 1 GB of NPU memory; the DX-M1ML variant runs at 13 TOPS at INT8 precision with 512 MB. The NPU is soldered to the board at manufacture, so the variant is fixed per SKU. The driver, dxrt-runtime, and DXNN SDK are identical for both. See the Hardware Reference for the full variant specifications.

Different NPU silicon and different SDKs: the products are not interchangeable. Sixfab AI HAT+ uses DEEPX DX-M1M / DX-M1ML and the DXNN SDK; the Raspberry Pi AI HAT+ uses Hailo-8L and the HailoRT SDK. Models compiled for one platform will not run on the other.

Choose based on SDK preference, available model zoo, and your compilation pipeline. See the Sixfab AI HAT+ overview for what ships with the product.

Yes, the two boards are compatible when stacked. The Base HAT communicates over USB and AI HAT+ communicates over PCIe, so there is no data-bus conflict. Both boards carry HAT+ EEPROMs on the I²C ID bus (BCM 0 / BCM 1), which is the expected stacked-HAT+ behavior. Extra-long pass-through stacking headers are required to seat the boards physically. See the Pinout & GPIO page for the full pin map and reserved-pin table.

Partially compatible: the case lid will not close. AI HAT+ fits the Raspberry Pi 5 footprint, but the HAT+ board and NPU package are too tall for the standard enclosure lid. The official Raspberry Pi Active Cooler is fully compatible, and AI HAT+ is designed to seat above it on the included M2.5 standoffs. For closed enclosures, use a third-party HAT+ case sized for stacked HAT+ accessories. See the Hardware Reference for mechanical dimensions and standoff height.

Not supported. AI HAT+ is designed and tested exclusively for the Raspberry Pi 5 (and Raspberry Pi Compute Module 5 via the official Raspberry Pi CM5 IO Board). The DEEPX runtime targets x86_64 and ARM Linux, so a third-party SBC with a matching FFC connector may work in principle, but Sixfab does not validate or support that path. See the Sixfab AI HAT+ overview for the canonical supported-platform statement.

Yes. Capture frames from a Raspberry Pi Camera Module using libcamera (C++) or Picamera2 (Python), then pass the NumPy array into the dxrt-runtime inference pipeline. AI HAT+ does not interpose on the camera path; your application code orchestrates capture and inference. See the Quickstart for an end-to-end example.

Any standard USB webcam works. The camera connects to the Raspberry Pi 5, not to AI HAT+; the NPU only sees preprocessed frames from your application code. USB webcams, Raspberry Pi Camera Modules (via libcamera or Picamera2), local video files, and RTSP streams from IP cameras are all valid frame sources. See the Quickstart for a working capture-and-inference example.

No: one AI HAT+ per Pi 5. The Raspberry Pi 5 exposes a single PCIe FFC connector, which AI HAT+ occupies. To scale beyond a single NPU, deploy multiple Pi 5 + AI HAT+ units and coordinate them from an edge orchestrator on your local network. See the Sixfab AI HAT+ overview for fleet-deployment guidance.

Yes. AI HAT+ ships configured for PCIe Gen 3 x1, and the Raspberry Pi 5 negotiates the link at Gen 3 automatically at boot. No edit to /boot/firmware/config.txt and no raspi-config step is required on current shipments; the HAT+ EEPROM and the bundled boot configuration apply the Gen 3 setting on first power-on. Verify the link speed with dxrt-cli -s after installing dxrt-runtime; the report should show PCIe : Gen3 X1. See the Quickstart for verification commands.

Approximately one 4K stream at real-time frame rates, or up to four 1080p (1920×1080) streams at 25–30 FPS in parallel, on the DX-M1M variant. In multi-stream pipelines the Raspberry Pi 5 CPU usually saturates before the NPU does, because frame capture and preprocessing are CPU-bound. Profile with dxtop during multi-stream inference to see whether the NPU or CPU is the bottleneck. See the System Monitoring page for profiling commands.

Yes: use the RunAsync API in dxrt-runtime. The NPU schedules concurrent inference requests across both models. Practical limits depend on the combined model size fitting in NPU memory (1 GB on DX-M1M, 512 MB on DX-M1ML) and on the CPU's ability to feed frames at the requested rate. See the DXNN SDK: Deployment Workflow page for concurrent-inference patterns.

The hardware is ready immediately: the NPU appears in lspci output as soon as you power on the Pi 5 with AI HAT+ mounted. To run AI models you need to install dxrt-runtime from APT, which provides the kernel driver, the user-space runtime, and the dxrt-cli tool. See the Quickstart for the install procedure.

Yes. OpenCV, NumPy, Pillow, scikit-image, Picamera2, and libcamera all coexist with dxrt-runtime with no conflicts. Both Python and C++ APIs are supported; C++ is the more latency-optimized path for production pipelines. See the Quickstart for a Python integration example.

Yes: run the container in privileged mode with the NPU device node passed through. The kernel driver lives on the host, and the container needs access to /dev/deepx0:

docker run --privileged --device /dev/deepx0 my-app:latest

See the Quickstart for runtime-on-host requirements.

It depends on the file format. ONNX files fall back to CPU inference automatically; this works but runs significantly slower than NPU execution and provides no acceleration benefit. Any non-ONNX, non-DXNN format triggers a load error and the model is rejected. Compile to .dxnn with DX-COM before deployment to use the NPU. See the DXNN SDK: Deployment Workflow page for the ONNX → DXNN compilation workflow.

Yes, after a one-time compilation step. Download the ONNX file, compile it with DX-COM on an Ubuntu workstation, and deploy the resulting .dxnn file to the Raspberry Pi via SCP; no retraining needed. Check the DEEPX supported-operator list before compiling, since models with unsupported layers may error or fall back partially to CPU. See the DXNN SDK: Deployment Workflow page for the full conversion path, and the Sixfab Model Zoo for pre-compiled models that skip this step entirely.

The Raspberry Pi 5 detects under-voltage and degrades in stages. First, a yellow lightning-bolt indicator appears on the desktop. Next the CPU throttles its clock to lower current draw. As load climbs, the NPU may throttle or time out mid-inference, and at extreme transients the system reboots. Use the official Raspberry Pi 27 W USB-C PD Supply (5 V / 5 A) for any AI HAT+ deployment. See the Troubleshooting page for under-voltage diagnostics.

Not without an enclosure. AI HAT+ is a commercial-grade PCB intended for indoor use. Outdoor deployment requires a sealed enclosure rated IP54 or higher to handle moisture, an active cooling path inside the enclosure (the NPU can reach 85 °C under sustained load even at 25 °C ambient), and a thermal design that dissipates the system's full power draw without breaking the IP seal. See the Hardware Reference page for thermal envelope and operating-range specifications.

The DEEPX silicon supports vision models today; LLMs are on the DEEPX roadmap and Sixfab will support them as the silicon enables. The following workloads are not supported on current AI HAT+ shipments:

• Large language models and text generation
• Audio-only models (speech recognition, acoustic classification)
• Transformer-based language models (BERT, GPT, T5 variants)
• On-device model training or fine-tuning (AI HAT+ runs inference only)

For training-then-deploy workflows, use the ONNX → DXNN compiler on an Ubuntu workstation, or follow the Sixfab × Ultralytics acceleration path. See the DXNN SDK: Deployment Workflow page for both routes.

If the NPU supports your model architecture, the migration is a four-step path: export your trained model to ONNX from your training framework, compile the ONNX with DX-COM on an Ubuntu workstation, copy the resulting .dxnn file to the Raspberry Pi via SCP, and refactor the inference call to use the dxrt-runtime Python or C++ API. Preprocessing and postprocessing code typically does not change. See the DXNN SDK: Deployment Workflow page for end-to-end conversion examples and the Sixfab × Ultralytics acceleration path.

Yes: fully on-device after install. The initial dxrt-runtime install requires internet access to fetch APT packages. After that, AI HAT+ runs entirely offline at inference time: no telemetry, no cloud calls, no data leaves the device. This makes it suitable for privacy-sensitive deployments such as facial recognition, medical imaging, and restricted-area monitoring where data must stay on the local network. Internet is needed again only when you want to update the runtime or NPU firmware. See the Sixfab AI HAT+ overview for the on-device privacy posture.

Copy the new compiled model file over a secure channel and restart the inference service. SCP, rsync over SSH, and SFTP all work; the .dxnn file is just a binary artifact:

# 1. Copy the new model to the device
scp new_model_v2.dxnn <user>@<device_ip>:~/models/

# 2. Restart the inference service
sudo systemctl restart <your_inference>.service

For production fleets, wrap this into your existing OTA pipeline. See the System Monitoring page for telemetry hooks that confirm a model swap succeeded.

Driver and firmware downgrades are technically possible but not recommended. Sixfab and DEEPX validate the latest stable version pair, and older combinations are not regression-tested against current shipments. If a specific version triggered a regression, report it on the DEEPX runtime GitHub repository or the Sixfab community forum so the next stable release can fix it. See the Troubleshooting page for diagnosis steps before considering a downgrade.

APT delivers everything in one channel. The kernel driver, dxrt-runtime, the dxrt-cli tool, and DXNN SDK Python and C++ bindings all ship from the official Raspberry Pi APT repositories as a single package set. Run a standard apt update && apt upgrade on the Pi 5 to pull the latest stable release; APT replaces the previous versions in place and the kernel module reloads automatically. NPU firmware on the DEEPX module is a separate, manual flash and only when the runtime asks for it; see the firmware question below.

For production fleets, pin the runtime to a known-good version and stage upgrades through a single canary device first; the next two questions cover the runtime upgrade command and the firmware flash. See the Quickstart for the full upgrade procedure, version-pinning guidance, and APT repository setup.

Use APT: the runtime ships from the official Raspberry Pi APT repositories. Run the upgrade command on the Pi 5; APT replaces the previous version in place and keeps a rollback copy in /var/cache/apt/archives/. The kernel driver is part of the same package, so a runtime update also refreshes the driver. Restart any inference service (or reboot) so processes pick up the new shared libraries; the device node and PCIe link are not affected. See the Quickstart for the full upgrade procedure and version-pinning guidance.

# 1. Refresh the APT index and upgrade dxrt-runtime
sudo apt update && sudo apt install dxrt-runtime

# 2. Verify the installed version
dxrt-cli -s

Use dxrt-cli -u fw.bin after downloading the firmware image from the DEEPX website. Firmware updates are rarely required: only run this when the runtime reports a firmware-version mismatch, or when DEEPX publishes a firmware that is required by a newer dxrt-runtime release. Firmware update is a manual operation; there is no over-the-air firmware flow by default, and the device must be SSH-accessible during the flash. Verify the running firmware version with dxrt-cli -s before and after. See the Troubleshooting page for symptom-to-fix mapping when a runtime update reports a firmware mismatch.

# 1. Check the current firmware version
dxrt-cli -s   # FW version : vX.Y.Z

# 2. Flash the firmware (fw.bin downloaded from deepx.ai)
dxrt-cli -u fw.bin

# 3. Confirm the new version is active
dxrt-cli -s

In most cases, yes: Sixfab follows a backward-compatible runtime policy. If a dxrt-runtime release does not introduce breaking changes, existing compiled .dxnn files keep working without recompilation. When a release does break the model ABI, the runtime returns an explicit version-mismatch error at load time rather than failing silently; that is the signal to recompile the source ONNX with the matching DX-COM compiler version. Pin dxrt-runtime to a known-good version on production fleets and stage upgrades through a single canary device first. See the Troubleshooting page for the version-mismatch error pattern and recovery steps, and the DXNN SDK: Deployment Workflow page for the recompilation workflow.

Buy direct from the Sixfab shop at sixfab.com. Two SKUs are listed at the published MSRP:

The Raspberry Pi 5, the 27 W USB-C PD power supply, and the official Raspberry Pi Active Cooler are sold separately and required for a full bring-up; see the Overview page Recommended bring-up kit section. For volume pricing, OEM and ODM engagements, custom variants, or distributor inquiries, contact Sixfab. See the Sixfab AI HAT+ overview for the SKU comparison and what is included in each box.