System Monitoring

Monitor the Edge AI Expansion Board on Raspberry Pi 5

Three subsystems on one board — NPU, NVMe storage, and LTE/5G cellular. This page is the canonical reference for every monitoring command, what each one reveals, and which subsystem to inspect when something misbehaves on the Sixfab Edge AI Expansion Board.

dxtop dxrt-cli lspci lsusb lsblk ifconfig DEEPX DX-M1M DEEPX DX-M1ML

Edge AI Expansion Board · Operations · Reference · System Monitoring · Updated 2026-05-14

How do I monitor the Sixfab Edge AI Expansion Board on Raspberry Pi 5?

Three subsystems, three monitoring entry points. For the DEEPX DX-M1 NPU, use dxtop for live per-core utilisation and temperature, and dxrt-cli -s for a full hardware snapshot. For the NVMe SSD (USB-attached via the internal hub), use lsblk and lsusb. For the LTE/5G modem (also USB-attached), use lsusb and ifconfig. The first quick-diagnostic pair when anything misbehaves is dxrt-cli -s followed by dxtop.

Three subsystems on one board

Unlike the AI HAT+, which monitors a single NPU subsystem, the Edge AI Expansion Board carries three independent subsystems that can all run simultaneously with no measurable degradation to AI inference throughput. Each subsystem has its own monitoring path. The card strip below maps each one to the commands you'll spend most of your time with.

PCIe Gen 3 x1

NPU (DEEPX DX-M1)

25 TOPS at INT8 (DX-M1M) or 13 TOPS at INT8 (DX-M1ML). Connects to the Raspberry Pi 5 over a dedicated 40 mm PCIe FFC.

dxtop dxrt-cli -s lspci

USB 3.2 Gen 1

NVMe SSD

Routed through the internal USB 3.0 hub and a Realtek RTL9210B-CG USB-to-NVMe bridge. The OS sees a USB Mass Storage device, not a native NVMe block device.

lsblk lsusb df -h

USB 3.2 Gen 1

LTE/5G modem

M.2 Key-B slot, also routed through the internal USB hub via the USB Bridge PCBA. Exposes /dev/ttyUSBx serial nodes and a network interface (commonly usb0, but device-dependent).

lsusb ifconfig ping -I <iface> 1.1.1.1

Running AI inference, writing inference results to the NVMe, and streaming output over LTE/5G at the same time is the intended workload on this product. There is virtually no degradation in AI inference performance when all three subsystems are active. Storage and cellular share the internal USB 3.2 Gen 1 (5 Gbps) hub, so combined storage + cellular throughput is bounded by that bus, but the PCIe path to the NPU is separate and unaffected.

Software stack overview

The DEEPX NPU runs as a four-layer software stack on Raspberry Pi 5. Each layer has its own monitoring command. When something goes wrong on the AI path, this map tells you which layer to inspect first.

Your application

Python (dx_engine) or C++ (dxrt API) code calling the DEEPX runtime, OpenCV, demos, or your own inference pipeline

Python / C++ journalctl

DEEPX Runtime (DX-RT)

Model loading, inference scheduling, memory management, async execution on the NPU

sixfab-dx dxtop / dxrt-cli

DEEPX kernel driver

Out-of-tree Linux kernel module (dx_dma) exposing the NPU as a PCIe device. Built via DKMS against the running kernel headers at install time.

sixfab-dx (DKMS) lsmod / dmesg

NPU hardware + firmware

DEEPX DX-M1M (25 TOPS at INT8) or DX-M1ML (13 TOPS at INT8) on the M.2 AI slot. Firmware on onboard flash, loaded by the driver at probe.

onboard flash lspci

The DEEPX runtime, the kernel driver (RT Driver and PCIe Driver), and the on-NPU firmware all carry independent version numbers. A drift between any two shows up later as silent CPU fallback, version-mismatch errors when loading .dxnn files, or unstable inference. Catching it in monitoring is much cheaper than catching it after deployment, which is why dxrt-cli -s prints all three version numbers in one snapshot.

Quick reference

Every command on this page mapped to a subsystem and a layer. The Subsystem column tells you which of the three on-board paths the command is talking to; the Layer column tells you where in the software stack you're inspecting.

