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:

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:

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


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.


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
01 - High 0 From Node INFO
1 To Node TEST
10 - Low 0 To Node CONTROL
11 - Lowest 0 From Node DATA
1 To Node GET




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: 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.