openinverter forum

I'm totally new to CABbus, but have extensive experience reverse engineering other things.
I was wondering if there was a general convention in car applications for how Acks are generated.
Seems that there are many cases where sensors etc. spit out their data, and multiple devices can make use of that data.
Is there any convention on which nodes send Acks to these packets?
Possible scenarios I can envisage are
1) All devices Ack all received packets
2) All devices which are interested in that ID send an Ack (I'd imagine it doesn't look at validity of parameters etc. as there isn't time)
3) One specific "primary" device that makes use of that ID sends an Ack
4) Only the gateway sends an Ack
5) It's a big old mess, every manufacturer does it different, with lots of fudges and special cases

If(2) is the case, it seems that would be very useful for reversing a device to see which IDs it's interested in.

I just checked the MCP2515 datasheet and it says: "The final field is the two-bit Acknowledge (ACK) field. During the ACK Slot bit, the transmitting node sends out a recessive bit. Any node that has received an error-free frame acknowledges the correct reception of the frame by sending back a dominant bit (regardless of whether the node is configured to accept that specific message or not)."

Wikipedia seems to agree? At least it doesn't say otherwise: "Each node that receives the frame, without finding an error, transmits a dominant level in the ACK slot and thus overrides the recessive level of the transmitter."

If someone knows about automotive stuff specifically, that would be useful.

OK so that implies that Acks are a low-level CAN thing, as opposed to a higher level application-dependent behaviour.

It seems to be low level, yes. A CAN controller can also be configured to 'silent' mode where it will not send ACK bits -- this can be useful if you don't want to disturb a system but still want data.
The MCP2515 will go into an error state if it does not receive any ACK bits after 255(?) messages - I believe it's "bus-off" state. It's a pain when testing if you don't want to have to hook up something else on the bus.

Additionally, when no one sends an ACK the sender will repeat the message indefinitely. Happens if you have your DUT hooked up to only a logic analyzer. Can only be fixed by recompiling the senders software to setup CAN hardware to not retransmit lost frames.

johu wrote: ↑Tue Jun 29, 2021 4:26 pm Additionally, when no one sends an ACK the sender will repeat the message indefinitely. Happens if you have your DUT hooked up to only a logic analyzer. Can only be fixed by recompiling the senders software to setup CAN hardware to not retransmit lost frames.

..or maybe just hook any other CAN device on the bus to genaerate the ACKs ?

Yes, if you have one at hand

It's a feature which is done on hardware level but is controlled by software. I think if you don't set the RTR bit it won't happen anyway. CanBus is a broadcast network so everybody writes and reads.
Hardware takes care of the implied challenges.