Announcement

Collapse
No announcement yet.

Sniff a no-OBD Toyota

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

  • Sniff a no-OBD Toyota

    I have a Toyota diesel no-obd compliant.
    In the OEM manual say that it use ISO protocol, but it is inaccessible to OBD-progs. (Only works with Techstrem)
    I'm trying to use a sniffer to see the data traffic between the car and the OEM program. I'm trying to discover, if it use really the ISO, header, timming, fast or slow init....

    But my knowledge is not as high as my enthusiam...

    I intend to put a Y-cable, the mongoose in a PC running Techstream and other obd tool to read the K-line in another PC.
    Is there any other solution to sniff the traffic of data between the application and car?

    I searched and researched information about the protocol that Toyota car use (M-OBD), previous at CAN-bus and find nothing....
    Someone can aid-me?
    Thanks in advance
    Regards
    Last edited by crosyn; 02-13-2012, 05:18 AM.

  • #2
    The idea of using a Y-cable works. I have used that before.
    BUT, depending on what hardware you use for the sniffer it only works on one pin (7).
    I used a small breakout box between diagnostic socket and scanner. That way you can listen to any pin you want to. Useful when recording the communication for systems like Abs, Airbag, etc.
    You do have to convert the signal from the car to something useful to a PC - you could do that using a simple KKL-interface.
    I didn't use an obd-tool for listening. That doesn't give enough information. I used a program called COMWATCH that records data and timing information.
    Take a look here: Universal Communication Analyzer<br> <font color="red">Discontinued Product</font><br>
    Of course there are many other recording tools.

    Comment


    • #3
      Originally posted by crosyn View Post
      I intend to put a Y-cable, the mongoose in a PC running Techstream and other obd tool to read the K-line in another PC.
      Easier than a Y-cable, just enable the Mongoose debug log (instructions are in the manual). That creates a text file with lines recording every J2534 API call.

      Comment


      • #4
        Thanks for your replies, p2psmurf and joeyoravec.

        Where can I find a manual for Drewtwch Tool?
        At this moment I don't have yet the Mongoose, only the Tactrix, It's possible to log with it?

        Comment


        • #5
          A million thanks for your answers, p2psmurf and joeyoravec

          I have not got the mongoose yet, I have only the tactrix, do you know if I can log with it?

          Where can I find a manual for the Drewtech J-2534-1 Tool?

          TK

          Comment


          • #6
            Originally posted by crosyn View Post
            I have not got the mongoose yet, I have only the tactrix, do you know if I can log with it?
            No idea, I don't make that product, so you'd have to call their tech support.

            Originally posted by crosyn View Post
            Where can I find a manual for the Drewtech J-2534-1 Tool?
            Browsing the DrewTech website and clicking on support/downloads is a good place to start. Or call tech support. Or email support.

            Comment


            • #7
              Originally posted by joeyoravec View Post
              Browsing the DrewTech website and clicking on support/downloads is a good place to start. Or call tech support. Or email support.
              I looked for it in http://www.drewtech.com/downloads/index.html, where I found the 'Drew Technologies J2534-1 Tool' (a very useful tool).
              I'll try in the tech support mail.

              TK one more time

              Comment


              • #8
                I have been researching the process for doing this too.
                My car only has the mobd too which is really annoying but I saw on another forum a user getting some data off uisng tactrix openport 2.0 with techstream.

                Has got me contemplating trying to get an obd cable and cutting it up and trying to log the data and see if I can figure it all out. Just wish I had some time and money to spend on it..

                Comment


                • #9
                  Sniffing/logging/recording the protocol isn't that complicated.
                  It get's interesting when you start to interpret the protocol and find out which command does what and what reply you get, how the checksum works, etc.
                  The fun begins when you have to find out the conversion formulas for the data that is returned.
                  The biggest challenge is making the protocol fool-proof. What to do when an ecu doesn't respond, or sends something different then you expect.
                  Because these problems have probably not been recorded.
                  And then after some hard work you have implemented the protocol and it doesn't work, because you have timing problems.

                  Comment


                  • #10
                    Originally posted by p2psmurf View Post
                    Sniffing/logging/recording the protocol isn't that complicated.
                    It get's interesting when you start to interpret the protocol and find out which command does what and what reply you get, how the checksum works, etc.
                    The fun begins when you have to find out the conversion formulas for the data that is returned.
                    The biggest challenge is making the protocol fool-proof. What to do when an ecu doesn't respond, or sends something different then you expect.
                    Because these problems have probably not been recorded.
                    And then after some hard work you have implemented the protocol and it doesn't work, because you have timing problems.
                    Yeah, I guess the tricky part comes once you start the communication ...
                    But with a program that makes the calls (Techstream) if you can record the code that sends and what ecu responds, should not be so complicated, no?....a lot of work!
                    I would get to communicate with the ECU.
                    Know you about a similar project with toyotas? (I only know with OBD compliant vehicles)

                    TK
                    Last edited by crosyn; 02-13-2012, 05:20 AM.

                    Comment


                    • #11
                      Well you make that sound like a barrel of fun
                      I think if it got to that stage I would be giving up, I was more hoping that as an earlier implementation it would be a broadcast only setup rather than a query based system.. But just to be difficult probably not

                      Comment

                      Working...
                      X