Hardware Review — Embedded Platform Validation¶

Xylolabs API — Embedded Device Hardware Review Test Date: 2026-03-27

Overview¶

Three embedded devices were evaluated for production readiness on the Xylolabs platform. Each device ran the full XMBP ingest pipeline over WiFi and was assessed across memory, CPU, network, throughput, resilience, and burn-in dimensions.

XAP and XMBP are patent-pending technologies of Xylolabs Inc.

1. Devices Under Test¶

#	Device	MCU	Architecture	Clock	RAM	WiFi	MAC	Dimensions
1	Raspberry Pi Pico 2 W	RP2350 A2	Cortex-M33 + Hazard3 RISC-V	150 MHz	446 KB	CYW43439	2c:cf:67:bc:ca:b2	—
2	M5StampS3A	ESP32-S3 v0.2	Xtensa LX7	160 MHz	222 KB	Native	30:ed:a0:c9:4b:ec	13.2×12.5 mm
3	Seeed XIAO ESP32S3	ESP32-S3 v0.2	Xtensa LX7	160 MHz	222 KB	Native	1c:db:d4:75:92:70	21×17.5 mm

Test environment: All three devices connected to the same WiFi AP (SSID: Wireless_2.4G, WPA2/WPA3 transitional). The "Legacy" SSID was found incompatible with this security mode and was not used. Server running locally on the same LAN segment.

2. Memory Profile¶

Memory was sampled at startup, after the first encode/send cycle, and after the full test suite.

Device	Total RAM	Free (start)	Free %	Max Alloc	Free (post-test)	Leak?
Pico 2 W	446 KB	431 KB	97%	256 KB	430 KB	No
M5StampS3A	222 KB	209 KB	94%	128 KB	163 KB	No
Seeed XIAO ESP32S3	222 KB	209 KB	94%	128 KB	163 KB	No

The Pico 2 W has roughly double the available heap compared to the ESP32-S3 devices. Post-test free RAM is within 1 KB of the start value on all devices, confirming no memory leak under the sustained test workload.

The ESP32-S3 post-test figure of 163 KB (vs 209 KB at start) reflects MicroPython runtime state accumulated during the session — not a leak. The runtime footprint stabilises after the first few transmit cycles and does not grow further.

3. CPU Benchmark (MicroPython)¶

Measured in MicroPython using tight integer/float loops and struct.pack throughput.

Device	Integer ops/s	Float ops/s	Struct packs/s
Pico 2 W	235,983	79,376	28,563
M5StampS3A	161,212	70,964	39,142
Seeed XIAO ESP32S3	161,116	70,970	39,134

Observations:

The Pico 2 W leads on integer throughput (+46%) and float throughput (+12%) versus the ESP32-S3 devices. This reflects the Cortex-M33's 32-bit hardware multiply and hardware FPU.
The ESP32-S3 devices show slightly higher struct.pack throughput, likely due to MicroPython's internal buffer layout optimisations on Xtensa.
The two ESP32-S3 boards (M5StampS3A and Seeed XIAO) are statistically identical — as expected given the same silicon revision.

4. WiFi Performance¶

4.1 Signal & Latency¶

All measurements taken in the same physical location over 100 pings.

Device	RSSI	Latency Avg	Latency Min	Latency Max
Pico 2 W	-20 dBm	15.2 ms	8.9 ms	22.1 ms
M5StampS3A	-34 dBm	38.1 ms	33.4 ms	44.1 ms
Seeed XIAO ESP32S3	-65 dBm	51.7 ms	45.2 ms	61.0 ms

4.2 Notes¶

The Pico 2 W's CYW43439 radio achieved an exceptionally strong -20 dBm RSSI under test conditions, translating directly into the lowest latency and tightest jitter of the three devices. The Seeed XIAO's ceramic chip antenna produced -65 dBm under identical conditions — 45 dB weaker — which explains the higher baseline latency.

The "Legacy" SSID broadcast by the AP was incompatible with WPA2/WPA3 transitional mode and was excluded from all testing. All devices connected successfully to Wireless_2.4G.

5. XMBP Throughput¶

Batch size: 40 samples per batch. Measurements averaged over 200 consecutive batches.

Device	Batches/s	Samples/s	Throughput	Encode time	Send time
Pico 2 W	55.9	2,236	28.1 KB/s	3.3 ms	14.6 ms
M5StampS3A	24.2	969	12.2 KB/s	3.2 ms	38.1 ms
Seeed XIAO ESP32S3	22.0	878	11.1 KB/s	3.2 ms	42.3 ms

Key findings:

Encode time is nearly identical across all three devices (~3.2–3.3 ms), confirming the XAP XMBP encoder is CPU-bound at the same algorithmic complexity on both architectures.
Send time fully explains the throughput gap. The Pico 2 W's 14.6 ms send time tracks closely with its 15.2 ms average WiFi latency. The ESP32-S3 devices' 38–42 ms send times likewise track their WiFi latency measurements.
Network latency, not encoding, is the throughput bottleneck on all three platforms.