Command	Subsystem	What it shows	When to use
`dxtop`	NPU · Runtime	Real-time NPU utilisation, temperature, voltage, clock per core, memory usage	During active inference to watch performance and thermal headroom
`dxrt-cli -s`	NPU · Runtime	Full hardware status: device, runtime version, RT and PCIe driver versions, firmware version, memory, PCIe link speed, per-core state	After installation, after any kernel update, or as the first command in any diagnostic flow
`lspci`	NPU · Hardware	PCIe device enumeration, confirms the DX-M1 is detected on the bus	First check if `dxrt-cli` reports no device
`lsmod \| grep -i dx`	NPU · Kernel	Whether the `dx_dma` kernel module is loaded	After a Raspberry Pi OS / kernel update, or if `dxrt-cli` fails to find a device
`dmesg \| grep -i dx`	NPU · Kernel	Kernel messages from the DEEPX driver during boot probe	Diagnosing driver init errors or PCIe link failures
`lsblk`	NVMe · OS	Block-device tree; the SSD appears as `/dev/sda` via the USB-to-NVMe bridge	Confirming the NVMe slot is recognised, checking partition layout
`lsusb`	NVMe + Cellular · Hardware	USB device enumeration on the internal hub — NVMe bridge, cellular modem, hub itself	Verifying the USB-attached subsystems are visible to the OS
`df -h`	NVMe · OS	Filesystem-level free/used capacity for mounted NVMe partitions	Capacity monitoring on long-running deployments that log to the SSD
`ifconfig`	Cellular · OS	Network interface list, including the modem's data interface (commonly `usb0`, but device-dependent)	Discovering the actual interface name on this device before `ping` tests
`journalctl`	Application · OS	systemd journal — application logs, service status	When the runtime starts but inference jobs or background services fail

Installed CLI tools

The sixfab-dx APT package installs three command-line tools alongside the kernel driver and DEEPX runtime. Each one targets a different monitoring or diagnostic job on the NPU. You do not need to install them separately.

dxrt-cli

Hardware status, version inventory, and NPU firmware update. The first command to run when diagnosing any NPU issue. Run dxrt-cli --help for the full subcommand list.

dxtop

Real-time NPU monitor — per-core utilisation, temperature, voltage, and clock. Effectively htop for the DEEPX silicon.

run_model

Headless model runner. Test any compiled .dxnn file without writing application code — useful for benchmarking or validating a freshly compiled model.

# 1. Full hardware and firmware status
dxrt-cli -s

# 2. Real-time NPU utilisation (press q to quit)
dxtop

# 3. Test a compiled model headless
run_model --model_path <model_path>.dxnn

# 4. Discover all dxrt-cli subcommands
dxrt-cli --help

dxtop and dxrt-cli are the only tools that surface NPU-internal telemetry — per-core utilisation, voltage, clock, and on-die temperature. Standard Linux tools (top, htop, sensors) cannot reach inside the DEEPX silicon. For NPU-aware monitoring in a production fleet, scrape dxrt-cli -s output on a schedule and ship it to your time-series store of choice.

NPU monitoring

The DEEPX DX-M1 NPU is the only PCIe-attached subsystem on the Expansion Board, and the only one with its own dedicated CLI tooling. The two commands you'll use 95 % of the time are dxrt-cli -s for snapshots and dxtop for live monitoring.

dxrt-cli -s Full hardware and firmware status report

Displays the runtime version, both kernel-side driver versions (RT Driver and PCIe Driver), the on-NPU firmware version, memory spec, board revision, PCIe link speed, and per-core voltage, clock, and temperature. This is the canonical first diagnostic command after installation or whenever anything looks off.

dxrt-cli -s

Expected output NPU healthy

DXRT v3.3.0
=======================================================
 * Device 0: M1, Accelerator type
---------------------   Version   ---------------------
 * RT Driver version   : v2.4.0
 * PCIe Driver version : v2.2.0
-------------------------------------------------------
 * FW version          : v2.5.6
--------------------- Device Info ---------------------
 * Memory : LPDDR5 5600 Mbps, 3.92GiB
 * Board  : M.2, Rev 1.0
 * Chip Offset : 0
 * PCIe   : Gen3 X1 [01:00:00]
NPU 0: voltage 750 mV, clock 1000 MHz, temperature 45'C
NPU 1: voltage 750 mV, clock 1000 MHz, temperature 45'C
NPU 2: voltage 750 mV, clock 1000 MHz, temperature 45'C
=======================================================

Output above reflects a DX-M1M on a Raspberry Pi 5 (8 GB) with the sixfab-dx APT package shipping DXRT v3.3.0, RT Driver v2.4.0, PCIe Driver v2.2.0, and on-NPU firmware v2.5.6. Actual version numbers on your system will move forward with package releases. The DX-M1ML reports the same shape with a different device variant.

dxrt-cli -u <fw.bin> Update on-NPU firmware

