Waiting for a device, digging into the IR (Recoil: Part 2)

Well, none of the devices I have available to me at work are new enough to run the Recoil app, so digging into the gameplay will have to wait until tomorrow. Instead, I'll dig into the IR protocol a bit, and see what info can be gleaned from it.

The setup

I have a Saleae Logic that works great for things like this, and a little IR receiver gadget that's not much more than a 38KHz 3-pin IR receiver, a resistor, an LED, and a battery pack. So by connecting the Logic to the IR receiver's output, and the battery pack's ground, I have a nice little visual indication on whether I'm receiving anything at all, and the Logic captures it to my PC for analysis.

So let's grab some signals!

Capturing 

Thanks to having had the IR gadget on earlier, I already know the various ways to get things to send IR. There's a whole five captures I need to do: Grenade with countdown, turning the grenade off early, holding down the grenade button, a single shot from the blaster, and holding down the trigger on the blaster. A few minutes of setup and renaming files, and that's done. So what do we have?

What it looks like

What I believe to be the basic unit of data in the Recoil IR protocol

Keep in mind that 3-pin IR receivers tend to be active low, so the signal goes down towards the bottom when signal is present, and back to the top when there isn't. So, right off the bat, we have a nice long SYNC pulse(3.3ms), and then a delay(1.5ms), and then a bunch of data. Data looks to be encoded in both the high and low states, so you'll need to be able to capture times on both edges.

You'll also note that I captured two "packets" in a row, and that these are identical "packets". Everything that's sent from the blaster seems to be sent like this, probably for error checking purposes. The grenade seems to send the same packet over and over and over.

Now, back to the encoding. It looks like there's a "short" and a "long" bit, with short bits being (very) roughly 0.4ms, and long bits being 0.8ms. Tolerances are /very/ wide on these timings, with anything from 0.276ms to 0.927ms being seen.

I'm arbitrarily setting the threshold between a "short" and a "long" bit at 0.575ms, a minimum valid period of 0.25ms, and a maximum valid data bit period of 1ms.

I'm also arbitrarily saying that a "short" bit is a 0, and a "long" bit is a 1.

So the packet shown in the screenshot above would decode as 00000010000111000000000000001100001, or 00000010 00011100 00000000 00001100 001. This seems a bit weird, that it's 35 bits... But for now, I have no better ideas on how to decode it, so I'll stick with a 35-bit packet for now.

For the moment, a coworker lent me their phone for the purposes of trying out the actual gameplay, so let's switch gears again!