Tuesday, April 26, 2011

Making PCBs using presensitized boards

Here's my current procedure for making single-sided printed circuit boards. 

1. Draw the schematic and PCB layout. I use DesignSpark PCB since it's full-featured and free without any limitations whatsoever. Getting the layout right is the most time-consuming part. But it's all on computer so I really have no problem with this part of the work. In fact I kind of like it--optimizing a design on the drawing board is my kind of game.

Instead of (just) pouring copper all over the empty parts of the board, I put in as much relevant text including what it is for, creation date, what major ICs populate it, etc. Since I don't have the luxury of having a silkscreen on the component side, placing information on the copper side is a fairly good substitute.


2. Print PCB layout on transparency film. Since I'm using an inkjet printer, the transparency is one made specially for inkjet printers--one face of the sheet is rough to take on the ink. Scale of printout is of course is 1:1. This is very important. And to make sure that component lead pitch on the printout is correct it may be wise to print a draft copy on plain paper and check.

The printer is set to black-only printing. Contrast and other controls (eg. gamma) are set to maximize ink deposition and darkness. I'm using an Epson T10 and the print quality leaves much to be desired. It isn't solid black--there are minute cracks, gaps, lines which allow light to seep through. Because of this exposure time has to be at its minimum else copper traces will be compromised.


3. Cut the presensitized board to size if necessary. I use the score and snap method: Score both sides of the board where the cut will be made using an X-Acto type of knife. Use a ruler/straightedge as a guide for the knife. Run the knife several times to deepen the groove. Insert the board into or lay it underneath a thick book (I use a telephone directory) all the way until the score line. With one hand pushing down on the book, use the other hand to push down on the part of the board that's sticking out. If the scoring is deep enough, the cut should be fairly clean.

Peel off the protective backing. Center and secure the transparency film to the board. Do this under subdued lighting and as quickly as possible. There are various ways of securing the film to the board. Taping the transparency and board to a glass sheet is one, albeit crude, way of doing it. With my current setup I have a large foam sponge (approx 15" x 24") I use as a base on which the presensitized board is mounted (photoresist side facing up). I then lay the transparency on top of the board and align it. Printed side of film touches the presensitized side of the board. Next a large glass pane (3mm thick) goes on top. Finally the fluorescent lamp is placed on top of the glass. The lamp doubles as a weight to compresses the board-film-glass sandwich. The foam at the base evens out the pressure. Placing additional weights on the glass may be necessary because it's important that the transparency is firmly touching the photoresist for the traces/tracks and pads to be distinct.

4. Expose to UV light or fluorescent light or sunlight. Exposure time depends on light source, its intensity, and its distance from the board. It will usually be anywhere from a minute to ten minutes. With Kinsten phenolic paper single-sided boards and the 2 x 11-watt Toshiba daylight compact fluorescent lamp set up that I use with the lamps approximately 2 inches from the board, it takes between 1 to 2 minutes for boards less than 4x4 inches.

5. Develop the PCB until light-exposed photoresist is washed away. Agitate the developer and board while developing. If developer isn't included with the presensitized board when purchased, then one can make it by using a sodium hydroxide (NaOH) solution or better yet sodium metasilicate solution. If the board isn't underexposed, developing time will usually be under a minute.

6. Rinse developer off the board under running water.

7. Etch the board in a mixture of (by volume):
1 part tap water
1 part 6% (20 volumes) hydrogen peroxide (H2O2)
1 part 29% hydrochloric acid (HCl).
Etching time will depend on the thickness of the copper cladding. Etching will usually be complete within  three minutes. The etchant will turn green as the acid reacts with the copper and eats it away. The mixture is exothermic so expect it to get warm. Bubbles may also form. It's probably oxygen being liberated from the peroxide. 

8. Rinse etchant off the board under running water.

9. Drill holes into pads.

