DMX e Ricevitore IR

Bene, eccoci qua, sono Claudio Rossi e sono uno studente, ho appena concluso il quarto anno di studi all’ISIS Facchinetti di Castellanza, corso d’informatica.

Al momento sto affrontando un periodo di 3 settimane di stage presso la Futura Elettronica  di Gallarate.

In queste tre settimane dovrò portare avanti un progetto che consiste nello sviluppo di un software che attraverso l’utilizzo di un prototipo di shield DMX  e di Arduino dovrà gestire il funzionamento di un faretto a led.

Per chi non lo sapesse, il DMX è un particolare protocollo per la gestione dell’illuminazione di scena. (Per maggiori informazioni visitate la relativa pagina di Wikipedia)

Dal momento che è la prima volta con cui ho a che fare con Arduino, ho trascorso il primo giorno per capirne le funzionalità di base facendo alcune prove basilari.

Il secondo giorno ho cominciato a lavorare sulla shield che si occupa di gestire il segnale DMX in uscita, subito si è presentato un problema, infatti la shield non inviava alcun segnale e di conseguenza il faro rimaneva spento. Dopo molti tentativi sono riuscito a rilevare la fonte del problema che stava tutto in un integrato difettoso che non convertiva il segnale digitale in segnale DMX.

N.B. La shield DMX da me usata non è ancora in commercio, essa è solamente un prototipo realizzato dalla Futura Elettronica, e a differenza delle normali shield DMX, su questa è stato integrato un ricevitore Infrarossi.

Dopo aver risolto il primo problema ho iniziato ad affrontare il problema di come usare il ricevitore IR per controllare la shield attraverso un comune telecomando universale. Ma anche in questo caso i problemi non hanno tardato ad arrivare infatti inizialmente il ricevitore non interpretava a dovere i segnali, la soluzione stava nel cambiare la posizione del jumper che determina quale pin usare per prelevare il segnale IR.

Successivamente quando ho iniziato a unire i progetti con l’intento di comandare il faro con il telecomando, è risultato che nè il ricevitore IR ne il faro davano segni di vita, quindi facendo delle ricerche su internet, ho scoperto che le due librerie che gestiscono rispettivamente il ricevitore e la shield DMX entrano in conflitto in quanto entrambi usano lo stesso timer per il conteggio del tempo trascorso, purtroppo questo problema non ha ancora trovato una soluzione e per questo mi vedo costretto ad abbandonare l’idea.

Nei prossimi interventi spiegherò come ho deciso di modificare il progetto.

 

 

WiFi shield e riconnessione alla rete

Scusate il ritardo ma il lavoro di certo qui non manca 😉
Prima di tutto mi presento. Mi chiamo Ruffo Daniele e vengo dall’ ISIS Facchinetti di Castellanza ( 4 anno ).

 

Preciso che sono già stato stagista presso Futura Elettronica assieme al mio compagno Speroni Manuel ed abbiamo realizzato un robot LineFollower per permettere all’istituto di partecipare alla robocup. Il robot è attualmente a scuola ed utilizzato da dei ragazzi di 5 come progetto per la maturità. Spero di avere la possibilità di rendervi partecipi di quel progetto non appena mi ricapita sotto le mani. ( Se lo ritrovo, pubblico il video di prova effettuato durante uno dei vari test)

 

Quest’anno invece mi è stato proposto un lavoro di diverso tipo:
Prima di tutto trovare una soluzione ad un problema riscontrato nella nuova WifiShield ( 8190-WIFI_SHIELD ), ovvero ritrovare e riccolegarsi alla rete in caso di perdita del segnale ( derivante da una caduta di rete, spegnimento del modem, perdita del segnale, caduta di corrente o qualsivoglia tipo di situazione).

Risolto questo problema sviluppare diverse applicazioni utilizzando questa shield.

 

Come primo passo aggiorniamo l’idee di Arduino alla versione 1.0.1  ( qui il link per la pagina del download ) e riscontriamo il primo problema.
Alcune delle vecchie librerie sembrerebbero non funzionare su questa nuova versione per cui un consiglio che posso darvi per
N.B. Ci tengo a precisare che tale operazione non risolve il problema per tutte le librerie !!tentare di risolvere questo problema consiste nel aprire il .h che avete incluso e controllare che non ci siano istruzioni del tipo:
#include <wire.h>
In tal caso sostituendole con #include <Arduino.h> dovrebbe risolvere il problema.

Ora scarichiamo la libreria per il  WifiShield ed ecco che purtroppo sorgono ulteriori e gravosi problemi. Purtroppo questa libreria risente di diverse limitazioni, ecco il motivo per cui mi sono permesso di apportare delle modifiche ( Il perchè viene spiegato in seguito ).
Qui il link per il download della libreria aggiornata.

Per la ricerca del problema si è utilizzato uno sketch di esempio, atto a scaricare dei valori

da un sito francese(CO2 presente nell’aria) ed accendere delle lampade di un intensità

