# Imaging high-speed clinico a 250 fps: il problema si sposta dal silicon al canale > Acquisire 250 frame al secondo a VGA su un MCU embedded e mandarli wireless per 30 minuti consecutivi. Il bottleneck non è dove il datasheet dice di guardare. Pubblicato: 2026-03-31 Categoria: hardware Tag: stm32, stm32n6, imaging, high-speed, wifi, wireless, h264, medical, embedded Pagina: --- Nel [post precedente](/blog/stm32n6-uvc-h264-nucleo-port/) 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](/contatti/).