[RISOLTO] Infrarossi: ho una stringa di bit, SO COSA FARCI ora :-)

International Italiano Generale
1

Ciao a tutti,
grazie ad un sensore IR opportunamente collegato al mio fido arduino (e seguendo questo link: Arduino Playground - InfraredReceivers)
ho captato il segnale emesso da tasto di un telecomando IR. Ora ho la stringa di bit:
0 0
128 0
128 1
232 1
232 0
1372 0
1372 1
1684 1
1684 0
1824 0
1824 1
1924 1
1924 0
3064 0
3064 1
3384 1
3384 0
3516 0
3516 1
3620 1
3620 0
3900 0
3900 1
5068 1
ecc ecc.

Però ora non ho ben chiaro come fare per farla riprodurre all'arduino. Ho già in mente lo schema per collegare l'emettitore IR all'arduino ma non so come scrivere lo sketch per farlo..mi aiutereste?

grazie!

RISOLTO
Per la soluzione vedere questo post:

2

scusa l'ignoranza :slight_smile: cosa identifica il numero a sinistra?

3

quella libreria ti da come risposta i tempi di cambia stato. Usa la libreria A Multi-Protocol Infrared Remote Library for the Arduino
Ciao Uwe

4

Puoi postare per piacere tutta la sequenza di bit? :slight_smile: Voglio solo verificare una cosa :slight_smile:

5

uwefed:
Usa la libreria A Multi-Protocol Infrared Remote Library for the Arduino

Quoto: non perder tempo, usa questa libreria e amen.

6

Stavo pensando una cosa, nel caso non si riuscisse con la libreria di ken shirrif, si potrebbe analizzare la sequenza di bit per trovare un pattern preciso, che corrisponde alle tempistiche del telecomando, a quel punto si possono memorizzare i codici anche dei telecomandi sconosciuti :slight_smile:

è un lavoraccio ma sono curioso di vedere se funziona, quindi rinnovo la richiesta, puoi postare per piacere tutta la sequenza di intervalli che ti ha dato il tuo programma? magari registrata dalla pressione di un tasto per almeno 5 secondi :slight_smile:

7

Tobo:
è un lavoraccio ma sono curioso di vedere se funziona, quindi rinnovo la richiesta, puoi postare per piacere tutta la sequenza di intervalli che ti ha dato il tuo programma? magari registrata dalla pressione di un tasto per almeno 5 secondi :slight_smile:

eccola:

Analyze IR Remote
Waiting...
Bit stream detected!
0    0
140    0
140    1
236    1
236    0
1436    0
1436    1
1692    1
1692    0
1844    0
1844    1
1924    1
1924    0
3120    0
3120    1
3388    1
3388    0
3528    0
3528    1
3624    1
3624    0
3964    0
3964    1
5092    1
5092    0
5220    0
5220    1
5320    1
5320    0
5664    0
5664    1
6780    1
6780    0
6912    0
6912    1
7020    1
7020    0
7356    0
7356    1
8464    1
8464    0
8608    0
8608    1
8712    1
8712    0
9048    0
9048    1
10176    1
10176    0
10304    0
10304    1
10404    1
10404    0
10756    0
10756    1
11868    1
11868    0
12000    0
12000    1
12100    1
12100    0
12444    0
12444    1
13556    1
13556    0
13692    0
13692    1
13796    1
13796    0
14992    0
14992    1
15248    1
15248    0
15388    0
15388    1
15488    1
15488    0
15828    0
15828    1
16948    1
16948    0
17080    0
17080    1
17188    1
17188    0
17520    0
17520    1
18636    1
18636    0
18780    0
18780    1
18876    1
18876    0
19216    0
19216    1
27120    1
27120    0
27244    0
27244    1
27352    1
27352    0
28544    0
28544    1
28792    1
28792    0
28948    0
28948    1
29044    1
29044    0
30232    0
30232    1
30504    1
30504    0
30652    0
30652    1
30728    1
30728    0
31080    0
31080    1
32208    1
32208    0
32332    0
32332    1
32436    1
32436    0
32772    0
32772    1
Bit stream end!
8

Trisonic:
Quoto: non perder tempo, usa questa libreria e amen.

dunque, se uso lo sketch presente in quel link, ovvero questo:

#include <IRremote.h>

int RECV_PIN = 11;
IRrecv irrecv(RECV_PIN);
decode_results results;

void setup()
{
  Serial.begin(9600);
  irrecv.enableIRIn(); // Start the receiver
}

void loop() {
  if (irrecv.decode(&results)) {
    Serial.println(results.value, HEX);
    irrecv.resume(); // Receive the next value
  }
}

dal monitor mi escono una serie di "0" e nulla più...
come può essere?

9

Usa lo sketch irreceiver dump

10

Trisonic:
Usa lo sketch irreceiver dump

ora l'ho messo ma ottengo questo:

Could not decode message
Raw (48): -8050 100 -100 1100 -400 100 -100 1100 -400 100 -100 250 -1250 100 -100 200 -1300 100 -100 200 -1250 150 -100 250 -1200 150 -100 200 -1250 150 -100 150 -1300 150 -50 1100 -400 100 -100 250 -1250 100 -100 200 -1250 150 -100 250 
0
Could not decode message
Raw (48): -8000 150 -50 1150 -350 150 -100 1150 -300 100 -100 350 -1100 150 -100 300 -1200 100 -100 300 -1150 150 -100 300 -1150 150 -100 300 -1150 150 -100 300 -1150 150 -100 1150 -300 150 -50 300 -1200 100 -100 300 -1200 100 -100 300 
0
Could not decode message
Raw (48): -7950 150 -100 1150 -300 150 -100 1200 -250 150 -50 350 -1150 100 -100 350 -1150 100 -100 350 -1150 100 -100 350 -1100 150 -100 350 -1150 100 -100 350 -1100 150 -100 1250 -200 150 -100 350 -1100 150 -100 350 -1100 150 -100 300 
0

