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.

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:

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

Flight State Commands

Node Commands

General Node Data & 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.

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:

Virtual Node ID	Reserved	Verb	Noun	RTR	DLC	Data Bytes
5 bits	1 bit	2 bits	3 bits	0	# bytes	0 - 8 bytes

"Back Channel" (BC) messages:

Virtual Node ID	Reserved	Verb	Noun	RTR	DLC	Data Bytes
5 bits	1 bit	2 bits	3 bits	1	3.125 bits	0 bytes

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.

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.

Priority	Back Channel (RTR)	Direction	Verb
00 - Highest	0	To Node	ACTION
	1	From Node	ACTIONRESPONSE
01 - High	0	From Node	INFO
	1	To Node	TEST
10 - Low	0	To Node	CONTROL
	1	From Node	CONTROLRESPONSE
11 - Lowest	0	From Node	DATA
	1	To Node	GET

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.

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.

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.