Announcement

Collapse
No announcement yet.

Anyone interested in DIY CAN info?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Anyone interested in DIY CAN info?

    Hello,
    I'm a grad student at Minnesota State University, Mankato. Much of my work over the last couple years has been working with the Controller Area Network systems used in newer vehicles, mainly Prius and Escape hybrids, but also a Canadian diesel smart for a hybrid project. We have used several Mp3car systems in our test vehicles and been very satisfied with their performance. In conjunction with the mobile systems we use LabVIEW software, some National Instruments data collection hardware, and third party CAN-USB adapters.

    I've been working on some stand alone software for CAN, which is mostly functional, and adding a few more options and fixing bugs in the next couple days. It shows Message ID information, graphs, basic calculations, and can transmit messages to the CANbus and also record messages to a text file for easy transfer into a spreadsheet. As an example, with an earlier version of this software we connected to a smart diesel and within about 5 minutes had identified TPS, RPM, and brake position information present on the network. We eventually deciphered clutch actuation, gear position, CTS, and KPH also.

    Is anyone interested in a free copy of the software to try recording from their vehicle? I am very close to making an executable version that doesn't require the LabVIEW development software.

    I should warn that the software currently doesn't automate OBDII requests or responses, although we have done some work with those. It is mainly geared towards deciphering the native CAN traffic present on the vehicle. Other caveat is that this isn't an offer tied to any business or to my school, just trial software offered by me for your personal use with no suitability warranty offered. If you do try the software I'd appreciate your willingness to share your recordings with the Mp3car forum community, and also feedback on bugs and suggested improvements, etc.

    Basic requirements:
    -Laptop/mobile computer (Win XP has the most testing, others may work. Very moderate specs are perfectly acceptable)
    -Free download of LabVIEW Run Time Engine
    -CAN-USB adapter

    I will post more information/updates on software progress. I'd expect a few days before I have an executable to send out. You can post here with questions that others might share, or PM for something particular.

    Thanks,
    Mark

  • #2
    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
    Last edited by preet; 11-12-2011, 05:15 PM.
    Check out my Frontend project!
    http://prismaticproject.weebly.com/blog.html

    Comment


    • #3
      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.

      Comment


      • #4
        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.
        Click image for larger version

Name:	grab1.JPG
Views:	1
Size:	196.4 KB
ID:	2281276
        Click image for larger version

Name:	grab2.JPG
Views:	1
Size:	204.7 KB
ID:	2281275

        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.
        Click image for larger version

