Data encoding for GFSK wireless

In my experience when decoding IR signals it is almost always better to be very pedantic about the signal timings. For example, just accumulating the HIGH times in an array will work most of the time, but will not cope with the occasional noise burst. You need to validate each HIGH and each LOW period.

As another example of the need to be careful with timings, for the "start" signal, you only detect that the initial LOW period (i.e. 38 kHz IR burst) is longer than the minimum (2200)...but what if it is way longer due to a noise burst? And what if the quite time immediately after that is too long or too short? You'll trigger falsely, and then continue to try to make sense of the possibly still noisy signal that follows and get an unreliable result.

What I would suggest is that you use your scope and timing figures to get a feel for the correct timings (which you have largely done), and write your code to detect whether each individual bit is valid (that is, both LOW and HIGH times are within tolerance) and, if an invalid bit is encountered, ignore all further transitions for say 100 ms before listening again for a "start" sequence. The aim is to never attempt to process a command unless it is known to be parsed completely.

Also (probably less important) the 16 bits that seem to be always the same may not always be that way. You may just not have seen the cases where they are significant. Maybe they are for a device address and/or flags (such has "key pressed and held"). In some protocols, the signal sequence changes significantly when a remote key is pressed and held, and others toggle a bit in the "command" field as each command is issued.

I think a good way to rigorously parse an IR signal is by using a finite state machine (FSM). For an example you can see my open source project at http://sourceforge.net/projects/irk-usb/ ...it's not for arduino, but it should be helpful nonetheless.

Sampling asynchronously is probably not the best way to deal with this because the sample rate is only a few times higher than the data clock rate. It's Manchester encoding and the main bonus is that you get the clock for free (well, almost) and it's dead easy to make an edge detection circuit from an exor gate and a small delay: -

Here you get a pulse for each edge present in the signal and, if you set a counter running that is maybe 16 times higher than the data clock rate you can position your sampling point at count number 8.

At that point carry on counting and if you don't receive a counter reset (due to lack of a clock pulse) you sample the data at count 24 for the next bit. Manchester encoding is more accurate than asynchronous UART data because clock is embedded into the data and you get far more transistions than can be expected with plain ordinary asynchronous data.

Here's what you are proposing and note the error you can get if your fast clock is only 4 or 8 times the data clock rate: -

I've drawn a red arrow where asynchronous data timing starts to hit a problem - UARTs will sync up their clock on every edge detection thus always minimizing this error.

I've implemented this type of system in FPGAs running non-manchester encoded signals (no embedded clock and thus far fewer clock edges) at speeds up to 50 odd Mbpsec. I've used data scrambling to enhance the number of clock edges but manchester decoding should be a breeze.