Rete di sensori wireless a basso costo su banda 433 MHz: 5 passaggi (con immagini)

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:02

Molte grazie a Teresa Rajba per avermi gentilmente concesso di accettare di utilizzare i dati delle loro pubblicazioni in questo articolo

* Nell'immagine sopra - le cinque unità sensore-mittente che ho usato per i test

Cosa sono le reti di sensori wireless?

Una definizione semplice sarebbe: le reti di sensori wireless si riferiscono a un gruppo di dispositivi elettronici distribuiti su una determinata area per il monitoraggio e la registrazione di dati ambientali, che vengono trasmessi in modalità wireless a una posizione centrale per essere elaborati e archiviati.

Oggigiorno le reti di sensori wireless possono essere utilizzate in diversi modi, di seguito sono riportati solo alcuni esempi:

• Aree di sorveglianza ecologica di foreste, fiumi, laghi, mari e oceani;
• Possibilità di allertare in caso di attacchi terroristici, chimici, biologici, epidemici;
• Sistemi di monitoraggio per bambini, anziani, pazienti o persone con bisogni speciali;
• Sistemi di sorveglianza in agricoltura e serre;
• Sistema di monitoraggio delle previsioni del tempo;
• Sorveglianza del traffico cittadino, scuole, parcheggi;

E molte, molte altre applicazioni.

In questo articolo voglio mostrare i risultati di un esperimento con reti di sensori wireless che sono state utilizzate per monitorare i dati di temperatura e umidità, con una variazione lenta e relativamente prevedibile. Per questo esperimento ho scelto di utilizzare sensori-trasmettitori che ho costruito da solo utilizzando moduli convenienti. Anche il ricevitore è DIY, la comunicazione è unidirezionale (sulla banda radio 433 MHz), il che significa che i sensori trasmettono solo i dati e la postazione centrale solo riceve. Non c'è comunicazione tra i sensori e dal ricevitore ai sensori.

Ma perché scegliere di utilizzare più trasmettitori e un solo ricevitore? Ovviamente il primo motivo sarebbe “rendere le cose semplici”. Più semplice è l'assemblaggio, meno è probabile che si guasti, ed è sicuramente molto più facile riparare e sostituire i singoli componenti in caso di malfunzionamenti. Anche il consumo energetico è inferiore, le batterie dureranno più a lungo (i sensori consumeranno solo durante il monitoraggio e la ricezione, il resto del tempo il dispositivo sarà in modalità di sospensione profonda). Il fatto che sia semplice rende il dispositivo anche economico. Un altro aspetto da tenere a mente è l'area di copertura. Come mai? È molto più facile costruire e utilizzare un ricevitore sensibile che avere un ricevitore sensibile e un trasmettitore potente sia ai sensori che al modulo centrale (questo è necessario per una buona comunicazione bidirezionale). Con un ricevitore sensibile e di buona qualità è possibile ricevere dati da una lunga distanza, ma l'emissione di dati per la stessa distanza richiede un'elevata potenza di emissione e questo comporta costi elevati, consumi elettrici e (non dimentichiamo) la possibilità di superare il potenza di trasmissione massima legale sulla banda 433 MHz. Utilizzando un ricevitore di media qualità, economico ma con un'antenna di alta qualità (anche fai da te) e trasmettitori economici con un'antenna di buona qualità, possiamo ottenere ottimi risultati ad una frazione del costo delle reti di sensori wireless esistenti.

Fase 1: Considerazioni teoriche

L'idea di costruire una rete di sensori wireless per monitorare la temperatura e l'umidità dell'aria e del suolo in diverse aree di una serra mi è venuta in mente molto tempo fa, quasi 10 anni. Volevo costruire una rete a 1 filo e utilizzare sensori di temperatura e umidità a 1 filo. Sfortunatamente, 10 anni fa i sensori di umidità erano rari e costosi (anche se i sensori di temperatura erano molto diffusi) e dal momento che la diffusione di fili in tutta la serra non sembrava un'opzione, ho rinunciato all'idea abbastanza rapidamente.

Ora però la situazione è radicalmente cambiata. Siamo in grado di trovare sensori economici e di buona qualità (temperatura e umidità), e abbiamo anche accesso a trasmettitori e ricevitori economici sulla banda 433 MHz. C'è solo un problema: se abbiamo più sensori (diciamo 20) come risolviamo le collisioni (tieni presente che questa è una comunicazione unidirezionale), cioè sovrapponendo l'emissione di 2 o più sensori? Durante la ricerca di una possibile soluzione mi sono imbattuto in questi documenti molto interessanti:

