Introduction

I completed this design a number of years ago when I was still learning to program.  In fact, this was my first “proper” project that I directed my new-found programming skills towards.  My programming skills have improved by many orders of magnitude since, and with that in mind I was a bit ambivalent about whether to put this project up on my site.  I only like to showcase my best work, and although this really was my best work back in 2009, it’s nowhere near up to my current standards.

That said, I constantly find myself receiving emails from people who want to have a copy of the code and/or PCB design files.  It seems I’m not the only one who is intrigued by IR communication methods.

I have therefore decided that I will publish this old work on my site for the benefit of others who are also learning.  The information is a literal copy of the original article I wrote for a very old version of my website, back in the days when I used to hand code the HTML.  I have simply copied and pasted the information into this post.

Known Problems:

1. The code for the LCD and the RC5 decoding is mixed in to one C file, although obviously they are separated into their own relevant functions.  These should ideally be made into their own libraries, particularly the LCD code.  I have in fact used the LCD code in other projects and during that time I have made huge improvements to it and I’ve made it into my own library.  The LCD code provided in this project is basically a skeleton solution, suitable for this particular application but not a lot else.
2. In practice I found this version of the LCD code to be a bit hit-and-miss.  It works fine with the LCDs stated in the BOM, but when I tried it with other LCDs it sometimes worked and sometimes didn’t – so bare that in mind.
3. The RC5 decode solution provided here analyses the RC5 data stream in real time, bit-by-bit, as it is received by the IR receiver.  There is some error detection that throws out the stream if it is not deemed to conform to expected RC5 standards, but you might want to have a play with this.  In practice I found it to be reliable with a number of different RC5 remotes.
   A better solution to this problem is to do a post-analysis on the received data.  That is the technique being employed by version 2 of my RC5 decoder, which is currently in development as a kind of side project that I work on every now and then.
4. The IR receiver listed in the BOM is very important because it filters out ambient noise.  The code relies upon that.  If you try to use a simple IR LED to detect an RC5 stream you will experience noise problems because the code is not designed to account for it.

What is an RC5 Decoder?

If you’re a computer geek, you might think I’m claiming to have built a project that decrypts the RC5 block cipher. I wish that were the case, and indeed if it were I’d certainly be earning a lot more money than I am now! But alas, this project refers to a much simpler idea – the RC5 protocol for wireless (infra-red) communication. If you’ve used a television remote control before, then it’s quite possible that you’ve used one that transmits RC5 coded commands. In that case your television will be acting as an RC5 decoder; receiving the infra-red data stream from your remote control, decoding it and acting upon the command it has received.

The project described here can receive an RC5 coded infra-red data stream, decode it, and display the address, command and toggle data on an alpha-numeric LCD.

Why?

What is the point of this project? Well for me it was an educational experience. I had been busy learning assembly and C for PIC Microcontrollers and, whilst I had already written a number of experimental programs to help with my education, this was my first attempt at a complete microprocessor based project. Thus, this project served no other purpose than academic value. In practice, though, you could use this project in any application that requires remote control of equipment via infra-red communication. I have used my decoder firmware to display information about the commands that were received, but the project software could be easily modified to act upon the commands that are recieved and control practically anything you want with it. If you do create something useful/interesting with this project, please let me know!

RC5 Explained

The heart of this project is based upon receiving and decoding an RC5 data stream. So, I guess the first question to ask is: “what does an RC5 data stream look like?” A second one might be: “how does it work?” and a final one would be: “how can I decode it?”. These are all questions I had to ask of myself before I could come up with a working design, and hence this section shall answer those questions.

• What does RC5 look like?

Firstly, to find out what an RC5 data-stream looks like, you can employ one of two techniques. Either you can try to find some written reference to an RC5 data-stream, or you can try to measure one. I did both. For written references, google is your friend. You will find that I am not the first Electronics hobbyist to try to decode an RC5 data-stream – far from it in fact. Plenty of other Engineers/hobbyists have done this before! That said, I haven’t yet found anyone else who has designed a solution using the C language so if C is your poison you’ve probably come to the right place.

If you do take the time to trawl google results you’ll probably do well to find a diagram better than this one:

