Un sensore che misura il campo elettrico a radiofrequenza produce numeri in volt al metro, e quei numeri non dicono nulla finché non vengono letti accanto a una soglia. Per un misuratore personale che lavora nella banda 100 MHz – 3 GHz — le frequenze del WiFi, della telefonia mobile, dei dispositivi wireless — il software che scarica e interpreta i dati conta quanto la sensoristica: deve portare la misura dal dispositivo allo schermo senza driver dedicati e, soprattutto, deve metterla a confronto con i limiti normativi giusti.

Il problema del trasferimento dati

Un sensore portatile registra in memoria interna una serie temporale di campioni: per ciascuno, l’intensità del campo e un timestamp. Per analizzarli bisogna tirarli fuori. La via tradizionale è una porta seriale: il microcontrollore espone un’UART, un convertitore USB-seriale (tipicamente un integrato FTDI come l’FT232R) la presenta al sistema operativo come una COM virtuale, e un programma desktop apre la porta a 115200 baud e legge il flusso.

Il costo di questa via è l’installazione. Driver del convertitore, un eseguibile per ogni sistema operativo, aggiornamenti separati. Per un dispositivo pensato per essere usato da chiunque — non da un tecnico di laboratorio — ogni passaggio di installazione è un punto in cui l’utente si ferma.

Una porta seriale dentro Chrome

Le Chrome App introducono un’alternativa. A differenza di una pagina web, un’app impacchettata Chrome può accedere all’hardware locale, e fra le API disponibili c’è chrome.serial: l’accesso diretto a una porta seriale dal codice JavaScript dell’app, senza un binario nativo intermedio.

Il flusso è essenziale. Si elencano le porte con chrome.serial.getDevices, si apre la connessione con chrome.serial.connect(path, {bitrate: 115200}, callback), e i byte in arrivo si ricevono registrando un listener su chrome.serial.onReceive, che consegna i dati come ArrayBuffer insieme al connectionId. La trasmissione verso il dispositivo passa per chrome.serial.send. Il convertitore FTDI resta lo stesso lato hardware, ma sul lato software sparisce la dipendenza da un eseguibile per piattaforma: l’app gira ovunque giri Chrome.

Da qui in poi è codice applicativo. Il flusso grezzo va parsato secondo il protocollo del firmware, ricostruito in una serie di campioni (timestamp, V/m), e gestito per il resto del ciclo di vita: archiviazione delle importazioni con i loro metadati, filtraggio per intervallo di date, disegno dei grafici. Una libreria come D3.js, o il wrapper C3.js costruito sopra, basta a tracciare l’andamento temporale del campo. Tutto questo funziona offline: scaricare e analizzare i dati del sensore non richiede rete, perché il sensore è l’unica sorgente che serve.

Il punto critico: V/m non è un numero, è una misura contestuale

Il lavoro difficile non è il grafico. È decidere cosa significa un valore. Un picco di 4 V/m è alto o basso? La domanda non ha risposta senza un riferimento, e il riferimento è normativo.

Sul piano internazionale i livelli di riferimento per l’esposizione della popolazione vengono dalle linee guida ICNIRP del 1998. Per il campo elettrico variano con la frequenza: nell’intervallo 10–400 MHz il livello di riferimento è 28 V/m, e sale a frequenze più alte (per esempio 61 V/m intorno a 2 GHz). In Italia la cornice è la legge quadro 36/2001, attuata per le radiofrequenze dal DPCM 8 luglio 2003, che fissa limiti di esposizione, valori di attenzione e obiettivi di qualità nella banda 100 kHz – 300 GHz. Il valore di attenzione per gli ambienti a permanenza prolungata, nel testo allora vigente, è 6 V/m per il campo elettrico.

C’è un secondo dettaglio che cambia il software. ICNIRP non confronta il valore istantaneo: prescrive la media su un intervallo di sei minuti per le frequenze fra 100 kHz e 10 GHz. Una serie temporale di campi RF, quindi, non si valuta campione per campione ma per finestre. Un’analisi di soglia onesta deve poter mediare sull’intervallo giusto, contare i superamenti su quella base, e distinguere un picco isolato da un’esposizione prolungata. Mostrare il massimo istantaneo accanto a una soglia di media è un errore di metodo, non di grafica.

Implicazioni progettuali

Ne discende che un misuratore personale è in buona parte un traduttore di unità verso significato. La parte che richiede attenzione non è il rendering del grafico ma la catena: protocollo del firmware corretto, conversione in V/m coerente con la calibrazione del sensore, media sulla finestra prescritta, confronto con la soglia normativa pertinente. Una declinazione applicativa di questa catena è il software eyEM Data Manager realizzato da noze per il sensore di Polab, descritto nella scheda di progetto: https://www.noze.it/progetti/polab-eyem/.

La scelta della Chrome App ha un effetto che va oltre la comodità. Eliminando il driver e l’eseguibile per piattaforma, sposta la complessità dall’installazione al codice JavaScript ispezionabile dell’app. Chi vuole verificare come un dato grezzo diventa un V/m sullo schermo legge quel codice, non un binario opaco. Per uno strumento di misura, dove la fiducia nel numero è il punto, la trasparenza della catena di elaborazione non è un dettaglio.

Limiti

Il quadro descritto riguarda il trasporto e l’interpretazione del dato, non la sua accuratezza fisica. Un misuratore personale non è uno strumento metrologico certificato: la calibrazione del sensore, la sua risposta in frequenza, l’isotropia dell’antenna e l’incertezza di misura restano fuori dal software e determinano quanto ci si possa fidare del numero a monte. Il confronto con il valore di attenzione, inoltre, è indicativo: una valutazione di conformità formale segue procedure di misura standardizzate che un dispositivo tascabile non riproduce. E la dipendenza dalle Chrome App lega lo strumento a una piattaforma il cui futuro non è nelle mani di chi lo costruisce. Il software rende la misura leggibile; non la rende un certificato.

Immagine di copertina: scheda del progetto POLAB eyEM (noze).