Announcement

Collapse
No announcement yet.

Optimizing Scan Rate

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

  • Optimizing Scan Rate

    Hi,

    I have written an application running on an embedded system platform that connects to a serial-based Scan Tool. The vehicle I am testing against is a BMW X3. My goal is to maximize the number of PIDs I can read in a 1s period. The initialization sequence of my application sends the following to my ELM327 Scan Tool:

    "ATZ"
    "ATTP5" // set protocol to ISO 14230 KWP
    "AT ST32" // set timeout to 200ms
    "AT AT1" // Use adaptive timing option 1
    "AT BRD 23" // Set baud rate to 115200

    I can successfully poll PIDs at a rate of 1 per second if I use the above settings. Ideally, I need to get 10-20. Technically, is this possible? My application waits 50ms for a reply to each PID request in order meet the goal of 20 PIDs in 1s. I have not been able to to better than 4-5 PIDs in 1s. Is there something I can do to improve the performance? I get the feeling that it is a limitation of the bus on my vehicle. However, when I run a ScanTool software package with my ScanTool dongle on my vehicle I am almost certain it is polling better than 5 PIDs/second.

    I should note here that I get better performance on a Ford vehicle (somewhere in the order of 15 PIDs/second).

    Thanks in advance for your feedback.

  • #2
    I'd suggest using the elm optimisation of adding one byte on the end of your requests saying how much data you expect in response. That almost doubles the scanrate I see on my getups.

    Also, upgrading the baudrate between your computer and your scantool can have highly positive effects.

    Both of these optimisations are covered in detail in the ELM327 DataSheet.

    For what it's worth, I'm seeing data rates upward of 40-50 PID/s on both my OBDLink and my OBDPro right now, enabling just those two large-scale optimisations. [The rate is probably actually higher - I'm just seeing 40-50 PID/s arriving in my logfile, but my app is single-threaded, so in the time it spends burning those PIDs to the log and looking up the GPS position might translate to another couple PIDs].

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

    Comment


    • #3
      Oh. I see you're already upping the baudrate - nvm me. [are you sure it's working, by the way? There's a lot more to making the upgrade fully work than just "ATBRDXX"]

      Gary (-;
      OBDGPSLogger, for logging OBDII and/or GPS data
      OBDSim, an OBDII/ELM327 software simulator
      mp3car forums: obdgpslogger, obdsim

      Comment


      • #4
        Oh. And if that's all your app is doing right now, you can trim out a bunch of serial comms cruft:
        ATS0 - no spaces
        ATL0 - no linefeed [just cr]
        ATE0 - Don't echo what you send

        Probably others that I'm not thinking of right now, too.

        Gary (-;
        OBDGPSLogger, for logging OBDII and/or GPS data
        OBDSim, an OBDII/ELM327 software simulator
        mp3car forums: obdgpslogger, obdsim

        Comment


        • #5
          Hi Gary,

          Thanks for your prompt reply. Yes, I was able to verify the 115200 baud rate. I confirmed it by polling for one PID every 1 second at that rate. My next step was to keep increasing the number of PIDs. Eventually, I reached a limit of 5 PIDs.

          To clarify, would I just, for example, send:
          "01 0C 01"
          to get my RPM at a highly optimized rate?

          Thanks!

          Comment


          • #6
            It's covered in the data sheet in more detail, but ... almost. RPM is two bytes, and I guess I meant "nibble" at the end of the request [or byte, from the serial port's perspective]. So what you want for RPM would be:
            01 0C 2

            [you can strip spaces out there, too: 010C2]

            Gary (-;
            OBDGPSLogger, for logging OBDII and/or GPS data
            OBDSim, an OBDII/ELM327 software simulator
            mp3car forums: obdgpslogger, obdsim

            Comment


            • #7
              THANK YOU!!!

              I will try that first thing in the morning. Would you expect your observed results on a European vehicle that use the IS0-based protocols?

              Comment


              • #8
                Hi all,

                Gary is right disable space caracters, line feed, etc.. to expect get PID faster. But for an ISO 14230 protocol based vehicule don't expect to get more than 5 or 6 PIDs per seconds. Even your baudrate is set to 115200 the ISO baudrate is still 10400 baud so...
                The ISO15765 protocol (CAN) is quite faster. I 've got 10/11 Pids per second futhermore the CAN protocol allows to ask several PIDs per frame

                example:
                010C0D
                41012323

                in the example you ask rpm and vehicule speed at the same time. So you can reach 20 PIDs per second.
                I know you can ask more than 2 PIDs in the same frame but I can't say you that is the maximun.. Using this method, you will have to decipher multi-frame response

                I'm working on the topics too.. Please give us aware of the result of your test. I'm gonna do some too..
                www.outilsobdfacile.com

                Comment


                • #9
                  Thank you, remus08. Your post got me into thinking about something:

                  The only way I knew what protocol my vehicle was running was by sniffing the serial data from a PC-based scan tool software package that I was using. The one thing I couldn't decipher was how it was able to determine that my protocol was ISO 14230. My application needs to be agnostic and work for any vehicle. Is there a way to programatically determine the fastest protocol that a vehicle is using? I understand that the "AT SP 0" will automatically select the protocol. Is it safe to assume that this command will find the fastest protocol a vehicle is capable of?

                  I will post my results of the best scan rate that I can get on my BMW (ISO 14230 - based vehicle) as soon my car returns home :-)

                  Thank you very much to all for your help!

                  Comment


                  • #10
                    In all honesty, you probably want to leave ATSP well alone

                    ATDP and ATDPN are how you find out what protocol the ELM is using to talk to your car.

                    Gary (-;
                    OBDGPSLogger, for logging OBDII and/or GPS data
                    OBDSim, an OBDII/ELM327 software simulator
                    mp3car forums: obdgpslogger, obdsim

                    Comment


                    • #11
                      Is it safe to assume that this command will find the fastest protocol a vehicle is capable of?
                      Yes, it is the best way to stay "agnostic". Using parameters 0 for AT SP command let the charge to the ELM to fid the protocol automaticaly. The automatic research take for time for the initialization. I insist only on the initialization. I guess it's advice to wait 14s before sent the first OBD command.

                      the fastest protocol a vehicle is capable of
                      A vehicule (ECU) is design with a protocol and can't support severals. Older vehicule (non CAN) are slower that's all!

                      Could you please let us know on what you are working.
                      www.outilsobdfacile.com

                      Comment


                      • #12
                        Originally posted by remus08 View Post
                        Yes, it is the best way to stay "agnostic". Using parameters 0 for AT SP command let the charge to the ELM to fid the protocol automaticaly. The automatic research take for time for the initialization. I insist only on the initialization. I guess it's advice to wait 14s before sent the first OBD command.
                        Thanks, remus08. I changed my application to do a discovery of the protocol then send "0100". After that I wait 14s for the initialization to complete.

                        Originally posted by remus08 View Post
                        Could you please let us know on what you are working.
                        I am trying to get a better grasp of some embedded system platforms that I am working with. I thought that interfacing a hardware platform with a Scan Tool would give some good technical practice with serial I/O and working with a Real-Time Operating System.

                        I sincerely appreciate everyone's feedback. As promised I wanted to let the readers of this thread know that I can only get a maximum of 5 PIDs on a ISO 14230-based car.

                        Comment


                        • #13
                          Originally posted by remus08 View Post
                          Yes, it is the best way to stay "agnostic". Using parameters 0 for AT SP command let the charge to the ELM to fid the protocol automaticaly. The automatic research take for time for the initialization. I insist only on the initialization. I guess it's advice to wait 14s before sent the first OBD command.
                          Unfortunately, the built-in ELM327 protocol detection algorithm is not 100% reliable. In fact, on some vehicles it will fail 100% of the time.

                          For example, some cars support ISO 9141 and KWP, but only ISO 9141 reports OBD-2 data. Since ELM327 tries KWP before ISO, it will connect on KWP but you won't get any useful data.

                          Another example is 2000+ Chevy trucks. If you hard-set the protocol to VPW, ELM327 will connect just fine. If you don't, it will try PWM first, and cause the ECU to go deaf for almost a second -- which means it will not hear your VPW request either.

                          Doing protocol detection "manually" is harder, but if you do it right it is far more reliable. An added benefit is that you can display the progress to the user as you try each protocol.

                          Vitaliy
                          OBDLink MX: world's smallest, fastest, most advanced OBD/Bluetooth adapter with SW and MS CAN support. Read the review to learn more.
                          Need to look up a diagnostic trouble code? Try the most up-to-date, free DTCsearch.com!

                          You cannot send me a private message using this forum. Use my email instead: vitaliy[@]scantool.net.

                          Comment


                          • #14
                            OK, I didn't know that. So you advice to test each protocol with the ATSPx command and try to get the response of 0100.. and by the same time to inform the user on which protocol you're trying... This way will be more reliable than the automatic research (ATSP0).

                            Thanks Vitaliy for sharing your experience
                            www.outilsobdfacile.com

                            Comment


                            • #15
                              Originally posted by remus08 View Post
                              OK, I didn't know that. So you advice to test each protocol with the ATSPx command and try to get the response of 0100.. and by the same time to inform the user on which protocol you're trying... This way will be more reliable than the automatic research (ATSP0).
                              Correct, and most professional software does it this way. You also need generous delays b/w PWM & VPW, and ISO and KWP. Try CAN last.

                              Vitaliy
                              OBDLink MX: world's smallest, fastest, most advanced OBD/Bluetooth adapter with SW and MS CAN support. Read the review to learn more.
                              Need to look up a diagnostic trouble code? Try the most up-to-date, free DTCsearch.com!

                              You cannot send me a private message using this forum. Use my email instead: vitaliy[@]scantool.net.

                              Comment

                              Working...
                              X