CAN bus 11-bits or 29-bits ID - Page 1
Forum section: electronics / projects

author: unscripted
author_rank: Contributor
timestamp: February 26, 2023, 08:41:17 pm
content: I’m trying to build a high level protocol over CAN bus. It’s supposed to be lightweight because I really have very few nodes. What makes it a bit complicated is the fact that I need to transmit blocks of data greater than 8 bytes, and I can have both unicast (request/response) and publish (with or without ACK) frames. I’m thinking whether 11-bits or 29 bits ID fits better in terms of efficiency. At the end regardless I need to include the following information:Node Id or destination address (6 bits)Event tag/Opcode/Function code (command, request/response, publish, service ID)Frame type (According to CAN-TP, single frame, first frame, consecutive frame, flow control)Priority (3 bits) (Only for publish messages)If I go for 11 bits, then I need to use the data field for extra protocol information. While with 29-bits I may pack all that in ID field and use the data field, well, only for data.So, I guess this is a matter of how I want to handle the bits and the data in software. 29 bits may look overkill for my application, but it seems to me it could be more efficient. Any thoughts?

author: fastbike
author_rank: Regular Contributor
timestamp: February 27, 2023, 03:20:03 am
content: Quote from: unscripted on February 26, 2023, 08:41:17 pmTake a look at the NoCan protocol that sits on top of CanBus.It allows larger messages to be sent (64 bytes) and also supports application software update over the wire functionality.https://www.omzlo.com/articles/introduction-to-the-nocan-platform

author: Siwastaja
author_rank: Super Contributor
timestamp: February 27, 2023, 07:00:10 am
content: Quote from: unscripted on February 26, 2023, 08:41:17 pmIn that case, definitely go for 29-bit IDs.Really the only reason to use 11-bit IDs is when you simply don't have any use for more bits, so they are just extra overhead.Remember that 11- and 29-bit ID messages can coexist in the same bus. You can choose per-message basis, no need to make it a system-wide decision!

author: Rerouter
author_rank: Super Contributor
timestamp: February 27, 2023, 07:12:20 am
content: Go for 29, and increase the bit rate if your concerned about the overhead,Mixing them on the same bus can make things harder to diagnose as the cheap decoders only handle 1 at a time,

author: Siwastaja
author_rank: Super Contributor
timestamp: February 27, 2023, 07:20:20 am
content: Quote from: Rerouter on February 27, 2023, 07:12:20 amDidn't know such crappy adapters exist. Because the ID type used is just a bit in the message itself, actually building a product which supports both but not at the same time ismorework - they have to use some kind of state to detect the type of the first message and then actively break the support for other types of messages thereafter. Any example of such a thing?QuoteI had a case once where the payload bandwidth happened to be so close that with 29-bit messages at 1MBPS, timing was marginal. Solution was to use 11-bit IDs. Because the data points were naturally around 4-8 bytes in length, CAN FD was also not a helpful option because the headers are still transmitted at 1MBPS, so advantages are significant only if you can use longer frames.

author: Rerouter
author_rank: Super Contributor
timestamp: February 27, 2023, 07:32:11 am
content: saleae logic, my siglent scope and another tool we use for work, all treat mixed messages as invalid, I suspect because they are using positions to decode instead of the proper protocol defined method,