phil

As promised a class and a sample program using it that decodes the IR signals from RC6 remote controls. I used a Vishay TSOP34836 IR receiver connected as follows: Pin 1 (output) to netduino D7 input Pin 2 (GND) to netduino GND pin Pin 3 (VS) to netduino 3V3 pin I have attached a copy of the datasheet for the IR receiver, the decoder class, and a sample program that uses it, and just prints out the control values when a code is received. To use the class, you create an InterruptPort for the pin that the IR receiver output is connected to an event handler for when a code is received. You then set the public attribute in the class for the RC input pin to that InterruptPort. You MUST use an interrupt port - forget pin polling, it simply will not be fast enough. I measured the decode process as taking about 40ms. It is seriously not optimised - there are several opportunities to reduce the memory footprint and execution speed. However as the remote I'm using repeats codes every 75ms this is plenty fast enough to decode a repeated transmission. The theory of operation is simple. As each pulse level changes, the time of the edge is recorded in an array. Once we get a "quiet time" (the pulses stop) the timer will be triggered and the decode process commences. I have written that to be as easy to follow as I can, to make it easy to adapt to other IR code types. I have added some commented out debugs for various failure conditions. One of the tricks with the RC6 protocol is that it uses Manchester encoding. This is where 1's and 0's are encoded not by a signal level, but by a *change* in level of a signal. A 1 is encoded in this instance by the signal changing from a high to a low, and a 0 is encoded by a signal changing from a low to a high. Thus, when we record pulses, we're recording the "middle" of the bits (big hint there on how to massively optimise this program! :^) I show the details of this as decoding a sequence of half-bits, depending on the pulse time. There are many different IR protocols. The only reason I am using RC6 is I have access to piles of Microsoft Media Centre remotes (I work with a company that buys MCs and uses them for display units, and the remotes are just tossed out). The remotes in your house probably use as many different protocols as you have remotes. You can see the RC6 protocol explained at: http://www.sbproject...edge/ir/rc6.htm If you do not know what protocol your remote uses, then use this class and look at the state and timing arrays when the decode method is first called. You should be able to work out what the protocol is from those, and then you'll have to rewrite the decoder, of course! That page has most of the other protocols explained as well. Have fun .. I hope someone find this useful. I'm going to go the next step in a few days, if I get time, and add 8 MOSFET drivers to the sensor. I can then use the remote to individually dim up to 8 MR16 LED downlights (6W = 0.5A a piece). I can then create some cool mood lighting in a couple of the rooms of my house with remote control. Fun! We're actually planning to use the netduino as a dev tool for some commercial products, but right now I'm just exploring the capabilities of this processor (I also have a pile of other .net MF demo kits with different CPUs of varying types and speeds, so we can get our heads around the potential of these devices and the .net MF). PS - the big hint about optimisation .. imagine that the edge tells you what a bit was! The time since the last transition tells you what kind of bit it was (leader, trailer, etc). Something for the keen folks to play with. Phil