10. Remove photoresist from the the pads using Q-tips (cotton swabs) dipped in acetone. Photoresist on tracks and any copper pour area and anywhere where there won't be any soldering can be left on. After using a solvent to remove the photoresist the copper cladding may have to be further cleaned using a scouring pad to prepare the surface for soldering. 

11. Solder components to the board.


The great part about the etchant chemicals used above is that they're readily available in supermarkets, hardware stores and drugstores. I've chosen not to use ferric chloride not only because it can only be obtained from electronic parts and chemical suppliers but also because it's dark opaque color detracts from visually inspecting the progress of the etching process. The HCl+H2O2 mixture on the other hand is readily available, transparent, quick-acting, and cheap. I even use the spent mixture as toilet cleaner.

Safety notes: Sodium hydroxide and particularly hydrochloric acid are nasty stuff. You don't want them on your skin, your eyes, or making their way into your respiratory tract. Needless to say they are toxic when ingested. Here are safety guidelines that must be observed when using these substances:

* Always don protective eyewear, face mask, and gloves when using the chemicals
* Use only plastic (eg. polypropylene, polyethylene) containers for the chemicals and any implement that will come in contact with them
* Always pour water and H2O2 into a container first before adding HCl
* Always mix the chemicals outdoors or in well-ventilated area
* Dispose of them properly.


Some references which I found useful for PCB making:
http://www.youtube.com/watch?v=VtmWaxzgoK8
http://www.youtube.com/watch?v=RfelrrZyCYQ
http://www.rcexplorer.se/page14/page15/page15.html
http://www.foxhunt.com.au/misc/pcb/making_pcbs.htm
http://www.electricstuff.co.uk/pcbs.html

Saturday, April 23, 2011

Using the ICSP and T1OSx pins of the 16F1827

Am going to use the PIC16F1827 and the circuit needs a 32.768kHz crystal on the T1OSI and T1OSO pins. As it turns out the same pins are used for the clock and data lines of the In-Circuit Serial Programmer (ICSP) which will be needed as well. So I had to know whether I can have a crystal on the pins and still program the MCU via ICSP. I breadboarded a circuit and test shows there's no problem using the ICSP with a crystal and its capacitors on the pins.

However, I discovered that the crystal and timer1 will not work if the PICkit 2 programmer is left connected. Once removed the timer works fine.

Wednesday, March 30, 2011

DesignSpark PCB

Prototyping boards / stripboards are hardly the easiest way to make printed circuit boards. Because of the fixed pads and tracks it's impossible to optimize the layout, minimize board size, and eliminate the use of jumper wires to electrically join the components. In fact it's this latter "dis-feature" that drives me up the wall. Cutting short lengths of wire and soldering them onto the board is the kind of exasperating work that has made me stay away from making PCBs as much as I can. Personally I find it a pain in every part of the body using these boards. And for all the work the outcome is hardly pretty.

So graduating to "real" PCBs has been a relief. The only reason I've procrastinated is that when I tried Eagle years ago I just couldn't comprehend how to use it. Turns out that Eagle isn't the most intuitive EDA software. Kicad was another candidate recently, not least because it's freeware. But it made me tear my hair out as well. Fortunately I found one that's easy--almost fun--to use. DesignSpark PCB is completely free (for now at least) and has no restrictions on board size, layers, and other features. According to tests performed by some individuals, DS came out the winner amongst various EDAs (including Eagle and Kicad). I don't know how rigorous the tests were and how objective their assessment is, but personally I did find it relatively easy to get started. With DS I was able to produce my first PCB within a couple of days.

Apparently DS is a "non-crippled and modified version of Easy-PC." Moreover, another Easy-PC derivative, PCB Artist, is almost exactly the same as DS. What's so cool about the PCB Artist is that I've found a good number of video and pdf tutorials on their page. And practically all of what you can learn about PCB Artist applies directly to DS. Meanwhile, DS tutorials can be found right on software itself under the Help menu. At least one of the PCB Artist pdf tutorial is almost exactly the same as that of DS.