pari al valore letto.


Download
sketch di esempio

 

.
Da qui si inizia la ricerca del problema riconnesione wifi. Come prima soluzione si è pensato di effettuare un reset di arduino via software utilizzando una funazione che punta all’indirizzo 0.

void(* Riavvia)(void) = 0;

Questo riavvia appunto arduino e quindi lo sketch ritenta la connessione attraverso l’istruzione nel setup “WiServer.init(NULL);” . I problemi però non sono del tutto risolti utilizzando questo metodo poichè se la rete ritorna in tempi molto brevi la connessione risulta possibile, se però i tempi sono lunghi lo sketch si impalla sull’istruzione di inizializzazione appena citata . Ecco che entra in gioco la modifica apportata alla libreria.
Ad essa, infatti, sono stati aggiunti dei metodi che permettano la connessione asincrona di arduino, permettendo così allo sketch di non bloccarsi durante il tentativo ( sia esito positivo o negativo che sia ) di connessione.

WiServer.async_init(sendMyPage, NULL);

Anche questo presenta degli svantaggi ma non del tutto impossibili da ovviare. Il difetto principale è che anch’esso non riesce a collegarsi se la rete ritorna ad essere disponibile dopo tempi lunghi e a volte dopo una riconnessione parte dopo molto a scaricare gli eventuali dati dal sito richiesto. Di conseguenza si è trovato una via di mezzo tra queste due soluzioni per ovviare qualsivoglia tipo di problema ( mostrerò dopo il codice e la spiegazione di questa soluzione ). Come ultimo tentativo di soluzione si è provato a collegare il pin di reset del modulo wifi ad un pin di arduino per mandarlo basso (lavora in logica negativa) e vedere se la riconnessione era possibile attraverso il suo riavvio.Si è constatato che questo metodo porta gli stessi svantaggi dei metodi precedenti se non in aggiunta una modifica hardware allo shield.

Si è anche guardato un possibile utilizzo del watchdog ma essendo risultato inutile rimando la spiegazione a questo articolo di cosa consiste.

 

Ora la soluzione trovata è stata idealizzata pensando allo sviluppo di un datalogger ma può benissimo essere modificata per le proprie esigenze. Nella spegazione seguente non mi riferisco al datalogger ma semplicemente alla riconnessione dopo una perdita della rete.

Nel setup è stata sostituita l’istruzione WiServer.init(NULL); con questo ciclo ( si suppone che nel monento in cui avvio lo sketch  sono in presenza del wifi, altrimenti va modificata la partenza ) :

while(!WiServer.connection_up()){           
    WiServer.async_init(sendMyPage, NULL);     
if(WiServer.connection_up())
        WiServer.init(NULL);
    }

Finchè non mi collego veramente, tento la connessione attraverso il metodo asincrono async_init(sendaMyPage, NULL) così da evitare un eventuale blocco dello sketch derivante dalla init(NULL). Per ovviare la possibilità che avvenga la connessione attraverso tale metodo ma che non parti immediatamente il downliad effettuo una init(NULL) essendo sicuro che la connessione esiste davvero e che non si bloccherà lo sketch.

Nel loop(), nel momento in cui viene a mancare il segnale, si ha questo tipo di controllo:

if(!WiServer.connection_up()) {
    int i;
    for(i=0;i<300 && !WiServer.connection_up();i++){
        Serial.println(“Cerco di ricollegarmi”);
        server_up = WiServer.async_init(sendMyPage, NULL);
        delay(1000);
        Serial.println(i);
      }
   if(WiServer.connection_up() || i==300){
       Serial.println(“Riavvio i=” +i);
       delay(1000);
       Riavvia();}
}

Il ciclo for prosegue finchè o non trovo la connessione e quindi posso ricollegarmi ( viene effettuato un riavvio software precedentemente citato così da riportarsi nel setup ed escludere tutti i problemi ) oppure se sono passati 5 minuti.

Il riavvio effettuato dopo il passaggio dei 5 minuti ci solleva dal problema della connessione che ritorna dopo un tempo lungo ( o che non torna proprio). In sintesi se io provo a collegarmi ma la rete torna dopo molto che io proseguo con questi tentativi il modulo non riesce in ogni caso a collegarsi. Per effetto del riavvio, invece, il modulo torna ad essere in grado di effettuare un collegamento.

Qui il download dello sketch di esempio modificato in modo tale da presentare le diverse opzioni possibili per la connessione alla rete caduta. Spero sia abbastanza chiara.

Nel caso di un datalogger l’operazione di connessione e upload dei dati salvati su un sito viene effettuato solo nel momento in cui un eventuale sensore di movimento ci avvisa che siamo fermi. La ricerca della rete wifi continua finchè il movimento non riparte oppure finchè non mi collego veramente.

Ai prossimi articoli la spiegazione dei problemi e delle scelte effettuate per lo sviluppo di un datalogger.

 

 

Daniele Ruffo