Name:	grab3.JPG
Views:	1
Size:	172.3 KB
ID:	2281277

        edit:
        The columns are:
        millisecond timestamp;MID;data0;data1;data2;data3;data4;data5; data6;data7;
        Last edited by markmakeitso; 11-12-2011, 06:24 PM. Reason: added explanation of 3rd image

        Comment


        • #5
          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.
          Check out my Frontend project!
          http://prismaticproject.weebly.com/blog.html

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  Originally posted by SilverJester View Post
                  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.

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      Originally posted by markmakeitso View Post
                      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.
                      It streams over USB. Here is the can hardware I'm using: http://www.sparkfun.com/products/10039. Let me know if you need any other info.

                      Originally posted by markmakeitso View Post
                      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.
                      That's not a bad idea, except removing a valve stem will lose air very quickly. But I can probably some other way to have it slowly leak air. I will definitely use your suggestions, thanks.

                      Comment


                      • #12
                        Hi everyone,
                        I got a distributable version made up today. It has a couple rough edges, but is almost completely functional. If you have the RTE installed you can open it up and run it, but without the correct adapter and a vehicle there isn't a whole lot to do. Just figured out how to upload files using the advanced post option, see attached.

                        Couple notes:
                        Only the large icon works, small one and the Windows tray icon are blank. Not tied to the name Proto-CAN either.
                        Autoconnect doesn't work, so click the run arrow, then click on the "Connect" button during the countup to begin receiving messages.
                        Somewhere along the way the periodic TX functions stopped working, need a little bit of research why. The single TX function still works though.
                        Occasionally errant MIDs show up, the sorting algorithm from the com. port might need some tweaking.
                        Early message entries are occasionally assigned incorrect time stamps. Irritating, but should be a straight forward fix.

                        I'll try to get some vehicle recordings made soon and post them. I also need to get my University webspace set up so I can host the files. A spreadsheet viewer will also be available soon which will allow some sorting abilities for recordings. One of our undergraduate classes will be using the software for a lab assignment over the next couple weeks, I may have a pile of recordings and some free research courtesy of the academic process. Ideally we can get a collection of recordings (organized and labeled appropriately) as well as a knowledge base of deciphered values for various models and manufacturers.

                        Sweet deal, I'm pretty excited. I've had this project on the back burner for awhile, so to finally have it gaining inertia is fun.

                        Addendum: Pre-2008 vehicle? Check this list, it might still be CANbus equipped.
                        http://www.auterraweb.com/aboutcan.html
                        Attached Files
                        Last edited by markmakeitso; 11-17-2011, 07:01 PM. Reason: Added link for CAN vehicle lookup

                        Comment


                        • #13
                          Great, great thread, people.

                          I need to monitor, decipher and send messages on CAN busses on Dodge and Ford diesel trucks.

                          Do you think I should start with the Easy Sync or the Audrino shield ?

                          I don't have Labview, though I have used it in the past. I am a good programmer. I usually work on Linux systems.

                          Thanks !

                          Comment


                          • #14
                            Hi elmerfud,
                            Just to clarify, you don't need a LabVIEW development installation to use the Proto-CAN software, just a free download of the run time environment as linked. If you have the EasySYNC hardware on hand and the PC ready I would guess you could be viewing and recording messages in very short order. The software doesn't automatically decode OBDII messages though, so if you're primarily concerned with only those messages it's not developed enough to be extremely useful. On the other hand, for handling raw CAN traffic there are fewer options. We used to have a freeware Windows CAN viewer software at my school that we used with a CANUSB cable, but it didn't have graphic display or any logging capability besides taking screenshots of the traffic window, which worked as well as you'd expect. Don't remember the name of the software right now, perhaps I can find it though. There are also several commercial packages that do an excellent job of tracking CAN data, as well as integrating other protocols simultaneously. Bring a stack of wallets though, because neither the hardware nor software is cheap.

                            I haven't tried the Arduino hardware listed, although my brief experience with an Arduino Uno was fairly encouraging. Much easier than stumbling through Microchip's PIC datasheets, although I have managed a modicum of competency in PIC C despite the manufacturer's best efforts I'm not sure if there's an out of the box Arduino application that will do what you envision. Silverjester's description makes it sound like he has real time filtering in place to the PC, but not logging. If that will work for your process that could work. Hopefully he's still privy to this thread and could possibly give more details or even code.

                            I have recorded off of some Ford Escapes, and diesel smarts, but no full size trucks or Chrysler products yet. There was also talk of Chrysler isolating the OBDII port from the normal CAN traffic. I haven't confirmed, and there are workarounds involving wiring diagrams and soldering irons.

                            Long story still long: Not sure exactly what your project involves, some clarification could help. To muddy the waters even further, the possibility of streaming from one of the numerous ELM adapters is also possible.

                            Crosses fingers not a doublepost. We'll see.

                            Comment


                            • #15
                              Originally posted by markmakeitso View Post
                              Hi elmerfud,
                              Hello. Thanks for the reply.

                              Just to clarify, you don't need a LabVIEW development installation to use the Proto-CAN software, just a free download of the run time environment as linked.
                              OK, I didn't know that. The last time I used Labview was in 1990. I'm not kidding.

                              If you have the EasySYNC hardware on hand and the PC ready I would guess you could be viewing and recording messages in very short order. The software doesn't automatically decode OBDII messages though, so if you're primarily concerned with only those messages it's not developed enough to be extremely useful.
                              I like doing things in Linux. I was expecting to write my own CAN deciphering software, ALTHOUGH, Linux has a package called Wireshark that specializes in watching data on a "network" and applying filters, etc to figure things out. I have not used it extensively, but I have used it.

                              Sooner or later I'll need to handle CAN packets in my own code, so sooner or later I have to write that code.

                              On the other hand, for handling raw CAN traffic there are fewer options. We used to have a freeware Windows CAN viewer software at my school that we used with a CANUSB cable, but it didn't have graphic display or any logging capability besides taking screenshots of the traffic window, which worked as well as you'd expect. Don't remember the name of the software right now, perhaps I can find it though. There are also several commercial packages that do an excellent job of tracking CAN data, as well as integrating other protocols simultaneously. Bring a stack of wallets though, because neither the hardware nor software is cheap.
                              Like I said, I like doing things in Linux. Its got a lot of powerful tools built in.

                              I haven't tried the Arduino hardware listed, although my brief experience with an Arduino Uno was fairly encouraging. Much easier than stumbling through Microchip's PIC datasheets, although I have managed a modicum of competency in PIC C despite the manufacturer's best efforts I'm not sure if there's an out of the box Arduino application that will do what you envision.
                              I doubt there is.

                              Silverjester's description makes it sound like he has real time filtering in place to the PC, but not logging. If that will work for your process that could work. Hopefully he's still privy to this thread and could possibly give more details or even code.
                              I'll share whatever I develop.

                              I have recorded off of some Ford Escapes, and diesel smarts, but no full size trucks or Chrysler products yet. There was also talk of Chrysler isolating the OBDII port from the normal CAN traffic. I haven't confirmed, and there are workarounds involving wiring diagrams and soldering irons.
                              Well, the Ford trucks have 2 CAN busses, one low speed and one high speed. I'll actually need to look at both. I doubt that both go to the OBDII port, but I might be wrong.

                              Long story still long: Not sure exactly what your project involves, some clarification could help.
                              Doing all sorts of things from capturing various human interaction CAN messages (turn lights on) to sending data to and from engines and transmissions.

                              To muddy the waters even further, the possibility of streaming from one of the numerous ELM adapters is also possible.
                              I also need an ODBII scanner for both Dodge and Ford trucks, so please tell me about that.

                              Either way, I want to start with some dedicated hard core CAN scanning, so that will either be the EASYSYNC device or the Aurdino. Are maybe both as sooner or later I'll need to use a microcontroller to manage things.

                              Any and all insight is welcome.

                              Thanks again for replying.

                              Comment

                              Working...
                              X