Arduino: comunicazione wireless 2.4GHz con nRF24L01 e comunicazione SPI – it

Quest’oggi vediamo come sia possibile far dialogare alcune schede Arduino fra di loro attraverso una rete wireless in modo semplice ma soprattutto economico. Attenzione, non stiamo parlando del wifi, molto comodo ma altrettanto costoso, parliamo invece di comunicazione radio bidirezionale a 2.4GHz attraverso i moduli nRF24L01 che potete vedere nell’immagine qui accanto.

Questi moduli sono a dir poco straordinari, permettono infatti di trasmettere e ricevere dati sino ad un centinaio di metri (all’esterno e mooooolto teorici), consumano pochissimo e costano decisamente molto poco, si trovano infatti senza problemi a meno di 3 euro l’uno. Si noti però che questi moduli vanno benissimo per trasmettere fra un’arduino e l’altro, comunicare con Rasberry o altre schede elettroniche, ma non è utilizzabile per comunicare con un PC a meno di creare un’apposita scheda di “conversione”, in quel caso infatti è più agevole usare un modulo wifi che però è decisamente più costoso e che difficilmente riuscirete ad ottenere per meno di 30 euro. Certo se ve ne serve uno solo per un progetto potrebbe essere una soluzione praticabile, ma in tutti quei casi in cui ad esempio avete numerosi sensori che devono comunicare con una scheda centralizzata, dovete cercare una soluzione più economica e questi moduli sono sicuramente la giusta risposta.

Mi si potrebbe obiettare che la soluzione cablata è più sicura e permette trasmissioni a più lunga distanza come abbiamo visto negli articoli sulla rs485, ma diciamocela tutta, non sempre la soluzione cablata è praticabile, specie se stiamo creando dei sistemi in casa dove non erano previsti certi tipi di impianti. Inoltre pensiamoci bene: anche se ad esempio volessimo mettere delle centraline che raccolgono dati su temperatura ed umidità in una grossa serrra, la soluzione cablata sarabbe sicuramente più costosa a causa delle decine di metri di cavo, per cui in linea di massima potremmo risparmiare un bel po’ con questa soluzione.

Collegamenti

I collegamenti sono semplici, ma come sempre è meglio soffermerci un po’ su questo delicato aspetto anche perchè ci sarà un piccolo grande approfondimento da fare. La prima cosa da sapere è che il modulo è alimentato da una tensione compresa fra 1.9 e 3.6V ma i restanti pin possono funzionare anche a 5V per cui il modulo è utilizzabile anche in modo diretto con Arduino UNO. Attenzione però che se non avete un’Arduino con uscita a 3.3V, magari perchè ve lo siete costruiti da voi, servirà un regolatore a 3V per alimentare il modulo. Nella figura a lato vi ho riportato i collegamenti. La numerazione si riferisce al modulo visto dall’alto, esattamente come in figura. Vediamoli insieme:

• GND: è la massa, nulla di particolarmente complicato
• VCC: E’ il pin di alimentazione che, come abbiamo detto, deve avere una tensione compresa fra 1.9 e 3.6V
• CE: Chip Enable: determina se il modulo deve essere posto in ricezione o trasmissione
• CSN: SPI Chip Select
• SCK: SPI Clock
• MOSI: SPI MOSI
• MISO: SPI MISO
• IRQ: Interrupt

Ciò che salta subito all’occhio è che ben quattro dei pin presentano la dicitura SPI, ma di cosa si tratta? Sinora non ne abbiamo mai parlato ma è un protocollo di comunicazione molto usato nei microcontrollori per cui vediamo rapidamente alcune cose basilari:

SPI (Serial Peripheral Interface)

SPI è un’interfaccia single-master – multi-slave, seriale, sincrona, full duplex. Si noti che questo tipo di comunicazione è adatto a circuiti posti sulla medesima scheda o in stretta vicinanza e non è adatto allla comunicazione a distanza. Vediamo i principali punti:

