CAN telemetry structure

Info and Discussion about the ESC32 hardware and software

CAN telemetry structure

Postby finncarlsvi » Tue Oct 27, 2015 1:54 am

Hello,

I have an ESC32 hooked up to a CAN analyzer and am trying to figure out the message structure to communicate with the ESC. Is there any documentation on this anywhere?

I can't imagine this hasn't been asked before, but I just can't find any info on the subject (it's also hard to search for the word CAN without getting the wrong results). I apologize in advance for a possible repost.

Cheers
Finn
finncarlsvi
 
Posts: 3
Joined: Tue Oct 27, 2015 1:44 am

Re: CAN telemetry structure

Postby aBUGSworstnightmare » Tue Oct 27, 2015 7:24 am

Hi Finn,

the firmware for ESC32V2 is open source, so why do you want to go the 'hard 'n dirty' road by reverse-engineering the protocol with a CAN analyzer if you can have a look at the source code used to generate the messages?

Look here for the sources https://github.com/bn999/esc32

You may also want to look at the AQ FW here https://github.com/bn999/autoquad

Cheers
Joerg
aBUGSworstnightmare
 
Posts: 1460
Joined: Fri Jun 22, 2012 5:24 pm

Re: CAN telemetry structure

Postby finncarlsvi » Tue Oct 27, 2015 7:51 am

Hi Joerg,

Thanks for your reply. Sorry, I worded that poorly. I am looking at the source to try and figure out the message structure. Then testing out different commands with the analyzer.

But my understanding of C isn't good enough for me to reconstruct a mental image of how CAN commands are created/processed.

I was hoping there was some documentation. I'll just keep looking at the source and the answer will fall out like usual :)

Cheers
finncarlsvi
 
Posts: 3
Joined: Tue Oct 27, 2015 1:44 am

Re: CAN telemetry structure

Postby bn999 » Tue Oct 27, 2015 4:44 pm

Unfortunately, the type of documentation you are looking for does not exist. The structure of the CAN packet header is outlined in the can.h header file. Here are the field definitions:

Code: Select all
// Logical Communications Channel
// 2 bits [28:27]
#define CAN_LCC_MASK       ((uint32_t)0x3<<30)
#define CAN_LCC_EXCEPTION   ((uint32_t)0x0<<30)
#define CAN_LCC_HIGH       ((uint32_t)0x1<<30)
#define CAN_LCC_NORMAL       ((uint32_t)0x2<<30)
#define CAN_LCC_INFO       ((uint32_t)0x3<<30)

// Target Type
// 1 bit [26:26]
#define CAN_TT_MASK       ((uint32_t)0x1<<29)
#define CAN_TT_GROUP       ((uint32_t)0x0<<29)
#define CAN_TT_NODE       ((uint32_t)0x1<<29)

// Function ID
// 4 bits [25:22]
#define CAN_FID_MASK       ((uint32_t)0xf<<25)
#define CAN_FID_RESET_BUS   ((uint32_t)0x0<<25)
#define CAN_FID_ACK       ((uint32_t)0x1<<25)
#define CAN_FID_NACK       ((uint32_t)0x2<<25)
#define CAN_FID_CMD       ((uint32_t)0x3<<25)
#define CAN_FID_GET       ((uint32_t)0x4<<25)
#define CAN_FID_SET       ((uint32_t)0x5<<25)
#define CAN_FID_REPLY       ((uint32_t)0x6<<25)
#define CAN_FID_REQ_ADDR    ((uint32_t)0x7<<25)
#define CAN_FID_GRANT_ADDR  ((uint32_t)0x8<<25)
#define CAN_FID_ERROR       ((uint32_t)0x9<<25)
#define CAN_FID_PING       ((uint32_t)0xa<<25)
#define CAN_FID_TELEM       ((uint32_t)0xb<<25)

// Data Object Code
// 6 bits [21:16]
#define CAN_DOC_MASK       ((uint32_t)0x3f<<19)

// Source ID
// 5 bits [15:11]
#define CAN_SID_MASK       ((uint32_t)0x1f<<14)

// Target ID
// 5 bits [10:6]
#define CAN_TID_MASK       ((uint32_t)0x1f<<9)

// Sequence ID
// 6 bits [5:0]
#define CAN_SEQ_MASK       ((uint32_t)0x3f<<3)


AQ has a strategy for using CAN that is a departure from traditional approaches. The goal was to be able to have extremely high priority / frequency messages at the same time be able to use all excess bandwidth for low priority "bulk" streams like serial data communications. The logical channels in descending priority order are EXCEPTION, HIGH, NORMAL & INFO. All nodes must first register with the master (network ID 0) to received a unique network identifier before they are allowed to officially join the bus as an active node. There is also a sequence id that is used to keep track of multi-message state and reception acknowledgment. This is all quite different from standard CAN usage. Each node type can define its own Data Object Codes suited to its particular application. For instance, the master can assign ESCs to groups of various sizes to concentrate large number of actuator commands into single messages for increased decimination speed and bandwidth reduction.

As Jeorg said, you will need to follow the C code to understand the rules of use. Between ESC32, the FC and PDB code, there are a lot of good examples of most of the use scenarios. There is also room for expansion of the protocol for additional, unforeseen requirements.
bn999
 
Posts: 1559
Joined: Thu Jun 21, 2012 11:40 pm

Re: CAN telemetry structure

Postby Fritz » Tue Mar 14, 2017 2:11 pm

finncarlsvi wrote:Hi Joerg,

Thanks for your reply. Sorry, I worded that poorly. I am looking at the source to try and figure out the message structure. Then testing out different commands with the analyzer.

But my understanding of C isn't good enough for me to reconstruct a mental image of how CAN commands are created/processed.

I was hoping there was some documentation. I'll just keep looking at the source and the answer will fall out like usual :)

Cheers


Hi Finn,

I'm stuck at the same point as you were when you created this thread...
My aim is to combine a ESC32v3 with a Pixhawk FC (which uses UAVCAN) over CAN, but as far as i know, ESC32v3 are not supporting UAVCAN.

Any chance you finally found a good documentation on the CAN-protocol used by the ESCs? Or a less c-heavy solution than looking through the code?

Cheers
Fritz
Fritz
 
Posts: 3
Joined: Tue Mar 14, 2017 1:34 pm


Return to ESC32

Who is online

Users browsing this forum: No registered users and 5 guests