Not having much luck pulling this apart but not surprised at all. Not sure how you came up with column 9 being address. Also thinking there are two more hex pairs than necessary but I am not real good at this part of it.

 

I found some other programming online and it started to make a little sense. The data I'm getting follows the RP1210 format. All your normal software reworks the data into something that makes sense before it spits it out on the screen. It's supposed to be a standard driver so you can connect all your OEM or whatever software to more or less any device you want to connect to and it will work without having a different driver for everything. The extra bytes are either a timestamp or message counter.

The programs I found leave out enough detail to actually make sense of it and access to the specification is going to cost a small chunk of change I can't part with at the moment...

 

I put a little time into this idea recently and thought I would share a bit since there seemed a tiny bit of interest. Like @bwilliams60 said from the start if it was worth doing it would have already been done. I think in the end I'll just end up with a novelty gauge set on my phone. At the moment it's still more or less a data logger, but I've started to add in some calculations and display real values.

The screenshots are a test of the app's math using data I've collected so far from a few closely related Freightliners. It doesn't work as beautifully when I connect it for real, but it's coming along. The check button simulates messages sniffed to test if new programming additions are working right before trying it out at work later on.

The check boxes filter messages by their source address.

Each section has a few calculated values, and a few messages printed out for observation.

There are really not two engines here. One is the actual engine, and I think the other is a translator type module that was added to make glider kits easier and it just calls itself an engine. Actually the one I logged last night didn't have any engine 1 messages.

In the engine 0 section something is wrong with the decoding RPM and it doesn't update correctly at the moment. When the app first connects the RPMs are correct, but it doesn't update right after that (I'll get to it after ironing out a few other details). The RPM in the engine 1 section stays at 0 (I wasn't too sure if it would broadcast one or not when I added it in).

I just added the calculations for the torque values. I'll have to compare what my app says and what the OEM software says... it just doesn't look right or I'm thinking wrong. Maybe find out tonight.

The odometer is accurate within 1/10 of a mile. The spec actually calls for 1/8s of kilometers even if the dash displays miles and there's probably a precision issue somewhere in the math. So far I've only found the engine odometer being regularly broadcast. The dash and engine 1 odometers actually do not work at the moment with what I've tested the app on. I'm thinking I may have to ask the dash for it's odometer if I want to display it.

The fuel and DEF levels match the gauges in the dashes. On this particular breed the fuel level message comes from the dash, and the DEF level message comes from the engine ECU. It will be interesting to see if different manufacturers follow the same practice, or if they broadcast the levels at all.

The cruise values change in the cab controller section when I push buttons, but still have to work out the details. It will also be interesting to see if other manufacturers follow.

The program discards the proprietary messages and displays whatever isn't already displayed as a list below everything else. The save looking button saves the list so I can stare at it when I get home and figure out what to add next.

Now that the basic program is worked out the rest will come together over time.

 

Impressive that you have gotten this far. It would be nice to unravel the mystery of OEM coding but I think it is along the lines of coding used during the war. It was made not to be broken but you definitely are making a little headway. Pretty cool.

 

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.

Although CANBUS comms are standardized through a specification, the messages uses are not- they are virtually all proprietary to every vehicle/machine manufacturer. This has more to do with patent infringement and other aspects related to 'proprietary-ness' than anything else.