• Single master – multi slave: ne avevamo parlato nell’articolo sull’RS485, ma per riassumere, significa che c’è un dispositivo (master) che instaura la comunicazione e uno o più slave (schiavi) che rispondono quando interpellati. Se il master non richiede nulla agli slaves, questi non possono in nessun modo instaurare una comunicazione, possono infatti solo ed esclusivamente rispondere ad una specifica richiesta del master.
• Seriale: Significa che i bit transitano uno dietro l’altro lungo un solo conduttore.
• Sincrona: significa che c’è un segnale di clock che scandisce la coordinazione dello scambio dati
• Full Duplex: significa che è possibile inviare e ricevere dati nel medesimo istante

Le 4 linee necessarie alla comunicazione sono:

• SCK: Serial Clock: E’ un segnale che permette di sinconizzare l’avanzamento dei dati lungo il bus seriale.
• MOSI: Master Out Slave In: è la linea in uscita dal mater ed in entrata negli slaves.
• MISO: Master In Slave Out: è la linea in ingresso al master ed in uscita dagli slaves.
• SS o CS (Slave o Chip Select): Determina quale slave è selezionato in un determinato momento. Serve una linea CS per ogni slave per cui se avete 3 slaves, giusto per fare un esempio, dovrete avere altrettante linee. In alternativa può essere usata la configurazione “daisy chain” in cui usiamo una sola linea CS.

