I'm using the remote to my Panasonic TV, with the DBS/CBL button programmed to one of the Sony device codes from the TV manual. I found this sketch first: SIRCS Monitor and then tried different device codes from the manual until I found one that worked and supported the buttons I wanted to use, and used the codes reported by SIRCS Monitor to identify the codes for those buttons.
The Sony protocol consists of a 2.4ms start pulse, followed by 12 bits, LSB first. Each bit starts with a 0.6ms gap, then a 0.6ms pulse for 0, or a 1.2ms pulse for 1. The next code is transmitted about 45ms after the previous code began, so there's a gap of about 21-28ms between codes. You can see the waveform graphed here: http://www.kucher.org/projects/tvcontrol/
But I do have a question. What's the story on the commented out sections in the else if statements? Is it better to leave them out?
So, the routine should be looking for IR pulses that are ~2400us (start pulse), and then either a ~600us pulse or a ~1200us pulse. Since the receiver I'm using is active low, the routine looks at the low pulses on the input which indicate that the receiver is detecting IR. So I started by having the routine detect if the pulse was 2300-2500us, 1100-1300us, or 500-700us and rejecting outside of all of those ranges. Hence why you see two tests in each if(). Due to the sloppiness in making microsecond measurements with non-blocking code, though, and the delay between the IR receiver receiving IR and the ISR actually getting to the point where it checks against micros(), I found I got better results with the method I posted where pulse length is simply compared against a floor of 2400, 1220, or 600us. In particular I was getting a lot of false ones, which indicates that the delay in the routine is significant enough to push "0" delays into "1" territory. Any pulse shorter than 600 us is rejected and causes the receiving routine to reset, as does any gap shorter than 600us. The micros() bug is also an issue in this code, as I understand it, although I'm not sure how much of an impact it may be having in practice. (It's not clear to me how often the micros() overflow bug occurs, having not read enough of the datasheet to understand exactly what's going on in micros() ).
I'm going to continue trying to improve the routine, so if you have any suggestions or epiphanies, I'd be glad to hear them :).