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.
|Master||I2C Master Device|
|Slave||I2C Slave Device|
|Primary||Main Flight Computer|
|Secondary||Any I2C Master Device which is NOT the Main Flight Computer|
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.
|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|
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:
|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|
The following SensorTypes are Valid:
|SensorType String||SensorType HEX||Sensor||Description|
|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:
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.
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> …
|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|
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:
|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:
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.
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|
|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|