Se vi è capitato di intraprendere ricerche su come il protocollo ZigBee può esservi di aiuto per una vostra applicazione, o avete sentito parlare dell’implementazione micropython combinata con i nuovi moduli XBee3, o ancora se siete curiosi di sapere come programmare i moduli XBee3, allora siete capitati nel posto giusto. In questo primo appuntamento vedremo insieme le novità rese disponibili con i nuovi moduli XBee3 ed inizieremo ad acquisire dimestichezza con XCTU, il tool offerto dalla DIGI per la programmazione ed il debug dei moduli XBee3.
In articoli precedenti sono state sviscerate in maniera dettagliata le specifiche del protocollo ZigBee, esaminando in maniera accurata tutte le caratteristiche che il protocollo prevede sia a livello fisico sia a livello applicativo, se avete bisogno di un ripasso potete dare un’occhiata qui. Oggi, però, faremo qualcosa di diverso, abbandoneremo la parte teorica immergendoci nella pratica. In un primo momento vedremo insieme quali sono le caratteristiche ed i vantaggi introdotti dai nuovi moduli XBee3, successivamente inizieremo subito con la parte pratica lavorando immediatamente con XCTU, grazie al quale realizzeremo il nostro primo sistema che sfrutta il protocollo ZigBee per lo scambio di dati tra un Coordinator ed un Router.
XBee3: specifiche
Prima di iniziare con la pratica, vediamo insieme alcune caratteristiche degli Xbee3. Effettuando una macro distinzione possiamo dividere questi nuovi device in due famiglie: la famiglia dei moduli RF e la famiglia dei moduli Cellular LTE. Precisiamo che in mercato sono diffusi anche moduli nominati XBee PRO, questi però non verranno presi in considerazione in quanto non rispettano le specifiche stabilite dalla ETSI (European Telecomunications Standard Istitute). Grazie alla famiglia dei moduli RF è possibile sfruttare i segnali radio per la trasmissione e la ricezione di dati attraverso una rete PAN (Personal Area Network) che, rispettando le specifiche del protocollo ZigBee, permette lo scambio di informazioni tra il Coordinator ed altri dispositivi periferici. In seguito, vedremo come creare una propria rete PAN configurando un Coordinator ed un Router, ancora un pò di pazienza. Le specifiche tecniche dei moduli RF prevedono una larghezza di banda di 2.4 GHz, un data rate di 250Kbps e ricoprono in ambienti indoor una distanza di circa 60 metri. Questa famiglia è acquistabile in 3 diversi fattori di forma: Micro-mount, Through-hole e Surface-mount, riportati in Figura 1.
La scelta di un fattore di forma rispetto ad un altro, risente principalmente dello spazio disponibile per la realizzazione della propria applicazione, risulta logico, quindi, che nel caso ci proiettiamo in un’ottica di progettazione di un sistema embedded, il formato Micro-mount sarà il preferito, ma se rimaniamo in un contesto di sperimentazione, il formato Through-hole potrebbe risultare più user friendly. Qualunque sia la vostra scelta, l’unica accortezza che dovrete tenere ricade sulla nominazione dei pin che risulta discorde tra i vari fattori di forma. Tra le principali caratteristiche rese disponibili si ha la possibilità di utilizzare interfaccia come UART, SPI, I2C; sono disponibili 4 canali ADC a 10 bit e sono presenti 15 GPIO digitali, insomma tutto ciò che serve per rendere questi moduli low-cost indipendenti con appositi firmware. Analizzando invece la seconda famiglia citata in precedenza, ovvero quella dei Cellular LTE, questa si candida come cavallo di battaglia della DIGI. Questo modulo, oltre ad essere provvisto di tutte le caratteristiche dei moduli RF, prevede anche la possibilità di una connessione LTE consentendo la creazione di applicazioni IoT che sfruttano servizi come AWS, messaggistica MQTT, scambio di SMS e gestione della connessione HTTP. Questi moduli risultano disponibili soltanto nel fattore di forma Through-hole, come visibile in Figura 2.
Con tutto ciò, il vero valore aggiunto offerto da questi nuovi moduli, sia RF che Cellular LTE, è sbocciato con l’integrazione di micropython, un’implementazione snella ed efficace del linguaggio di programmazione Python3, consentendo lo sviluppo di applicazioni sempre più custom e realizzabili in contesti di risorse hardware limitate. Non lasciatevi intimorire da un “nuovo linguaggio di programmazione” perché gli snippet che scriveremo saranno di facile comprensione per chiunque abbia un minimo di dimestichezza con la programmazione. Questa nuova feature ci consente di svincolarci dalla necessità di un microcontrollore esterno, ad esempio Arduino, per la gestione dei moduli XBee. Torneremo su questo argomento in maniera più dettagliata nei prossimi appuntamenti.
Dal momento che l’aspetto economico è un fattore fortemente incisivo per la progettazione di sistemi embedded, in questa prima fase metteremo da parte le possibili applicazioni realizzabili con un modulo XBee3 Cellular LTE e ci focalizzeremo sui moduli XBee3 RF in quanto l’obiettivo iniziale è quello di acquisire confidenza con la loro programmabilità. Grazie a questa rapida analisi possiamo subito apprezzare come la DIGI sia intenzionata a non passare in secondo piano nel mercato IoT ormai pieno di competitors, ma si candida come uno dei principali leader, ricoprendo applicazioni che possono variare dal settore hobbistico fino ad arrivare al settore IIoT.
XCTU
Benissimo, è giunto il momento di iniziare con la pratica e come prima cosa cerchiamo di comprendere come lavorare con questi moduli, in particolare come possiamo configurarli. Per la realizzazione delle nostre applicazioni utilizzeremo il tool XCTU, l’interfaccia offerta gratuitamente dalla DIGI per la programmazione ed il debug dei moduli XBee. Precisiamo che per la realizzazione del sistema saranno necessari due moduli XBee3. L’istallazione di XCTU è raggiungibile tramite il seguente link: https://www.digi.com/products/iot-platform/xctu#productsupport-utilities. Una volta concluso il processo di installazione ed avviato il tool ci troveremo di fronte la seguente schermata riportata in Figura 3.
Per il momento trascuriamo le icone in alto a destra relative alla Console Working ed al Network Working e rimaniamo sull’icona di Configuration Working. A questo punto spostiamoci in alto a sinistra e selezioniamo l’icona Discover Radio Device per consentire a XCTU di acquisire il nostro modulo tramite l’interfaccia seriale. È bene precisare sin da subito che, al fine di consentire il rilevamento del device, è strettamente necessario l’utilizzo di una porta seriale, pertanto per fare ciò sarà necessario dotarsi di appositi adattatori XBee3 Through-hole oppure nel caso scegliate un modulo SMD potreste anche pensare di progettarvi la vostra breakout board come quella riportata in Figura 4.
Qualunque sia la vostra scelta, risulta fondamentale garantire al modulo una comunicazione affidabile, altrimenti difficilmente riuscirete a lavorarci.
Una volta selezionata la porta seriale come in Figura 5, potete passare con Next alla prossima sezione ed impostare i parametri relativi alla porta che state utilizzando, un esempio è visibile in Figura 6.
Se la procedura è andata a buon fine, XCTU rileverà il vostro modulo, altrimenti se insorgono errori, prima di ripetere la procedura di scansione, ricontrollate i parametri impostati ed accertatevi che sia garantita una buona comunicazione seriale con il modulo. Concluso il processo di identificazione e selezionato il modulo, ci verrà fornita una lista di parametri di configurazione, non li vedremo tutti ma approfondiremo solo i più significativi per questa prima fase. Con grandi probabilità il vostro modulo dopo il suo primo boot non avrà installata l’ultima versione del firmware, quindi una delle prime cose da fare è proprio l’update con l’ultima versione disponibile per il Function set DIGI XBee3 ZigBee 3.0, questo Function set ci consentirà di usufruire in un secondo momento delle API.
Concluso il processo di aggiornamento, possiamo iniziare ad esaminare le principali voci di configurazione, partendo dalla sezione fondamentale relativa al Networking. Tramite la voce Device Role è possibile configurare il nostro modulo come Coordinator o Router, se avete bisogno di un ripasso sulla loro distinzione potete guardare qui. A tale proposito se selezioniamo From Network[1], configuriamo il nostro modulo come Coordinator, viceversa otterremo un Router. Con l’occasione ricordiamo che il Coordinator ricopre un ruolo principale per il protocollo ZigBee ed al fine di ovviare conflitti nella rete è necessario garantire l’unicità del nodo. Subito dopo troviamo la voce Extended PAN ID, in questo spazio potete inserire un valore a vostra scelta compreso nel range previsto che consentirà l’identificazione della vostra rete. Come ultimi parametri impostiamo ad 1 la voce ZigBee stack profile in modo da garantire l’abilitazione delle specifiche ZigBee ed infine abilitiamo il Coordinator Verification per consentire ai futuri Router di verificare l’esistenza del Coordinator. In Figura 8 è riportato un riassunto di questi primi parametri impostati.
Passiamo ora alla sezione Security, qui abilitiamo Encripted Enable in modo da garantire una comunicazione criptata all’interno della rete. Nella sezione successiva, ovvero quella relativa all’Addressing, possiamo sfruttare la voce Node Identifier per inserire un nome a nostro piacimento, ad esempio CoordinatorEOS.
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2559 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.
Grazie Nicolò per questo articolo,
trovo l’argomento interessante e non vedo l’ora di leggere il seguito sull’uso di micropython!
Vista la mia attività (non a livello professionale) di progettista di piccole schede elettroniche mi sono subito fermato sull’immagine della scheda utilizzata per comunicare con il dispositivo nella sua versione Micro Mount. Si trova in commercio o è una realizzazione custom?
Saluti.
Grazie SuperG72 per il tuo feedback, mi fà molto piacere leggere le tue parole.
La scheda che ho riportato in Immagine è una breakout board progettata totalmente in maniera custom. Ho scelto questa strada per sperimentare la gestione dello sbroglio e l’ingombro di area della versione Micro Mount, in previsione di possibili implementazioni per applicazioni reali. Difficilmente trovi in commercio breakout board per la versione MicroMount.
Tuttavia in commercio sono disponibili principalmente degli shield che montano la versione Through-hole e sono ideali per sperimentare le nuove features.
Grazie per l’articolo interessantissimo.
Una valida alternativa da prendere in considerazione per applicazioni wireless.
E’ chiaro che il costo e superiore a tante altre soluzioni …mi riferisco ad Ex ai tradizionali moduli a 433Mhz….ma non sono nemmeno da paragonare.
Qui si possono fare selezioni dei dispositivi che devono comunicare tra loro ecc.
Ce ne sono anche con frequenze di trasmissinone differenti , Ex 900 MHZ, ma bisogna distinguere sulle normative.
Sono molto versatili e svincolano il sw da eventuali controlli su errori in TX , perche’ li implementa gia’ il modulo in se’, la comunicazione e’ affidabile.
Per le distanze di trasmissione si puo’ scegiere comunque tra i LOW Power e PRO ( Extended Range ) che consumano pero’ di piu’.
Grazie Maurizio!
Per la versione PRO bisogna fare attenzione in quanto non rispettano le specifiche stabilite dalla ETSI.
Mi fa piacere rivedere i moduli XBee, e come questi si stanno evolvendo, Pensare che i primi che ho utilizzato per pilotare un picco robot risalgono al 2009.
Per cui se la piedinatura è analoga credo si possa modernizzare del vecchio hardware.
Questo articolo mi è piaciuto moltissimo! era da un pò di tempo che volevo iniziare con i moduli XBEE come shield di arduino ma qui viene spiegato abbastanza bene come utilizzarli come moduli indipendenti. Ho scaricato anche l’applicativo XCTU per prenderne visione e ho visto che è dotato di tools molto interessanti. Mi resta solo di procurarmi i moduli e gli adattatori. In ogni caso, mi fa piacere se l’autore pubblica il seguito dell’articolo.
Grazie Mariangela!
Seguirò con interesse questa serie di articoli. Fin’ora avevo preso dimistichezza con ESP8266/32 sia con Arduino IDE che micropython ma sempre utilizzando frequenze del WiFi. Trovo molto interessanti questa proliferazione di sistemi che usano basse frequenze nei 868 Mhz con consumi bassissimi
Era da un po’ che pensavo di utilizzare ZigBee per un sistema di monitoraggio diffuso. Quello che mi preoccupa di più di questo protocollo è il fatto che il coordinator sia unico, per cui se succede qualcosa al nodo principale, la rete va giù e bisogna intervenire “fisicamente” per la riparazione. Ci sono mezzi per implementare un minimo di ridondanza automatica?
Dipende molto dalla topologia di rete che adotti. Se prevedi una topologia a stella centralizzata sul coordinator allora il suo funzionamento incide anche sugli altri device.
Tuttavia la topologia di rete largamente più usata è quella mesh, dove il coordinator si occupa di formare la rete e aggiungere i vari nodi. I device configurati come router possono parlare con tutti gli altri dispositivi. Spegnendo il coordinator i device router ed endpoint continuano a comunicare tra di loro.
Chiarissimo, grazie. Però è solo il coordinator che comunica con un server centrale (via connessione cellulare, WiFi o altro) oppure questo ruolo può essere assunto anche da uno o più router?
Scusa ma non so se ho capito la domanda, provo comunque a risponderti.
Il protocollo ZigBee rientra nella classificazione della rete WPAN ( Wireless Personal Area Network) quindi parliamo di comunicazioni a raggio corto.
Per salire a livello applicativo e fare chiamate ad esempio ad un server tramite API REST potresti usare il modulo XBee3 Cellular LTE utilizzando la libreria usocket. Il firmware che scrivi può stare anche nel router.
I moduli Xbee3 “standard” non gestiscono questa libreria. In alternativa al modulo Xbee3 Cellular LTE puoi usare un raspberry insieme al XBee3 “standard” per gestire la comunicazione fuori dalla tua WPAN.
È esattamente quello che intendevo chiedere. ZigBee gestisce le comunicazioni interne alla rete, ma poi in tanti casi i dati acquisiti devono essere inviati ad un server centrale che li raccoglie e li elabora. Quello che non mi era chiaro era se il modulo XBee3 Cellular LTE potesse svolgere solo il ruolo di coordinator o no. Se può fare anche da router significa, se capisco bene, che è possibile implementare un sistema ridondante, capace di funzionare (seppure in modo parziale) anche in presenza di malfunzionamenti del coordinator e/o di uno o più router.
Ciao a tutti,
il problema comunque a mio avviso e? che per applicazioni industriali il l costo e’ molto elevato.
Purtroppo ho trovato solo 1 modello di questi XBee della Digit a costo accessibile mi sembra sui 14 euro e fa parte della serie 1 , per cui alcuni rivenditori l’hanno tolto anche da catalogo.
Comunque bisogna pur partire da una base.
Io credo che sarebbe molto piu’ interessante la piattaforma offerta da Silicon Labs con i suoi moduli wireless multiprotocollo …oltre a Zigbee supportano altri protocolli .
Credo che i moduli Digit siano piu’ semplici da usare anche come Tool di sviluppo.
Quelli di Silicon Lab sono comunque molto piu’ performanti e a basso costo a mio avviso , se ne trovano anche da 7 euro o meno….il Tool di sviluppo e’ completissimo e comunque richiede uno studio approfondito , ho dato un’occhiata ma al momento ci sono pochi Tutorial.
Si chiama Simplicity_Studio