Flashes a firmware binary to the on-NPU flash. Only needed when a standalone firmware update is released between full runtime upgrades — most users will get firmware updates automatically as part of a sixfab-dx package upgrade. After flashing, re-run dxrt-cli -s to confirm the new firmware version.

dxrt-cli -u <firmware_path>.bin

# Confirm the new firmware version
dxrt-cli -s

dxtop: live NPU dashboard

dxtop is a live terminal dashboard for the NPU. It shows per-core utilisation, memory, voltage, clock speed, and temperature, updating continuously. Use it during active inference to watch real-time performance and thermal headroom, and as the second half of the standard diagnostic pair after dxrt-cli -s.

dxtop

Press q to quit, n / p to page through devices, h for help.

At idle

DX-RT: v3.3.0   NPU Device driver: v2.4.0   DX-TOP: v1.0.1

Device :0  Variant: M1  PCIe Bus Number: 01:00:00  Firmware: v2.5.6
NPU Memory: [3.98 MiB / 3.92 GiB (0.10%)]
  Core :0  Util:  0.0%  Temp: 45 °C  Voltage: 750 mV  Clock: 1000 MHz
  Core :1  Util:  0.0%  Temp: 45 °C  Voltage: 750 mV  Clock: 1000 MHz
  Core :2  Util:  0.0%  Temp: 45 °C  Voltage: 750 mV  Clock: 1000 MHz

During active inference

Device :0  Variant: M1  PCIe Bus Number: 01:00:00  Firmware: v2.5.6
NPU Memory: [1.20 GiB / 3.92 GiB (30.6%)]
  Core :0  Util: 87.0%  Temp: 58 °C  Voltage: 750 mV  Clock: 1000 MHz
  Core :1  Util: 92.0%  Temp: 59 °C  Voltage: 750 mV  Clock: 1000 MHz
  Core :2  Util: 89.0%  Temp: 58 °C  Voltage: 750 mV  Clock: 1000 MHz

Typical values at a glance

Idle temp

45–50 °C

Driver loaded, no model

Core voltage

750 mV

Idle and inference

Core clock

1000 MHz

Normal operating speed

PCIe link

Gen 3 X1

With pciex1_gen=3 set

Throttle threshold

~90 °C

DEEPX silicon limit

The DEEPX DX-M1 thermally throttles at approximately 90 °C. Sustained inference well below that ceiling is the operational goal, and dxtop is the canonical way to watch for it. If you see per-core temperatures climbing past 80 °C during your real workload, revisit cooling — the Raspberry Pi 5 active cooler runs from its own JST-SH header (the Expansion Board itself does not carry a fan connector), and enclosure airflow may also need attention. See the Thermal & power notes section below.

NVMe storage monitoring

The NVMe slot is wired through the on-board USB 3.0 hub and a Realtek RTL9210B-CG USB-to-NVMe bridge. The OS sees a USB Mass Storage device, not a native NVMe block device — which means lsblk and lsusb are the right tools, not nvme list.

lsblk Confirm the SSD is enumerated and mounted

The SSD appears as /dev/sda (or the next available USB block-device letter if other USB storage is plugged in). This is also why /etc/fstab entries should reference UUIDs, not device names — see the NVMe Storage page for full mount setup.

lsblk

Expected output NVMe detected

# lsblk (example with a 256 GB Raspberry Pi NVMe SSD)
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 238.5G  0 disk
mmcblk0     179:0    0  29.7G  0 disk
├─mmcblk0p1 179:1    0   512M  0 part /boot/firmware
└─mmcblk0p2 179:2    0  29.2G  0 part /

lsusb Confirm the USB-to-NVMe bridge is on the internal hub

The Realtek RTL9210B-CG USB-to-NVMe bridge enumerates on the on-board USB 3.2 Gen 1 hub. Its presence in lsusb tells you the bridge has powered up and is detected even before the SSD itself appears in lsblk.

Expected line in lsusb

Bus 002 Device 002: ID 0bda:9210 Realtek Semiconductor Corp. RTL9210 NVMe Bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Throughput envelope

Sequential read

380–440 MB/s

USB 3.2 Gen 1 ceiling

Sequential write

350–410 MB/s

USB 3.2 Gen 1 ceiling

Bus

5 Gbps

USB 3.2 Gen 1, 8b/10b encoding

Concurrent AI impact

~0%

No measurable inference degradation

Sequential read peaks at 380–440 MB/s and write at 350–410 MB/s, capped by the 5 Gbps USB bus and 8b/10b encoding overhead, not the SSD itself. A faster SSD will not raise these numbers. If your monitoring shows sustained throughput well below this band on a known-good SSD, investigate the USB-C bridge cable between the Expansion Board and the Pi 5, or check for under-voltage conditions during write bursts.