Il sensore wireless converge cast basato sulla procedura di operazioni casuali - di RAJBA, T. e RAJBA, S.

e

La probabilità di collisioni in Wireless Sensor Network con invio casuale - di RAJBA S. e RAJBA. T

Fondamentalmente, gli autori ci mostrano che la probabilità di collisioni in una rete di sensori wireless può essere calcolata se i pacchetti vengono emessi in determinati punti temporali secondo una distribuzione poissoniana (esponenziale).

Un estratto del documento di cui sopra elenca le caratteristiche della rete studiata.

• un numero abbastanza elevato di unità sensore-emettitore N;
• le unità sensore-emettitore rimangono completamente indipendenti e l'accensione o lo spegnimento delle stesse non ha alcuna influenza sul funzionamento della rete;
• tutte le unità sensore-emettitore (o parte di esse) possono essere mobili purché si trovino all'interno della portata radio della stazione ricevente;
• i parametri fisici che cambiano lentamente sono soggetti a misurazioni, il che significa che non è necessario trasmettere i dati molto frequentemente (ad esempio ogni alcuni minuti o diverse decine di minuti);
• la trasmissione è di tipo unidirezionale, cioè dall'unità sensore-emettitore fino al punto di ricezione ad intervalli di tempo T medi. Le informazioni vengono trasmesse nel protocollo a t_P durata;
• qualsiasi sensore selezionato inizia a trasmettere in modo casuale agli orari di Poisson. PASTA (Poisson Arrivals See Time Averages) sarà utilizzato per giustificare l'invio di sonde in epoche di Poisson;
• tutte le unità sensore-trasmettitore rimangono casualmente indipendenti e trasmetteranno le informazioni in un momento di tempo selezionato casualmente di t_P durata e di T tempo medio di ripetizione;
• se uno o più sensori iniziano a trasmettere mentre il protocollo di t_P la durata viene trasmessa da un altro sensore, tale situazione è chiamata collisione. La collisione rende impossibile alla stazione base centrale di ricevere le informazioni in modo corretto.

Si adatta quasi perfettamente alla rete di sensori che voglio testare…

Quasi.

Non dico di aver compreso fino in fondo la matematica dell'elaborato, ma sulla base dei dati presentati e delle conclusioni ho potuto capire un po' di cosa si tratta. L'unica cosa è che un valore utilizzato nella carta mi ha un po' preoccupato:). è la variabile t_P - durata della trasmissione dati che si assume pari a 3,2x10^-5 S. Quindi il tempo di trasmissione dei dati raccolti sarebbe di 3,2 noi! Questo non può essere fatto sulla banda 433 MHz. Voglio usare l'interruttore RC o la testa radio per programmare i sensori del trasmettitore. Studiando i codici delle due librerie, sono giunto alla conclusione che il tempo di trasmissione minimo sarebbe di 20ms, ben al di sopra del valore di 3,2 us. Con i trasmettitori a 2,4 GHz è possibile t_P tempo così piccolo… ma questa è un'altra storia.

Se applichiamo la formula proposta dagli autori di questo lavoro il risultato sarà:

Dati iniziali (un esempio):

• Numero di sensori N=20;
• Durata trasmissione dati t_P=20x10^-3 s (0.020 s)
• Intervallo medio di trasmissione T=180s

La formula:

La probabilità di collisione sull'intervallo T è

se prendiamo in considerazione i dati iniziali la probabilità di collisione sull'intervallo T sarà 0,043519

Questo valore, che indica la probabilità di avere 4,35 collisioni per 100 misurazioni, è, a mio avviso, abbastanza buono. La probabilità potrebbe migliorare se aumentassimo il tempo medio di trasmissione, quindi a un valore di 300 s avremmo una probabilità di 0,026332, cioè 2,6 collisioni per 100 misurazioni. Se consideriamo che possiamo comunque aspettarci una perdita di dati a pacchetto durante il funzionamento del sistema (a seconda delle condizioni meteorologiche per esempio) allora questo numero è davvero eccellente.

Volevo fare una simulazione di questo tipo di rete ma anche una sorta di assistente di progettazione, quindi ho realizzato un piccolo programma in C, puoi trovare il codice sorgente su github (anche un binario compilato che è in esecuzione nella riga di comando di Windows - pubblicazione).

Dati in ingresso:

• sensor_number - il numero di sensori sulla rete;
• numero_misure - numero di misurazioni da simulare;
• intervallo_di_trasmissione_media -tempo medio tra successive trasmissioni di dati;
• tempo_trasmissione - la durata effettiva della trasmissione dei dati.

