# Uno strumento interno finito nella documentazione ufficiale > Avevamo scritto una GUI Python per caratterizzare un sensore CMOS difficile. Mesi dopo, una mail tecnica ad Arducam ha cambiato la natura del tool open source. Pubblicato: 2026-04-14 Categoria: software Tag: open-source, python, arducam, tooling, imaging Pagina: --- Stavamo lavorando su una valutazione di sensori per imaging medicale, e ci serviva caratterizzare un nuovo sensore CMOS bianco-nero ad alta velocità. Il kit di valutazione Arducam era la strada più rapida per metterlo sul banco, ma dopo i primi giorni di lavoro è diventato chiaro che gli strumenti software di serie non bastavano: andavano bene per dire "il sensore funziona", non per capirlo davvero. ## Il problema, in due righe La GUI demo dell'SDK era basilare per design — apri il device, mostra un'immagine, salva. Per noi serviva altro. La parte difficile dell'imaging non è vedere se arriva un frame, è iterare sui registri del sensore: circa un centinaio, ognuno con vincoli reciproci che scopri leggendo il datasheet e poi verificando sul banco. Esposizione, gain analogico, gain digitale, finestratura, modalità di sincronizzazione. Quello che ci mancava davvero era la combinazione di tre cose: editor registri guidato dal datasheet (non un campo di testo crudo), preview live mentre tocchi i valori (non "modifica → riavvia → vedi"), profili JSON salvabili e ricaricabili per ogni sensore. L'iterazione che ci serviva era da minuti, non da decine di minuti. ## Cosa abbiamo costruito Una GUI desktop in Python con Tkinter. La scelta del linguaggio era pragmatica: rapidità di sviluppo prima di tutto, SDK Arducam già con bindings Python, Tkinter cross-platform sufficiente senza tirare in ballo un framework UI pesante. Per un tool interno da iterare giornalmente sul banco, era la combinazione giusta. L'architettura l'abbiamo aperta da subito, pensando a usi futuri: ogni sensore è descritto da un profilo JSON con la sua mappa registri, i gruppi funzionali, l'help in stile datasheet. Aggiungere un nuovo sensore significa rilasciare il file `.cfg` prodotto dal tooling Arducam in `configs/` e creare il profilo JSON corrispondente in `sensors/` partendo da `_template.json`. Nessuna modifica al codice Python: la GUI lo rileva al riavvio. Sopra a questo abbiamo costruito le funzioni che servivano davvero al lavoro di caratterizzazione: editor registri con barra strumenti per filtrare e raggruppare, vista per-byte alternabile a vista multi-byte combinata, help live dal profilo attivo. E un loop software di auto-esposizione con auto-gain opzionale — qualcosa che la GUI originale Arducam non aveva. L'abbiamo aggiunto perché ci serviva per separare il rumore del sensore dalle variazioni di illuminazione durante i test, ma l'abbiamo scritto generico, non legato al sensore che stavamo testando. ## Quando il tool diventa moneta di scambio A un certo punto il tool funzionava bene, copriva il nostro caso, e ci siamo trovati ad avere documentazione di un sensore specifico — mappa registri verificata sul banco, gruppi funzionali, vincoli operativi — che Arducam non aveva ancora condiviso pubblicamente per quel modello. Abbiamo scritto a un contatto tecnico Arducam via email diretta. Non era un cold pitch né una richiesta di endorsement: era un'offerta concreta. Avevamo dei profili JSON di sensore curati e verificati; loro avevano informazioni sui registri ufficiali che a noi mancavano. Una proposta di scambio fra ingegneri. La risposta è arrivata entusiasta in meno di due giorni. Hanno apprezzato il tool al punto di inserirlo nella loro documentazione ufficiale come strumento utile per chi lavora con i loro evaluation kit, e lo scambio si è concretizzato: ora abbiamo accesso a informazioni di configurazione più dettagliate dal loro lato, e loro hanno un tool open source curato a cui rimandare la propria community. Quello che li ha colpiti, dai messaggi che ci hanno scritto, non era una singola feature: era l'architettura aperta. Il fatto che il tool non fosse legato a un sensore specifico ma a un modello dati — i profili JSON — significava che era estensibile a tutti gli EVK del loro catalogo senza riscrivere codice. Un'altra persona poteva aggiungere il proprio sensore in mezz'ora. ## Il valore di un tool pubblico Il tool è nato per noi, su un caso specifico, con i vincoli di tempo veri di un progetto — non pensando ad Arducam. Quello che è successo dopo — la mail, la risposta entusiasta, l'inserimento nei docs ufficiali, lo scambio tecnico continuativo — è stato la conseguenza di una scelta fatta a monte: aprire l'architettura fin dall'inizio, anche quando ci sarebbe bastato hardcodare il sensore che stavamo testando. A volte la cosa più efficace che si possa fare per essere visti non è scrivere un post di marketing, ma rilasciare bene un tool che è davvero servito — e progettarlo in modo che possa servire anche ad altri. --- Il tool è open source, MIT-licensed, e vive su GitHub: [arducam-evk-gui](https://github.com/stefanofante/arducam-evk-gui). Per la documentazione tecnica completa c'è la [pagina wiki dedicata](/wiki/arducam-evk-gui/), e la [scheda del repository](/open-lab/arducam-evk-gui/) raccoglie i link. Il tool è citato nella documentazione ufficiale Arducam; aggiungeremo qui il link puntuale alla pagina. Lavori sulla caratterizzazione di sensori CMOS B&W ad alta velocità, o su un caso d'uso simile? [Parliamone](/contatti/).