I2C Communications Protocol

If your device operates on the main flight computer I2C bus, it must adhere to these protocol standards. For more information on hardware design standards, and general information on the I2C bus, see the Design Guide.
This page only applies to intelligent sub-devices. For sensors, and other I2C devices which operate simply as slaves on the I2C bus, their control and information is to be handled by the module which includes them. The main flight computer must be made aware of these module's presence and address using the protocol outlined below.


Term Definition
Master I2C Master Device
Slave I2C Slave Device
Primary Main Flight Computer
Secondary Any I2C Master Device which is NOT the Main Flight Computer

General Call

In order for the Master Flight Computer to initiate communications with all secondary control processors simultaneously, a general call must be implemented. This general call is separate from the I2C specification general call, and places more stringent requirements on the secondary control processors. This communication profile can be for informational purposes, or can initiate mass-operations. When this operation takes place, the Main Flight Computer will send a Write-Mode command to the I2C bus, addressed to I2C address 0000001. The byte following the address byte will indicate the command. Depending on the command issued, the Main Flight Computer will either follow with more data, or release the I2C bus.

General Call Command Summary

Command Action Following Data Flight Computer Action
00000001 Secondary Device Capability Discovery Master I2C Address Enters Slave Mode Listening State
00000010 Soft Reset of Secondary Devices None Waits for Slave Device Wakeup Message
00000011 Secondary Device Low Power Operation None None
00000100 Secondary Device Low Power Wakeup None None

Secondary Device Capability Discovery

