Announcement

Collapse
No announcement yet.

Send multiple OBD commands at a time and receive response simultaneously

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

  • Send multiple OBD commands at a time and receive response simultaneously

    I'm working on application which connects OBD2 adapter and getting the real time data like speed,rpm,throttle position etc..When I read one command at a time, it works fine like by sending command "010C\r", I get current RPM.

    But now I want to read multiple commands at a time. I mean at a point of time, I want to know speed,RPM and throttle position etc..So I want to send above commands and get a response at a time.

    How is it possible ? Someone can guide me.

  • #2
    The protocol isn't set up for multiple requests in one command, so no, you can't do what you're trying to do. You can automate the requests and the return data pretty close together, but the response times will depend on the vehicle make and the capabilities of your OBD reader. The faster you go, the more inaccurate the data.

    -Best,

    Matt
    http://petrolr.com

    Comment


    • #3
      @M-Helm ;

      Thanks for the reply !


      Yes but in other applications like EngineLink HD ,Dashcommand, we found that multiple components are updated at a time like if we are driving the car and check the RPM,Sped and Throttle then they are updating at every 1 second. It looks like real time data.

      I'm surprised that how is it possible ?

      We have added code like if user wants to show 3 components, then for every component, one thread is generated and it handles request and response of that command. So in this case , 3 threads are generated and we get response but it takes too much time like if we are watching on Speed out of 3 PIDs then speed is updated after 3-4 seconds delay.

      We also need to lock the code where it sends the request and get response bcoz OBD2 adapter handles one request and response at a time.

      And if we don't lock the code then we get unpredicted results which might be due to common shared stream used by socket communication between the application and obd2 adapter.

      Any idea or suggestions how to handle this ?

      Comment


      • #4
        Have you tried just monitoring the data that comes on the bus normally? I thought the main stuff was getting broadcast all of the time so if you just monitor traffic you can get the speed/rpm/temp etc. A lot of vehicles use the CAN bus to get information to the dash cluster and you only need to make requests if you need something else. The data is being sent all of the time otherwise to the cluster. If you just monitor that PID you should get any information sent to the dash cluster over the data lines.

        Note: I have not actually monitored the bus in my truck but this is the understanding that I have. You should be able to find source code that does this if you look around.

        Comment


        • #5
          Originally posted by nish View Post
          So in this case , 3 threads are generated and we get response but it takes too much time like if we are watching on Speed out of 3 PIDs then speed is updated after 3-4 seconds delay.
          If you're only requesting 3 Pids and the update time is 3 seconds or more, then there's something seriously wrong with your software. The problem is NOT the communication speed, nor the delays between requests and replies as specified by the protocols.
          Each of the protocols (even the slow ISO and SAE ones) can handle several requests and replies per second.

          Updates rates may vary between vehicles. It depends how many ecu's will respond to your request.
          If there are 2 engine ecu's you might get 2 replies to each and every request.
          Also the automatic gearbox can reply with either data or a Negative Acknowledge.

          Comment


          • #6
            I don't know what your code looks like, so I could be way off base, but I think you might have better luck handling all the obd messaging in one thread and then messaging(sending to handlers or whatever) the data to the GUI threads. On newer cars, polling the obd every 100ms shouldn't cause problems, though you could just programmatically wait for the ">" to be sent before sending the next request.

            -Matt
            http://petrolr.com

            Comment


            • #7
              I know this is an old thread.
              But just wanted to say that there're few apps out there does process multiple PIDs simultaneously using CAN bus protocol.
              I know this because I've been using an Android app called CarPros for a while. And it does it.
              Torque and the other app I can remember the name do that too.

              https://youtu.be/k8G2Y6RwlIo

              Comment

              Working...
              X