No vehicle manufacturer wants anyone to know what is fully possible on the bus. You might learn things that could make you very unhappy. (and this is real depending on vendor- your vehicle is constantly communicating with other vehicles for road-condition information, or that the police car behind you is patched into your audio system and is listening to what's going on inside the vehicle cabin).

 

Although CANBUS comms are standardized through a specification, the messages uses are not- they are virtually all proprietary to every vehicle/machine manufacturer. This has more to do with patent infringement and other aspects related to 'proprietary-ness' than anything else.

No vehicle manufacturer wants anyone to know what is fully possible on the bus. You might learn things that could make you very unhappy. (and this is real depending on vendor- your vehicle is constantly communicating with other vehicles for road-condition information, or that the police car behind you is patched into your audio system and is listening to what's going on inside the vehicle cabin).

The radio comment made me chuckle. Radios traditionally haven't been in the CAN loop on rigs up until recently (as in the last two or three years for Freightliner). There is no on star, no built in GPS, maps, or anything else unless you get into Mercedes and a select few overly technology laden vehicles. Certain options are available, but most people get their own GPS and good old fashioned map.

While I'll agree messages may be used for different things at times I have found that different manufacturers follow the spec to some extent... how much they actually implement of the spec is the variable. So far the engine odometer has been the same for Detroit Diesel 60 series with the later ECUs, as well as the DD series, and also both Cummins ISX and ISB families. I have a feeling the new X15 Cummins will work as well... just have to wait to try it. I have also found valid voltage messages from other ECUs on other manufacturers rigs, but have not yet added them into my program. Fuel and DEF levels have been along the same lines to some extent. There are also many instances in the spec of certain parameters being repeated in other parameter groups that would allow someone following the spec to pick and choose which message it wants to use to convey the data most efficiently. I have also seen a few instances of this in the logs so far. I'll just have to in the end sort messages by engine family also to get the correct data. Beyond that I haven't really looked into much more lately. This is a day here and there every couple weeks or so type project so it's pretty slow moving.

I'm not trying to control anything or make any changes. You can't just send a message to the engine ECU and tell it to run wide open without first convincing the engine ECU to take commands from the diagnostic tool (Obviously a proprietary function). I am Just picking off what is normally broadcast on the bus and sorting it out. There are 257 parameter groups designated for proprietary use and I have seen some in the logs, but most times the messages seem to follow the predefined parameter groups in the spec. There are also a couple hundred parameter groups to deal with agricultural equipment, generator sets, and the like that I have not seen any of in the logs which leads me to believe what messages are on the bus follow the spec for the most part.

I have also found that there is still a lot of old school type setups out there that use wires instead of messages even in newer equipment so the only messages are the basic status messages... the rest is the same as it's been from the beginning.

 

I thought I'd kind of explain what seems to me how this J1939 works...

Nothing is free! I've invested enough in this project to almost regret it just for information on how it "should work". It's been fun and educational for sure, but in the end I could have made some needed tool upgrades instead.

Your basic J1939 message that your diagnostic tool picks up consists of:
a) Four byte timestamp / counter (depends on the actual device used and not actually part of the CAN message if I'm reading things right... it's just to keep things in order)
b) Three byte parameter group number
c) One byte source address
d) One byte destination address
e) One byte priority
f) Data bytes

Most predefined parameter groups have eight bytes data.
Eight bytes = 32 bits.
The parameter group data is then defined in groups of bits to represent between one and 16 suspect parameter numbers. Every suspect parameter number is at least two bits. For example in parameter group 65265 the first and second bit of the first byte represent a two speed axle switch. As an example if the bits were say '01' it would be in low range, if the bits are '10' it would be in high range, the bit combination '00', could indicate a wiring issue (not getting power on either input), and bit combination '11' means that particular suspect parameter number is invalid. Different combinations of bits could mean different things more or less except bit combination '11' would always mean it's invalid and should be ignored.

Getting back to something earlier about how some parameters are repeated in different groups. If multiple groups are broadcast with the same parameter number in them then you would simply ignore the ones that have bit values of all ones. If none of the controllers broadcast that parameter with a valid bit value then that particular suspect parameter number would more or less mean nothing and should be ignored.

The 257 proprietary parameter groups on the other hand are allowed 14280 bits or 1785 bytes for their perspective data set. So far it seems there is one or two every second that are around 64 bytes on the Freightliner, but for the most part there aren't that many. The rest of them are mostly between the two fuse blocks. I didn't catch any proprietary looking messages on the Volvo the other day.

The source address is obviously what controller the message came from.

