Ed eccoci qui a parlare, questa volta, delle opzioni di risparmio energetico incluse nei moduli XBee con cui ormai abbiamo acquisito una certa familiarità.
Una rete di sensori wireless, come dice la parola, può anche dover fare a meno della rete di alimentazione, affidandosi a batterie più o meno capaci per garantire le comunicazioni all’interno della rete stessa, ed è quindi fondamentale conoscere come è possibile configurare i moduli per ottenere il minore consumo in assoluto: in alcuni casi possiamo allungare la durata della batteria anche di anni!
Come fare è presto detto: i moduli XBee configurati come End Device permettono di attivare una modalità ‘sleep’ in cui la radio è sostanzialmente dormiente, con consumi prossimi allo zero, ed ‘risvegliata’ ciclicamente per trasmettere o ricevere dati. La durata del ciclo di sleep può essere configurata a piacere, e può andare da pochi millisecondi fino a più di tre settimane, e in modo analogo può essere configurata la fase di attività.
Un po’ di teoria
Un End Device può essere messo in sleep mode in due modi diversi, impostabili con il comando ATSM:
- Modalità ‘pin’: consente ad un dispositivo esterno di determinare quando il modulo deve essere attivo e quando invece può rimanere in stand-by.
- Modalità ciclica: il modulo adotta un ciclo di attività / stand-by in base alla configurazione (tramite opportuni comandi AT).
Quando l’End Device è in modalità ‘pin sleep’ lo stato (attivo/stand-by) può essere comandato attraverso il pin fisico 9:
Lo stato del modulo è rilevabile attraverso il pin 13 (On/Sleep pin) che diventa HIGH se il modulo è attivo, LOW in caso contrario: basterà collegare un LED al pin in questione (ovvero tra pin e ground) per avere evidenza immediata di cosa succede.
C’è poi un altro pin utilizzato per indicare se il modulo può ricevere dati: il pin 13 , che è normalmente utilizzato per gestire il controllo di flusso HW CTS (Clear To Send). Un dispositivo esterno che comunica via seriale con il nostro End Device può fare riferimento allo stato del pin 13 per implementare il controllo di flusso hardware CTS, che, in sostanza, indica quando il modulo può accettare dati da spedire:
La figura seguente sintetizza tutto quello che abbiamo fin qui descritto:
All’inizio il modulo è attivo: il pin 9 è LOW, il pin 13 HIGH (modulo ON), il pin 12 LOW (possono essere passati dati per la trasmissione).
All’istante T1 il pin 9 è posto a HIGH (collegandolo a 3.3V), ovvero viene richiesto al modulo di entrare in sleep. Il modulo termina le eventuali attività in corso (trasmissione/ricezione di dati) e passa in sleep all’istante T2: il pin 13 diventa LOW, il 12 HIGH (non è più possibile la trasmissione).
All’istante T3 il pin 9 passa a LOW: il modulo è riattivato (impiega circa 10-15 millisecondi), ed i pin 13 e 12 tornano rispettivamente a HIGH e LOW (modulo attivo e pronto a ricevere dati).
L’intervallo di tempo tra T1 e T2 è variabile e dipende dalle attività in corso: nel caso in cui il modulo stia tentando di associarsi ad una rete può durare anche diversi secondi.
Se invece l’end device è configurato in modalità ciclica i periodi di attività e sleep sono gestiti direttamente dal modulo sulla base della configurazione impostata con specifici comandi AT oggetto del prossimo paragrafo. Si tratta, sostanzialmente, di definire la durata dei periodi di sleep e di attività:
All’istante T1 il modulo passa in stato attivo, il pin 13 passa a HIGH ed il 12 a LOW; all’istante T2 inizia il nuovo ciclo di sleep ed i pin 13 e 12 passano a LOW e HIGH.
Qualunque sia la modalità impostata, il modulo, appena attivato, invia al parent un campionamento I/O e inizia il polling, ovvero la richiesta di invio dati che viene ripetuta ogni 100 millisecondi finché non inizia un nuovo periodo di sleep (sia via pin che ciclico).
Nel caso in cui la frequenza di campionamento (impostata con il comando ATIR, qui i dettagli) sia maggiore di zero, il modulo invierà campionamenti I/O sino alla successiva fase di sleep in base alla frequenza indicata.
I comandi del ‘sonno’
Dopo aver visto le modalità di sleep possibili, approfondiamo qui quali sono i comandi AT necessari per la configurazione in dettaglio del modulo: i comandi sono sei, tre basici e tre avanzati, destinati a gestire le situazioni più complesse. I tre comandi di base sono:
- ATSM: (sleep mode), legge/assegna la modalità di sleep. Il comando accetta i parametri:
- 0 : modalità sleep disabilitata (impostabile solo su router o coordinatore);
- 1 : modalità sleep pin;
- 2 : non utilizzato;
- 3 : non utilizzato;
- 4 : modalità sleep ciclica (default per end device);
- 5 : modalità sleep ciclica con possibilità di utilizzo del pin 9 per attivare comunque il modulo (in pratica un mix tra 1 e 4).
- ATSP: (sleep period), legge/assegna la durata del periodo di sleep. Il valore indica (in esadecimale) la lunghezza del periodo in centesimi di secondo (es 0x7D0 = 2000 centesimi = 20 secondi). I valori impostabili vanno da 0x20 (320 millisecondi) a 0xAF0 (28 secondi), il default è 0x020.
- ATST: (sleep timeout), legge / assegna la durata del periodo precedente ad un nuovo ciclo di sleep (periodo di attività). Il valore (in esadecimale) indica la lunghezza del periodo in millesimi di secondo (es: 0x1388 = 5000 millesimi di secondo = 5 secondi). I valori accettati vanno da 0x001 (1 millisecondo) a 0xFFFe (65534 millisecondi). Il valore di default è 0x1388 (5 secondi).
Per impostare un end device in modo che rimanga in sleep per 10 secondi e poi si attivi per 100 millisecondi basterà quindi assegnare la modalità di sleep ciclica con il comando ATSM 4 (o 5), impostare il periodo di sleep con il comando ATSP 3E8 (1000 centesimi di secondo) ed infine impostare il periodo di attività con ATST 064 (100 millesimi di secondo).
I tre comandi più complessi di norma sono utilizzati quando il modulo è collegato fisicamente a qualche altro dispositivo, come potrebbe essere una stazione di rilevamento dati meteorologici o un servomeccanismo da azionare. Questo secondo set di comandi comprende:
- ATSN: (sleep periods number), legge/assegna il numero di periodi di sleep che devono trascorrere senza che, in mancanza di dati, sia portato a On il pin 13 (On/Sleep pin). Di fatto serve ad evitare di ‘svegliare’ un eventuale dispositivo connesso senza necessità. Il valore di default è 1, il range ammissibile va da 1 a 0xFFFF (65535 periodi).
- ATSO: (sleep options), utilizzato per impostare una serie di opzioni ulteriori. I valori accettati sono:
- 0x02 : il modulo rimarrà in stato attivo per l’intera durata di ST;
- 0x04 : attiva la modalità di sleep estesa, la durata del periodo di sleep sarà pari a SP (periodo di sleep) x SN. In questo modo si può arrivare alla massima durata della fase di sleep in modalità ciclica, che è pari al massimo valore di SP (28 secondi, come visto) moltiplicato per il massimo valore di SN (65535 periodi), ovvero poco più di 21 giorni.
- 0x06 : imposta entrambe le opzioni descritte.
- ATWH: (wake host). legge/assegna la durata dell’intervallo di tempo tra il momento in cui il pin 13 è On ed il momento in cui il modulo inizia una qualunque operazione di I/O. E’ utilizzato per permettere ad un dispositivo collegato di uscire da un eventuale stato di stand-by prima che il modulo inizi la lettura o la spedizione di dati. Il range di valori utilizzabili (millisecondi espressi in esadecimale) va da 0x0 a 0xFFFF (65535 millisecondi).
Una prova sul campo!
Per i nostri test possiamo ripartire dal termometro wireless realizzato nella puntata precedente: manterremo la stessa stazione ricevente, e modificheremo il termometro in modo che il modulo XBee trasmetta la lettura di temperatura una volta ogni 20 secondi, rimanendo in sleep per il resto del periodo.
Per prima cosa riconfiguriamo il modulo in modo che sia un end device utilizzando X-CTU (i dettagli su come utilizzare X-CTU li trovate qui). I parametri di configurazione, sia a livello di networking che di configurazione interna del modulo dovrebbero rimanere invariati, ma conviene prender nota comunque della configurazione originale.
Fatto questo, lavoriamo sulla parte di sleep. Abbiamo detto che vogliamo un periodo ciclico di sleep di 20 secondi, ovvero 2000 centesimi, che in esadecimale è 0x7D0. Poi il modulo dovrà attivarsi il tempo necessario ad inviare il segnale di temperatura, 100 millisecondi dovrebbero essere più che sufficienti (in esadecimale 0x064). I comandi da utilizzare sono quindi:
A questo punto, se è tutto a posto, il modulo dovrebbe iniziare ad attuare i cicli di sleep / attività come li abbiamo impostati. Per verificare che sia così possiamo utilizzare due LED collegati opportunamente tra i pin 12 e 13 ( CTS e On/Sleep) e ground:
Come visto in precedenza i due LED si accenderanno alternativamente in base allo stato del modulo: On / Sleep sarà acceso quando il modulo è attivo, CTS in caso contrario.
E se non funziona?
Che succede se sbagliamo la configurazione? In teoria nulla, possiamo sempre modificare i parametri errati e ripartire. In pratica potremmo trovarci con qualche difficoltà inattesa: quando il modulo è in sleep non è possibile alcuna comunicazione, quindi non saremo in grado nemmeno di effettuare alcuna variazione ai parametri, e con un periodo di attività limitato a qualche frazione di secondo potrebbe divenire impossibile ‘resuscitare’ il modulo. E quindi cosa possiamo fare? Abbiamo diverse possibilità in base alla modalità di sleep impostata.
- pin sleep (SM 1): il problema non dovrebbe sussistere, in quanto portando a HIGH il pin 9 il modulo si attiva.
- sleep ciclico (SM 4): la cosa si fa un po’ più complicata in quanto il pin 9 viene ignorato. Esiste tuttavia la possibilità di usare il pin 20 (Commissioning Button), che, se abilitato a questa funzione (il default è che lo sia) , attiva il modulo per 30 secondi quando viene portato a HIGH. Nel caso in cui sia disabilitato bisogna tentare la fortuna, utilizzando un emulatore di terminale e digitando la stringa ‘+++’ per entrare in command mode ad intervalli non più brevi di un secondo, sperando di ‘azzeccare’ un periodo di attività. Ho fatto qualche test, ed in effetti sembra che sia meno difficile del previsto: la stringa viene comunque bufferizzata per un breve intervallo, in attesa di risposta. Per leggere/impostare il bottone di commissioning si utilizza il comando ATD0 (risponde 1 se attivo).
- sleep ciclico con wakeup pin (SM 5): in questo caso dovrebbe essere possibile utilizzare sia il pin 9 che, eventualmente il bottone di commisioning.
Un ultima strada potrebbe essere quella di un reset del modulo, che può essere eseguito staccando (delicatamente) il modulo dal supporto senza togliere l’alimentazione.
Le puntate precedenti di questo divagare ondivago su Arduino e ZigBee sono qui: prima puntata, seconda puntata, terza puntata, quarta puntata, quinta puntata.
Pingback: Cardboard tronics | The Monday Morning Tech Newsletter
Pingback: Arduino, Zigbee e le infinite possibilità (6) | The Monday Morning ... | E4Y Electronics For You | Scoop.it
Salve, innanzitutto complimenti per la guida.
Mi domando come si potrebbe fare se io volessi utilizzare il modulo xbee anche come attuatore; mi spiego meglio:
supponiamo che voglia mandare il valore della temperatura ogni 5 minuti ed in base al valore rilevato (ad esempio da un Arduino) viene inviato all’xbee un remote AT Command che setta ad High uno degli I/O digitali al quale collego ad esempio una ventolina; se il modulo è in sleep non riceverà mai tale comando giusto? almeno che non arrivi giusto giusto nel momento in cui è sveglio.
Su due piedi mi vien da pensare che potrei inviare a raffica il remote AT Command finchè non ricevo la remote AT response; potrebbe essere questa una buona soluzione?
Mah, sono un po’ perplesso…
Dal punto di vista della pura comunicazione il parent (router o coordinatore) possiede un buffer dove memorizzare i messaggi destinati agli end device ‘child’ dormienti: nel momento in cui un modulo si attiva inizia a fare polling verso il proprio parent per verificare se ci siano messaggi destinati a lui (il default è una richiesta ogni 100 millisecondi). Il buffer ha comunque un timeout massimo di 30 secondi, per cui, se il modulo è in sleep per un tempo superiore, occorre inviare i messaggi in modo da essere certi che non siamo scaduti quando il modulo esce dallo sleep, e questo, a occhio, può essere fatto in due modi:
1) rimandi lo stesso messaggio ogni 30 secondi (o meno);
2) fai partire un timer al ricevimento della lettura della temperatura e, prima di spedire il messaggio, attendi un tempo sufficiente a garantirti che il modulo si attivi non più tardi di 30 secondi dal momento dell’invio (es: se lo sleep period è di 5 minuti conti 4 minuti e 45 sec. dall’ultima lettura prima di inviare).
Il metodo 2 mi sembra quello più ‘pulito’, in quanto non effettui trasmissioni a vuoto.
Quello che non ho capito è il disegno generale. Mi spiego meglio: il modulo xbee può funzionare da attuatore, ma non è certo in grado di attivare direttamente una ventola (anche minima) attraverso un pin: il pin può arrivare al massimo a 8 milliampere (se non ricordo male), sufficienti ad accendere un LED ma di certo non abbastanza per far girare un motore. Quello che dovresti fare è costruire un circuito di alimentazione della tua ventola pilotato dal modulo attraverso un transistor (magari un MOSFET), un optoisolatore o altro (potresti anche sfruttare il PWM per modulare la velocità), e qui sta il mio dubbio: se pensi di dover gestire una ventola significa che hai a disposizione un’alimentazione ben più ‘robusta’ di quella necessaria a far funzionare il modulo, il cui consumo diventa probabilmente trascurabile se comparato con quello della ventola. A questo punto è probabilmente inutile impostare dei periodi di sleep particolarmente prolungati, in quanto di fatto non porterebbero benefici tangibili: imposta uno sleep di 20 secondi e vivi felice!
Giusto per fare qualche numero: una ventola per PC alimentata tipicamente a 12 volt assorbe una corrente intorno a 0,5 A (qualcuna di più, altre meno, ma quello è l’ordine di grandezza), il modulo Xbee attivo e in trasmissione è intorno a 40 milliampere, quindi meno del 10%…
Si, dal lato dell’xbee end device suppongo di avere un relè ed un’alimentazione tale da mettere in moto una ventola/motore etc.. anche se effettivamente è vero che non ha tanto senso cercare di risparmiare batteria dell’xbee a questo punto.
Per quanto riguarda il comando inviato dal parent pensavo che potrei optare inviando il comando appena ricevo un campione dall’end device al quale imposto di stare attivo un po’ più a lungo; in questo modo ad ogni campione ricevuto invio un comando relativo al campione precedente, ma almeno dovrei essere sicuro che arriva, in quanto col metodo 2 che hai suggerito tu se il mio Arduino perde più tempo a svolgere altre operazioni potrei non arrivare in tempo ad inviare il comando.. oppure se non ho più il problema di risparmiare batteria lato end device allora imposto lo sleep di 20 secondi e sfrutto la bufferizzazione del parent
Ho un altro dubbio:
hai scritto “il modulo, appena attivato, invia al parent un campionamento I/O e inizia il polling”; ma quindi se l’end device viene impostato per inviare campioni ogni 61535 ms , ossia il valore massimo si IR (FFFF), mentre lo sleep dura 5 minuti attivandolo ciclicamente per 100 ms, coma succede? suppongo che appena il dispositivo si sveglia invia un campione, ma a questo punto impostare IR ad FFFF non servirebbe più a nulla giusto?
Rispondo ad entrambi i tuoi post (in ordine inverso):
1) sulla frequenza di campionamento (IR): hai perfettamente ragione, impostare IR ad un valore maggiore di ST è di fatto inutile, può servire solo come garanzia di non ricevere più di un campione per ogni periodo di attività.
2) Non capisco bene cosa intendi quando dici “..col metodo 2 che hai suggerito tu se il mio Arduino perde più tempo a svolgere altre operazioni potrei non arrivare in tempo ad inviare il comando”. Io non suggerivo di inviare il comando non appena ricevuto il campione, cosa che, come giustamente sottolinei, potrebbe essere in qualche modo rischiosa (se per qualunque motivo Arduino è ‘occupato’ da altre elaborazioni potrebbe non arrivare in tempo), ma, potendo prevedere la fine del periodo di sleep del modulo pensavo di inviare il comando una decina di secondi prima del istante previsto per il wake up, in modo che al momento del risveglio il comando sia disponibile nel buffer. Ovviamente è comunque un comando legato all’elaborazione del segnale ricevuto in precedenza, quindi potrebbe avere un ritardo pari al periodo di sleep.
Probabilmente una sequenza migliore potrebbe essere:
– Arduino riceve la lettura del sensore, fa partire un timer ed inizia l’elaborazione;
– Arduino tenta la trasmissione immediata del comando AT remoto (se necessario);
– Se Arduino riceve un feedback positivo entro un certo tempo (direi non più di qualche secondo) tutto ok, il ciclo si ripeterà al prossimo campione;
– Se invece non c’è alcun feedback assumo che il comando non sia stato eseguito. Calcolo quindi l’istante in cui prevedo che il modulo si riattivi: conosco l’istante in cui si è riattivato l’ultima volta (è quello in cui ha inviato un campione), il periodo di sveglia (ST) e quello di sleep (SP o SPxSN), quindi posso pensare che il modulo si attivi di nuovo dopo ST + SP (o ST + SP x SN) a partire dl momento in cui ho ricevuto il campione. Invierò quindi il comando qualche secondo prima dell’istante in questione in modo da avere un margine di sicurezza, il comando resterà disponibile nel buffer abbastanza a lungo da permettere al modulo di riceverlo comunque.
Se invece hai a disposizione un’alimentazione alternativa rispetto alla bateeria dell’ xbee il discorso si fa piuttosto inutile, in quanto ti basta limitare lo sleep. In sostanza era questo il senso della mia prima risposta.
Ok, non avevo capito bene; l’idea del timer mi piace, prima intendevo che sarebbe stato rischioso usare i timer (forse invece mi sbaglio); non li ho mai usati su Arduino, quindi mi domando: se imposto un timer allo scadere del quale deve essere eseguito un determinato metodo, cosa succede se l’Arduino sta facendo altre elaborazioni nel momento in cui scatta il timer? si interrompe l’operazione per eseguire il metodo?
Il mio problema è che l’Arduino riceve i campioni e poi invoca vari servizi web di cui non posso conoscere il tempo di esecuzione.
Mah, guarda, forse ne sai più tu di me…quando parlo di timer sostanzialmente ho in mente una cosa molto banale: lo sketch deve essere fatto in modo da memorizzare un timestamp quando riceve il campione (basta chiamare la funzione now() definita dentro Time.h) , al quale poi sommare il periodo di attività e di sleep successivo. In questo modo sai quando il modulo si sveglierà (chiamamolo waketime). Poi, da qualche parte all’interno del loop() a valle dell’elaborazione, confronti now() con waketime e decidi se inviare il comando o aspettare un altro po’.
La cosa potrebbe essere un filo più complicata nel caso in cui le invocazioni ai web services, per un motivo qalunque, non si completino entro il periodo di sleep del modulo: te ne accorgeresti comunque dal fatto che al momento del controllo now() avrebbe superato waketime, il tempo residuo prima del prossimo risveglio dovrebbe essere calcolabile utilizzando il modulo:
(ST+SN*SP) – (now() – waketime) % (ST+SN*SP)
Almeno credo…
(certo che aspettare la risposta di un WS per 5 minuti….è sfiga! Onestamente non so se esista la possibilità di specificare un timeout sulle chiamate).
assolutamente no, sei tu il maestro 🙂
è vero, ma bisogna sembre analizzare il caso peggiore.
grazie mille, mi sembra un’ottima soluzione
Ho testato il sistema del buffer e funziona alla perfezione 🙂 .. vorrei pero’ precisare, per chi fosse interessato, che affinché funzioni si deve settare nel router o coordinatore il parametro SP con lo stesso valore di quello dell’end device, altrimenti non viene bufferizzato nulla.
Ottimo!
In effetti hai ragione, il parametro SP sul parent determina, tra l’ altro, l’intervallo di tempo in cui il messaggio resta bufferizzato (pari, a voler essere precisi, a SP x 1,2).
Ciao, volevo chiederti stavolta se è possibile che la modalità sleep influisca in qualche modo sul campionamento.
Praticamente sto usando i pin AD0, AD1 ed AD2 per campionare i valori di tre sensori diversi tra cui una fotoresistenza; il modulo XBee è settato in modalità sleep 5 (cyclic con pin-wake) e ha periodo di wake di 100ms e sleep di 3 minuti; vi è l’anomalia che quando il sensore di luminosità segna il valore massimo (1023, caso di buio) allora i valori degli altri due sensori aumentano inspiegabilmente, per poi ritornare al valore normale se la luminosità dovesse aumentare.
Potrebbe essere che il tempo di wake è troppo breve? (anche se ho provato a mettere 1 secondo ma non è cambiato nulla)
La cosa strana è che quando è buio il sensore di luminosità da 1023 e fin qui funziona tutto, solo quando l’ambiente diventa molto ma molto buio allora il valore resta sempre 1023, mentre gli altri sensori cominciano a dare valori maggiori del normale.. c’è forse qualche cosa riguardo il campionamento ADC che mi sfugge?
Ciao Nicola, detto così mi suona un po’ strano, sarei più propenso a credere che la variazione di lettura dipenda da qualche effetto secondario all’interno della circuiteria che hai utilizzato per connettere i sensori piuttosto che dal modulo Xbee: hai provato a ‘leggere’ direttamente l’output con un un tester? Fossi in te cercherei di andare per esclusione: prima testo i sensori da soli (misuro p. es. la resistenza al variare delle condizioni ambientali), in modo da escludere che la causa siano i sensori stessi, poi misuro il segnale (V) all’ingresso del modulo. Altro non saprei, non credo che la modalità sleep abbia influenze di qualche genere…
Va bene grazie, farò così.. mi era venuto il dubbio dato che altrove mi avevano detto che se i sensori condividono la stessa ADC con un multiplexer allora potrebbe essere questione di time-gap tra i vari campioni, ma sicuramente è un problema di circuito.
Salve,
ho un bel problema con questa modalità di sleep e spero che tu mi possa aiutare.
ho un modulo configurato nel seguente modo:
CE=1
SM=0
ST=1388
SP=1F4
che assolve alla funzione di coordinatore; nel progetto (arduino) quando tale modulo riceve dei dati li deve rispedire ad un altro modulo (end device) configurato come segue:
SM=4
ST=1388
SP=1F4
quindi 5 sec di sleep e 5 sveglio(se non erro)…dico che senza la modalità sleep attiva tutto funziona correttamente(ovvero da seriale mando il comando 1 (quello che si aspetta l’end device) e l’end device risponde a dovere)
la modalità ciclica funziona nel senso che (me ne accorgo dai led) però è come se l’end device non riceve il dato che gli passo da seriale(me ne accorgo sempre dal led rssi presente sulla board sulla quale è agganciato il modulino xbee), mentre il coordinator riceve, appena l’end device si sveglia, dei dati sporchi: eg:~…..7……….”~…..6……….#~…..:………..~…..5……….$~…..5……….$~…..4……….%~…..:………..~…..=………..~…..:………..~…..;………..~…..;………..~…..;………..~…..;………..~….
Come posso risolvere? Penso che questo sia l’unico posto giusto dove chiedere! =)
Ma i moduli a livello di firmware come sono configurati? coordinatore in API mode ed end device in AT?
IN più sarebbe utile capire di che ‘dati sporchi’ stai parlando, visto che a me quello sembra un po’ un frame che si ripete….prova a postare i dati che arrivano in HEX, invece che in ASCII, in modo da capire se quei byte hanno qualche significato…
In più l’End Device ha il sampling abilitato? ovvero, se interroghi IR (con il comando ATIR), cosa risponde?
Scusa, mi sono accorto da quanto hai scritto sul forum di Arduino che hai mnoduli serie 1, io ho usato solo i serie 2 (gli ZB), quindi probabilmente ho detto un sacco di cavolate!
quindi cosa credi che non vada?
ehm…questa è una delle prime config che faccio con gli xbee e non sono a conoscenze di queste cose =)…ho semplicemente letto: http://www.digi.com/support/kbase/kbaseresultdetl?id=2193
per operare in tale modalità in quanto il nodo end device deve essere alimentato con batteria e quindi mi interessava ridurre i consumi…credevo fosse banale come configurazione(quando arriva sul coordinator il dato(nel mio caso da internet) esso via seriale lo invia all’end device che nello specifico accende un condizionatore…comunque ti posto l’hex:
33 00 01 14 05 00 03 FF 03 FF 25 7E 00 0E 83 CHE IN ASCII è 3……….&~…
etc…
ps: non ho fatto particolati configurazioni sui moduli(xbee serie1)…solo quelle che ho detto su piu’ gli “indirizzi ” univoci per farli comunicare solo tra di loro..
ah….ho configurato entrambi i moduli con x-ctu
Segnalo quello che, a vedere lo schema successivo e la spiegazione, sembra essere un (doppio) refuso:
“se il modulo può ricevere dati: il pin 13 , che” → “se il modulo può ricevere dati: il pin 12, che”
Anche nella tabellina quindi credo che vada cambiato “13” in “12”.
Complimenti di nuovo per questa serie di articoli!