Produzione:

• il tempo massimo di misurazione calcolato;
• l'elenco delle collisioni tra due sensori;
• numero di collisioni;
• probabilità teorica delle collisioni.

I risultati sono piuttosto interessanti:)

Basta con la teoria, non vorrei insistere di più sulla parte teorica, gli articoli e il codice sorgente sono abbastanza eloquenti, quindi meglio passare all'implementazione pratica ed efficace della rete di sensori wireless e ai risultati dei test.

Passaggio 2: implementazione pratica - l'hardware

Per i trasmettitori-sensori avremo bisogno dei seguenti componenti:

• Microcontrollore ATtiny85 1,11 $;
• Presa per circuito integrato 8DIP 0,046 $;
• Sensore di temperatura/umidità DHT11 0,74 $;
• Modulo trasmettitore 433MHz H34A 0,73 $;
• Portabatterie 4xAA con interruttore 1$;

Totale 3,63 $;

Il ricevitore utilizzato per i test è un Arduino UNO (solo per test) e un modulo ricevente H3V4F (0,66 $) con un'antenna ad arco economica (0,32 $).

Schemi sensore-mittente

Le unità trasmettitore-sensore sono alimentate con 3 batterie AA da 1,5V (nel quarto vano del portabatterie è presente il gruppo elettronico). Come si vede l'alimentatore del trasmettitore e il sensore di temperatura-umidità sono agganciati al pin PB0 del microcontrollore (il trasmettitore e il sensore sono alimentati quando il pin è impostato su HIGH). Quindi, quando il microcontrollore è in modalità deep-sleep, può raggiungere un consumo di corrente di 4,7uA. Considerando che il tempo di attivazione del trasmettitore-sensore sarebbe di circa 3s (misurazione, trasmissione ecc.) e il tempo medio tra le trasmissioni di 180s (come nell'esempio nel capitolo precedente), le batterie dovrebbero resistere parecchio. Con alcune batterie alcaline di buona qualità (es. 2000 mAh), l'autonomia potrebbe essere superiore a 10 mesi come calcolato su omnicalculator.com (dove il consumo totale di corrente è: sensore - 1,5 mA, modulo trasmettitore - 3,5 mA e microcontrollore ATtiny85 - 5 mA, totale 10 mA).

Nella foto sotto potete vedere l'assieme sensore-trasmettitore quasi finito.

Di seguito è riportata la foto dell'unità ricevente di prova.

Passaggio 3: implementazione pratica - Software

Il software caricato in esecuzione sul microcontrollore attiny85, il componente principale delle unità sensore-trasmettitore, ha lo scopo di leggere i dati forniti dal sensore, convertirli per essere trasmessi via radio e trasmetterli entro i tempi di Poisson (distribuzione esponenziale o PASTA - Arrivi Poisson vedi medie temporali). Inoltre, tramite una semplice funzione, monitora lo stato delle batterie e segnala se non viene più fornita la tensione richiesta per il sensore. Il codice sorgente è disponibile su github. Il codice per il ricevitore di prova è molto semplice, lo inserisco di seguito.

//libreria rcswitch modificata da https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver// il codice è una versione modificata da esempi della libreria rcswitch originale #include RCSwitch mySwitch = RCSwitch(); dati lunghi senza segno = 0; void setup() { Serial.begin(9600); mySwitch.enableReceive(0); // Ricevitore su interrupt 0 => questo è il pin #2 } void loop() { if (mySwitch.available()) { unsigned long data = mySwitch.getReceivedValue(); //output(mySwitch.getReceivedValue(), mySwitch.getReceivedBitlength(), mySwitch.getReceivedDelay(), mySwitch.getReceivedRawdata(), mySwitch.getReceivedProtocol()); int umidità = bitExtracted(data, 7, 1); // 7 bit meno significativi dalla posizione 1 - primo bit più a destra int temperature = bitExtracted(data, 7, 8); // prossimi 7 bit dalla posizione 8 a destra e così via int v_min = bitExtracted(data, 1, 15); int id_pacchetto = bitExtracted(data, 3, 16); ///3bit - 8 id pacchetto da 0 a 7 int sensor_id = bitExtracted(data, 6, 19); //6bit per 64 ID sensore - 24 bit totali Serial.print(sensor_id);Serial.print(", ");Serial.print(packet_id);Serial.print(", ");Serial.print(temperatura); Serial.print(", ");Serial.print(umidità); Serial.println(); mySwitch.resetAvailable(); } } //codice da https://www.geeksforgeeks.org/extract-k-bits-given-position-number/ int bitExtracted(unsigned long number, int k, int p) { return (((1 (p - 1))); }

