Infrared Remote Recording Part 2
The PSOC electronic design shown in the last post provides a mechanism for capture of the Infra-Red light (IR) broadcast by the remote. You will find on the internet that most IR remotes use Manchester Encoding. I found that for A/C units, that was not completely true, so I resorted to “sniffing” the light and saving the results.
When the light turns on, the TSOP38238 output goes from a 1 (5volts) to a 0 (ground). When the light turns off, it goes from a 0 to a 1. The design here captures those edges and registers the time they occur relative to the start of the timer:
Theory of Operation
I connected the pulses in from the IR receiver (the TSOP38238) through a glitch filter, invert them, and sent the inverted signal to the Capture input of a counter. This 32 bit counter has a 2 mHz clock, so it can register an edge with around 1/2 a microsecond resolution (500ns).
The counter is 32 bits so it can count over 2 billion microseconds (or 4 billion 500ns intervals). This provides enough time for you to start the counter, find the button on the remote and press it to broadcast the IR signal before the counter overflows. Originally, I had used a 16 bit counter, and if I took too long before pressing the button, the counter overflowed and ruined my simple calculator. Making it 32 bits was the lazy way out.
Data sheets and API’s
For the Cypress PSOC Creator components, double-clicking on the component brings up a configuration dialog. In the lower right-hand corner of the dialog is the Data sheet button. That button allows you to learn how to configure the component, and what firmware API is available for your use.
In the data sheet for the timer you will find “hardware” specifications and API descriptions. The term API stands for Application Programming Interface, and the functions written for you by Cypress does the heavy lifting for you in terms of dealing with the hardware.
Using these functions, you retrieve the number of counts that have occurred before the edge (either positive or negative) from the TSOP device was seen by the counter. An interrupt output is driven by the timer, triggering your interrupt handling routine. The counts from the counter register when the edge is detected are put into a FIFO (First In First Out) register.
Capture Output Interrupt Handler
The interrupt routine reads this register and stores the counter value into an array deep enough to store all the counts for all of the edges detected. Later on, math will be done on the values in the array to determine the time between the edges.
Because the PSOC cpu is so fast, the capture register will only have one reading in it when the interrupt routine executes. The light signalling pattern takes milliseconds to perform. Relative to the PSOC this is slow; the PSOC can often handle an interrupt from beginning to end in less than 2 microseconds.
During testing, I found the TSOP IR receiver would often generate quick, unwanted pulses at the beginning or end of each of the off-to-on or on-to-off light transitions. These pulses were being captured by the counter, causing all kinds of problems for me.
The solution was to put a glitch filter in-between the counter capture input and the TSOP. If there are short pulses, the filter ignores them. It does produce a small displacement in time before the light-on transition edge is detected. Since it also produces the lag on the other side (for light-off), the net effect of the filter on the timing is greatly reduced.
Since the signalling timeframe is measured in milliseconds, and the light is also modulated on and off at a 38 kHz rate, the receivers have some tolerance built into them. The light on and off periods can vary back and forth several tens of microseconds without affecting their decoding.
The Sync Component
During development with the PSOC, especially after you have created several pages of schematics, you will often find that a clock synchronization error occurs. This error is due to clocks and other signals being routed throughout the UDB’s and the input-output connecting fabric inside of the PSOC.
The PSOC has the equivalent of a small FPGA inside. Cypress chose Verilog as their main logic programming language for the PSOC. They adapted the Verilog Warp compiler system and integrated it with PSOC Creator. All of the components are written in Verilog, and compiled into binary data that is programmed into the switch fabric and the UDB’s to create components and interconnects.
When a clocked logic cell is interconnected with another clocked logic cell through pathways chosen by the Verilog Compiler, differences in path lengths can occur, usually due to limited resources. (You work with what you have available.) These differences in path lengths can cause the clock to arrive a few nano-seconds later in one component than in another component. This is called clock skew, and it varies from component to component.
In many cases, this is not a problem. If the clock skew is between components that don’t interact with each other, it can be safely ignored. If the components require the clock skew to be minimized in order to work properly, then you have a problem.
Fortunately, Cypress came up with a component driven solution. The Sync component is used to synchronize the clock within the UDB subsystem. This synchronization removes the clock skew and allows your more complicated designs to work properly, without you having to fight the compiler. (If you have programmed using VHDL or Verilog on Xilinx or Altera, you may remember setting timing constraints to accomplish this. It is always a pain.)
In this post, I covered two important components: The Glitch Filter and the Sync. You will find yourself using the Sync component over and over. The glitch filter will be used much less. When you need it, however; you need it.
If things permit, next time I will bring out PulseView and show you how to use it to look into the system as you are capturing IR pulses. We will also print out the time domain of the pulses, and prepare for playing them back.