Most of the work in setting up DS will be customizing the component/schematic/pcb libraries. Even with the extensive number of parts from various manufacturers already in the libraries I've found myself adding more and more components and editing the pads of existing items in the pcb library. I've also realized that I waste a not insignificant amount of time shifting from one library to another so I'm copying the most often used components to my own library. I will be editing the schematic library as well--a lot of the symbols are not at all pretty.

Monday, March 14, 2011

Four-way traffic light

Scoured some 20 toy and collectibles stores in search of a model/toy traffic light that I can hack and modify. Not a single one had. Unbelievable! So over the week I painstakingly constructed my own 4-way light out of 12 LEDs, a pseudo-lego piece, the tube of a spent marking pen, an AA battery case, and wires of course. Used cyanoacrylate glue, hot melt glue, and epoxy to hold them all together. Spray painted it black all over.

Not pretty at all. It looks worse than any signal light in Japan after it'd been felled and drowned by this week's Sendai tsunami. Good thing my nephew didn't mind its looks. Just hope it's strong enough to withstand the temblors from a 6-year old.

A Microchip PIC 12F1822 is the brains controlling the lights. To minimize power consumption its internal clock is set to just 125kHz. (This baby is capable of running at 32MHz!). Three AA batteries provide the juice. No current-limiting resistors are used for the LEDs. Measurements show they're not needed for VDD up to 4.5VDC. Only four MCU pins are used to switch the LEDs. Charlieplexing is employed to turn one LED in each of the four directions for 4milliseconds every 16 milliseconds (25% duty cycle). That's a frequency of around 62Hz--enough to fool the eye into not seeing the LEDs switching on and off that rapidly.

The original design was to power it off two AAs, but tests revealed that even without current limiting resistors the PIC could only deliver 5mA to the LEDs which have forward voltages of 1.6 to 1.8V. Considering the duty cycle is only 25% the average brightness would be quite low indeed. One option of course is to install very high brightness LEDs. I've searched RS Components and found various candidates. A possible drawback is that a number of these superbright LEDs have very high forward voltages, meaning their output will probably dramatically fall off as the batteries are depleted.

The circuit doesn't have an on/off (slide) switch. Instead the MCU goes to sleep 10 minutes after the last button press. When asleep pressing the button wakes it up and the light resumes operation in whatever it mode it was in when it dozed off.

When the lights are on the tactile switch/button allows the user to cycle between four modes:

1. Lights for opposite directions are on simultaneously. That is, when North-South is red, then South-North lights are red too and when NS is green SN is green too. Likewise with East-West and West East.

2. Light is green only in one direction at a time. This implies that for the direction that's green left-turning vehicles and those going straight can simultaneously go.

3. Four-way flashing yellow, 0.8 second on, 0.8 second off.

4. Four-way flashing red, 0.8 second on, 0.8 second off.

Just for fun I was tempted to add a four-way flashing green albeit at a much faster blink rate (say, 2 to 4 Hz). Would allow my nephews to have cars from all directions crashing into each other and getting a pile up. But I eventually scratched that idea--it's not a good way to train future drivers :)

Green stays on for 15 seconds, yellow for 2 seconds.

In modes 1 and 2, when after the light turns red, all directions will be red for a second. The rationale is that (in real life) any crazy driver beating the red light would be given enough time to cross the intersection without causing a tragedy.

When I gave the traffic light to John he critiqued the flashing mode saying one set should flashing yellow (eg. NS and SN) while the other (eg. EW and WE) should be flashing red. Actually I can't remember which lights are on in real four-way traffic lights during flashing mode. Googling shows that my nephew has a point. That's trivial enough to implement, given that the firmware uses a state machine implementation to charlieplex the lights. 



The table on the right shows which lines (PORT pins) control which traffic light direction. The table on the left gives the TRIS and PORT status in order to light up LED Lx.

Here's the light at work:



Hoping to make a much more decent model the next time around.

Wednesday, March 2, 2011

