Nel post precedente abbiamo raccontato il porting della demo webcam UVC ufficiale dalla EVAL alla Nucleo STM32N6: era il banco prova minimo per verificare che ISP, encoder H.264 hardware e DMA del silicon funzionassero davvero insieme, su un trasporto facile come USB. Qui teniamo la stessa pipeline imaging ma cambiamo il trasporto, perché il caso d’uso lo richiede: Wi-Fi 6 a 5 GHz, untethered, per 30 minuti consecutivi.
Il caso d’uso, in quattro numeri
Stiamo costruendo un sistema embedded per un’applicazione clinica di acquisizione dinamica, in cui contano eventi rapidi e ripetitivi nel corso di una sessione di esame. Il dominio specifico non è oggetto di questo post, ma i requisiti di sistema sì:
- 640×480 a 250 fps (risoluzione bassa, framerate alto — il contrario di una webcam)
- Sessione di acquisizione continua di circa 30 minuti
- H.264 hardware come codec
- Wi-Fi 6 a 5 GHz come trasporto
Niente USB nello stream principale. Una porta USB c’è, ma è di servizio: ricarica della batteria e debug. In produzione, durante l’esame, il dispositivo è untethered.
La risoluzione bassa e il framerate alto vanno letti insieme: in applicazioni cliniche di questo tipo non serve definizione spaziale per analisi statiche, serve risoluzione temporale per catturare la dinamica di un evento. È esattamente il caso opposto di una webcam consumer, che ottimizza per risoluzione e accetta 30 fps.
Cosa cambia a 250 fps rispetto a 100 fps
Sul silicon, di per sé, non cambia molto: l’encoder H.264 hardware dello STM32N6 regge il framerate senza forzare. Avevamo già verificato 720p a 100 fps nel porting UVC con buon margine; scendere a VGA e salire a 250 fps mantiene il throughput totale gestibile dall’encoder.
La conseguenza interessante è dove finisce il carico effettivo. Il throughput grezzo di 640×480 a 250 fps a 8 bit di colore è circa 610 Mbit/s prima della compressione. L’encoder H.264 lo abbatte di un fattore tipico fra 100 e 200 — dipendendo dalla scena, dalle impostazioni di GOP e dal target bitrate. Per la nostra applicazione ci stabilizziamo intorno a 3-5 Mbit/s in uscita, sostanzialmente lo stesso ordine di grandezza del post precedente nonostante il framerate sia 2,5×: il fattore di compressione è migliore perché frame consecutivi a 250 fps sono temporalmente molto correlati, e H.264 sfrutta bene questa correlazione con il prediction inter-frame.
Numericamente, il problema è quindi gestibile. Ma “gestibile in cifra media” e “gestibile sostenuto per 30 minuti su Wi-Fi” sono due cose diverse.
Dove si sposta il problema
Il punto critico si sposta altrove: la stabilità del canale Wi-Fi sotto carico costante, e su questo il datasheet del modulo radio dice poco — bisogna misurarlo sul banco.
Wi-Fi 6 a 5 GHz è la scelta giusta per due ragioni concrete. La banda da 5 GHz è meno congestionata della 2,4 GHz in ambiente clinico, dove proliferano dispositivi medicali e di rete sulla 2,4. Il MAC layer di Wi-Fi 6 — OFDMA per la condivisione del canale, TWT per il risparmio energetico — gestisce meglio traffico costante a basso jitter rispetto al best-effort di Wi-Fi 5.
Sul margine di bitrate dimensionare il link al doppio del bitrate medio in uscita non è esagerato. 3-5 Mbit/s medi richiedono almeno 10 Mbit/s di banda allocata in modo stabile, e Wi-Fi non garantisce banda: la negozia frame per frame, e il throughput effettivo dipende dalle condizioni del canale.
Sotto fading, in un ambiente clinico il dispositivo si muove — è indossabile o portatile — e il segnale Wi-Fi varia. 30 minuti senza dropout richiedono un buffer di sicurezza dimensionato sulle perdite tipiche della radio prima del recovery. Più il buffer è grande, più la latenza glass-to-display sale.
Sotto questi vincoli emerge un trade-off classico: un buffer grande assorbe le perdite ma ritarda la visualizzazione; un buffer piccolo è reattivo ma cede sotto fading. Per il nostro caso, la latenza tollerabile è dell’ordine di alcune centinaia di millisecondi — non serve real-time stretto, ma serve continuità totale.
L’USB sarebbe la strada più facile: throughput garantito, niente fading, jitter trascurabile. Ma il cavo è il vero vincolo dell’applicazione, non un dettaglio. Se l’esame dura 30 minuti e il paziente si muove, il cavo è incompatibile col caso d’uso prima ancora di essere incompatibile con i numeri.
Stato e cosa resta da capire
La parte imaging+encoder è ereditata dal porting UVC e regge. Il lavoro corrente è sul trasporto: caratterizzare il modulo Wi-Fi sotto carico continuo, dimensionare il buffer, misurare il degrado in scenari di mobilità tipici di una sessione clinica. Non ci aspettiamo sorprese sull’encoder o sul silicon: in questa fase i grattacapi vengono dalla coda della pipeline, non dalla testa.
I vincoli che hanno deciso il progetto
Il limite reale dell’imaging high-speed embedded non è quasi mai dove il datasheet dice di guardare. Su STM32N6 l’encoder regge 250 fps senza sforzo; quello che chiede attenzione è la finestra temporale del trasporto e il comportamento del Wi-Fi sotto carico costante per la durata di un esame clinico. Il datasheet ti dice il throughput di picco; l’esperienza ti dice quanto puoi mantenere quel throughput.
Quando il silicon è dimensionato bene, smetti di lottare contro l’MCU e cominci a lottare contro la fisica del canale. È un buon segnale.
Questo è un progetto interno; non c’è ancora un repository pubblico associato. Se lavori su imaging clinico high-speed, wireless biomedicale, o casi d’uso con vincoli temporali stretti, parliamone.