Honda tire pressure monitor light project

FYI, just discovered this also work in Ubuntu running on Parallels on my mac!

Now what does all this mean. :slight_smile:

1 Like

nice work! now try the following:
cansniffer -cae can0

and do another screenshot

So it appears to be the same ID’s showing up. Is that interesting?

Also is there any good documentation for canutils? For example, what does the section on the right side represent (where you see the … that change from time to time)

1 Like

The text you see on the right is simply ascii representations of the bytes. Sadly, mostly useless in for obd info (or at least in my experience)

What you’re looking at are the raw broadcasted values on the bus. Some are broadcasted, other messages are not. example - VIN.

Check out these links (each helped me a ton in understanding some basics). I’m new to forum but plan on posting something helpful within the week on hackster revolving around getting obd2 data to thingspeak for visualizations.

1 Like

Thanks!

Other great resources that I was looking at last night include the Car Hackers Handbook and the Open Garages YouTube series.

BTW- if there is anyone in the Toronto area interested in this stuff, I’d love to meet up!

So I did some static CAN sniffing and determined a few things on my 2012 Honda Odyssey.

I was able to decode brakes, parking brake, gear shift position, TCS status, headlight status, doors open/closed, seat belt status, cruise status, and AC on/off.

Pretty happy about this.

One thing I’ve noticed is that for all of the ID’s, Byte 7 is constantly changing. Is this some kind of checksum? Wondering if that could be difficult to reverse engineer. I have tried injecting some messages with no luck…really hoping to convince the car something is happening that is not.

Another thing I’ve noticed is that the radio, climate control, and door module are likely on a different bus. Not too surprised.

Next need to get a buddy to drive while I take some on the road data!

1 Like

I’ll be in Montreal over New Years if you’re around for a cup of coffee… and the journey!

Hey, personally I’d love to come to Montreal for New Years but my wife and kids might not be so keen on it. :slight_smile:

Phew, it took me a while to get here, but I was able to successfully capture canbus data from my 2012 Honda Odyssey and then play it back to an extra instrument cluster I had lying around.

Test rig:

I built a simple test rig by learning the pinout of my Honda Odyssey cluster. It is a 32 pin connector. For purposes of this test, I used 2 12V power lines (pins 1 & 17), 3 grounds (pins 4,31, 32), HSCAN+ and HSCAN-. There are pins for low speed CAN (125kbps) but I am not playing with those yet. The setup is powered by 8 AA batteries. I added a 125 ohm resistor between the data lines on my breadboard.

Using socketcan-serial, I ran “candump -l” which is part of the socketcan Linux utility. I drove for about 15 minutes and captured 59 mb of packet data.

Next comes the fun part…I ran canplayer -I [filename] to play my data into the test cluster. Voila, the cluster showed the RPM from the start of the file!

Unfortunately the fun only lasted for a few seconds, as I keep getting a “no buffer space available” error. The only way to clear it is to turn the cluster on and off. Any suggestions on how to fix this? The output below might be interesting. Also here is a movie showing the tach move!

parallels@ubuntu:~$ ip -details -statistics link show can0
5: can0: <NOARP,UP,LOWER_UP> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
RX: bytes packets errors dropped overrun mcast
638465 80715 0 0 0 0
TX: bytes packets errors dropped carrier collsns
198 29 0 0 0 0

1 Like

In the video I just noticed that before the file errors out the TPMS light turned off! So in theory I can now isolate the “good TPMS” CAN messages, disconnect my TPMS module, and publish “good TPMS” CAN messages using a Carloop!

Craig, this is fantastic work! Congratulations! Once you find the actual messages that modify the TPMS light on the dashboard, you will be entering the Carloop Hall of Fame!

Thanks Alan! Any thoughts on the buffer error? I’m not sure where to go with that.

Maybe try restricting the amount of CAN message IDs that you log. For example candump can0 374:374 might be a good idea to restrict CAN messages to ID 374 for example.

I’m actually receiving the error when trying to send CAN messages. Seems like I can send 15 at a time or so.

Just wondering if there is a workaround, would be great to playback the 15 minutes of candump file and watch the gauges move around

Well I did it! Discovered that the arbitration ID for TPMS is 333

I then noticed that the messages go in a pattern like this:

(1476987407.909367) can0 333#0000000000000F
(1476987408.009644) can0 333#0000000000001E
(1476987408.109524) can0 333#0000000000002D
(1476987408.208971) can0 333#0000000000003C

I wrote a script to keep playing those messages via canplayer and the light seems to be staying off!

PS I still want to figure out how to play 15 minutes of a candump file!

Update. So now I verified that it REALLY works. :slight_smile:

I modified the Julien’s minimal transmitting code app and changed the values to the appropriate ones for “working” TPMS in my Honda.
I then disconnected the TPMS module, located just above the accelerator pedal.
I flashed the code to my Particle and so far so good, no TPMS light!
Next step I need to get the Particle to go to sleep when the car is off and do some more testing to make sure this really works.
Below is a snippet of code (changes from Julien’s code) and some pictures. Note that I have a light on for a missing Blind Spot Information System since I took the cluster from a car that had this feature and ours does not. So next I need to reverse engineer this signal!


// A CAN message has an ID that identifies the content inside
message.id = 0x333;

// It can have from 0 to 8 data bytes
message.len = 7;

// Pass the data to be transmitted in the data array
message.data[0] = 0x00;
message.data[1] = 0x00;
message.data[2] = 0x00;
message.data[3] = 0x00;
message.data[4] = 0x00;
message.data[5] = 0x00;
message.data[6] = 0x0F;
// Send the message on the bus!
carloop.can().transmit(message);
message.data[6] = 0x1E;
carloop.can().transmit(message);
message.data[6] = 0x2D;
carloop.can().transmit(message);
message.data[6] = 0x3C;
carloop.can().transmit(message);
lastTransmitTime = now;

}
}

Wow, that’s an impressive accomplishment! Well done! You can put a delay(100); in between each transmit to insert a 100ms pause in between each transmit. The messages you posted above show a delay of 0.1s in between each frame.

I’ll see if I can figure out what the “no buffer space available” message means.

Thought it might be useful to share the message shown when the TPMS Module is reporting low tire pressure:

Where the last digit changes from 0E to 1D to 2C to 3B

333 01 00 00 00 00 00 0E

Not sure if 01 just means “a tire is low” or “1 tire is low”. Pretty clear that in this car the TPMS module does NOT report tire pressure, only if a tire is low.

1 Like

Thought it might be useful to share the message shown when the TPMS Module is reporting low tire pressure:

Where the last digit changes from 0E to 1D to 2C to 3B

333 01 00 00 00 00 00 0E

Has anyone have any insight to the algorithm used to generate the last nibble of the last byte? It does seem like a sum then XOR’d by a value…

For example, sum of (00 00 00 00 00 00) = 00 ^0x0F == 0x0F
sum of (01 00 00 00 00 00) = 00 ^0x0F == 0x0E

But this does not work with much of the data I have traced from a Honda. I mean, I can confirm that there are some messages that are 8 bytes, first seven are 0x00s and the last byte is 0x0F, but that algorithm doesn’t work with everything.