[TheBurro]

For what it's worth, on mine 0x21 0x5c returned:

7E9 07 61 5C 0D D0 00 50 5A


That was with the engine off, however.

0x5A=90
90-50=40°C

Assuming it isn't 40°C/104°F in Colorado, was that after it cooled down for a few hours? It looks like a reasonable value if that was the case. I bet it matches the other trans temp pid(if you put it in drive so the other one works).

 

[plextor]

0x5A=90
90-50=40°C

Assuming it isn't 40°C/104°F in Colorado, was that after it cooled down for a few hours? It looks like a reasonable value if that was the case. I bet it matches the other trans temp pid(if you put it in drive so the other one works).

So that's dead on. I did a few more experiments this afternoon with that PID.

When the transmission was in park, and the trans temp was displaying the engine coolant temp of 197ºF, the data returned from this query was 61 5c 0d d0 00 50 8e. 0x8e=142, 142-50 = 92ºC, or 197.6ºF.

When the transmission was in reverse, and the trans temp was displaying a trans temp of 111ºF, the data returned was 61 5c 0b b0 01 52 5e. 0x5e=94, 94-50 = 44ºC, or 111ºF.

So that's dead-on. I am suspecting byte C is the gear selection, too (00 = park, 01 = reverse?). Need to try that out real quick.

 

[plextor]

Yep.


7e9 61 5c 0d d0 00 50 8e # engine running, in park
7e9 61 5c 0b b0 01 52 5e # engine running, in reverse
7e9 51 5c 00 00 02 4e 88 # engine off, in neutral
7e9 51 5c 00 00 04 44 60 # engine off, in drive


So, byte C is definitely the gear selector. I'll have to do some recording to see if indicates manual gear selection for the automatic, too.

Bytes A and B look like might be interesting, too.

 

[TheBurro]

Well that was disappointing, I thought LID0x5C was going to be trans temp without needing to be in a specific gear. I guess that exercise was a waste of time, it didn't buy you much over LID0x30.

I am not sure if byte C is gear selector but I think byte D is bitmapped PRNDL as it is displayed on the cluster. I am sure you will figure out A&B on a test drive.

FWIW, be careful venturing out in modes that aren't read only. If you are randomly sending commands, it is very easy to change a setting and turn your Jeep into a nice looking lawn ornament until you can have it towed to the dealer and reset.

 

[dangerz]

The ODBII port doesn't give you access to the CANBUS, right? From what I understand, it's a slower transport layer? Or is it all the same?

 

[plextor]

The ODBII port doesn't give you access to the CANBUS, right? From what I understand, it's a slower transport layer? Or is it all the same?

The OBD-II port in the Jeep implements a CAN bus, and a high-speed one at that. But, there are two other CAN bus networks in the Jeep: the CAN-interior bus, and the power-train CAN bus, or CAN-C bus.

When you're talking to the CAN-D bus (the diagnostic bus via the OBD-II port), you are not able to electrically communicate directly with the CAN-C or CAN-interior busses. The TIPM module acts as an electrical gateway between CAN-D and the other two.

This is speculation based on observation, but it appears the current TIPM in the Jeep is somewhat intelligent about what messages get transferred between busses. From what I've read, it looks like older TIPMs in Mopar products (say early-to-mid 2000s) transferred messages between busses freely.

I attached a diagram of what the busses and many of the modules within the Jeep look like at the logical level (several modules left out). It will give you an idea of what is connected to which bus, and how the TIPM is in-between everything.

I think if someone has access to the wiTECH or StarScan they can provide the real network diagram of all the modules.

 

[plextor]

Well that was disappointing, I thought LID0x5C was going to be trans temp without needing to be in a specific gear. I guess that exercise was a waste of time, it didn't buy you much over LID0x30.

At least according to the service manual, the actual sensor isn't sending a temperature reading unless the transmission is in gear. Why, they're not real clear on.

 

[plextor]

Oh, Dr. Google to the rescue. Here's an example vehicle (not a JK, but similar) to give you an idea of how the network looks from their point of view.

 

[plextor]

FWIW, be careful venturing out in modes that aren't read only. If you are randomly sending commands, it is very easy to change a setting and turn your Jeep into a nice looking lawn ornament until you can have it towed to the dealer and reset.

For sure. I'm not a big fan of brute forcing these commands. When I was first experimenting with hacking the CAN-IHS bus, I was able to get the car to stall in the driveway a few times. Not something I'd like to do while moving.

 

[TheBurro]

When you're talking to the CAN-D bus (the diagnostic bus via the OBD-II port), you are not able to electrically communicate directly with the CAN-C or CAN-interior busses. The TIPM module acts as an electrical gateway between CAN-D and the other two.

I don't think that is correct. I don't have access to a JK but other vehicles I have worked with that have the old gateway architecture pass CAN-C straight through to the DLC. If CAN-D were truly a separate network then it would require a termination resistor in whatever plugs into the DLC and that is a no-no according to SAE specs. I suspect if you have the ability to monitor broadcast messages, you will see there tons of messages coming through the DLC. There is no reason to do that unless the DLC is directly connected to CAN-C.

 

