×

Sale ends todayGet 30% off any course (excluding packages)

Ends in --- --- ---

J1939 vs CAN 2.0B

CANBus Communications Decoded

Forum Posts

Courses

Blog

Tech Articles

Discussion and questions related to the course CAN Bus Communications Decoded

= Resolved threads

Author
4231 Views

Hope you can help me out understanding J1939. So far I've worked with CAN2.0 A and B. However, now I need to integrate a J1939 device onto a CAN2.0 A/B bus and I am getting confused.

As far as I understand, technically CAN2.0B and J1939 are identical in terms of message layout. However what I do not understand yet is the whole concept of claiming and the protocol data unit (PDU) 1 vs 2.

So my questions are:

- Can I just add a J1939 device onto a CAN2.0 bus as long as I send 29-bit messages to it?

- What is your favorite read on learning about J1939?

PS. I am doing the CAN course, but have this question now already. Perhaps it will be answered in the course as well.

J1939 is a higher level protocol that sits on top of the CAN protocol. It uses CAN for the communication, but specifies a whole heap of rules around PIDS, Request and Replies, Message lengths and content. All the data flowing is CAN 2.0B data, as its on a CAN 2.0B bus, but the J1939 protocol rules specify things even further.

To be completely honest, it's not something I have a huge amount of experience with, I've not had an application that has required using it, as it's pimarily heavy industry stuff that uses J1939.

CSS Electronics has a good entry explanation of what J1939 is: https://www.csselectronics.com/screen/page/simple-intro-j1939-explained/language/en

I have worked with J1939 a little bit, no expert by any means, but for the vast majority of common devices that I have played with, it works just like the common motorsport and general automotive stuff we are used too. The vast majority of it seems to be standard 8 byte frames that are just broadcast (no specific destination, PDU2), I haven't come across the PDU1 format much (intended for a specific destination). I also haven't come across anything that needed to claim an address or request an address, it has always been pre-configured/known.

There are some really odd variations of J1939 such as "NMEA 2000 fast packet" used in marine stuff where multiple frames are sent kind of like a compound/multiplexed message but thankfully they are rare.

The 29bit "Message ID" is made up of several different bits of information that can tell you where the message came from, what device it is for and what data it contains. But generally you dont need to know any of that as you will be given a "PGN" from the device documentation, or you will sniff a bus and you can work it all out from the message ID.

I always find this Kvaser page helpful when I get lost: https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/

Also there are a couple of "ID to PGN" convertors around online, I think one on the CSS site that Zac linked above. These can be quite helpful as you can type in the sniffed ID and it will break it down into the PGN etc and what the message contains.

Thanks guys!

Last week I attended the Kvaser SAE J1939 Fundamentals webinar which was really helpful. What I did not realize previously is exactly what Zac says "J1939 is a higher level protocol that sits on top of the CAN protocol". So in my mind it became a difficult think where you had to claim, etcetera.

What I concluded is that the 'complex' part of the PGN's, PD1/PDU2 is all part of the identifier. Thanks for confirming that Adam.

I know the identifiers of the messages I need to send to that particular J1939 device. So I just took it from there.

So in my head I made it more complex than it actually is. No need to claim, address, etc. Bottomline in this case "my J1339 device" is just a CAN device with 29-bit ID and thus 2.0B. Thanks again for your input.

We usually reply within 12hrs (often sooner)

Need Help?

Need help choosing a course?

Experiencing website difficulties?

Or need to contact us for any other reason?