NVMe health and SMART data

Because the SSD is reached through a USB-to-NVMe bridge rather than the native NVMe block layer, some health-monitoring paths behave differently than they would on a directly-attached NVMe drive. The exact behaviour of smartctl over this bridge depends on the SSD's bridge-pass-through support and is still being documented.

[NEED FROM SIXFAB: confirmed smartctl / SMART pass-through behaviour over the RTL9210B-CG bridge, recommended health-monitoring command and expected output — QP51]

Cellular monitoring

The LTE/5G modem slot is M.2 Key-B and routes through the same internal USB 3.0 hub as the NVMe SSD, via the USB Bridge PCBA. The modem appears as a USB device in lsusb, exposes one or more /dev/ttyUSBx serial nodes, and provides a network interface whose name varies by modem module.

lsusb Confirm the modem is enumerated on the internal hub

The expected VID:PID depends on which M.2 modem you installed. The example below shows a Quectel RM520N-GL — your modem will show its own VID:PID pair.

Expected line in lsusb (Quectel RM520N-GL example)

Bus 002 Device 003: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. RM520N-GL
Bus 002 Device 002: ID 0bda:9210 Realtek Semiconductor Corp. RTL9210 NVMe Bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

[NEED FROM SIXFAB: complete tested-modem list with expected VID:PID for lsusb verification — QP39, QP49d]

ifconfig Discover the modem's network interface name

The cellular data interface is commonly named usb0, but the actual name is device-dependent and you should not assume it. Run ifconfig to list all interfaces and identify the modem's data interface before issuing any ping or routing tests.

ifconfig

# Then ping out the modem's actual interface (replace usb0 if needed)
ping -I usb0 1.1.1.1

Expected output Cellular online

# ping -I usb0 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 10.x.x.x usb0: 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=42.3 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=38.1 ms

Signal-quality metrics

Reading RSRP, RSRQ, SINR, and operator/band information requires sending AT commands to the modem's diagnostic serial port. The exact AT command set varies by modem family and is documented per-modem by its vendor; we will publish the recommended Sixfab signal-quality monitoring flow once the tested-modem list is finalised.

[NEED FROM SIXFAB: recommended signal-quality monitoring flow (RSRP / RSRQ / SINR / throughput) for the tested modem list — QP45]

This page covers monitoring once the modem is up. APN configuration, data-connection setup, AT-command flows, GPS/GNSS enablement, and failover are all documented on the Cellular Connectivity page.

System diagnostic commands

These standard Linux utilities complement the DEEPX-specific tools. Use them to verify hardware detection and kernel-level driver state when something higher up the stack isn't responding. The order below matches the recommended diagnostic flow: hardware (lspci / lsusb), kernel (lsmod / dmesg), then service-level (journalctl).

lspci Verify the NPU is detected on the PCIe bus

Confirms the Raspberry Pi 5 has enumerated the DX-M1 NPU over PCIe. If this line is missing, the hardware connection has a problem — first suspect is the 40 mm PCIe FFC between the Expansion Board and the Pi 5; next is whether the M.2 AI module itself is fully seated. Check dmesg for the matching driver probe output if lspci succeeds but the runtime still cannot find a device.

lspci

Expected line in output

00:00.0 PCI bridge: Broadcom Inc. BCM2712 x1 PCI Express Bridge (rev 21)
01:00.0 Processing accelerators: DEEPX Co., Ltd. DX-M1 AI Accelerator (rev 01)

If lspci shows no DEEPX device, the hardware is most likely not fully seated. Power off the Pi 5, reseat the 40 mm PCIe FFC at both ends (verify the cable label "RPi5" goes to the Pi side and "Edge AI" goes to the Expansion Board side, with Pin 1 alignment), reseat the M.2 AI module in its slot, and verify the standoffs are finger-tight so the pogo pins make contact. Then power back on and re-check.

lsmod | grep -i dx Confirm the DEEPX kernel driver is loaded

The dx_dma kernel module must be loaded for the runtime to communicate with the NPU. The sixfab-dx package builds and installs this module via DKMS, so it normally survives kernel updates automatically — but it is the first thing to check after a Raspberry Pi OS upgrade or any unexpected runtime failure.

lsmod | grep -i dx

Reinstall the package to rebuild the module against the new kernel: sudo apt install --reinstall sixfab-dx. The DKMS tooling will pick up the running kernel's headers (pulled in automatically by the package) and recompile dx_dma in place.

dmesg | grep -i dx View kernel messages from the DEEPX driver

