Sniffing the i2C traffic of a NunChuk

There are several articles on the web about how to use a NunChuk with an Arduino.  There are also articles about how to get NunChuk data via communication to the WiiRemote.  But what I haven’t found is a sampling of the actual interchange between the NunChuk and WiiRemote during their initialization and use.  I developed this program to help me understand that communication traffic.

The communication between the NunChuk and Remote utilizes i2C at 400KHz.  I studied the atmega128 product specification and couldn’t determine how to use Arduino’s i2C hardware for sniffing and not as a master or slave device.  I decided to write my own i2C protocol parsing algorithm. 

i2C is a simple communication protocol.  There are only three wire connections needed: SCL, SDA and ground reference.  SDA is primarily data, but is used for signifying start and end of message.  SCL is the data clock.   The state relationship is shown in the following diagram.

There are six fundamental operations: 1) Idle, 2) Start condition, 3) Sample SDA, 4) Process Sampled SDA Bit, 5) Stop condition, and 6) Repeated Start condition.  Startup condition is in the idle state.  A byte of data occurs by accumulating the first 8 bits (from MSB 1st bit to LSB) of the sampled SDA.   A ninth bit is then processed as the byte acknowledge with a “0” meaning acknowledged and “1” a not acknowledge.  The next byte + ack is then processed unless there is either a “stop condition” or a “repeated start” condition.  A message is a collection of bytes that start with a “start condition” or “repeated start” and ending with a “stop condition” or “repeated start”.   The first byte of a message is the message address and message read/write information.

Because of the i2C data rate, the Arduino USB serial interface is not fast enough and has too much overhead to simultaneously transmit the data received.  Because of this, we have to store the bytes in Arduino memory, which isn’t very much (<<1024 bytes).  This also means that this memory will fill rather quickly.  This full condition is checked every time a new data byte has been accumulated.  When “full” is detected, the process shown above is aborted and the program outputs all of the accumulated messages that were received.

Now for some of the messages.   The following stream of messages occurs immediated upon powerup of both the NunChuk + Remote (with comments).  The syntax of each line is the message byte count (e.g “(2):” for two bytes) and each of the message bytes (in hex).   After each byte is either a “+” or “-” signifying acknowledge/not-acknowledge respectively.  The first byte of a message always contains the address of the device (bits 7:1) and bit 0 is either read (=1) or write (=0).  Bytes with 0xa4 or 0xa5 have been previously identified as NunChuk messages by others in their web sites.  I don’t know what is being addressed by all of the other addresses.  Keep in mind that several of the values in these messages are particular to my NunChuk and other NunChuks will likely have different values.  I’m assuming at this point that the sequence of messages won’t change with the values however.  It would be nice to get any confirmation to that assumption.

 .. looks like a non-NunChuk addressed device
(2):A0+ 00-
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 00-
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 00-
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 00-
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 00-
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 00-
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 00-
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 02+
(8):A1+ 00+ 00+ 00+ 00+ 00+ 00+ 00+
(2):A0+ 00+
(8):A1+ 1E- F5+ 5A+ 46+ 09+ CE+ 80-
(8):A1+ 2C+ E5+ E2+ F5- A8- D2- 30+
(2):A0+ 00-
(8):A1+ 2E+ CC+ 1A+ 63- 29- 0F- A0+
(8):A1+ FE+ 15+ C2+ B4- 01+ 88+ 3D-
(2):A0+ 00-
(8):A1+ FE- 04- F8+ 54- 09- D3+ 04-
(2):A1+ 80-

.. something happening with NunChuk addresses
(3):A4+ F0+ 55+
(3):A4+ FB+ 00+
(2):A4+ FA+
(7):A5+ 00+ 00+ A4+ 20+ 00+ 00-
(3):A4+ F0+ AA+
(8):A4+ 40+ AC+ B9+ 8B+ 35+ 1F+ C8+
(8):A4+ 46+ 28+ BE+ B2+ 89+ 07+ 18+
(6):A4+ 4C+ 19+ FF+ 01+ C6+

… the following looks like the calibration data being read
… this is the parameters for my NunChuk
(2):A4+ 20+
(9):A5+ 3F+ 6B+ 0C+ 67+ BD+ D2+ 5F+ 72-
(9):A5+ 3F+ 6B+ 0C+ 67+ BD+ D2+ 5F+ 72-
(2):A4+ 30+
(9):A5+ 3F+ 6B+ 0C+ 67+ BD+ D2+ 5F+ 72-
(9):A5+ 3F+ 6B+ 0C+ 67+ BD+ D2+ 5F+ 72-

.. some more non-NunChuk data
(2):B0+ 60+
(8):B0+ 00+ 08+ 00+ 03- 20+ 40+ 2A-
(3):B0+ 0E+ 00-
(3):B0+ 34+ 8C+
(2):B0+ 66+
(2):B0+ 60+
(2):B0+ 60+
(8):B0+ 00+ 08+ 00+ 03- 20+ 40+ 2A-
(3):B0+ 0E+ 00- (3):B0+ 34+ 8C+
(2):B0+ 66+
(2):B0+ 60+
(1):B0+
(8):B1+ FE- FD- FB- F7- EF- DF- BF-
(2):B1+ FE-

… the following 5 messages are then repeated, which is the polling of the accelerations and buttons
… of course the NunChuk data varies with changes of position of the NunChuk device
    (2):A4+ 00+
    (7):A5+ B0+ EB+ B3+ 1F+ 00+ B7-

… non-NunChuk messages (part of the 5 repeating messages)
    (1):B0+
    (8):B1+ FE- FD- FB- F7- EF- DF- BF-
    (2):B1+ FE-

————————————————————————————————-

Here is the program.  The way the “loop” routine was written was to make it possible to process the i2C messages at 400KHz.  It does not follow normal structured programming rules – there are lots of “goto” statements instead of for/while/do structured techniques.   I found that normal structured C code executed too slowly and missed the SDA data.

i2c_sniffer2

Advertisement

Tags: Arduino, i2C, i2c sniffer