PIC 12F1822 current draw at different frequencies

Because the datasheet for the PIC 12F1822 lists the supply current for only a select number of internal oscillator frequencies I went and measured the current draw for all of them under various I/O settings.

The MCU was programmed and powered by a PICkit2 whose VDD was set to 5.0VDC when programming. It was set to either 5.0V or 3.0V when logging maximum, minimum and average current draw. The only thing connected to the MCU was the PICkit 2. The two were mated throughout the test. No resistors, capacitors, etc. were used. Ambient temperature during tests was 27° to 29° Celsius.

A Fluke 87V digital multimeter was set to read µA, with Min-Max feature enabled. The DMM was hooked up in series with the MCU's VSS and PICkit2's VSS. The meter was given between half a minute to a minute to gather data.

In the MCU configuration words, INTOSC with I/O function on CLKIN pin was selected. MCLRE, WDTE and PLLEN were disabled. Note that with the MCLR inoperative, RA3/MCLR pin is floating. Leaving an input floating increases current draw. In the tests below weak pull-ups were either enabled or disabled to record this difference. All peripherals (ADC, comparators, etc.) were left at their default settings, which I believe are off.  

The various firmware used are provided below. C compiler employed was the mikroC Pro v4.60

A1.
// FOR MEASURING CURRENT AT VARIOUS INTERNAL OSCILLATOR FREQUENCIES
// All I/O pins are all digital outputs in sinking current mode (grounded) 
// RA3/MCLR pin weak pull-up is enabled (MCU automatically disables pull ups for pins configured as output)
void main()
{
  PORTA = 0;
  TRISA = 0;
  ANSELA = 0;
  NOT_WPUEN_bit = 0;    // global pull-up enable
  WPUA = 0XFF;          // individual pull-up enable
  OSCCON = 0b0;         // change OSCCON value to set various internal oscillator frequencies
  while(1) ;
}

A2.
// FOR MEASURING SLEEP CURRENT
// All I/O pins are all digital outputs in sinking current mode (grounded) 
// RA3/MCLR pin weak pull-up is enabled (MCU automatically disables pull ups for pins configured as output)
void main()
{
  PORTA = 0;
  TRISA = 0;
  ANSELA = 0;
  NOT_WPUEN_bit = 0;    // global pull-up enable
  WPUA = 0XFF;          // individual pull-up enable
  asm sleep
  while(1) ;
}

B1.
// FOR MEASURING CURRENT AT VARIOUS INTERNAL OSCILLATOR FREQUENCIES
// All I/O pins are by default analog inputs 
// All weak pull-ups are enabled
void main()
{
  NOT_WPUEN_bit = 0;    // global pull-up enable
  WPUA = 0XFF;          // individual pull-up enable
  OSCCON = 0b0;         // change OSCCON value to set various internal oscillator frequencies
  while(1) ;
}

B2.
// FOR MEASURING SLEEP CURRENT
// All I/O pins are by default analog inputs 
// All weak pull-ups are enabled
void main()
{
  NOT_WPUEN_bit = 0;    // global pull-up enable
  WPUA = 0XFF;          // individual pull-up enable
  asm sleep
  while(1) ;
}

C1.
// FOR MEASURING CURRENT AT VARIOUS INTERNAL OSCILLATOR FREQUENCIES
// All I/O pins are by default analog inputs 
// All weak pull-ups are by default disabled
void main()
{
  OSCCON = 0b0;         // change OSCCON value to set various internal oscillator frequencies
  while(1) ;
}

C2.
// FOR MEASURING SLEEP CURRENT
// All I/O pins are by default analog inputs 
// All weak pull-ups are by default disabled
void main()
{
  asm sleep
  while(1) ;
}

Open this Google spreadsheet to see the test results. As can be clearly seen, the lowest power consumption is obtained with I/O pins set as output. The worst configuration as expected is that with floating inputs. It was discovered that having analog instead of digital inputs just slightly decreases current draw.