Shows kernel ring buffer messages from driver initialisation. Look here for PCIe link errors, firmware load failures, or device enumeration issues. Use sudo dmesg if output is empty without elevated permissions on a restricted system.

dmesg | grep -i dx

Healthy boot output Probe done

[    2.102285] dx_dma: loading out-of-tree module taints kernel.
[    2.112716] dx_dma_pcie 0001:01:00.0: enabling device (0100 -> 0102)
[    2.112830] dx_dma_pcie 0001:01:00.0: dw->dx_ver: 3
[    2.182700] dx_dma_pcie 0001:01:00.0: [dx_dma_pcie_probe] Probe Done!!
[    2.799076] dxrt_driver_cdev_init: 1 devices

journalctl View systemd journal for runtime and application logs

The systemd journal is where application-level logs land. Use journalctl -xe to view recent errors, -f to follow a log live, and --since "10 minutes ago" to limit a noisy stream. For your own inference application running under systemd, filter by unit name.

# Recent errors across the journal
journalctl -xe

# Follow live
journalctl -f

# Limit to the last 10 minutes
journalctl --since "10 minutes ago"

# Filter by your inference systemd unit
journalctl -xeu <your_service>.service

Some dmesg and journalctl calls may require sudo on restricted systems. If you see empty output or a permission error, prefix the command with sudo.

Thermal & power notes

Two things to know up front before designing thermal or power dashboards for an Edge AI Expansion Board deployment.

NPU thermal throttle threshold

The DEEPX DX-M1 thermally throttles at approximately 90 °C. Production inference workloads should aim to keep all three cores well below that ceiling — comfortable headroom is core temperatures under 80 °C under sustained load. Active cooling on the Raspberry Pi 5 (the official Pi 5 Active Cooler driven from the Pi 5's own JST-SH fan header) handles most desktop and lab conditions; high-ambient or enclosed deployments need application-specific airflow planning.

Cooling on this product is handled by the Raspberry Pi 5's own active cooler, which plugs into the Pi 5's 4-pin JST-SH fan header (PWM control, electrically and functionally identical to a standard Pi 5 fan setup). The Expansion Board itself does not expose a separate fan connector. If you need additional cooling for the DX-M1 module or the modem, that is part of your enclosure design rather than something the Expansion Board provides directly. Customers are responsible for monitoring and controlling thermal behaviour for their specific ambient, enclosure, and workload conditions.

Power monitoring: no onboard sensors

The Expansion Board itself does not include any onboard power-monitoring circuitry. The single USB-C PD input powers the full stack and back-powers the Pi 5 through the pogo pins, but there is no instrumentation on the board that exposes real-time current or wattage to the OS. The practical consequences:

dxtop and dxrt-cli -s expose NPU-side telemetry (voltage, clock, temperature) but not whole-board power draw.
For full-stack power figures, use an inline USB-C PD power meter on the input cable, or a bench supply with current readout.
Under-voltage events on the Pi 5 still surface through the standard Raspberry Pi mechanisms (kernel warnings, vcgencmd get_throttled on the Pi), and are the most reliable signal that the USB-C PSU is undersized for your workload.

Minimum USB-C PD input is 27 W; 45 W is recommended for stacks running the DX-M1 plus NVMe plus an LTE/5G modem under sustained load. Under-voltage warnings on the Pi 5 almost always trace back to an undersized PSU or a cable that cannot carry the negotiated current — replace the PSU first before investigating software.

Long-running deployments

For production fleets, the recommended way to log inference results, NPU temperature, cellular signal strength, and system metrics together is to write to the NVMe SSD on a schedule that does not create a meaningful CPU bottleneck. The specific store is up to you — a time-series database, a flat-file logger, or a structured-event log all work. The constraint that matters is keeping the logger's CPU cost low enough that pre/post-processing around the NPU does not become the bottleneck.

A typical loop scrapes dxrt-cli -s output every N seconds and appends to an NVMe-mounted log path. Inference applications can write their own per-detection records to the same log, and cellular signal samples (once the QP45 flow is documented) can be added to the same stream. See the NVMe Storage page for mount setup and the Cellular Connectivity page for the modem side.

If something's wrong: the first-diagnostic pair

When the Edge AI Expansion Board is not behaving as expected, the two commands to run first, in this order, are:

# 1. Snapshot the NPU stack
dxrt-cli -s

# 2. Watch it live
dxtop

If dxrt-cli -s finds no device, drop one layer down with lspci and dmesg | grep -i dx to see whether the NPU enumerated on the PCIe bus and the driver probed successfully. For per-symptom diagnosis (NPU not detected, NVMe not mounting, modem not registering, under-voltage warnings), go to the Troubleshooting page.