Same DEEPX silicon family, different form factor and different surrounding subsystems. The Sixfab AI HAT+ is a top-mounted HAT+ specification compliant board that carries the DEEPX DX-M1M (25 TOPS at INT8) or DX-M1ML (13 TOPS at INT8) NPU only — soldered to the PCB and selected at purchase as one of two SKUs. The Edge AI Expansion Board is a bottom-mounted baseboard that carries the DEEPX DX-M1 M.2 AI Module on a swappable M.2 slot and adds an NVMe SSD slot plus an LTE/5G modem slot alongside the NPU, all three accessible at the same time. The DXNN SDK, dxrt-runtime, and compiled .dxnn models work across both products: generally, migration between AI HAT+ and the Edge AI Expansion Board can be done with the same commands without issues. See the Edge AI Expansion Board overview for the full product positioning.

Same baseboard, same mounting kit, same accessories — the difference is whether the DEEPX DX-M1 M.2 AI Module is included in the box. Variant 1 (Board only) ships the Edge AI Expansion Board, the USB 3.0 Bridge, the 40 mm PCIe FFC, and the full M2.5 / M2 mounting kit. The DEEPX DX-M1 M.2 AI Module is not included; this variant is for customers who already have the module, want to source it on a separate purchase order, or need to standardise a single board SKU across deployments. Variant 2 (Board + DEEPX DX-M1 module) ships the same kit plus the DEEPX DX-M1 M.2 AI Module pre-bundled, for a single-SKU path from box to first inference. The driver, dxrt-runtime, and DXNN SDK are identical for both. See the Overview for the full variant breakdown.

