Aaron's Sandbox

By the way - last time I noted a lot of random noise in the IR signal. I decided to build another IR module circuit (IR receiver, resistor, capacitor), this time with the components socketed, so I could more easily debug the problem. Lo and behold, the new circuit has no noise. At some point I'll disassemble the first IR module and swap its parts into the new circuit to see if I can blame the noise on a defective component, but for now, I'd rather do something more fun: decipher the Xbox remote codes.

First off, a fundamental fact about IR communication. The usual milieu for such communication is a noisy environment inhabited by naive yet fault-intolerant users. Transmission is expected to work perfectly, even if the batteries are weak and the user is pointing the remote at the wrong device. The IR receiver compensates for a lot of these problems in its cascade of analog circuits (here), and it performs admirably, but all that circuit can detect is full-on (mark) and full-off (space). So, for any given remote, for each of its buttons, a particular sequence of mark and space durations will be transmitted. The set of possible sequences, and their interpretation into data, is the protocol.

Long ago, before the Internets, I would have had to pore over traces of mark-and-space durations, seeking the elusive pattern of the protocol. Well! That would have been good clean fun. However, on the Internets I see that someone has already done that part. The Xbox remote allegedly conforms to the "RCA protocol". To summarize:

• 4ms mark, 4ms space begins a transaction.
• The data is in "pulse distance protocol": each bit consists of a 500μs mark, followed by either 1ms space (logical 0) or 2ms space (logical 1).
• 24 bits are sent per transmission (4-bit address, 8-bit command, then complement of that same address and command).
• Address and command are sent MSB-first.
• Each transmission ends in a final 500μs mark.

I have some experimental data; how well does it match up with that description? Before I answer that question, I'm afraid I'm going to indulge myself in a little rant.

Signaltap's Tragic Flaw

I thought I had a great flow going here. My input was a handful of verilog files and a tcl script for each stage of the flow. I was making good progress (I thought) toward a data collection system which would work like this:

1. I type "make" (or something)
2. The fpga configuration file is built, if necessary (if any of its dependencies changed)
3. The fpga is programmed from its configuration file
4. I'm prompted, "type the name of a remote control button, then press that button, or <esc> to quit"
5. I do it, and the signaltap data for that button is captured and logged
6. After enough data logging, I type <esc> and data for each button is written to a report file.

I can do everything up to step 5), but step 6) appears to be impossible! Why? When, via a tcl script, signaltap is instructed to capture data, the captured data goes into the stp file. (That file looks like some form of XML.) But there are no scripting commands (at least that I could discover) which make stp file data available for further processing. I'm sure I could figure out the format of the XML file and get the data, but that just seems deeply wrong. So sad.

Fallback position: The GUI does provide a way to export signaltap data into various formats. I'll convert my data using the GUI, then work on it in Excel. It'll work, but it will be very time-consuming. Oh, well.

Onward! An example: DISPLAY

Is my Xbox remote really transmitting according to the RCA protocol? I'll have a look at the data that's transmitted when the DISPLAY button is pressed. Here's the sequence of pulse durations that occur, in milliseconds. (I admit to begging the question in the suspicious display format I've chosen.) The first pulse is a "mark" (active transmission, and logic low on the ir signal). Each subsequent number is the duration of a pulse of opposite type to its predecessor.

4,4,
0.5,1,0.5,2,0.5,1,0.5,2,
0.5,1,0.5,1,0.5,2,0.5,1,0.5,2,0.5,1,0.5,2,0.5,1,
0.5,2,0.5,1,0.5,2,0.5,1,
0.5,2,0.5,2,0.5,1,0.5,2,0.5,1,0.5,2,0.5,1,0.5,2,
0.5

Now, if I believe the RCA protocol description, each sequence "0.5,1" is a logical 0, and each "0.5,2" is a logical 1. And I can strip off the 4 ms mark-space at the beginning, and the terminal 0.5ms mark. The result:

0 1 0 1 
0 0 1 0 1 0 1 0 
1 0 1 0 
1 1 0 1 0 1 0 1 

As predicted, I see 12 bits (4 address, 8 command) and then their complements. Here's the beginning of a table:

Next up: I'll fill in the rest of the table. There are 27 buttons on the Xbox remote - this will be tedious.

Postscript: I lied. The mark/space durations above matched the RCA protocol perfectly. But it just isn't true! Unless, that is, I quantize to 1 decimal place, as I did for the data above. If I look at my data with a higher-resolution lens, I see a less tidy picture. This table shows the discrepancies, which are accurate to one signaltap period (5.12μs):

Mulling over these hypotheses will give me something interesting to do while I go about the rote business of collecting and translating the data for the button-to-code table.

tb_5 files