Below are screenshots of the pertinent table from the datasheet:


Compared to the datasheet, the results I obtained shows the 12F1822 (at least the chip I tested) performs  better than specification, although I hardly duplicated Microchip's test conditions exactly.

According to the specs the LF version draws a maximum of 1.1µA during sleep @85°C, compared to the F version's 45µA. The astronomical difference probably implies the F version employs a low drop out voltage regulator to supply the MCU core with 3.6V (see the datasheets for the PIC 16F193X series for notes on the LDO).

Friday, February 18, 2011

Now when will I get one?

Agilent just unveiled its latest lines of InfiniiVision oscilloscopes.  Brochure and spec sheet for the 2000X and 3000X. Dave Jones has a comprehensive review of this wonderful, jaw dropping scope.

Monday, February 7, 2011

Philips RC-5 Infrared Protocol Decoding

Currently developing a circuit that will have as its input device off-the-shelf (TV) remote controls. I initially planned on using the NEC protocol given its inclusion of the complement of the command code which could be used for signal/data integrity checking. However, given that each NEC frame has 32 bits + a leader code (start bit), I decided to use the simpler and less interrupt-service-routine-intensive RC5 protocol by Philips.

The following will be a primer on the method I'm using to decode the RC5 signal. The IR receiver I used for the circuit is the Osram SFH5110-38. This particular part is suppose to be used for IR signals with a 38kHz carrier frequency, but the Philips uses 36kHz. Tests show the Osram has no problem picking up the Philips transmission although I cannot say what improvement in quality of signal output (particularly bit periods) will be if a 36kHz receiver is employed. For the remote control I used a Cybertec RM-312x universal control programmed with setup code 1528 for Philips TV.


Introduction

The Philips RC5 uses bi-phase encoding whereby:
  • logic zero is represented by a falling edge during the middle of the bit period
  • logic one is represented by a rising edge during the middle of the bit period

Here's a summary of the RC5 protocol (this image is purportedly from an original 1992 Philips document on the RC5).



One RC5 bit period = 1.778ms. Half of that is 0.889ms. The start bit is always a logic one and occurs, of course, at the middle of the first bit period. The entire RC5 word is repeated every 114ms while the remote control key is kept pressed. The Toggle/ Control bit remains at the same logic level as long the present key is not released. This bit will toggle if the key is released and another key is pressed or the same key is pressed. The Toggle/Control bit can therefore be used to detect whether the current key is still pressed (required for instance for TV volume control) or the same key has been released and pressed again (required for the input of digits for example).

The above diagram is from the point of view of the IR transmitter wherein the IR LED is normally off (to conserve battery power). The IR receiver output, however, is normally on (output voltage is high while no IR signal is detected). Because of this the output of the receiver will be the complement of the transmitted signal and thus:
  • logic zero is represented by a rising edge
  • logic one is represented by a falling edge

The receiver has circuitry to filter out the 36kHz carrier wave and thus its output is clean and doesn't have the 36kHz "spikes."

From the point of view of the IR receiver output here are some important facts we can infer from the RC5 protocol:
  • F1. A level change must occur during the middle of every bit period. 
  • F2. A level change may or may not occur during the start/end of a bit period. 
  • F3. Half-bit-period level changes (i.e., the elapsed time between two level changes is 0.889ms) always occur in pairs, with the latest/current level change occurring at the middle of a bit period. 
  • F4. Given a pair of half-bit-period level changes, the current bit has the same value as the previous bit, i.e., if the value of previous bit was a logic one then the value of the current bit is a logic one, and the current bit is a logic zero if the previous bit was a logic zero. 
  • F5. Given a full-bit-period level change (i.e., the elapsed time between two level changes is 1.778ms), the current level change occurred at the middle of a bit period, and the value of the current bit will be the complement of the value of the previous bit, i.e., if the previous bit was a logic one then the current bit is a logic zero, and the current bit is a logic one if the previous bit was a logic zero.  
