Thread: Anyone interested in DIY CAN info?

Hey,

I'm super interested -- have a few questions for you though. What CAN-USB adapter do you use? Would you be willing to open source your software, or at least parts of it? If not, could you give us more details on some of the specifics (as a grad student, do you have any papers or something we could read?). It would be awesome if your software could be used along-side or as part of an infotainment system to provide manufacturer-specific data to the user. I'm working on an infotainment system that has some basic OBD/CAN functionality which started out as an effort to look for manufacturer-specific PIDs [see old v. http://www.youtube.com/watch?v=GsBpPDegAds]. You can do a ton of cool stuff with additional data not provided with the standard set of OBD PIDs.

Preet

What CAN-USB adapter do you use?

I use the EasySYNC USB2-F-7001, (http://www.easysync-ltd.com/product/...b2-f-7001.html) I assume the slightly more expensive 7101 would work identically. I was hesitant to mention the hardware, since it isn't sold by Mp3car. As far as I can tell however, the hardware and software offered focuses on OBDII functionality. I may be mistaken however.

Would you be willing to open source your software, or at least parts of it?

There is a chance of that, with a few hurdles. LabVIEW is very commercial software, and I doubt anything written in it could be released as a truly open source product. Sharing the .VI (the programs which require the LabVIEW development software to run) is possible. Making a free distributable executable (only possible with the pro versions of the software, $$$) is the stage I'm at right now.

If not, could you give us more details on some of the specifics (as a grad student, do you have any papers or something we could read?).

No paper right now unfortunately, part of the reason besides my elongated stay in grad school. The project began with a mostly stock Prius, and grew to several vehicles with add-on PHEV packs. We datalog drivecycle and also charging information. We have some OBDII requests used in the datalog, but hybrid operation is not covered very thoroughly by standard PIDs. Also, if the information is available natively on the bus it is much more convenient to eavesdrop than to request and decipher many OBDII responses.

It would be awesome if your software could be used along-side or as part of an infotainment system to provide manufacturer-specific data to the user. I'm working on an infotainment system that has some basic OBD/CAN functionality which started out as an effort to look for manufacturer-specific PIDs [see old v. http://www.youtube.com/watch?v=GsBpPDegAds]. You can do a ton of cool stuff with additional data not provided with the standard set of OBD PIDs.

Integration is probably possible, but I haven't looked into it too much so far. To be honest, this is designed as research software. Once network values have been identified and the algorithms established then usage in other more streamlined interfaces is much more feasible. I don't know if your software does bulk CAN transfer streaming or OBDII request/response traffic, but this program is definitely situated in the former.

I'm about done working for today, but I grabbed a couple screenshots for now to give you an idea about what I'm describing.



Aaaannnd a screengrab of an output data file. I may be an idiot, but didn't see a way to attach a file to a post.


edit:
The columns are:
millisecond timestamp;MID;data0;data1;data2;data3;data4;data5; data6;data7;

That looks pretty complicated
My software requests/replies right now, but the ELM327 cable that I'm using has an option to monitor the bus and just dump everything to a buffer. I'd imagine it wouldn't be too hard to just output all traffic the bus sees, similar to what you have in the third screenshot above.

With regards to open-sourcing, I was more interested in the methodology used to go from the data dump of traffic to figuring out what the message values mean. Are you using some 'intelligent' way to sort through the traffic or are you manually figuring out relationships (ie press gas / increase revs / see which message ids correspond to increasing values). There was a research team (http://www.autosec.org/index.html) that did something similar (they built their own tool to monitor and interpret messages on the bus) but for the purposes of attacking car security. I tried asking a couple of them awhile back about their software but didn't get any replies.

If there are other options to the EasySYNC cable that stream all traffic I may be able to change part of the programming to accommodate that also. The EasySYNC cable uses a virtual com port, and LabVIEW has several predefined functions for reading/writing that are great.

We are currently using manual association methods to determine message contents. I.E. two people in the car, one manipulates a value while the other monitors. Sometimes we use live analysis, other times we just make recordings to go over in a spreadsheet later.

For example, on the smart diesel we started with key on, engine off. One person cycled the TPS smoothly while I watched the bar graphs and progressed through the different MIDs until I found data bytes that seemed to correspond. After we documented the max and min ranges we started the engine and did a similar test with RPM. Making recordings to determine a single parameter has led to fairly good results. Fuel level, RPM, TPS, CTS, and KPH have all responded to this method. We have also tried unplugging sensors during operation to trigger abrupt changes in values. A bit crude perhaps, but perfectly acceptable in my book.

There has been some discussion about automating more of the process. For example, tracking OBDII PID values against CAN traffic might reveal obvious correlations, and automatic identification of adjacent byte addition (similar to AB responses in OBDII, i.e 0C-RPM) shows up as fairly noticeable sawtooth patterns when displayed against time. The "New MID" event log can also help, as some MIDs are not regularly broadcast unless required. So far different vehicles from the same manufacturer have shown a tendency towards similar if not identical methods, which is always a pleasant surprise. I'm sure if manufacturers were more intent on maintaining a higher level of secrecy they could make the job of reverse engineering almost impossible, but so far that hasn't been the case.

That's it for now, perhaps I'll get some more work done tomorrow.

Let me know in this thread or via DM if there is anything mp3car can do to help you. Looks like a fun project. Congrats on the progress so far.

I've been reverse engineering the CAN Bus on my Mitsubishi Evo X (2008) using a similar methodology as you. I'm using an arduino and a small program I wrote to that displays all the messages on the network. Basically I'll hide all but one ID at a time and begin manipulating the car (pressing buttons, pedals, driving, etc.). I'm actually doing it for another project I have in mind, but there are still a few ID's I need to find. The TPMS ID seems like one which would be especially hard to find.

If your software works with my arduino hardware then I'd love to give it a try and see if it can help me decode any more messages.

Originally Posted by SilverJester

I've been reverse engineering the CAN Bus on my Mitsubishi Evo X (2008) using a similar methodology as you. I'm using an arduino and a small program I wrote to that displays all the messages on the network. Basically I'll hide all but one ID at a time and begin manipulating the car (pressing buttons, pedals, driving, etc.). I'm actually doing it for another project I have in mind, but there are still a few ID's I need to find. The TPMS ID seems like one which would be especially hard to find.

If your software works with my arduino hardware then I'd love to give it a try and see if it can help me decode any more messages.

Hi SilverJester,
Does your arduino stream messages to PC over USB or serial? It might be relatively easy to rewrite part of the code to work with yours if that's the case. If you have a description of how you package data I could take a look.

As for TPMS, if I understand correctly many sensors need to be spinning before they'll transmit. What you could do is put your car up on stands or a lift and make a recording at a constant speed. Then rerun the test, but remove a tire valve stem just as you begin. As you run the tire will deflate, without danger of damaging a rim from vehicle weight. When your tire pressure warning goes off record the time stamp ms of the test and stop recording. Review of the log up to the noted time will hopefully show a decreasing value, or perhaps just a single change around when the monitor alarm went off. Just a possible strategy.

Fiberoptic,
Thanks, I'll let you know if anything springs to mind.

I did a fair bit of work today, hopefully a distributable version in a couple days. If anyone is interested you could download and install the Windows Run Time Engine for LabVIEW 8.5, some RTEs are backwards compatible, but most aren't.
http://joule.ni.com/nidu/cds/view/p/id/861/lang/en
If the RTE is installed you should be able to start the program at least, but it won't do much besides make a file and TX. If someone happens to have the EasySYNC adapter already that's ideal, otherwise if you're loaded for bear and want to buy it to try the software I'd salute your eagerness. Or, if someone feels like visiting Mankato, MN for a recording session we could make that work too. I'm open to other hardware solutions, but they do take a fair bit of time to implement.

Thanks for the interest, I'm crossing fingers for a program to send out Wednesday.

This is great and the timing is just perfect as I want to start deciphering can data from my Touareg. Eventually my goal is to be able to send song and other information from the carpc to then information display similar to how the stock nav unit did. There are some other things I would like to do as well but but I need to take baby steps.