Honda tire pressure monitor light project

[clemoyne]

Thanks for this post, I was able to use this to do my 2nd Carloop test.

I was able to dump a whole bunch of OBD2 data. My goal is to identify a message telling the cluster to turn on the TPMS light. So I thought I'd log some data with the light off and the light on and see what differences I find.

As I'm sure most of you already know, its not that easy! In just a few minutes of running my Honda generated almost 10,000 messages. I was able to delete 7,000 duplicates, leaving 3,000 messages to analyze.

So my question, what's the best way to go about analyzing the data? I'm not the best coder and barely understand Hex, but I think I can figure this out.

Here are some example messages that came across when the TPMS light was on

000002f500000007 (7 times)
7fc008000000001d (34 times)
02030c1c (1 time)

It is interesting that some are 16 characters and some are 8 characters. It also looks to me that the first 2 or 3 digits might identify something?

[jvanier]

Nice work! I moved the post to a new topic so I can help you get to the info you are looking for.

Do you have some code to share at this point? If you have a GitHub account you can post it to a gist and share the URL here. You can also post a log of the data you collected as a gist.

[clemoyne]

So far all I've done is used the code from this post and dumped the serial output to my laptop. I cleaned up the output and used Excel to look at it. Long term I'd like to write Python script to parse the data, but first I need to figure out what I'm looking at!

Can anyone recommend a good resource for decoding CAN data?

PS- met you guys at Maker Faire NYC last weekend, it's Craig from chicagodist.com and elmwoodelectronics.ca

[alanm]

Hey @clemoyne,
Yes, we remember you very well! Hello and welcome to the Carloop community! Here is a list of CAN IDs that we've started compiling and updating: https://community.carloop.io/t/list-of-can-id-descriptions-from-opengarages-org/104 Let me know if you find new ones for Honda specifically. Would be great to update that list.

In response to your question about reverse engineering, I would highly recommend socketcan with linux. You will need to use a linux computer (a Raspberry Pi works well). Running commands like cansniffer can0 can be incredibly helpful, especially if you can disconnect and reconnect the TPMS unit to identify which messages are changing.

[clemoyne]

To keep this thread going, here is a great link discussing how to install / run socketcan on Carloop: https://community.carloop.io/t/use-carloop-with-socketcan-and-can-utils/117

I was trying to figure out if I could install can-utils on my Macbook and of course stumbled onto a post by Alan leading me to believe it is not possible.

So I think I'll resort to running can-utils on a Raspberry Pi and just SSH into the Pi. I might get fancy and re-appropriate an old Windows machine with Linux, but hoping the lag with the Pi is not too bad.

[alanm]

Hey Craig!
Thanks for posting this. It reminded me that there is a great VM application to run Linux on your Mac OS called VirtualBox. At the last Car Hax two people used Virtual Box to effectively run socketcan and can-utils and communicate over USB serial with Carloop!

https://www.virtualbox.org/wiki/Mac%20OS%20X%20build%20instructions

To install from Mac OSX terminal with Homebrew:

brew update
brew tap caskroom/cask
brew cask install virtualbox

[clemoyne]

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

Now what does all this mean.

[alanm]

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

and do another screenshot

[clemoyne]

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

[clemoyne]

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)

[egarl004]

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.

http://www.digitalbond.com/blog/2015/04/13/attacking-canbus-part-1/

http://www.cowfishstudios.com/blog/canned-pi-part1

[clemoyne]

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!

[clemoyne]

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!

[egarl004]

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

[clemoyne]

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

[clemoyne]

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: 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

[clemoyne]

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!

[alanm]

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!

[clemoyne]

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

[alanm]

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.