[plextor]

The JK is actually different on that, significantly so. There are zero messages coming across the DLC form other busses without requests. I've attached monitoring tools to all three and the CAN-D bus in the JK is quiet (and different from other vehicles I've tested with).

 

[TheBurro]

I guess it is time for me to be quiet. My experience with other vehicles on the gateway architecture looks inconsequential. I look forward to seeing what you figure out.

 

[plextor]

I wish I had access to a pre-2011 JK, too. I suspect the previous implementation was pretty different. The post-Fiat influence is pretty evident now in the network implementation.

 

[plextor]

I don't think that is correct. I don't have access to a JK but other vehicles I have worked with that have the old gateway architecture pass CAN-C straight through to the DLC. If CAN-D were truly a separate network then it would require a termination resistor in whatever plugs into the DLC and that is a no-no according to SAE specs.

Remember, too, that the DLC is effectively a node in the middle of the CAN-D bus, so it doesn't need termination there. The TIPM is the termination point of the bus, internally.

 

[plextor]

And just so you know that I'm not making this up

There are actually three separate CAN bus systems used in the vehicle. They are designated: the CAN-Interior (also known as CAN Interior High Speed/IHS), the CAN-C and the Diagnostic CAN-C. The CAN-Interior and CAN-C systems provide on-board communication between all nodes in the vehicle. The CAN-C is the faster of the two systems providing near real-time communication (500 Kbps). The CAN-C is used typically for communications between more critical nodes, while the slower (125 Kbps) CAN-Interior system is used for communications between less critical nodes.

The added speed of the CAN data bus is many times faster than previous data bus systems. This added speed facilitates the addition of more electronic control modules or nodes and the incorporation of many new electrical and electronic features in the vehicle.

The Diagnostic CAN-C bus is also capable of 500 Kbps communication, and is sometimes informally referred to as the CAN-D system to differentiate it from the other high speed CAN-C bus. The Diagnostic CAN-C is used exclusively for the transmission of diagnostic information between the Totally Integrated Power Module/Central GateWay (TIPM or TIPMCGW) and a diagnostic scan tool connected to the industry-standard 16-way Data Link Connector (DLC) located beneath the instrument panel on the driver side of the vehicle.

The TIPM is located in the engine compartment near the battery. The central CAN gateway or hub module integral to the TIPM is connected to all three CAN buses. This gateway physically and electrically isolates the CAN buses from each other and coordinates the bi-directional transfer of messages between them.

The circuit indicators make it pretty clear these are separate busses, as well.

 

[TheBurro]

Remember, too, that the DLC is effectively a node in the middle of the CAN-D bus, so it doesn't need termination there. The TIPM is the termination point of the bus, internally.

Agreed but there should be 120's on each end of the bus. If the TIPM creates a separate bus then I would think there would be just one termination resistor there. At that point you would still need another, I don't know where that would be. Maybe they create a properly terminated bus completely internal to the TIPM where the DLC/tester is just a node. Either way this is the first gateway vehicle I've heard of that behaves like that.

I am definitely not doubting you. I thought my prior experience with gateway would be useful but apparently there are at least two versions of it. All I have to play with are powernet vehicles which do not filter anything at the DLC.

 

[plextor]

You know what's interesting about this, too, is that it seems yet different again with the newer Jeeps. I had a security researcher contact me about the Grand Cherokee and their gateway is acting really differently than the JK's.

There's an old thread on here where a guy took apart an early JK TIPM and looked at a lot of the circuits. I'd like to do that with one of the newer ones and do some circuit tracing. That said, I'm not yet invested enough in all of this to spend a few grand on spare ECUs

 

[plextor]

One thing I haven't tried yet with the CAN-D bus is requesting diagnostic access and sending tester present messages and seeing what behavior changes. I suspect there's a diagnostic mode where the TIPM will forward all traffic from the other two busses.

Most of my work has always been focused on the CAN-IHS bus, so I haven't bothered with this one too much. I'm rebuilding my rPi-based CAN system right now (the file system took a crap again) and I'll be digging into it a bit more. Doing it via those ELM327 chipsets is really limiting.

 

[TheBurro]

You might be on to something there. One of those Mode$10 subfunctions might cause it to pass through messages.

I've haven't played with the Linux boards too much. I don't trust them to do only what I say and do it reliably. I like using Vector,Kvaser and ICS tools. They all work great and you can do some nice scripting for command sequences, plus they do a good job of datalogging.

 

[dangerz]

So the only way to get data from the ODBII port is to query for it, right? Is that how all the CAN bus networks work, or can you just connect and sit and listen?

So for example, if I want to watch what happens when I turn on the turn signal, can I listen for messages on one of the other networks?

Sorry for the dumb questions. I have a lot of software dev experience (especially SOA) but this is my first time toying with cars.