The destination is usually 255 which means to all other controllers. I've seen a few messages to specific controllers, but they are usually asking for that controller to broadcast a parameter group. There are certain instances that this value could mean something else, but it's not covered in the documentation I have.

Priority is 0 - 7. This value could also mean other things not covered in the documentation I have.

There are a couple bits in the priority byte to determine if the destination or priority bytes have an alternate meaning, but I haven't seen any yet.

For anyone who has worked with diagnostic tools...
The SPN of your trouble code is actually referring to the value in the parameter group. SPN 110 is engine coolant temperature. There's also a FMI code that more or less indicates how the current value compares to what the ECU thinks it should be, or if it is past the short circuit or open circuit thresholds, and whatever else it wants to say. SPN 110 is the first eight bytes of parameter group number 65262 that should be being broadcast on a regular basis from the engine ECU to update your engine coolant temp gauge in the dash.

I probably made it clear as mud, but thought I'd give it a shot. Thanks for having a look.

**Edit**
As far as ignoring the parameter numbers having all '1' for it's bits... If you know for sure that particular suspect parameter number is supposed to mean something then having all bits as '1' would probably indicate a problem also.

** Another edit **
SPN 110 is the first eight bits... not bytes. PGN 65262 is supposed to be a hand full of temperatures of various things. Was past my bed time.

 

Fascinating thread BTW.

 

I decided to look into some gloom and doom type stuff as my last bit of research this time around on this project. I'll admit I have very limited experience with manufacturers outside of what I normally work with. I did find enough wiring diagrams and such to convince me that being able to overtake a CAN bus and control a truck going down the road will probably be an obstacle course for even someone with intimate knowledge of the system. There are a few key variables with how they built, how they work, and how they are wired up.

Unlike a car where you have a GM engine, GM transmission, and GM everything else built to be used in GM automobiles larger trucks tend to have several different options. Most manufacturers offer their own engine along with a Cummins option. There are still a fair amount of trucks sold with manual transmissions in them. All the driver has to do is put it in neutral and pull off the road. In the automatic world there are the individual manufacturer's own transmissions and also the automated Eaton and Allison automatic possibilities. On top of all that there are a lot of "gliders" out there which allowed you to put a non emission engine in a new truck (it was a loophole in the early years of emissions standards to deal with reliability issues). Most of those engines only used CAN for diagnostics and everything was wired to the engine controller. The controllers themselves are separate units bolted to whatever they are controlling instead of an all in one PCM like some autos. There is no automated steering, active park assist, or anything like that yet so you won't be able to steer it into a wall.

In other words... first you'll have to get access somehow. Next you'll have to find out what exactly is in the unit you're trying to take control of. You'll then have to somehow get what you hacked to gain access in the first place to spoof the right address so that the engine, trans, ABS, and whatever else controllers are wired in will pay attention to it which may cause data link faults due to too many ECUs with that address. There's the possibility you could get the ECUs to pay attention to any address you want, but you'll probably have to also convince the ECU the parking brake is set which is still hard wired in some configurations to the engine ECU.

I'm not saying it's not possible, but a large truck / semi / whatever isn't built to do the same work as your normal passenger car. The laws governing what a driver can do and can't do in a normal work day are tough enough... I'm sure the safety, reliability, and other standards are just as tough due to the nature of what they do.

Maybe after New Years I'll have time to mess with this idea some more. In the mean time it's getting busy at work and getting a chance to sneak in a couple hours my off time for testing isn't going to happen until then.

Enjoy your holidays and Happy New Years!

 

I also kind of see how easily it could be to exploit a CAN bus and wreak havoc so I won't get in to any more details. I'll be back with a final set of screen shots or screen capture when I decide it's as finished as it will get.

I'm also in the US... I have no clue how any of this would actually relate to the rest of the world other than a few videos I've checked out on youtube over the years.

 

It's good reading. Keep up the adventure. If I figure out any more I will let you know but pretty sure the details are sealed in concrete. Happy Holidays from Canada