When the Primary wishes to discover the system capabilities of the running flight-stack, it will initiate a Secondary Device Capability Discovery. After the Primary has released control of the I2C bus, the Secondary devices must seize control of the bus, and initiate a response to the Primary I2C Address (The primary's I2C address will be bits [6:0] of the 2nd byte transmitted). If another device is already using the bus to communicate its capabilities, your device must be able to properly arbitrate the bus, surrender control of the bus, and retry.
This response must be in the following format:

<Primary Address>+W ; 00000001 ; <Secondary Address> ; <Secondary DeviceType> ; <Sensor String> ; <Sensor Addresses> ; …

The Secondary address is the I2C address to which the Secondary will respond. The DeviceType indicates the types of commands (to be described below) to which the secondary device will respond. The remainder of the communication is to describe the sensors which are attached to the Secondary Device (this includes I2C and Non-I2C Sensors).

The following DeviceTypes are valid:

DeviceType String Device Description
00000001 Communications Any device designed to communicate with the outside world.
00000010 Battery Manager Any device which monitors power and can release battery payloads as ballast.
00000011 Ballast Manager Any device which can release ballast.
00000100 GPS Any device which can return geolocation information.
00000101 Sensor Platform Any device which is designed to specifically support sensors which aren't attached to the main I2C bus.
10101010 Termination Any device dedicated to terminating the flight.

The Sensor String is to have the following formatting:

Data: Number of Sensors SensorType
Bit: 7 6 5 4 3 2 1 0

The following SensorTypes are Valid:

SensorType String SensorType HEX Sensor Description
00001 0x1 Temperature Sensor
00010 0x2 Pressure Sensor
00011 0x3 Accelerometer
00100 0x4 Humidity
00101 0x5 Gyro
00110 0x6 Magneto
00111 0x7 Force
01000 0x8 Video Recorder
01001 0x9 Dust Sensor
01010 0xA Xbee Temp Sensor Top of the balloon

A sensorType string MUST be followed by a number of address bytes equal to the number of sensors indicated by bits [7:5] of the Sensor String. The address bytes which follow must be formatted thusly:

Data: I2C Addressable? Address
Bit: 7 6 5 4 3 2 1 0

Bit 7 is to be equal to 1 if the sensor is attached to the Main I2C bus, and the following 7 bits must represent the sensor's I2C address. If the sensor is not attached to the main I2C bus, Bit 7 must be equal to 0, and the following 7 bits must represent a Device Local address which the Primary can request data from the sensor. If the sensor is inaccessible to the Primary, the following 7 address bit must be equal to 0.

Directed Communication: General Commands which All Slave Devices Must Implement

There are a number of commands which must be implemented by all devices in order to discover, in more details, the capabilities of a system. Notice that the above communication only allows the Primary controller to know the, number, type, and location of sensors which may or may not be attached to the I2C bus. The Primary, at its discretion, will ignore some sensors, while expressing interest in others. These commands provide some general control over secondary devices, as well as allowing for more detailed discovery of protocol functionality.

A Data Transfer of this type will appear as follows from the perspective of the Master device:
<Secondary Address>+W ; <Directed Command> ; <Directed Data> ; (Bus is Released) ; <Primary Address>+W ; <Response> …

Directed Communication Command Summary

Command Command Hex Directive Data Sent Response Summary
00000010 0x2 Soft Reset None Response depends on device capability
00000011 0x3 Enter Low Power Mode None Response depends on device capability
00000100 0x4 Exit Low Power Mode None Response depends on device capability
10000001 0x81 Sensor Probe Sensor Address Sensor Information String

Sensor Probe

Using this directive, the Primary Control can request more information about the sensors attached to a given secondary. The data request will appear as the sensor address string described in the Device Discovery second, including the locally addressable information. The first byte of the response is a compatibility string, which will be different for each type on sensor.
The Table Below describes the Compatibility String for some different sensors:

Compatibility String Temperature Pressure Accelerometer Humidity Gyro Magneto Force
00000000 No Data Available
00000001 Locally Attached Device, Interfacing information to follow
00000010 TMP100 or Compatible BMP085 or Compatible

If the device is locally attached, then a string must follow the compatibility string which describes how the data received from a sensor inquiry is to be interpreted. The data following the compatibility string must be formatted as follows:
<Bits of Accuracy> ; <Minimum Sampling Time in Milliseconds> ; <Unit String> ; <Highest Possible Reading in Units> ; <Lowest Possible Reading in Units>

The table below gives an example of units for different Sensor Types:

Unit String Temperature Pressure Accelerometer Humidity Gyro Magneto Force
00000000 Degrees C Millibars/HectoPascals G
00000001 Degrees F KiloPascals M/s^2
00000010 Kelvin Pascals

Ground Support Board

The ground support board's I2C Address is 0b0000111, and currently responds to one command: 0x05. If this command is sent, it will print the remaining bytes sent via I2C as ASCII.

White Star I2C Addresses

The following I2C addresses have been used by other devices existing on the main I2C bus, and cannot be reused.
Please add your module's address here, starting at the next available address after 110.

* Devices marked by an Asterisk (*) are software controlled in their address. If your software implements communications with such a device, it would be advantageous to avoid statically calling these device addresses.

Device Address Arduino Hex Address Hex Address Location
TMP 100 0b1001111 0x4f Main Flight Computer
DS3231 0b1101000 0xD0 0x68 Main Flight Computer
BMP085 0b1110111 0x77 Main Flight Computer
Main Flight Computer* 0b0000101 0x0A 0x05 Main Flight Computer
Primary Cutdown* 0b0000110 0x06 Primary Cutdown Module
Ground Support Board* 0b0000111 0x0E 0x07 Ground Support
Communications Module* 0b0001000 0x10 0x08 Comm Module
Ballast Controller* 0b0001001 0x12 0x09 Ballast
AD7992* 0b0100000 0x20 Voltage Sensor
Int Sensor Module* 0b0001010 0x14 0x0a Internal Sensor Module
Tmp100* 0b1001011 0x96 0x4b External Sensor Module
TMP101* 0b1001001 0x49 Battery for Thermostat
24AA256 0b1010000 0xA0 0x50 I2C EEPROM on Comm Controller
protocolguide.txt · Last modified: 2012/04/15 19:00 by steamfire
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki