Non molto tempo fa ho scritto un articolo sull’utilizzo di Arduino come telecomando infrarossi e su come utilizzare un qualsiasi telecomando per controllare Arduino. Il lavoro era cominciato con la mia volontà di controllare un climatizzatore Daikin (modello ftxs25k2v1b – telecomando arc466a6). Prima di adedntrarmi in complesse decodifiche ho cercato in rete ed ho trovato questo tutorial in cui viene utilizzato Arduino ed una versione appositamente modificata della IR Remote. Quel tutorial lo troverete ripubblicato in un sacco di siti ed il disegno del telecomando è identico al mio, per cui pensavo di poter utilizzare quel tutorial per i miei scopi. Peccato che invece non funziona, ho infatti scoperto che la codifica usata dalla libreria modificata è del tutto incompatibile con la mia per cui ne deduco che diversi prodotti Daikin usano differenti protocolli infrarossi. In rete non si trovano molte informazioni, le uniche note tecniche che sono riuscito a trovare sono queste e queste. Le seconde non hanno nulla a che vedere con la codifica del mio telecomando, motivo per cui posso ritenere che i protocolli di trasmissione Daikin sono almeno tre. Le prime invece mi sono state molto utili in quanto sono in gran parte compatibili con quanto ottenuto con il mio telecomando. Vi informo sin da ora che il lavoro è ancora incompleto, sono infatti riuscito a ricevere ed interpretare correttamente la sequenza IR inviatami dal telecomando, ma attualmente non sono ancora riuscito ad usare Arduino per comandare il mio climatizzatore.

Analisi del segnale

Cercherò di non annoiarvi con troppi dettagli tecnici, ma ci tengo a sottolineare alcuni passaggi, giusto per comprendere quali sono stati i problemi incontrati in questo estenuante lavoro di decodifica e per aiutare chi si troverà a decodificare altri tipi di trasmissioni IR e si troverà ad affrontare i medesimi problemi. Se non siete interessati a tutto ciò, saltate all’ultima parte, vi scaricate la libreria modificata e la usate, se poi vi ricordate di fare un clik su una delle mie pubblicità non posso che ringraziarvi 🙂

Sinora non vi avevo mai assillati con i grafici ricavati dall’oscilloscopio, ma questa volta sono di grande utilità. Come vedete sulla sinistra della figura il segnale passa dallo stato alto di riposo ad una serie di repentini cambi di stato per un breve periodo per poi tornare allo stato di riposo. La libreria IR-Remote originale leggeva correttamente il primo pacchetto di dati, ma poi interpretava lo stato di riposo successivo come la fine della trasmissione in quanto la libreria è impostata per ritenerla conclusa dopo 5ms in cui non registra segnali. Peccato che in questa codifica Daikin ci sia uno spazio di 24,85ms motivo per cui ho dovuto ampliare quel limite. L’oscilloscopio è stato utile prorpio per questo motivo, infatti ho potuto calcolare il tempo da impostare e, cosa da non sottovalutare, ho scoperto che quanto veniva decodificato dalla IR-Remote (che d’ora in avanti chiamerò IRR) era solo una piccola parte di tutta la trasmissione. Se guardate successivamente, si vede che nella trasmissione ci sono altre due pause che sono ancora più lunghe, arrivando a 35,1ms, valori che mandano in crisi l’originale IRR. Ma i problemi non finiscono qui.

