In the previous post we walked through porting the official UVC webcam demo from EVAL to the STM32N6 Nucleo: it was the minimum bench needed to verify that the silicon’s ISP, hardware H.264 encoder and DMA really work together, over an easy transport like USB. Here we keep the same imaging pipeline but change the transport, because the use case demands it: Wi-Fi 6 at 5 GHz, untethered, for 30 minutes straight.
The use case, in four numbers
We’re building an embedded system for a clinical acquisition application where fast, repetitive events matter over the course of an examination session. The specific domain is not the subject of this post, but the system requirements are:
- 640×480 at 250 fps (low resolution, high frame rate — the opposite of a webcam)
- Continuous acquisition session of about 30 minutes
- Hardware H.264 as codec
- Wi-Fi 6 at 5 GHz as transport
No USB in the main stream. There is a USB port, but it’s for service: battery charging and debug. In production, during the examination, the device is untethered.
Low resolution and high frame rate go together: in clinical applications of this kind you don’t need spatial definition for static analysis, you need temporal resolution to capture the dynamics of an event. It’s exactly the opposite case of a consumer webcam, which optimises for resolution and accepts 30 fps.
What changes at 250 fps versus 100 fps
On the silicon itself, not much changes: the STM32N6’s hardware H.264 encoder handles the frame rate without strain. We had already verified 720p at 100 fps in the UVC porting work with good margin; dropping to VGA and pushing to 250 fps keeps the total throughput well within the encoder’s reach.
The interesting consequence is where the actual load ends up. The raw throughput of 640×480 at 250 fps with 8-bit color is around 610 Mbit/s before compression. The H.264 encoder cuts this by a typical factor of 100 to 200 — depending on scene, GOP settings and target bitrate. For our application we settle around 3–5 Mbit/s on output, essentially the same order of magnitude as the previous post despite the 2.5× higher frame rate: the compression ratio is better because consecutive frames at 250 fps are temporally very correlated, and H.264 exploits that correlation well with inter-frame prediction.
Numerically, the problem is therefore manageable. But “manageable on average” and “manageable sustained for 30 minutes over Wi-Fi” are two different things.
Where the problem moves
The critical point moves elsewhere: the stability of the Wi-Fi channel under constant load, and on this the radio module’s datasheet says little — you have to measure it on the bench.
Wi-Fi 6 at 5 GHz is the right choice for two concrete reasons. The 5 GHz band is less congested than 2.4 GHz in a clinical environment, where medical and network devices proliferate on 2.4. The Wi-Fi 6 MAC layer — OFDMA for channel sharing, TWT for power saving — handles sustained traffic with low jitter better than the best-effort behaviour of Wi-Fi 5.
On the bitrate margin, sizing the link at twice the average output bitrate is not excessive. An average of 3–5 Mbit/s requires at least 10 Mbit/s of stably allocated bandwidth, and Wi-Fi doesn’t guarantee bandwidth: it negotiates frame by frame, and effective throughput depends on channel conditions.
Under fading, in a clinical environment the device moves — it’s wearable or portable — and the Wi-Fi signal varies. 30 minutes without dropouts requires a safety buffer sized on the radio’s typical losses before recovery. The bigger the buffer, the higher the glass-to-display latency.
Under these constraints a classic trade-off emerges: a large buffer absorbs losses but delays display; a small buffer is responsive but caves under fading. For our case, the tolerable latency is on the order of a few hundred milliseconds — we don’t need strict real-time, but we need total continuity.
USB would be the easier road: guaranteed throughput, no fading, negligible jitter. But the cable is the real constraint of the application, not a detail. If the examination lasts 30 minutes and the patient moves, the cable is incompatible with the use case before it’s incompatible with the numbers.
State and what remains to be understood
The imaging+encoder part is inherited from the UVC porting and holds up. The current work is on the transport: characterising the Wi-Fi module under continuous load, sizing the buffer, measuring degradation in mobility scenarios typical of a clinical session. We don’t expect surprises on the encoder or the silicon: at this stage the headaches come from the tail of the pipeline, not the head.
The constraints that decided the design
The real limit of high-speed embedded imaging is almost never where the datasheet tells you to look. On STM32N6 the encoder handles 250 fps without strain; what demands attention is the temporal window of the transport and the behaviour of Wi-Fi under constant load for the duration of a clinical examination. The datasheet tells you peak throughput; experience tells you how much of that throughput you can actually sustain.
When the silicon is sized right, you stop fighting the MCU and start fighting the physics of the channel. That’s a good sign.
This is an internal project; there’s no associated public repository yet. If you work on high-speed clinical imaging, biomedical wireless, or use cases with tight temporal constraints, let’s talk.