summaryrefslogtreecommitdiff
path: root/CanBusIDs.mdwn
blob: df9c19a3c43d1f3fa76ef8562118183419b26c08 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
# <a name="CAN Message Identifiers"></a> CAN Message Identifiers

For information on the CAN bus, please see: [[CanBusLinks]]. You'll need to understand how the CAN bus works in order for any of this to make sense.

## <a name="Overview of choosing Message IDs"></a> Overview of choosing Message IDs:

Each CAN message has:

- 11 bits of "Message Identifier": 0x000 - 0x7FF / 0 - 2047
- 1 bit of RTR (request for transmit), which when set forces 0 bytes of data
- 4 bits of DLC (Data Length Code), which may only take on the values 0 - 8 (so it's really 3.125 bits!)
- 0 - 8 bytes of data.

What's the best way to use these bits? Is it possible to make the message ID's more "human readable"? Here's our best try, after literally hours of discussion:

## <a name="Virtual Node IDs"></a> Virtual Node IDs

Here's a list of "all" the messages we could think of could ever be broadcast on the LV2x series of rockets:

> External commands
>
> <br />
>
> Flight State Commands
>
> <br />
>
> Node Commands
>
> <br />
>
> General Node Data &amp; Commands:
>
> - IMU
> - GPS
> - Recovery
> - Temperature
> - Pressure
> - Magnetometer
> - Power
> - Battery
> - Umbilical
> - ATV Control
> - Payload
> - Power amp control

So here are around 12 different "data sources" on LV2 which probably requires the same number of message IDs to control them. However, many of these "data sources" may have multiple units, such as one or more GPS units or multiple temperature readings. Or there may be one physical node with multiple data sources - e.g., the power system may have the battery, power and umbilical systems all on one board. We decided to partition the top 5 bits of the 11 bit CAN ID as a "virtual node ID". Virtual nodes are basically any subfunction which can be functionally partitioned away from other functions. Since 2^5 = 32, we can have up to 32 virtual nodes.

## <a name="Re-partitioning the ID + RTR + D"></a> Re-partitioning the ID + RTR + DLC + Data

We've also created new symantics for the CAN bus bits. They fall in two flavors:

Standard messages:

<table border=1 cellpadding=0 cellspacing=0>
  <tr>
    <td align="center"> Virtual Node ID </td>
    <td align="center"> Reserved </td>
    <td align="center"> Verb </td>
    <td align="center"> Noun </td>
    <td align="center"> RTR </td>
    <td align="center"> DLC </td>
    <td align="center"> Data Bytes </td>
  </tr>
  <tr>
    <td align="center"> 5 bits </td>
    <td align="center"> 1 bit </td>
    <td align="center"> 2 bits </td>
    <td align="center"> 3 bits </td>
    <td align="center"> 0 </td>
    <td align="center"> # bytes </td>
    <td align="center"> 0 - 8 bytes </td>
  </tr>
</table>

"Back Channel" (BC) messages:

<table border=1 cellpadding=0 cellspacing=0>
  <tr>
    <td align="center"> Virtual Node ID </td>
    <td align="center"> Reserved </td>
    <td align="center"> Verb </td>
    <td align="center"> Noun </td>
    <td align="center"> RTR </td>
    <td align="center"> DLC </td>
    <td align="center"> Data Bytes </td>
  </tr>
  <tr>
    <td align="center"> 5 bits </td>
    <td align="center"> 1 bit </td>
    <td align="center"> 2 bits </td>
    <td align="center"> 3 bits </td>
    <td align="center"> 1 </td>
    <td align="center"> 3.125 bits </td>
    <td align="center"> 0 bytes </td>
  </tr>
</table>

Where:

- Virtual Node ID is the "functional subsystem" involved: Pyrotechnic, APS, IMU, GPS, etc. One physical node may have many virtual node IDs.
- Reserved is unused right now and should be set to 1 (recessive).
- Verb is two bits and indicates what we want to do.
- Noun is three bits and refers to a specific thing that the verb acts on.
- RTR bit: 0 = standard message, 1 = "back channel" message
- DLC: the number of data bytes in a standard message, 3.125 bits (0..8) of useable data in a BC message.
- Data bytes: 0 - 8 in a standard message, forced to be zero for a BC message

**_Standard Messages_** have the RTR - or as we relabel it, the "BC" - bit cleared (0, dominant). The DLC then is just what you expect - the number of data bytes in the message. And of course you can have 0-8 bytes of data.

**_Back Channel_** messages have the BC bit set (1, recessive). Since a message wih the RTR bit set may have no data according to the spec, the DLC becomes useless... _except_, we can use it to cary information. The value can be set from 0 to 8, allowing a limited application specific vocabulary.

## <a name="Verbs"></a> Verbs

The Verb is ACTION, INFO, CONTROL, and DATA when operating in the normal direction, and when going back the other direction (thanks to the RTR bit) these become respectively ACTION\_RESPONSE, TEST, CONTROL\_RESPONSE, and GET. The most common messages we'll see are ACTION, INFO, GET, and DATA.

<table border=1 cellpadding=0 cellspacing=0>
  <tr>
    <th align="center" bgcolor="#99CCCC"><strong> Priority </strong></th>
    <th align="center" bgcolor="#99CCCC"><strong> Back Channel (RTR) </strong></th>
    <th bgcolor="#99CCCC"><strong> Direction </strong></th>
    <th bgcolor="#99CCCC"><strong> Verb </strong></th>
  </tr>
  <tr>
    <td> 00 - Highest </td>
    <td align="center"> 0 </td>
    <td align="center"> To Node </td>
    <td> ACTION </td>
  </tr>
  <tr>
    <td>
    </td>
    <td align="center"> 1 </td>
    <td align="center"> From Node </td>
    <td> ACTION_RESPONSE </td>
  </tr>
  <tr>
    <td> 01 - High </td>
    <td align="center"> 0 </td>
    <td align="center"> From Node </td>
    <td> INFO </td>
  </tr>
  <tr>
    <td>
    </td>
    <td align="center"> 1 </td>
    <td align="center"> To Node </td>
    <td> TEST </td>
  </tr>
  <tr>
    <td> 10 - Low </td>
    <td align="center"> 0 </td>
    <td align="center"> To Node </td>
    <td> CONTROL </td>
  </tr>
  <tr>
    <td>
    </td>
    <td align="center"> 1 </td>
    <td align="center"> From Node </td>
    <td> CONTROL_RESPONSE </td>
  </tr>
  <tr>
    <td> 11 - Lowest </td>
    <td align="center"> 0 </td>
    <td align="center"> From Node </td>
    <td> DATA </td>
  </tr>
  <tr>
    <td>
    </td>
    <td align="center"> 1 </td>
    <td align="center"> To Node </td>
    <td> GET </td>
  </tr>
</table>

Examples:

- `CID_APS_ACTION_SWITCH[DLC=1][DATA=0x3f]` - Standard message, turns on APS power switch
- `CID_IMU_DATA_GYRO[DLC=6][DATA=RR PP YY]` - standard message, roll, pitch yaw gyro data
- `CID_IMU_GET_GYRO[BCDATA=0b0001]` - BC message to turn on gyro data (DLC's LSB = "on/off")

Notes:

- ACTION requests behavior from the CAN node (which it may choose to deny based on state model)
- ACTION\_RESPONSE is a quick and optional way to respond to an ACTION request.
- INFO is like error messages and TEST responses.
- TEST requests specific test response (responds with INFO)
- CONTROL is like ACTION but used for debuging - usually cannot be denied by the CAN node. CONTROL messages may be ignored if not in debug mode.
- CONTROL\_RESPONSE is a quick and optional way to respond to a CONTROL request
- DATA is the way that CAN nodes typically blabber lots of data to everyone and no one in particular
- GET is the means by which DATA can be activated or squelched for a given message.

## <a name="Nouns"></a> Nouns

Nouns are specific to the virtual node. For example, the IMU has a ACCEL noun, which refers to data from the accelerometers, as well as commands to turn on and off those broadcast accelerometer data messages.

## <a name="Finding Specific IDs"></a> Finding Specific IDs

The actual IDs are kept in CVS: <http://cvs.psas.pdx.edu/>. For access to the CVS server, you can just hit the previous URL with your browser, use CVS anonymously, or use your PSAS CVS account if you have one.

07/23/2003 - Right now Dave C and Andrew are discussing how to go about putting all the CAN IDs into one large file, accessable to everyone in the CVS tree (java and C alike), like Jamey originally thought up with the m4 script/macro/thing. More details, including a link, when that process is done.

----

**_Note_** : Removed old CAN ID's 07/23/2003. See page versions before this one if you need the old IDs.