This diagram was found at davshomepage and I think it is a good rendition of the RC5 protocol. This particular diagram is showing the following information:

• Start Bits: 11 (these are always logic 1)
• Toggle: 0
• Address: 00000
• Command: 000001

It also clearly shows the timing for a single RC5 encoded bit, as well as the timing for one full transmission in its entirety. If the logic levels look a bit weird to you, it’s because they’re Bi-Phase (Manchester) encoded. We’ll get to that later.

So that’s pretty much answered the first question, “what does RC5 look like”, but just for completness I’m going to show you what it looks like if you try to measure it. In order to do this experiment, I purchased an IR receiver device sensitive to 36Khz (because RC5 uses 36Khz modulation) with a demodulator built inside. You can receive the stream using a simple photodiode if you want, but then you’re going to have to demodulate it and you’ll need to concern yourself with other problems such as gain control and noise reduction etc. You can buy very small modules that have all of these features built in, so my opinion is why burden yourself with the hassle? Don’t reinvent the wheel, life is too short! The little module I used was a TSOP2236 which you can buy readily from Farnell.

All you need to do to start experimenting with one of these devices is to connect it up to a power supply and you’re good to go. If you read the datasheet it’ll start telling you about using pull-up resistors and connecting some capacitive filters etc, which is all very relevant and important to include in your final design but for the purpose of just playing around and experimenting you don’t need any of that stuff – power connections are all you need to do.

So, with some power connections made (I’d show you a picture but what’s the point – it really is that simple) we’re ready to receive an RC5 data stream. All we need now is an RC5 generator. For this I used an old Philips Universal Remote Control set up for TV and VCR modes. Philips designed the RC5 protocol, so most of their older equipment uses it. I also experimented with a universal remote application for Windows CE and that worked fine as well. You need to be a little bit careful here because your IR receiver package will receive your datastream regardless of the protocol – it won’t care whether it’s RC5 or not. It’s easy to recognise an RC5 protocol though, just compare it to the diagram on the previous page, paying particular attention to the start-bits and the number of bits in total. The data stream should also be Manchester Coded (or bi-phase coded, same thing). What’s Manchester Coding? We’ll get to that in the next section.

So, with the RC5 generator to hand and my IR module connected up to a power supply, I just need to press a button on the remote control and the IR module should recieve the infra-red light, demodulate the data stream, and output a manchester coded packet of data on its output pin. To see this, we need to connect the output pin to a Digital Storage Oscilloscope. If you don’t have one of these then you’re not going to be able to do the experiment yourself, but you don’t really need to unless you’re particularly interested – just check out my results on the next page!

This is what an RC5 Data Stream looks like if you measure it. I captured this shot using the Single Sequence Aquisition mode on my Tektronix DSO. To generate the RC5 I used an old Universal Remote Control set to VCR mode. I happen to know from previous experiments that a VCR remote is assigned Address number 5, so if you decode this stream (I’ll show you how next) you’ll find that the address is indeed 05. Also, I pressed number “8” on the Remote and, again from previous experience, I have found that the numbers 0 – 9 on the keypad are encoded as Data 00 – 09 respectively.

San Bergmans has compiled a small list of some RC5 codes on his website here. The list is by no means exhaustive, but it gives you the general idea. In addition to San’s listed codes, there are also codes for satellite receivers, CD players, and lots of other stuff. I have found through my studies that the RC5 protocol is not fully populated (i.e. not all of the possible addresses / commands have been used) so it is possible to make up your own little address and command codes to control your own equipment, without fear of inteference with other commercial products.

San’s site is also a good reference if you’re hoping to learn more about the RC5 protocol or indeed any of the other Remote Control protocols that exist!

This shot is merely a close-up of the data on the previous page, using the zoom function on the instrument. The zoom function is quite handy for seeing the fine details of your aquisition, and I used it here to zoom in on one single bit of the Manchester encoded data.

