Week 6: NXT Sensor Data Spec

As I'm still waiting on the NXT, I went ahead and did some reading into how Lego currently communicates with their digital sensors. As we can directly control the I2C link we can implement the communications protocol however we want, but it's probably good to learn how it's performed as it is now.

Briefly summarizing what I learned, the Lego spec adheres to the master-slave rule that I2C normally operates with. The slaves will sit idly on the bus lines, happily processing whatever input they deal with. They will continue to do this until the NXT polls them for data, at which point they reply over I2C with a packet containing the relevant data. They then continue on without much pause. Now the interesting twist to this routine is that the digital sensors are capable of storing and receiving multiple data values.

To clarify, each sensor is responsible for maintaining a local bank of I2C accessible registers. These registers are updated with whatever data is relevant to the process that a particular sensor is performing. For example in a compass sensor, the sensor itself keeps a particular register updated with the current heading. When the NXT polls the compass, it will specify that register in its data request packet, at which point the sensor retrieves the register value and transmits it back to the NXT.

Fig 1. Simple visualization of the register bank concept.

This is interesting because it opens the possibility for multiple data values to be processed by a particular sensor, while still keeping them accessible from the NXT. Particularly in our case, we could fold multiple sensor functions into our Arduino, and still only require one I2C line to return all of them. This also opens the possibility of bidirectional communication, allowing the NXT to send messages to the sensor to be processed. These could be configuration values, or they could be commands. For example the NXT could signal a particular color to be turned on in an LED strip, or the SSID to search for in a WiFi module.

A quick aside: just to make sure the ChipKit is working I uploaded some basic Arduino example programs to the ChipKit, everything seems to be fully compatible.

Idea: Wireless sensor capacity is possible, by linking an Arduino to the output of an I2C line as we're doing now. However instead of the sensor being locally attached, the Arduino can wirelessly interface through an XBee or WiFly controller, or even a Spark Core.