PIC talks UART on IR

PIC talks UART on IR

 

Overview

When talking about infra-red communication my first thought goes to TV remote controls, my second to IrDA. This article is about the remote control type of infra-red which provides the physical layer on top of which one must build the rest of the communication. IrDA is a complete stack and albeit being used for similar purposes, it requires different devices and considerations compared to what we will see in this article.

The very nature of infra-red dictate the boundaries of its implementation. Just as with visible light the communication happens by either direct line of sight but also by reflection.

One tip to overcome the limitations imposed by the line of sight is to provide more than one transmitter installed at different angles so as to cover wider angles or install a matte material in front of the receiver to help increasing its operating angle.

The wave length ranges from 700 nm to 1 mm. Within this range there are further subdivisions. Our components work in the Near Infra-red part or NIR  which spans from 750 nm to 1400 nm.

For this article we will use two sensors from iNex.

One of the useful tips when dealing with infrared is to use a CCD or CMOS sensor in order to make the infrared visible to us. Using your phone will do the job just fine but why can it render “the invisible” visible on its display? Well it turns out that it is a rather interesting reading. Have a look at Icarous82 answer on this forum and the spectral response of some cameras to which he also provides a link to.


  The communication

In order to carry our information over infra-red we then need to modulate it over a carrier wave.

Infra-red is a radiation that is strictly linked with temperature. As such there are normally many sources of infra-red in any given environment and we need to be able to filter out all the ones we are not interested in. Our sensors are set to work with modulated signals so as to make sure that the sender signal is made “extremely interesting” to the receiver.

As you can appreciate from the block diagram off of a Vishay datasheet, the sensor incorporates a demodulator and a filter which is set to a specific frequency. In our case 38 kHz.

Phototransistor Block Diagram
Phototransistor Block Diagram

In order to carry our information over infra-red we then need to modulate it over a carrier wave. The 38 kHz signal needs to be generated at the sender side and our data will piggy back onto it until it gets to the receiver. The phototransitor at the receiver demodulates the incoming signal and strip the carrier from the data. From then on the receiver will work as a plain UART like in our main article.


 The Circuit

The circuit below includes two NAND ports off of an —– which are used to modulate the signal onto the carrier wave.

PIC-Talks-UART-IRBelow a picture of the two iNex modules and the breadboard I used to take the measurements.

The IR module and the breadboards
The IR module and the breadboards

The Code

The TX part of our program will be very similar to the one of the main article, the major difference is given by the instructions that will be used to configure and generate the 38 Khz carrier wave for our “Hello, world!”. The other minor difference is about the baud rate which needs to be set to 4800 bps because the modules are not designed for anything higher.

The 38 Khz signal is generated via the Pulse Width Modulation which is a technique used to switch on and off a signal off pin RC2 to generate the square wave we need.

void main() {
  ANSEL  = 0;                     // Configure AN pins as digital
  ANSELH = 0;
  C1ON_bit = 0;                   // Disable comparators
  C2ON_bit = 0;
  
  PWM1_Init(38000);               // Initialize PWM1 module at 38KHz

  UART1_Init(4800);               // Initialize UART module at 4800 bps
  Delay_ms(100);                  // Wait for UART module to stabilize

  while (1) {                     // Endless loop
        PWM1_Start();                        // Start PWM1
        PWM1_Set_Duty(100);                  // Set duty cycle
        
        UART1_Write_Text("Hello, world!");   // 0x48 0x65 0x6C 0x6C 0x6F 0x2C 0x20 0x77 0x6F 0x72 0x6C 0x64 0x21
        UART1_Write(10);                     // 0x0A
        delay_ms(1000);                      // Wait a bit
        UART1_Write_Text("From 0xEE.net");   // 0x46 0x72 0x6F 0x6D 0x20 0x30 0x78 0x45 0x45 0x2E 0x6E 0x65 0x74
        UART1_Write(10);                     // 0x0A
        delay_ms(1000);                      // Wait a bit
  }
}

Here you can fin the full TX code and the RX code for MikroC


The Results

The only part which seemed interesting showing was the one from the logic analyser point of view as it gives a nice representation of the various stage through which our signals get eventually mixed together to produced the 38 Khz modulated signal that we are sending to the receiver.

Signals through the NAND ports
Signals through the NAND ports

Logic analyser

To highlight each signal I have chosen the same colours on both the diagram above and the logic analyser (it was a poor choice of colours on hindsight)

Bitscope-LogicBelow is the signal as coming out of TX on PIC1

Bitscope-Logic-UARTIt then needs to be inverted by going through a NAND which we use as a NOT by fixing on input to 5V

Bitscope-Logic-InvUARTRC2 generates the 38 Khz carrier wave

Bitscope-Logic-Carrierand both the inverted signal and the carrier wave, get mixed together on another NAND port to produced our 38 Khz modulated UART

Bitscope-Logic-Modulatedwhen going through the filter within the module at the receiver end, the signal returns plain and simple as the red one above and can be applied to pin RC6 of PIC2 without any further manipulation.


 

LCD output

Sure enough the LCD on PIC2 will show our familiar message.

"Hello, world!" on the LCD
“Hello, world!” on the LCD

This article does take into considerations any method to filter out interferences which in wireless communications are to be always accounted for. The following picture shows a message displayed whilst I was using another IR remote just to confuse the receiver.

Wrong message consequence of interference
Wrong message consequence of interference

Final thoughts

IR communication is quite fun, many devices use this method which is cheap and reasonably reliable, It will allow your projects to free from wired umbilical cords and inspire countless hacks like the following from Kerry D. Wong

Reverse Engineering the Syma S107G IR Protocol

With any wireless type of communication though interferences and signal degradation are to be expected and will affect your projects much more frequently than wired links will. To deal with error detection and error correction you might want to consider including ad-hoc algorithms or implement some of the standard ones. Chas was suggesting looking at  High-Level Data Link Control (HDLC) or Hamming code both of which could be right for anything as tiny as 8 bit microcontrollers.

As always we hope the article was helpful.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.