The RC5 protocol specifies that one single bit should be 889uS long but in practice, with my Remote Control, I found that it actually measured 812uS (see the cursor readings on the right hand side of the image), which is approximately 10% outside of that which the protocol specifies. This has implications for the design of an RC5 Decoder, because it means that the system will need to measure the length of a single bit of the encoded data, to account for inaccuracies in the RC5 generator. Thanks to Manchester Encoding, this is actually quite easy. The whole point of Manchester Encoding is that it is self-clocking. This is what I’m going to talk about next, and in the process of talking about Manchester Encoding it’ll become clear how the RC5 data can be decoded.

• How do I decode RC5?

Now, to answer that question it’ll be necessary to talk about Manchester Encoding. Once the details of Manchester Encoding are understood, it will then be quite a simple task to analyse an RC5 stream and see how it might be decoded. We’ll do this later using the stream I captured on previous pages, and see if we do indeed arrive at Address: 05, Data: 08. Once all of this has been understood, we are then presented with the problem of how to accomplish the decoding task using an Electronic solution. I came up with a software based solution which I shall present later on!

Manchester Encoding

Before I get into Manchester Encoding, I want to illustrate the problem that arises when your data stream is not Manchester Encoded.

Usually, digital data communication requires at least two separate lines – clock and data. The clock line is required for synchronisation purposes, so that the receiver knows when to sample the incoming data. For example, suppose I were to transmit an 8-bit data stream comprised of the data, “10001100“. This data stream might look something like that illustrated below:

Now, it’s not immediately obvious that the data above is equal to 1001100 is it? That’s because you don’t know where the data starts or where it ends, or even how long a single bit is. It would seem that the first logic 1 is a single bit, but how do you know? It could be 1, 2 3, or any amount of bits long. And, if we accept for the moment that it is 1 bit, then is that a logic 0 at the start? Or does the data start with the logic 1? And where does it end – how many logic 0’s are there on the end of that stream?

To make matters worse, what if I were to transmit 00000000? That’s a perfectly valid data stream, but without any kind of synchronisation technique (a clock) your only option for data recovery would be to agree a communications speed up-front with the transmitter.  In fact, some communications protocols do exactly that! RS232, for example, relies upon us both agreeing – transmitter and receiver – that we’ll talk at a certain BAUD rate before we can exchange any data.  After we’ve agreed the BAUD rate, we each have to trust the other’s internal clocks to be stable and accurate, so that 9600 BAUD means the same thing to me as it does to you.  Communication in this manner works for small data packets.

In regular wired data communication busses, a clock line is normally included so that you know where to sample the line in order to recover the correct data. Data is either sampled on the rising edge or falling edge of the clock, depending on how the system has been designed. To illustrate a rising edge system, see the diagram overleaf which shows how the above signal could be sampled and recovered using a clock signal.

Recovering Data with a clock

The following diagram shows how the previous data is recovered using a clock signal:

With the addition of the clock signal it is suddenly easy to reconstruct the data. Data is only sampled on the rising edge of the clock line, and in this manner the original data (10001100) is correctly reconstructed.

Manchester Encoding – A Self-Clocking Communications System

In order to get around the problems caused by long strings of logic 1’s or logic 0’s, where there is no clock to aid data recovery, a clever person came up with Manchester (also called binary phased shift) keying. I’m not actually sure who that clever person was – answers on an email!

In Manchester Coding, logic 1’s and logic 0’s are no longer represented by simple high and low voltages. Instead, they are represented by a rise in logic level and a fall in logic level respectively. This is illustrated below:

Note that in some systems this is the other way around – a logic 0 can be represented by the low to high transition and the logic 1 by the high to low. It depends how the system has been designed.

To see how this method effects the previous transmission data 10001100, the data below has been generated using Manchester Code logic levels:

If you trace through the above diagram, you should be able to see that the original logic 1’s and logic 0’s are represented by low-high and high-low transitions. If you’ve understood this correctly, then a little further thought should convince you that the problematic data stream described earlier (00000000) would now be transmitted as a long string of high-low transitions under the Manchester Coding scheme. The clock signal is easily extracted from a manchester coded transmission, even when there are long periods of logic 1’s or 0’s! Also, the start point and stop point of the transmission is more easily determined.

For these reasons, a Manchester Coded data stream is often refferred to as “self clocking”. No separate clock line is required under this scheme.