Yes, fully on-device after install. The initial sixfab-dx install requires internet to fetch APT packages. After that, the Edge AI Expansion Board runs entirely offline at inference time: everything stays on-device, with no outbound data flow unless your application explicitly adds it. 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. By default, no application is shipped pre-installed to monitor traffic; for verification, tools such as tcpdump can be used to inspect whether data is going out. Internet is needed again only when you want to update the runtime or NPU firmware. See the Overview for the on-device privacy posture.

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 Edge AI Expansion Board 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 (the Edge AI Expansion Board 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 Custom Models (DXNN SDK) page for both routes.

By default, yes, but verification is your responsibility once a cellular modem is installed. No application is shipped pre-installed to monitor or block outbound traffic. The AI inference stack itself does not phone home, and the LTE/5G modem will not transmit unless your user application initiates a connection. For deployments that require traffic verification, tools such as tcpdump can be used to inspect outbound traffic; this requires intermediate-level network knowledge. See the Cellular Connectivity page for traffic-control patterns.

The end labelled RPI5 goes to the Raspberry Pi 5; the end labelled EDGE_AI goes to the Expansion Board. The cable is a 40 mm FFC. The metal pin contacts must face inward (toward the respective circuit boards) and the labels must face outward (visible to you) at both ends. Using a different or longer cable is not recommended. PCIe FFC orientation is the most common assembly mistake; if lspci returns nothing after install, this is the first thing to check.

27 W USB-C PD minimum; 45 W recommended for full-stack configurations. The board accepts USB-C PD profiles of 5 V / 5 A, 9 V / 3 A, or 12 V / 2.25 A. Connecting a supply below 27 W results in reduced system performance and triggers a visual under-voltage warning on the Raspberry Pi 5. The 45 W envelope is recommended when AI, NVMe, and LTE/5G are all populated, since the cellular modem and NVMe SSD are both power-heavy. The board's total budget across all three M.2 slots, pogo pins, and the USB hub is bounded by the connected PSU; there is no on-board buck or boost. See the Quickstart for the recommended bring-up kit.

Through two 5 V pogo pins and two GND pogo pins on the underside of the Pi 5 GPIO header. No GPIO data pins are used. The pogo pins are rated for 3 A each (standard 2.54 mm pitch header rating), and the back-power scheme is compatible with the supported Raspberry Pi 5 variants (4 GB and 8 GB). Because no GPIO data pins are consumed, a standard top-mounted HAT can still be installed on the Pi 5 GPIO header while the Expansion Board sits underneath. See the Pinout & GPIO page for the pogo-pin map.

Yes, standard HATs are supported. The Edge AI Expansion Board sits under the Pi 5 and uses only pogo pins for back-power, so it does not consume any Raspberry Pi 5 GPIO data pins. The GPIO header is forwarded upward and a standard HAT can be installed on top of the Pi 5 as normal. If your top-mounted HAT requires additional external power, consult Sixfab before assembly. Anything designed for Pi 4 / Pi 5 that connects via the GPIO header or USB ports and draws power from the Pi is supported without issues. See the Pinout & GPIO page for the GPIO forwarding diagram.

Yes, the Edge AI Expansion Board is 100% compatible with the official Raspberry Pi Active Cooler. The Active Cooler installs on the Pi 5 as usual and runs from the Pi 5's own JST-SH fan header. The Expansion Board has no dedicated fan connector of its own; the design is intended to work in harmony with the Pi 5's existing cooling infrastructure. Active cooling is strongly recommended: the Pi 5 sits on top of the Expansion Board and can throttle under sustained AI load without it.

No. The Edge AI Expansion Board requires the Raspberry Pi 5 to be fully powered off before mounting, removing, or changing any M.2 module. The PCIe FFC, pogo pins, and M.2 slots are not designed for live insertion or removal. Always shut down the Pi 5 from the OS, disconnect the USB-C PD supply, then make the change. If the USB-C power cable is accidentally unplugged during operation, no physical damage occurs to the board, but unsaved data is lost and file-system errors may occur on the NVMe SSD.

Generally not: off-the-shelf Pi 5 cases are not compatible. The Expansion Board sits under the Pi 5 with 15 mm M2.5 spacers as base standoffs and the assembled stack measures roughly 36 mm in Z height. Standard Pi 5 enclosures are designed for the Pi 5 footprint alone and do not accommodate an under-mounted baseboard with three populated M.2 slots. For closed-enclosure deployments, plan a custom enclosure sized for the full stack including the protruding USB-C connector and the assembled spacer height. See the Specifications page for mechanical dimensions.

Raspberry Pi OS Bookworm and Trixie (64-bit) are the officially supported environments. ARM-based Debian Bookworm or Trixie can be made to work if pushed, but Raspberry Pi OS is the recommended path. The model-compilation toolchain (DX-COM) runs on a separate x86_64 workstation (not on the Pi itself) and supports Ubuntu 20.04 / 22.04 / 24.04 as the primary environments, plus Fedora 42–45, Red Hat Enterprise Linux 9–10, and CentOS Stream 9–10 validated as of DX-COM v2.3.0. See the Custom Models (DXNN SDK) page for the host-machine requirements.

Three settings go at the end of /boot/firmware/config.txt before installing the Sixfab APT package. PCIe is not enabled by default on Raspberry Pi OS, and Gen 3 is opt-in:

# Enable the PCIe x1 lane (default: disabled)
dtparam=pciex1

# Force PCIe Gen 3 for the AI accelerator (default: Gen 2)
dtparam=pciex1_gen=3

# Allow the full USB-C PD current; required by the Expansion Board
usb_max_current_enable=1

Reboot, then install sixfab-dx from the Sixfab APT repository. See the Quickstart for the full first-boot procedure.

Install sixfab-dx from the Sixfab APT repository. The package handles the driver build via DKMS, installs the user-space dxrt-runtime, and pulls in all required dependencies automatically. After installation, verify the NPU with dxrt-cli -s and the device node with ls /dev/dxrt0:

# 1. Fetch and install the Sixfab APT repo definition
wget https://github.com/sixfab/sixfab_dx/releases/download/v0.1/apt-repo-sixfab.deb
sudo dpkg -i apt-repo-sixfab.deb

# 2. Install the driver, runtime, and dependencies
sudo apt update && sudo apt install sixfab-dx

# 3. Verify the NPU is detected
dxrt-cli -s

See the Quickstart page for the full install flow including verification commands for the NVMe and cellular subsystems.

Yes. OpenCV, NumPy, Pillow, scikit-image, Picamera2, and libcamera all coexist with dxrt-runtime with no conflicts. Both Python (dx_engine) and C++ (dxrt API) interfaces are supported; C++ is the more latency-optimized path for production pipelines. The dxrt-api provides direct connection to the NPU. See the Custom Models (DXNN SDK) page for both API patterns.

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/dxrt0:

docker run --privileged -v /dev/dxrt0:/dev/dxrt0 my-app:latest

See the Quickstart page for runtime-on-host requirements.

Yes, after a one-time compilation step. Download the ONNX file, compile it with DX-COM on an x86_64 Ubuntu workstation, and deploy the resulting .dxnn file to the Raspberry Pi via SCP; no retraining needed. If the model has a layer the NPU cannot accelerate, the runtime falls back to CPU for that layer if it is executable by ONNX, but FPS will drop significantly. Check the DEEPX supported-operator list before compiling. See the Custom Models (DXNN SDK) page for the full conversion path, and the Sixfab Model Zoo for pre-compiled models that skip this step entirely.

Runtime via APT, firmware via dxrt-cli -u. The runtime ships through the Sixfab APT repository: sudo apt update && sudo apt install sixfab-dx replaces the previous version in place, and the kernel driver is part of the same package, so a runtime update also refreshes the driver via DKMS. Firmware updates are rarely required; only run them when the runtime reports a version mismatch:

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

# 2. Clone the firmware image (one-time)
git clone https://github.com/DEEPX-AI/dx_fw

# 3. Flash the firmware
dxrt-cli -u dx_fw/m1/2.5.6/mdot2/fw.bin

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

Existing compiled .dxnn models generally continue to work after a runtime update. When a release introduces a breaking ABI change, 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. See the Troubleshooting page for the version-mismatch recovery flow.

Roughly four 720p streams before the Raspberry Pi 5 CPU becomes the bottleneck. After four streams, the frame rate begins to drop, but the drop is caused by CPU saturation on frame capture and preprocessing, not by the NPU itself. Profile with dxtop during multi-stream inference to confirm which subsystem is the limiter. For higher concurrency, reduce per-stream resolution, use C++ rather than Python for the preprocessing path, or offload frame capture to a hardware accelerator. See the System Monitoring page for profiling commands.

Yes, up to 3 concurrent models tested. The NPU schedules concurrent inference across multiple models. Up to three models running in parallel have been verified without issue; more than three has not been tested. Practical limits depend on the combined model size fitting in NPU memory and on the CPU's ability to feed frames at the requested rate. See the Custom Models (DXNN SDK) page for concurrent-inference patterns.

No, there is virtually no degradation in AI inference performance. The AI accelerator sits on a dedicated PCIe Gen 2 / Gen 3 x1 link via the 40 mm FFC, while the NVMe SSD and LTE/5G modem share a separate internal USB 3.2 Gen 1 (5 Gbps) hub through the USB Bridge PCBA. Because the two data paths are independent at the hardware level, AI throughput does not measurably drop when both the SSD and the cellular modem are active. The triple-subsystem story is the reason this board exists: it is designed to do all three concurrently. See the Overview for the data-path diagram.

380–440 MB/s sequential read; 350–410 MB/s sequential write. The NVMe slot is USB-attached through the internal USB 3.2 Gen 1 (5 Gbps) hub and a Realtek RTL9210B-CG USB-to-NVMe bridge, so throughput is capped at the 5 Gbps USB bus minus 8b/10b encoding overhead and protocol management. The OS sees the SSD as a USB Mass Storage device (typically /dev/sda), not as a native PCIe NVMe device. For workloads that need native NVMe throughput, the Edge AI Expansion Board's storage path is not the right tool; its design priority is concurrent operation with the cellular modem on the same USB hub. See the NVMe Storage page for the validated SSD list and partition setup.

Reduced system performance and a visual under-voltage warning. The Raspberry Pi 5 detects under-voltage and degrades in stages: a yellow lightning-bolt indicator appears, the CPU throttles, and at extreme transients the NPU may throttle or time out mid-inference. The board's total budget is bounded by the connected PSU, so undersized supplies cascade across every subsystem. Use the official Raspberry Pi 27 W USB-C PD supply as the minimum; 45 W is recommended when AI, NVMe, and cellular are all populated. See the Troubleshooting page for under-voltage diagnostics.

The Expansion Board carries three M.2 slots, each silkscreened with a slot label. Modules are not interchangeable across slots:

All three slots use the same insertion procedure: 30° insertion angle, seat the gold contacts, press flat, secure with an M2 × 6 mm flat-head screw, finger-tight only. See the Quickstart for the assembly walkthrough.

Yes, both run in parallel without issue. The NVMe slot and the LTE/5G modem slot are both managed by the same internal USB 3.2 Gen 1 hub, but the hub splits Raspberry Pi 5's USB 3.0 bandwidth at the hardware level, so the two paths are functionally independent. The total USB bus ceiling is 5 Gbps, shared across both devices; sustained NVMe at 380–440 MB/s plus typical LTE/5G data rates fit comfortably under that ceiling. AI inference on the dedicated PCIe lane is not affected. See the Overview for the data-path diagram.

No, bring your own antenna. The Expansion Board has no built-in antennas. It provides the mechanical infrastructure to connect external antennas via the M.2 modem module's own RF connectors. The antenna connector type (typically U.FL or a similar SMC variant) and the number of antenna ports (main, diversity, GNSS) depend on the modem module installed in the M.2 Key-B slot. [NEED FROM SIXFAB: tested modem list with confirmed antenna connector types]. See the Cellular Connectivity page for the current cellular module compatibility status.

One nano SIM slot; eUICC nano SIMs are supported; no onboard eSIM chip. The Expansion Board carries a single physical nano SIM slot as the primary connectivity option. There is no onboard eSIM chip integrated directly into the board's PCB, but users can run an eUICC nano SIM card in the physical slot to switch between operator profiles in software. See the Cellular Connectivity page for SIM and eUICC setup.

Yes, but it is technically a USB Boot. Because the NVMe slot routes through the internal USB hub via the Realtek bridge, the OS sees the SSD as a USB Mass Storage device, not as a native PCIe NVMe device. To boot from it, update the Pi 5 bootloader (EEPROM) configuration to enable USB Boot at the appropriate priority. The SSD then becomes the boot device the same way an external USB SSD would. See the NVMe Storage page for the bootloader update steps and validated boot configuration.

Yes, three of the four Pi 5 USB ports remain free for peripherals. The USB Bridge PCBA occupies one of the two blue USB 3.0 ports on the Pi 5 to connect the on-board hub. That leaves one USB 3.0 port and both USB 2.0 ports available for keyboard, mouse, USB camera, or other peripherals. Two caveats:

• Bandwidth. All Pi 5 USB ports share the 5 Gbps bandwidth of the RP1 chip. Adding another high-speed drive forces the on-board NVMe, cellular modem, and that drive to share the 5 Gbps ceiling.
• Power. Total current across all Pi 5 USB ports is capped at 1.6 A. The cellular modem and NVMe SSD are both power-heavy, so adding another high-draw device (such as an external HDD) may cause system instability.

For peripherals that draw < 500 mA (keyboards, mice, low-power webcams) there is no measurable impact.

Raspberry Pi 5 (4 GB or 8 GB) and Raspberry Pi Compute Module 5 via the official Raspberry Pi CM5 IO Board. The Edge AI Expansion Board's mechanical layout, pogo-pin back-power scheme, and 40 mm PCIe FFC cable are designed to work with the Pi 5 board and with CM5 mounted on the CM5 IO Board. The 2 GB Pi 5 SKU is not supported; 4 GB is the minimum so the system has enough headroom for the AI inference stack alongside the OS. See the Overview for the canonical compatibility statement.

All current Raspberry Pi camera modules are tested and supported. The camera connects to the Pi 5 CSI port, not to the Expansion Board, so the NPU only sees preprocessed frames passed from your application code. Validated cameras include:

• Camera Module 2 (IMX219, 8 MP): the standard module
• Camera Module 3 (IMX708, 12 MP): with powered autofocus
• High Quality Camera (IMX477, 12.3 MP): interchangeable C/CS-mount lenses
• Global Shutter Camera (IMX296): high-speed motion capture

USB webcams, local video files, and RTSP streams from IP cameras are also valid frame sources. See the Quickstart for an end-to-end capture-and-inference example.

No, one Expansion Board per Pi 5. The Raspberry Pi 5 exposes a single PCIe FFC connector, which the Edge AI Expansion Board occupies. The pogo-pin back-power scheme and the under-board mechanical footprint also assume a single baseboard. Using multiple Expansion Boards across multiple Pi 5 units in the same deployment is fine; stacking them on a single Pi 5 is not supported. To scale beyond a single NPU on one Pi 5, deploy multiple Pi 5 + Expansion Board units and coordinate them from an edge orchestrator on your local network.

Not without an enclosure. The Edge AI Expansion Board is a commercial-grade PCB intended for indoor use. Outdoor or industrial deployments require a sealed enclosure rated IP54 or higher to handle moisture and dust, an active cooling path inside the enclosure (the NPU can throttle around 90 °C under sustained load), and a thermal design that dissipates the system's full power draw without breaking the IP seal. The customer should monitor and control the level of cooling required for their application; for many applications passive cooling is sufficient at 25 °C ambient, but under stress conditions or in higher ambient temperatures, this must be measured and managed by the deployer. For fully-rated industrial AI workloads, see the ALPON X5 AI product line, which ships fanless, IP-rated, and 24/7 certified out of the box.

Yes, the same .dxnn models and dxrt commands work unchanged. Both products are built on the DEEPX DX-M1 series NPU and share the same DXNN SDK: the Edge AI Expansion Board carries the DEEPX DX-M1 M.2 AI Module on a swappable M.2 slot, while the AI HAT+ ships the DEEPX DX-M1M (25 TOPS at INT8) or DX-M1ML (13 TOPS at INT8) soldered to the board. Migration is generally a drop-in: compiled models, inference code (Python dx_engine or C++ dxrt API), and command-line tools (dxrt-cli, dxtop) carry over without modification. What changes is the surrounding environment: the Edge AI Expansion Board adds the NVMe and LTE/5G subsystems, the PCIe Gen 3 step requires a config.txt edit (unlike AI HAT+, which factory-applies Gen 3), and power is supplied through USB-C PD rather than the Pi 5's own USB-C input. See the Quickstart page for the bring-up steps unique to this product.

Yes, the watchdog lives on the Raspberry Pi 5 itself, not on the Expansion Board. If the Pi 5 freezes or crashes, the Pi 5's built-in hardware watchdog can automatically restart the system once configured in config.txt and enabled at the systemd level. The Expansion Board has no independent watchdog of its own and no physical power button. Initiate clean shutdowns from the Raspberry Pi 5 software, and rely on the Pi 5's watchdog for unattended recovery from soft hangs.