Announcement

Collapse
No announcement yet.

Need advice on OBD c#.net app

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

  • Need advice on OBD c#.net app

    First off let me state that I have found ALOT of information on this forum, but it is lot to mentally process. So if anyone reading this can give me some specific advice I'd greatly appreciate it. I am insterested in building a c#.net application to read data from my 2000 Nissan Frontier. From what I gather you cannot nativly talk to the on-board computer and that I need a special cable to convert the data stream from the car to serial. What exaclty do these devices do to convert the stream to serial? Do they process all availible data from the car, or do they only process the government mandated operations? I understand that there are manufactured specific codes/operations that can be revered engineered or obtained at I high price. I'm not concerned with those, *yet*. What product out there gives the most flexible API.

    Also what is an ELM?

  • #2
    That is correct -- there are 7 different types of vehicle networks, depending on how you look at it. None of these are ethernet, usb, or anything on your PC so you need a vehicle network interface box/cable. It's basically a gateway between your PC and the car. Most tools will let you send and receive raw bits/bytes so you can do almost anything with almost any tool; it'll just vary in difficulty, speed, and effort.

    There's a published international standard API defined by society of automotive engineers called SAE J2534 and everything else uses it's own proprietary-little-driver. The big difference among boxes is speed, control, technical support, etc just like you'd experience with any other product. I work at DrewTech and we make the J2534 Mongoose cable. I don't have a lot of C# experience, but I can send you some example C# code that would get you started. I'm a lot better at C/C++ than C# so don't throw tomatoes.

    The ELM is a popular, dirt-cheap interface box that falls into the proprietary category. It's fine but be prepared to reinvent the wheel, access the serial port directly, and make your own driver. A lot of people go this route and it's ok for some hobbyists. But you won't exactly get a business standing behind it with 8am-5pm phone based technical support.

    Comment


    • #3
      Originally posted by OrangeSword View Post
      First off let me state that I have found ALOT of information on this forum, but it is lot to mentally process. So if anyone reading this can give me some specific advice I'd greatly appreciate it. I am insterested in building a c#.net application to read data from my 2000 Nissan Frontier. From what I gather you cannot nativly talk to the on-board computer and that I need a special cable to convert the data stream from the car to serial. What exaclty do these devices do to convert the stream to serial? Do they process all availible data from the car, or do they only process the government mandated operations? I understand that there are manufactured specific codes/operations that can be revered engineered or obtained at I high price. I'm not concerned with those, *yet*. What product out there gives the most flexible API.

      Also what is an ELM?
      I manufacture an ELM compatible device so I am probably biased towards that but for whatever it's worth.

      The ELM devices use a modem like AT command set to control the inner workings of the interface, like everything else this has it's pros and cons..

      Pros.

      1. It's an extremely simple interface and you can rapidly develop an application for this, witness the number of programs (free and for fee) available for the ELM compatible devices

      2. Experimenting with OBD II just requires the interface and a serial terminal. Example: To see what the response would be on sending 0100 to the vehicle simply connect to the interface via a serial terminal and send a 0100.

      3. Actually going direct to a serial port is a lot easier than trying to finagle an API to do what you want... there are tons of C# classes that handle talking directly to the serial port and it is pretty trivial so I do not consider this a CON.

      Cons.

      1. Speed- The ELM style devices are going to be slower than a J2534 device but the OBDPro for example can keep up with all traffic on most of the protocols and even on CAN it takes a lot of traffic to overwhelm it.. Also by playing with filters etc you are able to do what you want without much overhead.

      Just my 2 cents for what it's worth

      Paul
      www.obdpros.com

      Comment


      • #4
        thank you

        I like this forum and thank you for replies.

        Comment


        • #5
          What about an interface that is compatible with Vag-Com would this be in a similiar manner?
          Failure is not an option...
          __________________________________________________ ______________________________
          The only full multizone / multiscreen cross platform open source Front End -> OpenMobile

          Comment


          • #6
            So am I correct in thinking that a J2534 device is a ELM device with logic layer(api) built into it? And that that logic layer is mandated by the SAE?

            I would probably write it in C++ if i knew the language better. I've been working with C# for the past year and part of the reason I want to do this is for practice.

            Comment


            • #7
              You're correct that J2534 is just a driver layer on top of a product, defined by the SAE and mandated by the california air resources board (and others). This way independent repair shops can buy a passthru interface, the passthru reflash software from the automaker, and perform flash-updates on a modern car.

              ELM Electronics is company that sells super-low-cost chips used in hobbyist equipment. They do not provide a J2534 driver.

              Comment


              • #8
                Originally posted by michbound View Post
                Also by playing with filters etc you are able to do what you want without much overhead.
                Hi Paul, could you explain that ? That went over the top for me. What are filters ?
                Thanks!

                Comment


                • #9
                  it's a honda,

                  Since the Can bus spews data at 500 KBits in order to limit the data you can use filters and masks to only look at a subset of the data.

                  This capability if built into the Pic micro used by the OBPros and the datasheet explains how you can set the filters and masks to look at a subset of the data....

                  This is only applicable for the CAN buses since the OBDPro can easily keep up with the rest of the protocols.

                  Paul
                  www.obdpros.com

                  Comment

                  Working...
                  X