J1939 support

[HappyDias]

Hello

I am fairly new to CAN messaging and have inherited a codebase that uses this library to grapple with a CAN bus that uses the SAE J1939 protocol.

I quite like this library's feature of parsing a .kcd file and allowing control of the signals and sending of messages via constructs over the raw channel. It abstracts away a lot of the things I don't wish to care about.

In all my searching I was unable to find any kcd support for the SAE J1939 protocol apart from having to programmatically define every possible unique id for the messages (thus defeating the purpose of the format which is readability). So I now expect that the J1939 protocol is something that is added in a different part of the communication.

My questions are the following:

1. Does this library offer support for the J1939 protocol?
2. Am I correct in assuming that the kcd format is agnostic when it comes to the protocol?
3. Are there any code examples of this library using the J1939 protocol?
4. If the answer to question 2 is 'no', would you be able to point me in the direction of a kcd file that does in fact define signals and messages using said protocol?

Many thanks in advance!

[sebi2k1]

AFAIK understand the .kcd doesn't support J1939 at all, even though @corn3lius added some quirks for his own project.

Anyhow, I understand you basically just want to decode/encode message respecting the node id encoded in the ext. CAN id, that shouldn't be a big problem to extend. We could just provided a j1939 flag and the database will use the node id from the .kcd definition to adapt the CAN id.

I did implememented once the ISOBUS (based on j1939) but I don't remember (except the transport protocol) what else you may need to properly work on a j1939 system. If you got some details I can look into it.

[HappyDias]

Hi @sebi2k1, thanks a lot for the answer!

Unfortunately, I don't have much more details, I was actually considering making my own .kcd file pending a positive answer to these questions. All I currently have is a google translated .doc of a chinese spec sheet wherein they state to have implemented the protocol.

From what I understood from the protocol, the ext. CAN id is divided into the following (info gathered from here), from most to least significant bit(s):

• Priority (3 bits),
• Reserved (1 bits),
• Data page (1 bits),
• PDU format (8 bits),
• PDU specific (8 bits),
• Source address (8 bits)

I'm assuming that the message ID from the .kcd file would go into the PDU format category, though I would need to do some more checking for my particular case to be sure.

Anyway, I'm just gauging interest here and like you said, since .kcd is not supposed to handle J1939, it is probably better if I use the raw sockets and implement something myself.

Thanks again for answering my questions.

[HappyDias]

May have been too quick to answer. Thinking about it a bit more, I do see a problem here. The ID of the message from the .kcd file doesn't really "go" anywhere in the J1939 definition. It is simply unusable at that point.

With the j1939 flag the following would be required:

• When decoding a received frame, it is simply a matter of extracting the different bits and assigning them to the aforementioned parts of the ext. CAN id.
• When encoding a frame, it would be trickier but it should be a question of requesting from the user the aforementioned bits of the ext. CAN id every time a message is sent.

But none of these requirements seem to harmonize well with the .kcd database code, since you can't really do database.messages anymore as the ID is no longer usable. The .kcd specification does allow for the Producer/Consumer markup to be added to a message (although, Consumer seems to only be usable in a Multiplex environment), could these be used to validate the sending of a message?

Regardless, there would still be a need for the user to specify whether a message is broadcast or sent to a specific node. So that is already more functionality to implement.

[sebi2k1]

Correct, we would have to introduce a J1939-light-mode:

• apply a filter on message.id when receiving e.g. messages[0x1234578 & 0xFFFFFF00]
• add node-id when sending (from .kcd file) e.g. message.sendToNodeId(message, node_id)

This way we can add the node_id when sending and receiving. We could do the same with the other fields (except PGN and so) by just providing a ID mask when receiving, so you define basically only the PGN in .kcd and priority/sa/da are filtered when applying the decoding rule in database service.

[HappyDias]

That does sound like it would suit most of my needs. While node_id would work, I'd say that you could keep it more broad and have the user specify the PS and SA bytes.

Question is, should it be implemented though? This would be, as you said, a J1929-lite mode, not an actual implementation of the protocol, since it does not allow the PGN to be altered. Unless it fulfills the needs of A LOT of people (that number is currently only 1 - me), I'm not sure it should be something fro you guys to spend too much time on.

This sounds more like a job for a fork or a new library built on top of this one.

Anyways, food for thought, I could look into the source code and see if I could come up with a PR that implements these changes, when/if I get the time.

[sebi2k1]

Keep me postet if you have a patch.

[pbegg]

Did this implementation ever gain any traction with yourself @HappyDias? I am looking for a similar solution where we only need to monitor a J1939 network for remote telemetry purposes.