Jeep Wrangler Forum banner
  • Hey everyone! Enter your ride HERE to be a part of January's Ride of the Month Challenge!
41 - 60 of 78 Posts

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #41 · (Edited)
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.
No dumb questions there! :)

You may want to check out my post Hacking the Jeep Interior CAN-Bus | Chad Gibbons' Blog and the other thread here http://www.wranglerforum.com/f202/hacking-the-can-interior-bus-466730.html for more details on the CAN bus stuff.

CAN itself is a broadcast protocol. Any node on the bus receives all messages from all other nodes. If you hook up a device capable of connecting to a CAN bus, and monitoring it, to the CAN-C (power-train) or CAN-IHS (interior - the dash, radio, etc.) busses you will see a non-stop torrent of data.

What I've done is the basics of performing an action in the vehicle and looking at how the data changes. There are a bunch of tools to help isolate background noise from data that's actually new. For example, the Jeep constantly sends out a 'power on' CAN bus message, among many, many others. If you wanted to see what message gets sent when you press the window down button, it can be a little hard to see amongst all those constant other messages... but the tools (https://gitorious.org/linux-can in my case) can really help with that.

There are some other tools that folks have written to do statistical analysis of how many messages with certain id's are being sent around if you capture everything. That can help you figure out how many unique messages exists.

The diagnostic CAN bus, on the OBD-II port, is a bit different in the JK. It's only there to exchange messages between the scan tool (or whatever) and the TIPM. So by default, it is quiet... you ask it for something, and it tells you. But what we're speculating above is that if you ask it the right things, then it will forward all the traffic off the other busses. Which is convenient from a tooling perspective - physically connecting to the other busses is a bit of a pain.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #42 ·
And to summarize the state of everything - why do any of this hacking stuff?

First and foremost, curiosity. It's fun to know how the electronics systems of the vehicle actually work, and not to be hamstrung by the OEM's decisions on how they're implemented. This let's us understand the vehicle, and let's us monitor the vehicle in useful/fun ways.

Second, as described in the other thread, I have a desire for better and smarter accessory integration. That's my main personal project. If a vendor winds up taking my experiments and running with it, great! If not, then I'll do that (that's my current strategy).

Third, I'd like to get the configuration options that are available in the ECU's and make them easily changeable. Right now even changing tire sizes, etc. requires a programmer. That's not something that should be a hidden secret.

Fourth, and this is the holy grail, would be to reverse engineer the software in the ECUs themselves. This is beyond even what most tuners do, where they 'reprogram the PCM'. In reality, most of them are just changing the throttle / air fuel tables and a few settings, they aren't really changing the code in the ECU (nor do they have to). I'd love to change the code in the EVIC, or at least replace the EVIC with my own that had better features. A lot of the behavior in the car is driven by the software choices in the EVIC and TIPM. I doubt I'll go this far unless I make this a full-time job :)
 

·
Registered
Joined
·
161 Posts
I think I'm going to make a set of pigtails like you did for the radio, dcgibbons. I want to just passively listen to get an understanding of it all.

I was able to get my laptop hooked up and get basic things like rpm out of the car yesterday.. that was fun. I'm trying to be careful about sending random commands. It's one thing to brick a phone. Complete other thing to brick my jeep.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #45 ·
You may find that hooking into the connector where the amplifier is will be easier. It's right there by the driver's footwell. A few more cables in the connector, but much easier to get to.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #46 ·
When I first started all of this, I wanted to tap into the TIPM connectors, since everything connects to there anyway. But those connectors suck to deal with :)
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #47 ·
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.
So here's some new data while the vehicle was moving, and playing with the auto-stick. Pretty easy to see the gear selector indicators there.

auto in 1st = 61 5C 01 10 04 31 4B
auto in 2nd = 61 5C 02 20 04 32 49
auto in 3rd = 61 5C 03 30 04 33 61
auto in 4th = 61 5C 04 40 04 34 61
auto in 5th = 61 5C 05 50 04 35 61
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #49 ·
Let's talk a bit about ECU identifiers. For the OBD-II via CAN standards, you send a message to a special broadcast id, which is id $7df. Any ECU capable of answer this request will respond, typically with a message id of $7E0 to $7E7.

The JK may also respond to the generic broadcast message id with the actual low-level ECU message id. This can be useful in figuring out what the ECU id's really are, outside of the scope of OBD-II.

From some experiments, we can see in the JK that message id $7e9 is the TCM, and $7b8 is the PCM.

But, sometimes we see different message id's. From my experiments, it appears that $500 is the PCM (I suppose it could also be the TIPM), and it is listening to message id's in the $6xx range.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #50 · (Edited)
One of the standard OBD-II messages is mode 9, with a PID of 1 to return the VIN. I've not found that the JK supports this message (which is not uncommon). If I send the following request:

7df#0209010000000000

Then I will see this response:

7B8 [8] 03 7F 09 11 00 00 00 00

Which is the PCM telling us:
A=03=3 additional data bytes
B=7f=negative acknowledgement for request
C=09=mode of request
D=11=negative response code $11 - service not supported

So, how do we get the VIN? In the KWP2000 and beyond standards, we do that with mode $1a:

7df#021A880000000000

Which breaks down like this:
A=02=# of additional data bytes
B=1a=Read ECU identification service
C=88=VIN (Original)

On my JK, I will then receive the following responses:

7E9 [8] 10 13 5A 88 31 43 34 48 '..Z.1C4H'
7B8 [8] 10 13 5A 88 31 43 34 48 '..Z.1C4H'
500 [8] 10 13 5A 88 31 43 34 48 '..Z.1C4H'


So, that tells me there are 3 potential ECU's that are responding to the VIN request. Some experiments will show that $500 is also the PCM, along with $7B8.

If we break down these messages, we see the following identical format:
A=10=CAN-TP header A
B=13=CAN-TP header B
C=5A=Read ECU Identification Positive Response Service ID (service $1a + $40)
D=88=VIN Request ID
E-H=31433448=1st 4 digits of VIN

For reference, CAN-TP, or ISO 15765-2, is a convention for sending long data messages over the CAN bus. In the message above, the 1st nibble (1) indicates this is the first frame of a multi-frame message, and the 2nd, 3rd, and 4th nibbles (013) indicating the total data length of the message. That's 19 bytes total in this case, which is the length of the VIN plus 2 bytes for the positive response code and the VIN Request ID as shown above.

The format of the CAN-TP header can be confusing, as it is in big-endian order.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #51 ·
So that's only the first 4 digits of the VIN, where's the rest? That's part of the CAN-TP protocol's flow control mechanism. When we see a response like above, we know to expect 19 total bytes, and only 6 are available in the first message. Per the ISO 15765-2 description:
A message longer than 7 bytes requires segmenting the message packet over multiple frames. A segmented transfer starts with a First Frame. The PCI is two bytes in this case, with the first 4 bit field the type (type 1) and the following 12 bits the message length. The recipient confirms the transfer with a flow control frame. The flow control frame has three PCI bytes specifying the interval between subsequent frames and how many consecutive frames may be sent (Block Size).
So when we received that first message back above, we need to send a flow control message to let the ECU know it is okay to send us the rest of the data. We do this with:

600#3000000000000000

In this decodes as the first nibble (3) indicating a flow control frame, and the second nibble (0) indicating clear to send, letting the ECU know it should send the remainder of the data without delay.

What I get back in my JK is something like this:

21 4A 57 46 47 33 45 4C '!JWFG3EL'
22 32 39 39 39 39 39 39 '"2999999'

The first byte of each message represent the CAN-TP header, with the first nibble (2) indicating this is a consecutive data frame, and the second nibble (1, and then 2), indicating the frame index.

The timing between the ECU sending out its initial message and the tester responding with the flow control message above is just milliseconds, so it needs to be done via software or via very quick back-to-back commands. On my test system I can run the following commands and get a valid response about 80% of the time:

$ cansend can0 600#021A880000000000;cansend can0 600#3000000000000000
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #52 ·
Another interesting set of data is the Engine Data identifier ($0a) from the Read Data by Local Identifier ($21) command:

02210a0000000000


I'll get back the following-responses (the flow control response sent between receiving the 1st and remaining messages is not shown for simplicity):

10 12 61 0A F3 8E 11 01 '..a.....'
21 0E 05 02 03 00 00 2E '!.......'
22 01 00 01 01 03 0F 00 '".......'

I put the actual raw data in bold; the rest of the data is header information. I don't know the format of the data in this case, but we should see (based on kwp2000 examples) battery voltage, coolant temp, throttle position, O2 sensor voltages, etc.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #53 ·
And this is why people just pay the ETI and OEM's to license their data... it's complex. It's a damn shame we can't get this data opened.
 

·
Premium Member
Joined
·
8,897 Posts
I'm going to send a link to this thread to the Electrical guy at Advanced adapters. He might understand and have some questions.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #55 · (Edited)
On the advice of someone, I ran a script where I sent the standard Tester Present message to every CAN bus ID from $000 to $7FF.

Tester Present messages look like this:

02 3E 01 00 00 00 00 00

02=2 bytes in message
3E=tester present service
01=response required (02 would be no response required)

The intent of the Tester Present message is for a diagnostic scan tool to tell an ECU that it is still there. This is used primarily to keep ECU's in diagnostic / programming mode once it has been started. If the ECU doesn't see a Tester Present message after a certain amount of time (usually less than 2 seconds), then the ECU takes itself out of the mode it might have been put in.

In this case, we can use tester present to see what ECU's are out there listening. Here's what I got back from my '14 JK (the first line in each group is the tester present request; the rest are the responses):


01C#023E010000000000
504#017E3E07FFFF0F00
53E#017E000000000000
53F#017E000000000000
516#017E000000000000
514#017E400700000000

600#023E010000000000
500#017E1180FF1D1D05

620#023E010000000000
504#017E3E07FFFF0F00

622#023E010000000000
484#017E3E0000000000

688#023E010000000000
511#037F3E1200000000

6A0#023E010000000000
514#017E400700000000

6B0#023E010000000000
516#017E000000000000

6E0#023E010000000000
51C#017E000000000000

784#023E010000000000
785#017E000000000000

788#023E010000000000
789#017E3E0000000000

7B9#023E010000000000
7B8#017E000000000000

7DA#023E010000000000
7DB#037F3E120501EEFF

7DF#023E010000000000 # This is the OBD-II standard request ID
7E8#017E000000000000
51C#017E000000000000
7B8#017E000000000000
504#017E3E07FFFF0F00
789#017E3E0000000000
484#017E3E0000000000
7E9#017EFFFFFFFFFFFF
500#017E1180FF1D1D05
785#017E000000000000

7E0#023E010000000000
7E8#017E000000000000

7E1#023E010000000000
7E9#017EFFFFFFFFFFFF

7F0#023E010000000000
53E#017E000000000000

7F8#023E010000000000
53F#017E000000000000


Another note... I disconnected my PCM and redid the same test, and the only ID that did not answer was the 7E8.

Based on this test above, it doesn't look like my assumption about message id $500 in the previous posts was correct. :)
 

·
Registered
Joined
·
30 Posts
I have done some more research on this and it appears that, if you want to use an iPhone with the adapter, it is better to get a low power Bluetooth adapter instead of WiFi. This is because, once the phone is connected to device's WiFi, you can't use your cellular data to do things like stream Pandora, use Waze, Siri, get email, push notifications, etc... It's like you put your phone in airplane mode except for being able to take calls.

So the question is which low power Bluetooth adapter is compatible with the most software? So far, I am looking at the LELink due to its price point.
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #57 ·
I've only used the GoPoint BT1 with iOS so far, primarily because it was recommended by Harry's LapTimer. It works with that and DashCommand great.
 

·
Registered
Joined
·
1 Posts
Hi Chad,

Been reading this thread and some of the other stuff you've done must say some very nice work!

Just had a questions about the various busses and the OBD2 port. I don't have a Wrangler but have a 2015 WK2 Grand Cherokee so hoping similar enough.

According to Mopar Connection Repair Kit it looks like the IHS Bus is available on pins 3+11 as well as the C Bus. The pinouts certainly fit what the OBD2 port has wired Imgur

I've just ordered an OBDLink LX (https://www.scantool.net/obdlink-lx.html) so I can play around with getting access to some of the PID data (going with tried and tested at this stage). Apparently the OBDLink is based on the ELM327.

My questions:
1. Based on the above is that C Bus likely to be diag or normal?
2. Is that likely to really be an IHS Bus on 3+11?
3. Do I need anything special to read the IHS bus or can I either just build an adapter to cross them into PINs 6+14 and use anything off the shelf that reads/writes ISO15765-4 or plug them into an Arduino CAN-L and CAN-H and read them using pyOBD or canutils?

Thanks
 

·
Premium Member
Joined
·
532 Posts
Discussion Starter · #60 ·
According to Mopar Connection Repair Kit it looks like the IHS Bus is available on pins 3+11 as well as the C Bus. The pinouts certainly fit what the OBD2 port has wired Imgur

I've just ordered an OBDLink LX (https://www.scantool.net/obdlink-lx.html) so I can play around with getting access to some of the PID data (going with tried and tested at this stage). Apparently the OBDLink is based on the ELM327.

My questions:
1. Based on the above is that C Bus likely to be diag or normal?
2. Is that likely to really be an IHS Bus on 3+11?
3. Do I need anything special to read the IHS bus or can I either just build an adapter to cross them into PINs 6+14 and use anything off the shelf that reads/writes ISO15765-4 or plug them into an Arduino CAN-L and CAN-H and read them using pyOBD or canutils?
The diagnostic bus really is the diagnostic bus, but it likely has more information available than how the JK works. A lot of the other Jeep vehicles don't treat the diagnostic bus as firewalled off from the other.

That really is the IHS bus on pins 3 & 11. Very convenient!

Nothing special to read that bus. You'll have to lower the speed (I think - double check the service manual) since the IHS bus is usually only 125 Kbps instead of 500, but that's it.

You may also find this interesting: How hackers could slam on your car's brakes - Aug. 1, 2014

That Miller guy contacted me about the Grand they talked about in the article. One thing I found distateful - they didn't actually hack it, they just looked at the wiring information and said it could be done. Crappy press out of nothing, but they certainly do have a point in that the Grand appears to be more hackable than the JK.
 
41 - 60 of 78 Posts
Top