Protocol Definitions
Copyright © 2012 Keith Packard
+
AltOS Companion PortProtocol Definitions
Copyright © 2012 Keith Packard
| Revision History |
|---|
| Revision 0.1 | 13 January 2012 |
| Initial content |
| Revision History |
|---|
| Revision 0.1 | 13 January 2012 |
| Initial content |
Many Altus Metrum products come with an eight pin Micro MaTch
connector, called the Companion Port. This is often used to
program devices using a programming cable. However, it can also
@@ -12,20 +12,20 @@
(hence the name).
The Companion Port provides two different functions:
-
-
+
Power. Both battery-level and 3.3V regulated power are
available. Note that the amount of regulated power is not
huge; TeleMetrum contains a 150mA regulator and uses, at
peak, about 120mA or so. For applications needing more than
a few dozen mA, placing a separate regulator on them and
using the battery for power is probably a good idea.
-
-
+
SPI. The flight computer operates as a SPI master, using
a protocol defined in this document. Companion boards
provide a matching SPI slave implementation which supplies
telemetry information for the radio downlink during flight
-
-
2. Companion SPI Protocol
+
+
2. Companion SPI Protocol
The flight computer implements a SPI master communications
channel over the companion port, and uses this to get
information about a connected companion board and then to get
@@ -42,11 +42,11 @@
Because of the limits of the AVR processors used in the first
two companion boards, the SPI data rate is set to 187.5kbaud.
-
This section first defines the command message format sent from
the flight computer to the companion board, and then the various
reply message formats for each type of command message.
-
Table 1. Companion Command Message
| Offset | Data Type | Name | Description |
|---|
| 0 | uint8_t | command | Command identifier |
| 1 | uint8_t | flight_state | Current flight computer state |
| 2 | uint16_t | tick | Flight computer clock (100 ticks/second) |
| 4 | uint16_t | serial | Flight computer serial number |
| 6 | uint16_t | flight | Flight number |
| 8 | | | |
Table 2. Companion Command Identifiers
| Value | Name | Description |
|---|
| 1 | SETUP | Supply the flight computer with companion
+ Table 1. Companion Command Message | Offset | Data Type | Name | Description |
|---|
| 0 | uint8_t | command | Command identifier | | 1 | uint8_t | flight_state | Current flight computer state | | 2 | uint16_t | tick | Flight computer clock (100 ticks/second) | | 4 | uint16_t | serial | Flight computer serial number | | 6 | uint16_t | flight | Flight number | | 8 | | | |
Table 2. Companion Command Identifiers | Value | Name | Description |
|---|
| 1 | SETUP | Supply the flight computer with companion
information | | 2 | FETCH | Return telemetry information | | 3 | NOTIFY | Tell companion board when flight state
changes |
The flight computer will send a SETUP message shortly after
@@ -74,7 +74,7 @@
use this to change data collection parameters, disabling data
logging until the flight starts and terminating it when the
flight ends.
- Table 3. SETUP reply contents | Offset | Data Type | Name | Description |
|---|
| 0 | uint16_t | board_id | Board identifier | | 2 | uint16_t | board_id_inverse | ~board_id—used to tell if a board is present | | 4 | uint8_t | update_period | Minimum time (in 100Hz ticks) between FETCH commands | | 5 | uint8_t | channels | Number of data channels to retrieve in FETCH command | | 6 | | | |
+ Table 3. SETUP reply contents | Offset | Data Type | Name | Description |
|---|
| 0 | uint16_t | board_id | Board identifier | | 2 | uint16_t | board_id_inverse | ~board_id—used to tell if a board is present | | 4 | uint8_t | update_period | Minimum time (in 100Hz ticks) between FETCH commands | | 5 | uint8_t | channels | Number of data channels to retrieve in FETCH command | | 6 | | | |
The SETUP reply contains enough information to uniquely
identify the companion board to the end user as well as for
the flight computer to know how many data values to expect in
@@ -85,12 +85,12 @@
bit-wise inverse of board_id. Current companion boards use
USB product ID as the board_id, but the flight computer does
not interpret this data and so it can be any value.
- Table 4. FETCH reply contents | Offset | Data Type | Name | Description |
|---|
| 0 | uint16_t | data0 | 0th data item | | 2 | uint16_t | data1 | 1st data item | | ... | | | |
+ Table 4. FETCH reply contents | Offset | Data Type | Name | Description |
|---|
| 0 | uint16_t | data0 | 0th data item | | 2 | uint16_t | data1 | 1st data item | | ... | | | |
The FETCH reply contains arbitrary data to be reported over
the flight computer telemetry link. The number of 16-bit data items
must match the 'channels' value provided in the SETUP reply
message.
- 4. History and Motivation
+ 4. History and Motivation
To allow cross-programming, the original TeleMetrum and
TeleDongle designs needed to include some kind of
connector. With that in place, adding the ability to connect
|