e non ci capisco un granchè... :fearful:

11

Il tuo telecomando usa un protocollo che non è supportato dalla libreria (la libreria ne supporta 3 o 4).... probabilmente è uno delle centinaia di protocolli che ogni produttore implementa.
Non ti resta altro che leggere bene la documentazione postata sul sito: A Multi-Protocol Infrared Remote Library for the Arduino

Ad esempio cito:

Handling raw codes
The library provides support for sending and receiving raw durations. This is intended mainly for debugging, but can also be used for protocols the library doesn't implement, or to provide universal remote functionality.

The raw data for received IR measures the duration of successive spaces and marks in 50us ticks. The first measurement is the gap, the space before the transmission starts. The last measurement is the final mark.

The raw data for sending IR holds the duration of successive marks and spaces in microseconds. The first value is the first mark, and the last value is the last mark.

There are two differences between the raw buffers for sending and for receiving. The send buffer values are in microseconds, while the receive buffer values are in 50 microsecond ticks. The send buffer starts with the duration of the first mark, while the receive buffer starts with the duration of the gap space before the first mark. The formats are different because I considered it useful for the library to measure gaps between transmissions, but not useful for the library to provide these gaps when transmitting. For receiving, 50us granularity is sufficient for decoding and avoids overflow of the gaps, while for transmitting, 50us granularity is more than 10% error so 1us granularity seemed better.

12

19216 0
19216 1
27120 1
27120 0

Credo che in questo momento il telecomando ricominci la trasmissione del segnale segue circa questo pattern:

l'unità di misura del tempo dipende dall'unità di misura usata nella lista che hai scritto sopra, i tempi che scrivo non sono precisi, ci vorrebbero più misurazioni del telecomando per fare una media:

il segnale è a 0 per 140 
il segnale è a 1 per 96 
il segnale è a 0 per 1200 
il segnale è a 1 per 256     e continua così 
152 
80 
1196 
268 
140 
96 
340 
1128 
128 
100 
344 
1116 
132 
108 
336 
1108 
144 
104 
336 
1128 
128 
100 
352 
1112 
132 
100 
344 
1112 
136 
104 
1196 
256 
140 
100 
340 
1120 
132
108 
332 
1116 
144 
96 
340
pausa di 7904

Bisognerebbe fare una media perchè quando il codice ricomincia i tempi cambiano di qualcosina :slight_smile:

13

ma che telecomando è?
io mi sono sbattuto come l'acqua di mare per tentare di decodificare il telecomando di un condizionatore, poi ho lasciato perdere per mancanza di tempo, ma era un incubo =(
Trasmetteva anche la data e l'ora per qualsiasi pressione di tasto oltre che tutto il resto della configurazione, anche solo per fare +1 alla temperatura.

14

Caspita! che treno di impulsi mandava quell'affare? :astonished:

15

sparava 256 bit con la pressione di un tasto che sembravano ogni volta diversi all'inizio.... poi ho scoperto che mandava anche l'ora con tanto di secondi! per quello che era sempre diverso.

16

ed erano essenziali per il funzionamento del condizionatore? cioè omettendoli non funzionava più?

17

Il mio telecomando in questione è un accendi-spegni luce e ventola del lampadario...
l'ho aperto e ho visto che tra i vari componenti c'è un chip marcato così: SM5021BL..

tra l'altro mi ricordo che quando avevo la "vecchia" tv LCD Sony da 32" se schiacciavo il tasto "2" del telecomando a volte si accendeva la luce del lampadario :slight_smile:

18

Hai letto il mio post nella prima pagina? :slight_smile:

19

si, erano essenziali perchè il condizionatore controllava la quantità di dati ricevuti.
Probabilmente il telecomando del ventilatore non usa nessun protocollo conosciuto e per questo non riesci a decodificare i tasti.
Quindi devi spostarti nuovamente sull'analisi raw dei dati e cercare sequenze ricorrenti alla pressione degli stessi tasti e poi scriverti un parser partendo da quelli.
edit:
nel datasheet dell'ic c'è spiegata la codifica
http://pdf1.alldatasheet.com/datasheet-pdf/view/124369/ANALOGICTECH/SM5021B.html

20

Tobo:
Credo che in questo momento il telecomando ricominci la trasmissione del segnale segue circa questo pattern:

l'unità di misura del tempo dipende dall'unità di misura usata nella lista che hai scritto sopra, i tempi che scrivo non sono precisi, ci vorrebbero più misurazioni del telecomando per fare una media:

il segnale è a 0 per 140

il segnale è a 1 per 96
il segnale è a 0 per 1200
il segnale è a 1 per 256     e continua così
........
pausa di 7904




Bisognerebbe fare una media perchè quando il codice ricomincia i tempi cambiano di qualcosina :)

Scusa Tobo ci stavo ragionando su ma ancora non mi è chiaro... :blush:
stanotte ci penserò su...