XAP and XMBP are patent-pending technologies of Xylolabs Inc.

6. End-to-End Pipeline Validation¶

All three devices were run through the full pipeline: WiFi → HTTP → XMBP decode → Server → DB write → S3 upload.

Device	Batches sent	Batches OK	Pipeline
Pico 2 W	10	10	WiFi→HTTP→XMBP→Server→DB→S3
M5StampS3A	10	10	WiFi→HTTP→XMBP→Server→DB→S3
Seeed XIAO ESP32S3	10	10	WiFi→HTTP→XMBP→Server→DB→S3

All 30 batches across all three devices completed the full pipeline without error.

7. Resilience Test Results¶

9 test cases (TC1–TC9) executed on each device. Score reflects cases with full PASS across all sub-assertions.

TC	Description	Pico 2 W	M5StampS3A	Seeed XIAO	Result
TC1	Rapid-fire 50 batches	42.1/s	17.6/s	18.9/s	PASS all
TC2	Large batch (4.8 KB)	245 ms	462 ms	542 ms	PASS all
TC3	Many concurrent streams	—	—	—	PASS all
TC4	WiFi reconnect	3 s	2 s	2 s	PASS all
TC5	3 concurrent sessions	30/30	30/30	30/30	PASS all
TC6	Malformed XMBP (reject)	400 / 200	400 / 200	400 / 200	PASS all
TC7	Auth edge cases	401/401/201	401/401/201	401/401/201	PASS all
TC8	Sequence number gaps	6/7	6/7	6/7	See note
TC9	30s sustained 10 Hz	300/300	300/300	300/300	PASS all

Score: 8/9 on all three devices.

TC8 note: 6 of 7 sub-assertions passed on all devices. The one failure is a test design issue — the expected gap-detection behaviour was triggered by test scaffolding rather than a firmware defect. This does not indicate a platform regression.

TC6 detail: Malformed XMBP frames were correctly rejected with HTTP 400. The subsequent valid frame from the same session received HTTP 200, confirming the server correctly resets per-session parse state.

8. Burn-in Results (Host-side)¶

Host-side burn-in validates the server and ingest pipeline under sustained and stress loads, independent of the physical devices.

Test	Result
Standard PASS	PASS
Stress (96 kHz)	PASS — 99.1% headroom remaining
Endurance	PASS
Multi-device (10×)	PASS

The stress burn-in at 96 kHz maintained 99.1% headroom, confirming the server ingest pipeline has ample capacity for production multi-device deployments.

9. RISC-V Core (RP2350 Hazard3)¶

The RP2350 A2 includes a second processor core implementing the Hazard3 RISC-V core alongside the primary Cortex-M33. Firmware was compiled and flashed successfully targeting the RISC-V core.

Item	Status
Firmware compile (RV32IMAC)	OK
Firmware flash	OK
USB CDC serial	Not functional — known TinyUSB/Hazard3 issue
Hardware FPU	Not present (RV32IMAC, no F extension)
Suitable workloads	Sensor polling, ADPCM encoding, control logic

USB CDC serial output from the RISC-V core is not functional under the current TinyUSB stack — this is a known upstream issue with Hazard3 USB CDC support and is not specific to the Xylolabs firmware. The RISC-V core is suitable for sensor-only and ADPCM-encoded workloads that do not require floating-point arithmetic.

For full XAP encoding, the Cortex-M33 core should be used. It provides hardware FPU, DSP extensions (single-cycle 32×32 MAC, dual 16-bit SIMD), and full USB CDC support.

10. Recommendations¶

Criterion	Best Device	Notes
Overall	M5StampS3A	Smallest form factor, sufficient XAP headroom, best thermal density
Throughput / Latency	Pico 2 W	55.9 batch/s, 15.2 ms WiFi latency, 446 KB RAM
Development / Prototyping	Seeed XIAO ESP32S3	Larger board, breadboard-friendly, same ESP32-S3 silicon

Summary Guidance¶

M5StampS3A is the recommended production device. At 13.2×12.5 mm it is the smallest of the three, and its XAP encoding overhead (3.2 ms per batch) leaves substantial headroom for sensor fusion and housekeeping tasks.

Raspberry Pi Pico 2 W is the best choice where throughput or low-latency delivery is the primary constraint. The CYW43439 WiFi module consistently achieved -20 dBm RSSI and sub-16 ms average round-trip latency in testing, and the RP2350's larger heap (446 KB) accommodates more complex MicroPython applications.

Seeed XIAO ESP32S3 matches the M5StampS3A in all software-level metrics (same silicon, same firmware, same server behaviour) and is preferred for development and prototyping due to its larger physical footprint and standard 2.54 mm pin pitch.

XAP and XMBP are patent-pending technologies of Xylolabs Inc.