Il funzionamento è di fatto quello degli shift registers di cui abbiamo abbondantemente parlato in numerosi articoli, ciò ci fà subito capire che risulta possibile effettuare comunicazioni SPI in maniera semplice usando qualunque pin digitale, ma il nostro Arduino presenta un’interfaccia hardware dedicata ed una libreria apposita per il controllo di tale hardware. Il loro utilizzo ovviamente limita la scelta dei pin utilizzabili che sono (tratto da http://arduino.cc/en/Reference/SPI):

Arduino Board	MOSI	MISO	SCK	SS (slave)	SS (master)
Uno or Duemilanove	11 or ICSP-4	12 or ICSP-1	13 or ICSP-3	10	–
Mega1280 or Mega2560	51 or ICSP-4	50 or ICSP-1	52 or ICSP-3	53	–
Leonardo	ICSP-4	ICSP-1	ICSP-3	–	–
Due	ICSP-4	ICSP-1	ICSP-3	–	4, 10, 52

Ci sono alcune cose interessanti da notare. La prima è che ogni scheda utilizza pin differenti, ma l’altra cosa interessante è notare che tutte condividono gli stessio pin del connettore ICSP per cui utilizzando questo connettore possiamo standardizzare il funzionamento dell’interfaccia SPI su tutte le schede. Altra cosa interessante da notare è la colonna SS(Slave). Questa ci interessa poco in questo articolo ma è una caratteristica molto importante, infatti ci indica che Arduino è utilizzabile come slave di altre schede, perciò potremmo avere una scheda come una Rabspberry, una Rabbit o quel che vi pare che utilizza Arduino come una sua periferica secondaria. Potremmo anche usare più schede Arduino connesse insieme, di cui una deputata a coordinare le altre che svolgono compiti specifici.

 nRF24L01

Bene torniamo al nostro modulo. La prima cosa da dirsi è che il connettore del modulo nRF24 e l’ICSP di Arduino non sono compatibili per cui non fatevi venire la pessima idea di fare un collegamento diretto. Dallo schema sopra risulta già chiaro come fare i collegamenti, ma vediamo una tabellina di riferimento:

NRF24L01	UNO	Mega
1 GND	GND	GND
2 VCC	3.3V	3.3V
3 CE	n	n
4 CSN	n	n
5 SCK	13	52
6 MOSI	11	51
7 MISO	12	50
8 IRQ

Di fatto sono gli stessi dati riportati prima. Si noti che CE e CSN li ho contrassegnati con n per indicare che possiamo utilizzare qualunque pin digitale in quanto vengono configurati via software.  IRQ non viene utilizzato dalle librerie Arduino per cui non è indispensabile collegarlo. Ribadisco, vista l’importanza, che la VCC deve essere collegata all’uscita 3.3V e NON alla 5V.

Una volta fatti i collegamenti i quadro dovrebbe essere simile a quanto potete vedere qui sotto. Si noti che per i pin CE e CSN ho usato rispettivamente i pin 7 e 9 su Arduino UNO:

Il software.

Ci sono due vie percorribili per la stesura del software: La prima è utilizzare la libreria SPI e comunicare in modo diretto con il modulo nRF24, ma ciò implica uno studio approfondito dei comandi che questo dispositivo è in grado di elaborare. La strada sarebbe però particolarmente lunga e tortuosa per cui ci accontenteremo di seguire la via più semplice, ovvero l’utilizzo di una libreria già bella che pronta. L’unico problema delle librerie è che, come in questo caso, ne abbiamo più di una da poter scegliere e decidere a priori quale usare non è certo una cosa facile.

Le due principali sono la NRF24 e la Mirf senza contare tutte le versioni modificate e derivate da queste. Scegliere è estremamente difficile, per fare dei semplici test di comunicazione una vale l’altra, basta “che funzioni”, ma le cose possono diventare molto più difficili se la trasmissione radio è solo una delle caratteristiche di un progetto più complesso, in questi casì potrebbe essere necessario testare la compatibilità con altre librerie, con eventuali altre schede Arduino, magari autocostruite e con processori diversi dal più classico Atmega328, potrebbe diventare importante la velocità o l’occupazione di memoria; insomma, la scelta è tutt’altro che scontata. Non ho trovato da nessuna parte un articolo comparativo fra le due librerie, tutti si limitano ad usare una piuttosto che l’altra per cui toccherà a noi l’arduo compito di fare una prova di entrambe le librerie per cercare di scovarne le differenze.

Andiamo perciò a costruire uno sketch che dalla scheda A invia un messaggio alla scheda B, la scheda B interpreta il messaggio ed invia la risposta alla scheda A che a sua volta calcola il tempo intercorso fra l’inizio del messaggio A e l’interpretazione della risposta di ritorno. In questo modo possiamo studiare la comunicazione bidirezionale e fare un test di velocità delle due librerie nella speranza di poter sottolineare alcune differenze fra le due. Per farlo ho preso l’esempio “ping” già presente in entrambe le librerie. Ho fatto solamente alcune piccole modifiche per far si che i risultati siano il più comparabili possibile.

Comunque sia il test funziona in questo modo: la scheda A invia a B 2 bytes che rappresentano i millisecondi trascorsi da quando è stato acceso Arduino. A questo punto B preleva questi 2 bytes e li rispedisce alla scheda A. Quando la scheda A ha letto la risposta, calcola i millisecondi passati dall’inizio e li stampa sulla porta seriale per cui possiamo leggere il risultato stando seduti comodamente al PC. Per fortuna chi ha scritto il codice delle due librerie si è preoccupato anche di fare in modo che questi esempi siano compatibili fra loro , motivo per cui anche senza alcuna modifiche il server con una libreria dovrebbe comunicare senza problemi con il client dell’altra.

Sin dalle prime modifiche del codice mi sono accorto che gli esempi compilati con la NRF24 producono un eseguibile leggermente più grande, ma è anche vero che contengono molte più informazioni di debug. Infatti una cosa che si nota subito è che pressochè ogni funzione della NRF24 restituisce un valore bool che indica se l’istruzione è andata a buon fine o meno, cosa che non è presente in maniera così radicata nella Mirf. Per questo motivo possiamo dire che la grandezza degli eseguibili è sovrapponibile e trovo che le maggiori possibilità di debug siano un punto a favore della NRF24.

Giusto per fare un esempio, il listato server sulla mirf mi produce un eseguibile di 3866bytes, con la nrf24 4242bytes, ma eliminando le informazioni di debug supplementari scendiamo a 3960, qundi neanche 100bytes in più della rivale. Dopo tante chiacchiere vediamo i 4 listati:

 

Mirf

Mirf – Client

#include <SPI.h>
#include <Mirf.h>
#include <nRF24L01.h>
#include <MirfHardwareSpiDriver.h>

void setup(){
  Serial.begin(9600);
   while (!Serial); // wait for serial port to connect. Needed for Leonardo only
  Mirf.cePin = 7;
  Mirf.csnPin = 9;
  Mirf.spi = &MirfHardwareSpi;
  Mirf.init();
  Mirf.setRADDR((byte *)"c0001");
  Mirf.payload = sizeof(unsigned long);
  // To change channel: Mirf.channel = 10;
  Mirf.config();
  Serial.println("Beginning ... "); 
}

void loop(){
  unsigned long time = millis();
  Mirf.setTADDR((byte *)"s0001");
  Mirf.send((byte *)&time);
  while(Mirf.isSending()){}
  Serial.println("Finished sending");
  delay(10);
  while(!Mirf.dataReady()){
    //Serial.println("Waiting");
    if ( ( millis() - time ) > 1000 ) {
      Serial.println("Timeout on response from server!");
      return;
    }
  }
  
  Mirf.getData((byte *) &time);
  
  Serial.print("Ping: ");
  Serial.println((millis() - time));
  
  delay(1000);
} 

Mirf – Server

#include <SPI.h>
#include <Mirf.h>
#include <nRF24L01.h>
#include <MirfHardwareSpiDriver.h>

void setup(){
  Serial.begin(9600);
  
  Mirf.cePin = 7;
  Mirf.csnPin = 9;
  Mirf.spi = &MirfHardwareSpi;
  Mirf.init();
  Mirf.setRADDR((byte *)"s0001");
  Mirf.payload = sizeof(unsigned long);
  Mirf.config();
  Serial.println("Listening..."); 
}

void loop(){
  byte data[Mirf.payload];  
 
  if(!Mirf.isSending() && Mirf.dataReady())
  {
    Serial.println("Got packet");
    Mirf.getData(data);
    Mirf.setTADDR((byte *)"c0001");
    Mirf.send(data); // Send the data back to the client
    while(Mirf.isSending()){}
    Serial.println("Reply sent.");
  }
}

 

NRF24

NRF24 – Client

#include <NRF24.h>
#include <SPI.h>

 NRF24 nrf24(7, 9); 

void setup() 
{
  Serial.begin(9600);
  while (!Serial); // wait for serial port to connect. Needed for Leonardo only
  if (!nrf24.init())
    Serial.println("NRF24 init failed"); // Defaults after init are 2.402 GHz (channel 2)
  if (!nrf24.setChannel(1)) Serial.println("setChannel failed");
  if (!nrf24.setThisAddress((uint8_t*)"c0001", 5)) Serial.println("setThisAddress failed");
  if (!nrf24.setPayloadSize(sizeof(unsigned long))) Serial.println("setPayloadSize failed");
  if (!nrf24.setRF(NRF24::NRF24DataRate2Mbps, NRF24::NRF24TransmitPower0dBm)) Serial.println("setRF failed");    
  Serial.println("initialised");
}


void loop()
{
  unsigned long time = millis();
  if (!nrf24.setTransmitAddress((uint8_t*)"s0001", 5)) Serial.println("setTransmitAddress failed");
  if (!nrf24.send((uint8_t*)&time, sizeof(time)))  Serial.println("send failed");  
   if (!nrf24.waitPacketSent()) Serial.println("waitPacketSent failed"); 
  Serial.println("Finished sending");  
  
  if (nrf24.waitAvailableTimeout(100))
  {
    unsigned long data;
    uint8_t len = sizeof(data);
    if (!nrf24.recv((uint8_t*)&data, &len))
      Serial.println("read failed");

   Serial.print("Ping: ");
   Serial.println((millis() - time));//data;

  }
  else Serial.println("No reply from server");

  delay(1000);  
}

NRF24 – Server

#include <NRF24.h>
#include <SPI.h>

NRF24 nrf24(7, 9); 

void setup() 
{
  Serial.begin(9600);
  while (!Serial) ; // wait for serial port to connect. Needed for Leonardo only
  if (!nrf24.init()) Serial.println("NRF24 init failed");
  if (!nrf24.setChannel(1))  Serial.println("setChannel failed");
  if (!nrf24.setThisAddress((uint8_t*)"s0001", 5)) Serial.println("setThisAddress failed");
  if (!nrf24.setPayloadSize(sizeof(unsigned long))) Serial.println("setPayloadSize failed");
  if (!nrf24.setRF(NRF24::NRF24DataRate2Mbps, NRF24::NRF24TransmitPower0dBm)) Serial.println("setRF failed");    
  Serial.println("initialised");
}

void loop()
{
  nrf24.waitAvailable();
  unsigned long data;
  uint8_t len = sizeof(data);
  if (!nrf24.recv((uint8_t*)&data, &len)) Serial.println("read failed");
  else Serial.println("Got packet");
  if (!nrf24.setTransmitAddress((uint8_t*)"c0001", 5)) Serial.println("setTransmitAddress failed");// Need to set the address of the detination each time, since auto-ack changes the TX address
  if (!nrf24.send((uint8_t*)&data, sizeof(data))) Serial.println("send failed");  
  if (!nrf24.waitPacketSent()) Serial.println("waitPacketSent failed");  
  else Serial.println("Reply sent.");
}

Non ci resta che testarli sul campo. Leggendo sui vari forum sparsi per il mondo ho trovato tante persone che hanno avuto problemi di varia natura, sarò io fortunato, ma a me è funzionato tuto al primo tentativo e con entrambe le librerie. Ho fatto anche i test “crociati” ossia server e client compilati con le due diverse librerie (server Mirf con client NRF24 e viceversa) senza riscontrare particolari problemi.

E le prestazioni? Direi molto promettenti. Anche se il test è davvero banale, l’invio del dato, della risposta e sua ricezione impiega da 1 a 2 millisecondi, nonostante le informazioni di debug (foto a lato). Questo però con i moduli a circa 30 centimetri l’uno dall’altro, ma sulla distanza? Questi sono i moduli  con antenna stampata sul circuito e non esterna per cui dovrebbero avere un range di funzionamento più limitato rispetto ai fratelli maggiori, ma come si comportano sul campo?

I test iniziali sulla distanza non sono dei più incoraggianti. Con il software che vi ho presentato sopra, impostato alla massima velocità di 2Mb/s, le due schede Arduino hanno comunicato senza problemi nella stessa stanza a 4,6 metri di distanza. Passando però sui 6,3 metri con una parete intemedia il segnale non arriva e nemmeno a 3,7 metri ma con due pareti da attraversare.

Questi due test invece vengono superati portando la velocità di comunicazione da 2Mb/s  a 1Mb/s, infatti la riduzione di velocità determina un progressivo incremento della portata, anche se tutt’altro che proporzionale. Per farlo  con la nRF24 cambiate NRF24::NRF24DataRate2Mbps con NRF24::NRF24DataRate1Mbps. Una cosa estremamente curiosa che ho notato è che spostando il trasmettitore dal divano dove era poggiato, al pavimento, ho avuto un discreto guadagno che ha permesso di passare i due test anche a 2Mb/s cosa che mi fa pensare che la distanza effettiva di trasmissione venga notevolmente influenzata dal punto in cui è posizionato il modulo di tramissione e ricezione.

Invece impostando la velocità a 250k (NRF24DataRate250kbps) i due moduli non hanno comunicato nemmeno a breve distanza. Bizzarro notare che che nell’ultima versione l’unica modifica apportata alla libreria riporti “version 1.14 Fixed problem that prevented 250kbps data rate working.”, ossia risolto un problema che impediva il funzionamento a 250kb/s. Mi sorge il dubbio che ci sia perciò un errore software della libreria. Ho fatto numerose prove, sembra sia un problema, peraltro noto, nella gestione dei tempi di ritrasmissione dei pacchetti dati. Per ora ho deciso di non approfondire oltre visto che non è una cosa di fondamentale importanza.

Nota: Solo il RF24L01+ (con il + o una P finale) è compatibile con la velocità a 250k!

La Mirf è decisamente meno documentata, punto a suo sfavore, ma sono riuscito a settare la velocità a 250k. Per farlo, dopo l’istruzione Mirf.config(); aggiungiamo Mirf.configRegister(RF_SETUP,0x26); . Che sia stata settata l’esatta configurazione lo capiamo anche dal fatto che il ping passa a 4-5ms. Ho trovato questo modo studiando i listati e guardando il datasheet ufficiale, alla pagina 58, cosa che mi ha fatto perdere almeno un’oretta di tempo e di cui parliamo nel prossimo paragrafo. Così facendo ho ottenuto un ulteriore miglioramento della portata, e sono riuscito a coprire tutta la casa. Ho superato una distanza di 10metri con due pareti intermedie, anche se a dirla tutta qualche pacchetto dati viene perso, per cui la comunicazione risulta ai suoi limiti.

Per completezza vi riporto le tre possibili configurazioni di velocità con la Mirf, in tutti i casi con impostazione alla massima potenza del trasmettitore:

 Mirf.configRegister(RF_SETUP,0x26); //250k
 Mirf.configRegister(RF_SETUP,0x06); //1mb
 Mirf.configRegister(RF_SETUP,0x0E); //2mb

Fate molta attenzione che il modulo trasmittente e ricevente devono avere lo stesso canale di comunicazione, la stessa velocità e stesso payload, ossia grandezza del pacchetto dati che viene inviato di volta in volta, altrimenti non comunicheranno fra loro.

Smanettoni e registri.

Visto che la documentazione in rete scarseggia ho pensato di spendere due parole sui registri di configurazione del modulo, quelli che cominciano alla pagina 57 del datasheett ufficiale. Vediamo come funziona il resistro 6, di cui abbiamo accennato fra le righe nel precedente paragrafo, poi tutti gli altri utilizzano il medesimo meccanismo di funzionamento per cui basta seguire le stesse operazioni. Vediamo intanto cosa riporta la guida ufficiale al registro 6:

Con la Mirf abbiamo detto che per configurare i registri c’è la funzione configRegister la quale prende due parametri: il primo è il numero del registro, il secondo è un byte di configurazione i cui 8 bit hanno significati diversi in base al registro impostato. Anche con la NRF24 potete fare la stessa operazione, cambia solo il nome della funzione che è spiWriteRegister e che funziona nello stesso identico modo.

Il numero del registro è il 6, ma nella colonna vicina è specificato un valore mnemonico RF_SETUP e guarda caso nel file NRF24L01.h c’è un #define RF_SETUP    0x06 per cui possiamo utilizzare sia il valore numerico che quello mnemonico. La libreria Mirf, come anche la NRF24, mappa tutti i valori mnemonici per cui è possibile utilizzarli direttamente nelle funzioni richiamate, anche se purtroppo la nrf24 usa nomi mnemonici personalizzati più lunghi e non sovrapponibili, in questo caso sarebbe NRF24_REG_06_RF_SETUP che ovviamente non ricavate dal datasheet ma solamente cercando sul file NRF24.h con notevole dispendio di energie. La terza colonna specifica i bit interessati dai vari valori, la quarta indica il valore di default dopo il reset del modulo e l’ultima specifica il significato del singolo bit.

Vediamo i singoli bit del registro 6:

• Il bit 0 è obsoleto, andrà sempre impostato a 0 (valore di default)
• I bit 1 e 2 determinano la potenza di trasmissione del modulo radio. Il valore di default “11” (valore binario) corrisponde a 0dB che rappresenta la massima potenza.
• I bit 3 e 5 (attenzione che non sono contigui) determinano la velocità di trasmissione e ricezione del modulo radio. Di default abbiamo 0 e 1 (bit 5 e 3) che corrisponde a 2Mbps.
• bit 4: bit di test, normalmente a 0
• bit 6: Mantiene costantemente attiva la portante radio durante la trasmissione, default 0.

Impostando i singoli bit otteniamo i valori di nostro interesse. Facciamo un esempio, impostiamo il modulo radio a 250k a -12dB.

Otteniamo perciò un valore binario di 00100010, che rappresenta il 34 decimale o se preferite l’esadecimale 0x22. Quindi se con le due librerie volete impostare il modulo radio a 250k / -12dB dovete aggiungere:

Mirf: Mirf.configRegister(RF_SETUP,0x22);

NRF24: nrf24.spiWriteRegister(NRF24_REG_06_RF_SETUP, 0x22);

E’ vivamente consigliato inserire le istruzioni di configurazione diretta come ultime del setup. Questo perchè ci sono alcune funzioni che vanno ad alterare uno o più parametri per cui rischiate di vanificare lo scopo della funzione. Ad esempio la NRF24, quando impostate la velocità di 250k (se funzionasse!!), modifica anche i tempi di attesa fra le ritrasmissioni automatiche in caso di mancata ricezione, cosa che invece non viene fatta dalla Mirf. Quindi se la vostra intenzione fosse proprio quella di modificare tali velocità, se lo fate “troppo presto”, con la nrf24 la vostra istruzione verrà vanificata nel momento in cui viene selezionata la velocità di trasmissione in quanto il parametro viene sovrascritto. In questo modo non solo non funzionerà come credevate, ma avrete comportamenti diversi nelle due librerie.

Giusto per fare un altro esempio potreste usare i registri per incrementare il numero e l’attesa delle ritrasmissioni automatiche, cosa che permette di avere un leggero ulteriore aumento delle trasmissioni che vanno a buon fine quando siete ai limiti della portata, infatti con queste impostazioni ho coperto anche le zone della casa in cui perdevo alcuni saltuari pacchetti dati:

Mirf.configRegister(SETUP_RETR, 0x45);// 5 ritrasmissioni a 2250μs, di default sono 3 a 250μs.

Conclusioni

Se non fosse per il problema di trasmissione che ho avuto con la NRF24 a 250kbps vi avrei detto che il funzionamento fra le due è sovrapponibile. La NRF24 è notevolmente meglio documentata, a mio parere è più intuitiva e facile da usare, specie per chi è meno smaliziato. La mirf è invece meno documentata ma, sempre secondo la mia personale opinione, è più indicata per “smanettoni” in particolar modo la funzione configRegister permette di configurare in modo semplice e preciso ogni parametro del modulo nRF24L01+ anche se ovviamente dobbiamo fare diretto riferimento al datasheet. Tale operazione è notevolmente agevolata della mappatura degli mnemonici del datasheet che possono essere usati direttamente nei listati. Inoltre la mirf ha un ulteriore piccolo grande vantaggio, infatti esiste la versione anche per RaspBerry e per Attiny, motivo per cui diventa sicuramente preferibile per chi utilizza anche queste piattaforme hardware. Vi state chiedendo quale libreria sceglierò per i prossimi progetti? La Mirf, questa è stata la mia decisione dopo alcuni giorni di test, ma devo ancora testare la nrf24-network un fork che fornisce interessanti funzionalità aggiunte ma che mi ripropongo di provare in futuro, anche perchè i test andrebbero fatti con numerosi sensori e non solo con due schede in comunicazione fra loro.

Bene, siamo arrivati alla conclusione anche di questo articolo. Nella prossima puntata vedremo un progettino completo che utilizza questi sensori.