One way to decode a RC5 transmission is to check the direction of the level change during the middle of each bit period--whether it is a falling or rising edge. Given F2 we need a way to know whether it's the start/end or middle of a bit period. Since the start bit (a falling edge) occurs at the middle of the first bit period, we can use that as a reference point, confident that every 1.778ms thereafter--every full bit period or every two half bit periods--will be the middle of the succeeding bit periods.


MCU Implementation

The test circuit consisted of a Microchip PIC16F883 microcontroller using its internal RC clock running at 4MHz, an Osram SFH5110-38 infrared receiver, and four discrete LEDs as indicators to see if the IR signal was being detected and whether the transmitted command codes were being correctly decoded. The circuit was powered by an ATX supply since I discovered via oscilloscope that the PICkit 2 apparently didn't have enough juice to power the IR receiver--even with a 1uF tantalum or 10uF aluminum cap at the VS pin of the IR receiver its output would sporadically spike down to low (zero volts) even with no signal being received. And when signal was received its output was garbage.

Because level changes (falling and rising edges) need to be detected the output pin of the IR receiver is connected to an MCU pin that has interrupt-on-change (IOC) capability. In this case I chose the 883's RB0 pin. With the proper special function registers (SFR) set up, an interrupt will occur whenever a level change occurs--whenever voltage at the RB0 changes from high to low or from low to high.

A timer is set up so the elapsed time between successive IOCs can be measured. If it's ~0.889ms then we know half a bit period has passed. If it's ~1.778ms then elapsed time is a full bit period. I used Timer0 with a prescaler value of 1:16. Given the 1µs instruction cycle, register TMR0 will overflow every 256 x 16 x 1µs = 4.096ms (INTCON.T0IF will be set even if interrupt is not enabled).

The start of a RC5 word is the first falling edge detected after the IR receiver has been high for over 4.096ms--when Timer0 overflows and its interrupt flag gets set. This falling edge indicates the start bit. The start bit is not recorded/stored. It is used only as the reference for determining the middle of the bit periods. This falling edge occurs at the middle of the first bit period of the word, so every full bit period (1.778ms) after this is the middle of a bit period.

When an IOC occurs and the measured elapsed time from the last IOC is half a bit period long, given there was no prior half bit period or the previous half bit period has already been paired, then according to F3 the very next IOC will occur after half a bit period. That will then be the middle of a bit period. Checking the direction of the level change provides the bit value. Alternately, as per F4 that bit will have the same value as the previous bit.

When an IOC occurs and the measured elapsed time from the last IOC is a full bit period then the current IOC has occured at the middle of a bit period and the bit value (0 or 1) is recorded, depending on the direction of the level change. Because of F5, instead of checking the direction of level change, the value of current bit can be obtained by looking at the value of the previous bit.

Because the RC5 word is transmitted MSB first, we left shift the incoming bits into their storage variables (registers). Because I will be using the Command codes and the Control bit but won't for now be using the Address bits I've decided to store the Command bits in one variable and the rest in another.
 
As the Field bit, Control bit, and 5-bit System Address are received they are left-shifted into variable RC5FCSYS. Thus when all the bits are in, the Field bit and Control bit will be in bits 6 and 5 of RC5FCSYS, respectively, and the MSB and LSB of the System Address will be in bits 4 and 0 of RC5FCSYS, respectively.

The 6-bit Command bits are left-shifted into RC5COMM in the order they are received by the IR receiver. Thus, after all the bits are in, the MSB and LSB of the Command code will be in bits 5 and 0, respectively.

Variable RC5BITS keeps track of the number of bits already received and is used to determine into which of the two variables the current bit will be stored. 

Because the bit period of the incoming signal will never be exactly as per specifcation and because the MCU is running on its internal RC clock with limited accuracy, we need to predetermine a range of incoming IR pulse widths that are accepted as legitimate half and full bit periods. Any received pulse width outside these ranges will be considered an indication of an error and the entire RC5 word will be disregarded.