Vi faccio notare che si tratta di oltre 35000us, per cui fra le altre, la IRR  andava in crisi perchè memorizza i vari tempi in un int che come tale può memorizzare valori sino 32768. Per tale motivo ho dovuto usare un unsigned int. Altro problema è il numero di cambi di stato (585) che ha necessitato di un aumento del buffer e la modifica degli indici di indirizzamento visto che si trattava di un char che può arrivare solo fino a 256. A loro volta ho dovuto modificare le routines che gestiscono queste variabili per far si che funzionassero correttamente. L’aumento della memoria usata fà si che Arduino Uno non sia in grado di gestire il codice, per tale motivo sono stato costretto ad usare una Mega per procedere con lo sviluppo. Sinora non mi era mai capitato di avere problemi di memoria visto che ho sempre creato piccoli progetti dimostrativi non particolarmente esigenti di risorse. Purtoppo però Arduino Uno ha solamente 2K di memoria RAM per cui il solo buffer per tenere 585 interi occupa 1170bytes che sono oltre la metà di tutta la memoria disponibile. Ho cominciato perciò un lavoro di revisione del codice per ridurre l’occupazione di memoria sia flash che ram. In particolare ho pensato ad una cosa elementare che può far risparmiare un sacco di risorse. A meno che non siate interessati ad un circuito di pura decodifica dei segnali IR, normalmente sfrutterete una o poche codifiche per cui perchè usarle tutte? Ho inserito tutta una serie di #define per cui è sufficiente commentare quelli che non ci interessano per risparmiare il relativo codice. Ad esempio se lasciamo la #define USE_SAMSUNG avremmo il supporto alla codifica Samsung, altrimenti non viene compilata e non sarà possibile decodificare ed inviare con tale codifica. Nel caso alcune codifiche utilizzino specifici buffers, anche questi vengono inibiti riducendo il consumo di RAM. Al momento in cui vi scrivo c’è ancora molto lavoro da fare e non so se la versione comprensiva di tutte le codifiche possa girare sulla Uno classica, ma dopo la cura dimagrante sono riuscito a decodificare i codici Daikin anche sulla Uno. Per darvi un’idea dei vantaggi, la sketch che uso per il debug sulla mega con le sole codifiche Daikin e Samsung occupa 11870bytes e mi lascia 5972bytes di RAM libera mentre la versione con tutte le codifiche occupa 16014 bytes (+4144) e lascia 5620bytes di RAM liberi (-172).

Ma continuiamo con l’analisi del segnale. Come facciamo ad estrapolare i bit da quel “saliscendi” continuo? Visto che il segnale passa repentinamente  da uno stato alto a basso e viceversa, non può essere certo il livello logico a decidere quando si tratta di zero piuttosto che di 1. Infatti ciò che codifica il bit trasportato, in questo protocollo, è lo spazio, ossia il tempo che passa fra un impulso e l’altro. Nella figura qui sotto vediamo parte dei segnale visto sopra con una scala diversa che permette di vedere meglio le diverse spaziature fra i segnali:

Se aprite l’immagine per vederla nelle dimensioni originali, noterete che ci sono impulsi più brevi ed altri più lunghi. Quelli lunghi corrispondono all’1, quelli brevi allo 0. Le spaziature “non standard” delimitano i vari blocchi della trasmissione. Se riguardiamo un attimo la prima figura, notiamo che ci sono tre blocchi di dati, i primi tre sono sequenze di inizializzazione che sono sempre uguali mentre l’ultima contiene i dati veri e propri.

Dati…quali dati?

Bella domanda. Se prendete un telecomando di un televisore qualunque, quando premete un tasto questo invierà, indipendentemente dal tipo di codifica, un codice che corrisponde a quello specifico pulsante. Il televisore interpreta il codice ed agisce di conseguenza. Ora pensiamo al nostro climatizzatore. Facciamo finta che sia impostato a 20 gradi. Prendiamo il telecomando e lo portiamo in un’altra stanza, portiamo la temperatura a 25 gradi, ma anche se sul display compare la scritta 25C°, il climatizzatore continua ad andare a 20 perchè essendo fuori portata non ha ricevuto la trasmissione del telecomando. Ora torniamo nella stanza del climatizzatore e alziamo di un’ulteriore grado. Se il telecomando inviasse solo il codice del tasto il climatizzatore direbbe: “bene, vuoi che aumento di 1, io sono a 20 per cui mi imposto a 21°. Invece no, il climatizzatore si setterà a 26 gradi, proprio come scritto sul display. Questo esempio dovrebbe farci capire che ogni volta viene inviato lo stato di tutte le funzioni, ossia accensione, temperatua, modalità, velocità della ventola, direzione delle alette etc..

