RawCAN Header, Sender Address and Packet Type

I am configuring another device to communicate with the SDC2160 in RawCAN mode. I know the header is 11 bits and the User Manual in section "Using RawCAN Mode" says the header is comprised of the "sender address (bits 0 to 6) and a packet type (bits 7 to 10)". I have searched the manual for any other mention of the "packet type" and could not find it. I'd like to know how I set the packet type, or if the SDC2160 firmware hard codes this to something. If hard coded, what is it? The CAN Send command only takes 8-bit values for the frame. Therefore, I don't see how to set the complete 11-bit header of a RawCAN frame. I'm guessing I can only set/read the 7-bit sender address, and the SDC2160 controls the packet type. But I need to know how to configure my external controller for the packet type bits, assuming the SDC2160 will use that in the filtering process?

Thanks.

Although Roboteq uses 7 bytes for module ID, you can actually extract the information in all of the bits (there are 12, not 11) of the CAN header (a.k.a. "arbitration field") using the commands available in MicroBasic. That may take a little bit-bashing. For example, my wheelchair CANbus system uses the 3 lowest bits to specify the target or source node (among a small number of nodes), the top 2 bits to specify a category (SetCommand, GetValue or Configuration), and the middle 6 bits to specify a name for particular data involved (in most cases the same names defined in the Constants.h of the Roboteq API). Whether your sending node can populate all 12 bits depends on its programming; I used Arduino Nano copies in my nodes.

CAN is a robust protocol, but it's not a simple one. MicroChip has some good documents covering both software and hardware issues, and I strongly suggest a thorough read of their "AN713 Controller Area Network (CAN) Basics".

Thank you for your reply. However, the BasicScript CAN Send command specifies 8 bit values for the header, bytecount and data bytes. Therefore how do you write an 11 bit header with an 8 bit argument? There is only one index associated with the header. Tomorrow I will try writing a larger bit value to the header index. Perhaps the documentation is simply wrong?

I would also argue that 11 bit CAN IDs have 11 bits and not 12. But that is beside the question i really have.

I should also make it clear that I am perfectly happy with only being able to specify a 7 bit header for RawCAN. But the manual says there is a 4 bit packet type field within the header. Who specifies what that is? I wrote a simple can message out to another device and saw that the packet type bits were all 0s. That's fine also. Just wondering if I have access to anything to change that, or am I guaranteed that it will always be 0s?

The arbitration field is 12 bits long, of which 11 bits is "identification" - I guess what you are calling the "header". So, semantics aside, we're both correct.

there is a 4 bit packet type field within the header. Who specifies what that is?

You do, but how you do that depends on what you are using to create the CAN frames. Knowing nothing about BasicScript I can't offer any help for that. You have to create some kind of "dictionary" for what you want your IDs to mean and then pack that into the proper bits of the header. CAN messages are broadcast to all connected modules and the CAN controllers or the microprocessor in each node can be set to interpret the ID and respond only to the messages appropriate for that module. The ID field is also use to establish message priority to arbitrate among messages that arrive simultaneously - the lower the numerical value of the entire field, the higher the message priority.

In classical CAN systems, messages that are meaningless for that module are filtered out right away and not even loaded into the input buffer of the CAN controller. They are not sent on to the processor (or rest of the MCU chip if the CAN controller is integrated in the MCU chip). Any bits that are not used for filtering can then be used to tell the recipient what to do with that message. In the Roboteq the only pre-computation filtering is on the bits reserved for node number, so all other interpretation of the ID field has to be done in the processor via a script. If node number is set to 0, there is no pre-computation filtering and you can then have the processor's script interpret all 11 bits, discarding irrelevant messages and knowing what to do with the ones it can use. You can also (as is done in CANOpen) use some of the data bytes to tell the MCU what to do with the message rather than actual data - CANOpen uses the ID field just to identify which section of its "dictionary" is to be used, so the precise purpose of the message needs to be in the data bytes.

I think that Bosch's philosophy in designing the original CAN spec was not only to make messaging very robust and interference resistant, but to minimize both the length of the frame and the amount of computation needed (in the slow MCUs and communication speeds of the day) while doing so. I think that's still a good way of doing things. Some things since then that have been overlain on top of that design may make life simpler for the person using CAN, but are not nearly so parsimonious - they work OK because processors and networks have gotten much faster.