Ho cercato di includere quanti più commenti possibile per rendere le cose più facili da capire.

Per il debug ho usato la libreria softwareserial e la scheda di sviluppo attiny85 con il programmatore USBasp (vedi anche le mie istruzioni su questo). Il collegamento seriale è stato realizzato con convertitore Serial to TTL (con un chip PL2303) collegato ai pin piegati (3 e 4) della scheda di sviluppo (vedi immagine sotto). Tutto questo è stato di inestimabile aiuto per completare il codice.

Passaggio 4: risultati del test

Ho creato 5 unità sensore-mittente che raccolgono e inviano i valori misurati dai sensori DHT11. Ho registrato e salvato le misurazioni, con l'aiuto del ricevitore di prova e di un programma di emulazione terminale (foxterm), per tre giorni. Ho scelto un intervallo di 48 ore per lo studio. Non ero necessariamente interessato ai valori misurati (il sensore 2, ad esempio, mi mostra valori errati) ma al numero di collisioni. Inoltre, i sensori sono stati posizionati molto vicini (a 4-5 m) dal ricevitore per eliminare altre cause di perdita di pacchetti. I risultati del test sono stati salvati in un file cvs e caricati (guarda il file sotto). Ho anche caricato un file excel basato su questo file CSV. Ho preso alcuni screenshot per mostrarti come appare una collisione (nei miei test ovviamente), ho aggiunto anche commenti a ogni screenshot.

Potresti chiederti perché non ho usato un servizio di caricamento dati, ad esempio ThingSpeak. Il fatto è che ho molti record, molti sensori e dati che arrivano spesso a intervalli irregolari, e i servizi IoT online consentono dati solo a un certo numero di sensori e solo a intervalli abbastanza ampi. Sto pensando in futuro di installare e configurare il mio server IoT.

Alla fine, 4598 misurazioni su 5 unità sensore-emettitore (circa 920/sensore) hanno prodotto un totale di 5 collisioni per un periodo di 48 ore (0,5435 collisioni/100 misurazioni). Facendo un po' di calcoli (usando il programma wsn_test con i dati iniziali: 5 sensori, tempo medio 180s, tempo di trasmissione 110 ms) la probabilità di collisione sarebbe 0,015185 (1,52 collisioni/100 misurazioni). I risultati pratici sono anche migliori dei risultati teorici, non è vero?:)

Comunque ci sono anche 18 pacchetti persi in questo periodo, quindi le collisioni non contano molto in questo senso. Ovviamente il test dovrebbe svolgersi in un arco di tempo più lungo per ottenere i risultati più conclusivi ma secondo me è un successo anche in queste condizioni e conferma in pieno i presupposti teorici.

Passaggio 5: considerazioni finali

Applicazione immediata

In una grande serra vengono coltivate diverse colture. Se l'irrigazione viene effettuata manualmente senza monitoraggio del clima, senza alcuna automazione, senza registrazione dei dati c'è il rischio di sovra o sottoirrigazione e anche il consumo di acqua è elevato, non ci sono prove per l'ottimizzazione del consumo di acqua, c'è il rischio per le colture in generale. Per evitare ciò, possiamo utilizzare una rete di sensori wireless:)

Sensori di temperatura, sensori di umidità dell'aria, sensori di umidità del suolo possono essere posizionati tutt'intorno nella serra e con l'ausilio dei dati trasmessi si possono compiere diverse azioni: elettrovalvole start-stop per far defluire l'acqua dove serve, elettroventilatori start-stop per ridurre la temperatura in diverse aree, i riscaldatori start-stop secondo necessità e tutti i dati possono essere archiviati per analisi future. Inoltre, il sistema può fornire un'interfaccia web accessibile ovunque e allarmi via e-mail o SMS in caso di condizioni anomale.

Qual è il prossimo?

• Test con un numero maggiore di sensori;
• Test in tempo reale con sensori remoti nell'area di copertura;
• Installazione e configurazione di un server IoT locale (su un Raspberry Pi per esempio);
• Test anche con trasmettitori (ricetrasmettitori)-sensori su 2.4Ghz.

allora… continua…:)

ESCLUSIONE DI RESPONSABILITÀ: l'utilizzo della banda di frequenza 433 MHz nella propria regione potrebbe essere soggetto alle normative sulle frequenze radio. Si prega di verificare la propria legalità prima di provare questo progetto

Secondo classificato al concorso Sensori