Qui sopra vi ripropongo lo schema precedente con alcuni commenti. La prima sequenza è composta da 5bit tutti impostati a 0. La sequenza A è composta da: 0x11, 0xDA, 0x27, 0x0, 0xC5, 0x10, 0x0, 0xE7. La sequenza B è invece composta da: 0x11, 0xDA, 0x27, 0x0, 0x42, 0x25, 0x14, 0x8D. Dalle prove che ho effettuato queste tre parti sono sempre uguali, perciò hanno solo il significato di sequenze di inizializzazione. Purtroppo non ho la possibilità di fare prove con apparecchi diversi, è infatti plausibile che la sequenza possa cambiare al combiare del modello di climatizzatore. La parte più importante è la C, ma ovviamente è la più complessa. Rispetto a quano descritto nel link allegato agli inizi ci sono delle differenze per cui ho l’ennesima impressione che ci siano numerosi protocolli con differenze più o meno marcate. Vediamo com’è composta questa importante porzione di codifica.  Ci tengo a precisare che alcuni parametri li ho testati personalmente, altri li ho copiati dal forum che vi ho linkato. Per semplicità i bit segnati partono da 0, ignorando la parte di inizializzazione già vista:

0-39: 0x11, 0xDA, 0x27, 0x0,0x0 (vi faccio notare che i primi 3 byte sono identici alle fasi di inizializzazione)

40: ON-OFF: indica lo stato di accendimento o spegnimento generale del climatizzatore.

41: On timer: 0 spento, 1 acceso

42: Off timer: 0 spento, 1 acceso

43: ? Impostato ad 1, ma in rete avevo trovato zero : non ne conosco il significato.

44-47: Modalità di funzionamento: 0 – auto, 2 deumidificatore, 3 climatizzatore, 4 pompa di calore, 5 ventilatore

48-55: Temperatura in gradi celsius moltiplicata per due (25 gradi saranno rappresentati con 50). In modalità deumidificatore è impostato a 0xC0

56-63: 0x0

64-67: osclillazione verticale: 0 – spenta, 1 – accesa.

68-71: Velocità della ventola: 3: Fan1 – 4: Fan2 – 5:Fan3 – 6:Fan4 – 7:Fan5 – 0xA:Auto – 0xB:Modalità notturna (in modalità deumidificatore la ventola è in modalità automatica).

72-75: osclillazione orrizontale: 0 – spenta, 1 – accesa.

76-79: 0x0

80-91: Minuti “on timer” (altrimenti 0x0)

92-103: Minuti “Off timer” (altrimenti 0x0)

104: Modalità Powerfiul: 0 spenta, 1 accesa

105-108: 0x0

109: Modalità silenziosa: 0 spenta, 1 accesa

110: 0x0

111: Modalità “home leave”: 0 spento, 1 acceso

112-127: 0x00, 0xC1 (nel forum è riportato 0xC0)

128: 0x0

129: Attivazione sensore di presenza: 0 spento, 1 acceso

130-143: 0x0

144-150 (??) = Simple checksum of all 144 previous bits

Non prendete quanto sopra per oro colato, quasi certamente ci saranno degli errori. In particolare ho un problema proprio negli ultimi bit dove risiede il checksum. Nell’articolo che ho preso a riferimento è scritto che da 144 a 151 c’è un byte che rappresenta la semplice somma dei 144 bit precedenti, purtoppo però io ho solo 7bit (fino 150) e non sono riuscito a comprendere il meccanismo con cui viene fatta la somma. Di fatto la libreira da me modificata è in grado di riconoscere una sequenza inviata da un telecomando Daikin ma non è ancora in grado di inviarne una. O meglio, ho scritto una funziona rudimentale di invio di una sequenza fissa che viene correttamente interpretata da un’altra scheda Arduino ma non dal mio climatizzatore. Potrebbe essere legato ad un errore di checksum ma non ne sono sicuro.

Anche se il lavoro non è completo vi allego la libreria in modo che possiate usarla e farmi avere i vostri commenti su quanto riuscite a “risparmiare” in ram / flash nei vostri progetti rispetto la IR_Remote originale. Se poi qualcuno ha un climatizzatore come il mio ed ha competenze / voglia di cimentarsi nel decodificare l’ultimo anello mancante è il benvenuto, a tal proposito allego anche un foglio elettronico in formato ods in cui c’è la decodifica di 15 trasmissioni nelle quali varia unicamente la temperatura (primo numero in rosso, da 18 a 32). Vi ricordo che nel file IR_Remote.h ci sono i #define da commentare o decommentare per l’attivazione o disattivazione sia del DEBUG che delle varie decodifiche. Di base è attivato il debug con decodifiche Samsung e Daikin.

IR-Remote prebuild with partial Daikin support IR-Remote Daikin prebuild (1599 download )

Daiking IR decode  Daikin decoding spreadsheet (1505 download )