An oscilloscope can be used to sample several half and full bit periods from various remote controls (IR transmitters) used at various distances from the IR receiver. The Cybertec remote control used to test the firmware had half bit periods that were within ±20% and full bit periods within ±10%. Using 20% the ranges are: half bit period: 0.7112ms to 1.0668ms, full bit period: 1.4224ms to 2.1336ms. Those values  were converted to 8-bit integers taking into account the MCU clock frequency and timer prescale value.

After the firmware had been debugged, the response of the MCU to IR signals was found to be unreliable and intermittent--there was noticeable inability to detect valid signals around 50% of the time. So I increased the tolerance to ±25%. Thus the acceptable ranges of values increased to 0.66675 to 1.11125ms and 1.3335 to 2.2225ms. With that increased range the MCU picked up the transmission every time. Transmitter was tested up to 4 meters and within 45degrees of the receiver (zero degrees is perpendicular to the face of the receiver).

Note that if tolerance is uniform for both upper and lower limits and for half and full bit periods then the maximum tolerance allowable is 33% since with a value >33% the half bit period upper limit will be greater than the full bit period lower limit: 0.889ms + 0.889x > 1.778ms - 1.778x, with x > 1/3. Tolerances needn't be uniform, of course. If, as with the Cybertec remote control, the full bit period tolerances are much better than the half bit period's, then the range for the full bit period can be decreased accordingly.

Here's the pertinent part of the RC5 decoding firmware. It was written in mikroC Pro for PIC.


/*

Philips RC5 Decoding Routine
February 2011
Edwardson Tan 
 
processor = PIC16F883
*/

#define  irr                 PORTB.f0  // Osram SFH5110-38 infrared receiver
#define  tris_irr            TRISB.f0  // for use with setting the appropriate pin as input
   
// RC5 decoding defines
#define  rc5_on              FEN.f0              // 1 = irr output has been high for >4millisec and then goes low; this indicates a RC5 start bit
                                                 // 0 = irr output has been low for >4millisec and then goes high. This is an abnormal state and is an error
                                                 // rc5_on is also reset to 0 when all bits of word have been received
#define  halfper_prev        FEN.f1              // 1 = the last IOC was a half bit period, 0 = the last IOC occured after a full bit period
#define  button_pressed      FEN.f2              // 1 = button has been pressed and valid RC5 word stored
#define  rc5_read_error      FEN.f3              // 1 = read error, pulse width of either a zero or one bit is outside the acceptable limits; the data packet should be discarded
#define  bit_period          FEN.f4              // _full = 1 = one full bit period, _half = 0 = half bit period
#define  curr_bit            FEN.f5              // contains the latest decoded value of the bit of the RC5 word being received

#define  _full               1
#define  _half               0

// one full bit period for RC5 = 1.778ms; one half bit period = 0.889ms
// given clock = 4MHz and TMR0 initial value = 0 and timer0 prescale = 1:16, TMR0 overflows every 256 x 16 / 1MHz = 4.096ms
// 4.096ms / TMR0 count = 4.096 / 256 = 0.016ms per TMR0 count
// 1.778 / 0.016ms = 111   this is the TMR0 count when time elapsed is 1.778ms
#define  _fullbit            111                                     // full bit period of RC5
#define  _tolerance          25                                      // tolerance in percent, to be added/subtracted to/from half and full bit periods to create range of acceptable pulse widths
                                                                     // !! THIS HAS TO BE INTEGER NOT FLOATING POINT !!
                                                                     // !! MAXIMUM VALUE = 33%, ELSE halfbit_uplim WILL BE GREATER THAN fullbit_uplim

#define  _halfbit            _fullbit / 2                            // half bit period of RC5

