Wanting to build or program a SAE J1939 decoder, but...

Discussion in 'Automotive Electronics' started by geekoftheweek, May 4, 2019.

  1. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    What I would like to do is either build or program a J1939 decoder that could be somewhat universal. The question at the moment is if I spend the money to download the current specifications will I have enough info to do what I want? I am not sure of what in the will cost for everything, but from what I can tell is I have at least two more downloads besides the overview I have already downloaded. I just don't want to find out in the end I won't be able to do anything with it.

    For example: My employer has strictly Freightliner so we have everything we need for them, but there are some other makes we get in to every now and again. We have the engine software, but it would be nice to be able to pick up some messages between the rest of the various ECUs for troubleshooting. Something simple and as universal as possible would be nice. At times the proprietary software is a bit too much for what we need to do with it and it seems to intimidate people, along with a simpler layout would benefit everyone in the end.

    There are a few things I need to figure out... First thing is there is a extended message format along with the standard J1939 messages that is commonly used for proprietary messages. Secondly I don't know about all makes, but I do know Freightliner also has a proprietary CAN network besides the J1939 that may hide the messages I'm after unless you use the proprietary software to access them through the common gateway controller.

    In the end I would like to be able to just get basic information on switches, sensors, and such as defined in the current J1939 specifications and maybe be able to retrieve and clear error codes. I know in the end there will be some interpretation between the different makes as they may use some messages different than others, but hopefully I can show a ball park estimate of what the current status of things are.

    The build part of the question is a last resort. We have a Nexiq unit now we use for diagnostics and luckily there is an API for download to use to interface with it. I have skimmed over the example, but totally lost so far. There isn't much to go on. That will be the next battle.

    I know it's a long shot, but thought I would ask. Thanks.
     
  2. bwilliams60

    Senior Member

    Nov 18, 2012
    1,095
    196
    Im not sure I totally follow what you want to do as all sensors and messages are already being sent and can be read by proprietary software. If I understand you correctly, you want a universal reader for all makes and models? I can tell you that myself and many others have looked into this and if it was that easy, it wojld have been done by now. There are universal CAN BUS sniffers on the market and PICOscope can decipher some CAN signals, but every OEM to my knowledge has their own programming language for their engines. I dont think there is anything universal about it. NEXIQ is just an interface as is Inline 6, Dearborn Protocol etc. The language is in the software I believe. I wish you luck and if you find anything, please share.
     
  3. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    I started to wonder about that myself... Thanks for your thoughts.

    I was under the impression that if the manufacturers followed the messages defined in the standard most things would be somewhat universal. For instance in the overview I downloaded there appears to be quite a few SPNs that could be used as requests for things such as setting the cruise, turning on and off the engine brake, turning lights on and off, etc., as well as requesting the state of such devices. I am more interested in the request part. Even if it's just simply a changing number that I have no clue what it means when I turn a switch on it would at least signal a change that I could see and loosely verify something happened.

    Here's how I thought things would work on a Freightliner Cascadia (what I am familiar with)...
    1939 networked devices: SAM modules (controller, fuses, and relays in one) one for the cab and one for the chassis on separate addresses , common power train controller that translates the 1939 to what the engine ECU needs (Detroit or Cummins) as well as the transmission controller for the automatics (Detroit or Eaton) both with their own addresses on the bus, ABS controller, the instrument cluster, front and rear HVAC on separate addresses, modular switch field which is all your dash and steering column switches... the master is connected to the 1939 and the slaves are on a one wire serial of their own (no interest in that part), the common gateway which I was thinking allowed the proprietary CAN, J1939, and J1708 to exchange information between them (there are three physical networks strung about these things), and anything else I forgot. When I connect the laptop and bring everything up the addresses match what is defined in the 1939 spec.

    On top of all that we then tie in event loggers, cameras, the driver's e-log, and some other odds and ends to the 1939. All these devices communicate with each other and I was counting on things being somewhat plug and play like hooking up a new printer to your USB.

    I was kind of hoping since once upon a time you could have the exact same engine, transmission, axles, brakes, and such on three different manufacturers with just the body, frame, and suspension being different that they would continue that way with the electronics. I was also kind of hoping the proprietary software was more to get at changing parameters and such that I have no interest in attempting to do along with the specific troubleshooting information for that unit.

    We also have a Snap On scanner that will allow you to watch the bus traffic without even connecting to the ECUs. It scrolls lines of what looks to be 14 byte messages that seem to follow a pattern. If I could just get my hands on enough stuff to decode that it would tell me if it's possible or not. There is plenty of white space left in the box so I'm thinking 14 bytes is a magic number, or it's just the way they formatted it.
     
    Last edited: May 7, 2019
  4. bwilliams60

    Senior Member

    Nov 18, 2012
    1,095
    196
    I think you are correct in your assessment of the Snap-On tool. Like Nexiq, it will spew lines of code but I don'y believe they are complete. In fact, I believe NEXIQ to be more complete than any other that I have seen. I have been off the floor for a bit but I was Diamond Certified L3 with International and although the two systems are not alike, the functions are basically the same. I think what you are looking for may be a CAN sniffer such as this: https://www.can232.com/?page_id=16
    There are many of these on the market but perhaps this will lead you in the right direction:
    The guys name is Craig Smith. I have spoken to him a couple of times and he is brilliant at this stuff. Go to Open Garages and you will find the Cra Hackers Handbook which may also give you some information. It is a good read. Good luck. I started down this path before but I have too many things to do and this is a large area. Let me know what you find.
     
  5. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    Thanks for the info bwilliams60. I'll look into it. The part I like about the Nexiq is you can write your own programs for it which is my intent in the end.

    I kind of learned everything so far from some factory documentation I found so I'm not totally clear on some things, but it has for sure helped understand how things work.

    This idea has crossed my mind a time or two before, but a Volvo with bunk heat, but no cab heat recently really made me start looking into it seriously. The Cummins program will pick up the basics, but other than that you're guessing. We just don't do enough of anything else to make it worth having the software.

    If it wasn't going to be a $400 or so gamble to download the SAE specs I would already be working on it just for fun.
     
  6. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    So I looked again at what I downloaded and the 14 bytes makes sense. According to the J1939 spec the message identifier is four bytes (29 bits for the identifier and the other three for the priority) with the next eight bytes being data followed by a CRC which I believe is two bytes... just can't find it again. Might just be enough to start seeing what shows up. For the main messages there is a data format specified in another download, but for the rest you're on your own.
     
  7. bwilliams60

    Senior Member

    Nov 18, 2012
    1,095
    196
    Just to let you kniw a bit more, I sat down with an international engineer one time and compared our software to his. He had roughly four times the information available to him than what I could see on my screen. Even our OEM software is only a small portion of what it is capable of. I believe there is a way to decode all languages to some level but like I said, I do not have the time to chase that one down. It is a long adventure.
     
  8. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    Information is the key. It sounds you may have a little more knowledge and experience than I anticipated and appreciate your comments. Part of me says listen up and don't spend a whole lot of time and money on the idea, but the rest of me wants to figure out what I can actually do. I think I actually have enough information so far to at least figure out if it's worth pursuing further. I just need to figure out how the drivers work to connect my phone to the Nexiq and start sniffing the bus. I should be able to knock out a simple program like the ones in the video for my phone in a couple hours after the initial getting the Nexiq to work with my program.

    I'm thinking in order to be able to call it a J1939 bus you would at least have to follow the basic message format to some extent. I should be able to tell you where the message originated, if it is a broadcast or peer to peer message (along with the peer's address), what priority, and what message format it used. All of that information is contained in the identifier bytes. As far as what the eight data bytes actually are will be the mystery for now. I am hoping to see something to inspire me further.

    Although the OEM software is a huge help at times it is a bit bloated in ways and just sheer overkill for what we normally do day to day. It actually burned me pretty good last night chasing down a missing ABS controller due to a glitch in the software I'm assuming. The old Snap-On found it right away. Something simpler would help a lot!!

    Thanks again and hope to be back here again in a week or so with an update...
     
    Last edited: May 8, 2019
  9. bwilliams60

    Senior Member

    Nov 18, 2012
    1,095
    196
    I have spent a bit of time working with J1939 and CAN BUS and understand it fairly well. The one thing you have to keep in mind as you go along, is that this started out as a universal communication setting through SAE and has morphed into something much bigger. The hardest part you are going to run into is the proprietary part of the data. There are several hundreds program languages (from what I understand) and to figure out each is going to be very time consuming. The portion I believe you are after, the SPN, is the key to your analytics and the only way I know of to figure it out is with a CAN sniffer and watch signals as you physically change them. Then you can start to understand what they are doing. There are far more intelligent people on this forum than I when it comes to CAN BUS, but I think you have a long road ahead of you. Understanding the SAE papers on J1939 may be a good starting point.
     
  10. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    I have to admit up until I started working my current job five years ago I knew absolutely nothing about trucks in general other than they go down the road. I have been tinkering with computers and electronics my whole life and while some people may think I know a lot in all reality it's just I know a little more than them. The J1939 overview might have gave me a false sense of hope as it looks pretty simple other than the proprietary possibilities.

    So far everything has been fighting with me on every step. I'm stuck now getting the Nexiq examples to compile and since I only know enough about Java to do some simple programming I don't know how to go about rewriting the build scripts to work with what I normally use. Android Studio is being a pain... was from the first time I tried it before finding other ways to get the job done.

    I also talked to the boss a little about the cameras and event loggers that get put in and found out they seem to work more on internal GPS and gyroscopes than I anticipated. I know they tie into the 1939 for something, but for what I really can't say at the moment.

    There is also the fact that since each manufacturer is developing their own drive line and such there really isn't any motivation for some type of standardization any more.

    I won't give up on the idea, but after a little more thinking, research, your thoughts, and the fact I have much bigger priorities to spend time on at the moment it's looking like maybe this would be better as a rainy day type project.

    Maybe one day...
     
    Last edited: May 9, 2019
  11. bwilliams60

    Senior Member

    Nov 18, 2012
    1,095
    196
    Lol, I hear you. I spent a lot, and I mean a lot of time on the same road and after reading several hundred articles, posts, white papers etc, came to the realization that I may be in a little over my head. I had neither the time nor the resources to see this through so I backed way off on it. If nothing else though, I did gain a lot of knowledge about CAN BUS, J1939 and where the industry is heading. For technicians, the future looks bleak in diagnostics. Everything with a wire on it will become self diagnostic and techs will become parts replacers. We are laready halfway there. While technology is a good thing, it also has its pitfalls.
    I am always amazed at what we can do with twisted pair technology. It is hard to keep up with though. You are probably younger and have some years ahead of you on the floor. Enjoy the ride.
     
    geekoftheweek likes this.
  12. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    The good thing about wires is after 400,000 miles they start to wear out in places. At least there will still be the thrill of chasing down a broken wire. Thanks again.
     
  13. bwilliams60

    Senior Member

    Nov 18, 2012
    1,095
    196
    I would like to think thats true but again I think it will be, here is the code, do this, do that, REPLACE harness. No guessing games.
     
  14. Back to school

    Member

    May 22, 2019
    46
    6
  15. geekoftheweek

    Thread Starter Active Member

    Oct 6, 2013
    218
    26
    The ELM327 sounds interesting... just saw it mentioned in another post I was looking in to.

    I actually have the hardware side figured out. I kind of want to stick with what is already available instead of building my own.

    I did get a basic program to work on my phone, but it won't connect at the moment to the hardware currently available to me. Just need to drag the laptop to work one day so I can watch the logs and find out if it a software or hardware issue.
     
Loading...