October 9, 2013

Building your own Infrared-controlled car, Part 1: Receiving infrared signals


Well, technically not a car, but a tracked vehicle. Here you can see it in action:

Now, why do I write about this? After all, you can easily build such a car purely from Lego parts! That is true. However, later on - when this vehicle is upgraded to something you could call a robot - I want to connect my own little computer and some sensors, and this is not really possible with pure Lego parts.

First, we need a remote. We could build our own, but the result would be rather clumsy, so we use an existing remote. I use the Lego IR remote, but in principle you could use your TV remote - which, of course, would not only control the car, but also still control your TV...

Before we can use the remote, we have to read out the infrared protocol used - we have to know what the remote sends when we press, say, button 1 on the remote. You might luck out and find a complete instruction set online for your remote, but this is no sure thing, and the work needed for the readout is basically the same work we have to do anyway to receive infrared signals at all, so it comes basically for free.

The infrared LED in the remote has two states: It is either plain off, or it will flash at a high frequency, typically 38 kHZ. It will flash for some time, then it is off for some time, then it will flash again. The message we want to send is either encoded into the time it flashes before turning off again, or - more commonly - into the time between two sets of flashes. The point of the flashing is that a 38 kHz flashing signal is much less likely to be of natural origin compared to non-flashing infrared light, which makes receiving less error-prone.

The most convenient way for receiving the signal is using a receiver IC like the TSOP312xx. There are several different ones, depending on the carrier frequency: The 31238 is for 38 kHz, the 31236 for 36 kHz and so on. The 38 kHz frequency is the most common one, and the TSOP31238 should also work for 36 kHZ remotes, with somewhat decreased range.

The TSOP has three pins, two of which are for the power supply. The third is for the output of the demodulated signal: If the IC sees the remote flashing, it will pull the output pin low; otherwise, it is high. On the output pin, we hence do not see the carrier frequency at all, which makes reading the signal much easier.

Now we can connect the TSOP to some microcontroller and measure when the output line goes low. I will use an Arduino since it is easy to connect to a PC. A bare AVR can also easily receive the signal, but getting the data onto your PC is more difficult. The setup looks as follows:

Not much to see here: The orange output line goes to pin 2 on the Arduino, which is the pin for the external interrupt 0, the other two wires are ground and 5 volt. You should check the exact wiring in the data sheet of your receiver - it may be different, and a wrong wiring will probably destroy the receiver. Also, you might want to add a capacitator over ground and 5 volt, but it works for me without. Whenever the output line goes low, the interrupt routine saves the time passed since the last interrupt or (in case of the Arduino code) just the time in microseconds since startup.

Below you find the sourcecode in plain C and for the Arduino; but you should be careful with the Arduino code: the interrupt routine has lots of overhead, and this seems to be the outer limit of what is achievable in this way - I crashed it a few times when the program had a longer interrupt routine, so this approach is probably out for use on the car since there the Arduino has to do other stuff as well.

The source-code in Arduino-speak:

volatile unsigned long timevalues[150];
volatile int i = 0;
int finished = 0;
void setup(){
   attachInterrupt(0, external, FALLING); 
   Serial.begin(9600); 
   Serial.println("starting program");
}
void loop(){

  if(finished == 0){
 if(i > 140){
   finished = 1;
   for(int j = 1; j < 140; j++){
  Serial.println(timevalues[j]-timevalues[j-1]);
     
       }
    
 }
  
  
}
}
void external(){
  //if(timecounter > 1){
    timevalues[i] = micros();
    i++;
 //} 

}
and in AVR-GCC:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
#define F_CPU 16000000UL
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

#define BAUDRATE 9600
#define BAUD_PRESCALLER (((F_CPU / (BAUDRATE * 16UL))) - 1)

//Declaration of our functions
void USART_init(void);
void USART_send( unsigned char data);





volatile int i = 0;
volatile int timecounter = 0;
uint8_t finished = 0;
volatile uint8_t timevalues[150];

int main(void){
 USART_init();        //Call the USART initialization code
 EICRA = (1 << ISC01); //interrupt on falling edge
 EIMSK = (1 << INT0); //enable INT0-interrupt
 TCCR0A = (1 << WGM01); //clear timer on compare match
 
 TCCR0B = (1 << CS01) | ( 1 << CS00); //prescaler 64
 OCR0A = 16; //one timer interrupt every 16 ticks of the clock, which here means every 64 microseconds
 TIMSK0 |= (1 << OCIE0A); //turn timer interrupt A on
 sei();
 while(1){        //Infinite loop
 if(finished == 0){
  if(i > 100){
   cli();
   finished = 1;
   for(int j = 0; j < 100; j++){
    USART_send(timevalues[j]);
    
   }
   
  }
 }
 
 
}

return 0;
}

ISR(INT0_vect){
 if(timecounter > 1){
 timevalues[i] = timecounter;
 i++;
 timecounter = 0;
 } 
}

ISR(TIMER0_COMPA_vect){
 timecounter++;
} 


void USART_init(void){
 
 UBRR0H = (uint8_t)(BAUD_PRESCALLER>>8);
 UBRR0L = (uint8_t)(BAUD_PRESCALLER);
 UCSR0B = (1<<RXEN0)|(1<<TXEN0);
 UCSR0C = (3<<UCSZ00);
}

void USART_send( unsigned char data){
 
 while(!(UCSR0A & (1<<UDRE0)));
 UDR0 = data;
 
}
The principle is the same both times: Wait for 100 received signals and then send the time intervals over UART. The output of the Arduino program is the time in microseconds between flashes; the output of the C-code (for which you will need a serial terminal, for example Realterm) is in 64 microseconds, i.e. a "10" means roughly 640 microseconds. The precision is still sufficient, and it saves memory and processor cycles.

Part of the output when I press 1 on my TV remote for the Arduino code is

13464 1124 1156 1100 1124 1156 1100 2240 1156 2216 2244 2240 2244 2244 2244 1152 2216 2244 1152 1128 1128 1100 1152 1100 1128 1152 2216 2248 2240 2240 2244 2244 2244 40312 11208 96448 11208 96452 11208 96452 11208 96448 11208 96452 11208 96452 11208 96452 11208 96448 11212 96448 11208 96452 11208 96452 11208 96452 11208 96452 11208 96448 11208 96452 11208 96452 11208 96452 11208 96452 11208 96452 11208 96448 11212

It uses the NEC protocol, and you will find all the numbers above also in the linked document. We start with a pause of 13 ms, signifying the beginning of the transmission. Then we send the code 00000010111111011000000001111111 - a 0 for the short pause of 1.1 ms, a 1 for the long break of 2.2 ms. Then the remote starts a "continue" pattern, which is also described in the link: This signifies the receiver that the button keeps getting pressed.

No comments:

Post a Comment