CAN Bus Communications Decoded: OBD2 And J1939
Watch This Course
$199 USD
-OR-
Or
8 easy payments of only $24.88
Instant access. Easy checkout. No fees.
OBD2 And J1939
05.24
| 00:00 | - There are a couple of further standards we should discuss as it's likely you'll see them pop up when dealing with CAN systems. |
| 00:06 | These are OBD2 and J1939. |
| 00:10 | OBD2 or onboard diagnostics 2 is a standard that was created to ensure all modern vehicles output a selection of standard variables in a fixed format. |
| 00:20 | This differs from OBD1, the preceding system which was not particularly well defined. |
| 00:25 | A vehicle with OBD1 will have some sort of onboard diagnostic capability but how it's actually implemented was completely up to the vehicle manufacturer. |
| 00:34 | This lead to every manufacturer implementing OBD1 differently and independent repair shops then needed to purchase a separate scan tool for each manufacturer or sometimes even every model of vehicle that they wanted to read diagnostic data from. |
| 00:49 | OBD2 standardised this system by defining a set group of engine and vehicle running parameters that a compliant vehicle needs to output. |
| 00:57 | These parameters primarily relate to vehicle emissions and diagnostic trouble codes. |
| 01:02 | With this system more defined, independent testing and repair shops could interface with most vehicles using only a single scan tool which was much less expensive. |
| 01:11 | OBD2 has had a few iterations over the years and actually encompasses 5 different communication protocols. |
| 01:18 | CAN being just one of them. |
| 01:19 | SInce 2007, CAN has been the expected default though and now you often hear the terms OBD2 and CAN used somewhat interchangeably when talking about vehicle diagnostics. |
| 01:30 | We've discussed how CAN is a broadcast network with each device sending out its data and the entire network listening in. |
| 01:37 | A device then deciding if that data is relevant or not. |
| 01:41 | The OBD2 system uses the CAN network in a slightly different way. |
| 01:44 | An OBD2 scan tool sends out a remote request frame which another device on the network will read and then send out that requested data. |
| 01:54 | A common example of this would be engine speed. |
| 01:56 | When we connect an OBD2 scan tool to our vehicle and program it to display current engine speed, it will send out a request for this data to be put on the network. |
| 02:06 | A connected device that has this information like the engine ECU, will then start replying with this data. |
| 02:13 | This happens on a PID defined in the OBD2 standard so every scan tool knows how to request this data and then where to look for the response. |
| 02:22 | Now this sounds great and like we would be able to use the OBD2 data for all our logging purposes without reverse engineering any other CAN data streams in the vehicle. |
| 02:32 | But the problem is that the OBD2 data is transmitted quite slowly at approximately 2 Hz which is far too slow to be used for performance logging purposes. |
| 02:41 | There is also usually a limit on the number of OBD2 parameters that can be requested at once. |
| 02:47 | Vehicles with CAN networks will likely be constantly be transmitting much of the same data at a much higher frequency but on a PID and inner data structure that we don't know. |
| 02:59 | Where OBD2 becomes very useful is being able to get a reliable value for a variable or parameter that we're looking for in an unknown data stream. |
| 03:09 | A good example of this is engine coolant temperature. |
| 03:12 | Most OEM ECUs are likely to be constantly transmitting this on a CAN network as the gauge cluster will require this information to move the coolant temperature gauge needle to the correct position. |
| 03:23 | This is a pretty common parameter to want to log so it'd be nice if we could find the location of this parameter within the unknown data stream that the ECU is also transmitting. |
| 03:33 | If we connect an OBD2 scan tool and ask it to request engine coolant temperature data, we will be able to read the exact value of this variable as the engine ECU interprets it from the OBD2 data stream. |
| 03:47 | Then we can go looking for this value within the unknown higher frequency data stream. |
| 03:53 | Once we've determined where we think the data is located, probably by observing a particular selection of bytes within a single PID, that changes the same time the engine coolant temperature variable we're reading on the scan tool does, we can use the exact variable values from our scan tool to determine the correct scaling and offset of our unknown data from the higher frequency CAN data stream. |
| 04:16 | If that didn't make a huge amount of sense, don't worry, we'll show this method being applied in practice later in the course and you'll see how the systems relate to one another. |
| 04:25 | J1939 is another standard you'll see mentioned when dealing with CAN devices. |
| 04:29 | It's similar to OBD2 in that it defines particular data variables that need to be transmitted and how they should be transmitted on the CAN network. |
| 04:37 | We're not going to cover J1939 in this course though because it's primarily used in the heavy industry commercial vehicle sector and it's not something you're likely to come across in the performance automotive world. |
| 04:48 | However, if you do strike a situation where J1939 needs to be used, your best bet will be to purchase a CAN bus interface tool that includes software with the J1939 definitions included. |
| 05:01 | This will let you decode that data stream very easily. |
| 05:04 | This section of the course has been almost entirely theory and a lot of information to take in. |
| 05:09 | Don't worry if things are still a little murky. |
| 05:11 | In the next sections of the course, we're going to dive into some more practical examples of working with CAN data which will solidify your knowledge and give you the confidence to tackle your own projects. |