#define  halfbit_lolim       _halfbit - (_halfbit * _tolerance / 100) // minimum pulse duration for half bit period
#define  halfbit_uplim       _halfbit + (_halfbit * _tolerance / 100) // maximum pulse duration for half bit period
#define  fullbit_lolim       _fullbit - (_fullbit * _tolerance / 100) // minimum pulse duration for full bit period
#define  fullbit_uplim       _fullbit + (_fullbit * _tolerance / 100) // maximum pulse duration for full bit period


// ===========================================================================================
//       Global Variables
// ===========================================================================================

int8     FEN = 0;            // Flag and ENable and status bits register
int8     PULSEWIDTH;         // contains the measured pulse width (to get the real value in millisec multiply by 16)
int8     RC5BITS;            // contains the bit number (excluding the start bit) of the RC5 word currently being received
int8     RC5FCSYS;           // contains the RC5 Field bit, Control Bit, and the 5-bit System Address
int8     RC5COMM;            // contains the RC5 6-bit Command code
int8     TEMP;               // temporary memory


// ===========================================================================================
//       Functions
// ===========================================================================================

void InitRegisters()
{
  PORTA = 0;
  PORTB = 0;
  PORTC = 0;

  TRISA = 0;
  TRISB = 0;
  TRISC = 0;
  ANSEL = 0;
  ANSELH = 0;
  
  tris_irr = 1;
  
  OPTION_REG = 0b10000011;   // prescaler assigned to timer0
                             // prescale = 1:16
                             // timer0 uses internal clock instruction cycle
                             // weak pull ups disabled
                             
  // enable interrupt on change
  // intialize RB0/INT pin to interrupt on input change -- pin is connected to IR receiver
  INTCON.RBIE = on;
  IOCB = 0b1;
  
  INTCON.GIE = 1;
  INTCON.PEIE = 1;
  
} // void InitRegisters()

// ===========================================================================================
//       ISR
// ===========================================================================================

void interrupt()
{
  // interrupt on change
  if (INTCON.RBIF)
  {
    PULSEWIDTH = TMR0;
    TMR0 = 0;
    TEMP = PORTB;            // a read of PORTB is necessary before RBIF can be cleared
    INTCON.RBIF = 0;

    if (rc5_on && !rc5_read_error)
    {
      if (PULSEWIDTH >= halfbit_lolim && PULSEWIDTH <= halfbit_uplim)
        bit_period = _half;
      else if (PULSEWIDTH >= fullbit_lolim && PULSEWIDTH <= fullbit_uplim)
        bit_period = _full;
      else
        rc5_read_error = 1;

      if (bit_period == _half && halfper_prev == 0)
      {
        halfper_prev = 1;    // last IOC occured after a full bit period, so this current half bit period needs to be paird with the half bit period
      }
      else // if (bit_period == _full || halfper_prev == 1)
      {
        halfper_prev = 0;
        if (irr)             // rising edge, indicates logic zero
          curr_bit = 0;
        else                 // falling edge, indicates logic one
          curr_bit = 1;

        if (RC5BITS <= 6)
        {
          RC5FCSYS <<= 1;
          RC5FCSYS.f0 = curr_bit;
        }
        else
        {
          RC5COMM <<= 1;
          RC5COMM.f0 = curr_bit;
        }
        if (++RC5BITS >=13)
        {
          rc5_on = 0;
          button_pressed = 1;
        }
      }
    } // if (rc5_on && !rc5_read_error)

    // if timer0 interrupt flag is set then ir_rx output was low/high for >4ms before the IOC that just occurred
    if (INTCON.T0IF)
    {
      INTCON.T0IF = 0;
      RC5BITS = 0;
      RC5FCSYS = 0;
      RC5COMM = 0;
      rc5_read_error = 0;
      rc5_on = 0;
      if (!irr)                        // falling edge; pulse was high for >4ms so this is considered the start bit of RC5 word
        rc5_on = 1;
    }
  } // if (INTCON.RBIF)
} // void interrupt()


----

References:

AN10210 Using the Philips 87LPC76x microcontroller as a remote control transmitter
Philips RC-5 Protocol