Announcement

Collapse
No announcement yet.

What's the fastest EML based scan dongle?

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

  • What's the fastest EML based scan dongle?

    ElmScan OBD scan key can only scan a single parameter at a rate of once every 500ms. Is there any other OBD dongles that can scan at a faster rate?

    Thanks.

  • #2
    That is likely the limit of either your ECU, or the software you're using, not the dongle. I'm fairly certain the ELMScan can scan much faster than that.
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

    Comment


    • #3
      Thanks, I was quoting ScanTool.net

      Comment


      • #4
        Using an app that I wrote, once the ElmScan 5 initialized I send an AT0 to turn off the adaptive request rate and, receive a AT0 from the ElmScan 5. Then I send a ST 64 which should tell the ElmScan 5 to change the request rate to 400ms but the fastest rate that is responds with is 1 second per PID request. This is no matter how fast I make requests. When I send the ST command I get a response back a ST 64 response. Anyone use a ElmScan 5 dongle before and run into this problem?

        Thanks.

        Comment


        • #5
          Originally posted by dgarrett View Post
          ElmScan OBD scan key can only scan a single parameter at a rate of once every 500ms. Is there any other OBD dongles that can scan at a faster rate?

          Thanks.
          That sounds unbelievably slow. ISO 9141 is generally the slowest protocol. You have to wait 5 mS between each byte sent, and 55 mS between each request, so a 'fast' ISO ECU responds about about 8 Hz or so and a slow one is generally down at around 3-4, but that is still twice the rate you are describing.

          Sorry, I don't know much about ELM. I find the whole SH, adaptive rate, thing confusing (I actually just asked it in another thread).

          So, in a blanket response, yes there are definitely interfaces that go a lot faster. How you get better speed with ELM I could not say.

          -jjf

          Comment


          • #6
            Originally posted by dgarrett View Post
            Using an app that I wrote, once the ElmScan 5 initialized I send an AT0 to turn off the adaptive request rate and, receive a AT0 from the ElmScan 5. Then I send a ST 64 which should tell the ElmScan 5 to change the request rate to 400ms but the fastest rate that is responds with is 1 second per PID request. This is no matter how fast I make requests. When I send the ST command I get a response back a ST 64 response. Anyone use a ElmScan 5 dongle before and run into this problem?

            Thanks.
            Can you post your actual comm log, with the timings?

            Joe is right, 1 request per second is unbelievably slow.

            By the way, why are you turning off adaptive timing?

            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


            • #7
              Jason from Scantool.net wrote this...

              Hi,

              One second seems reasonable for the 400ms timeout for ISO or KWP. The timer resets after it receives a command, so the scan tool will wait 400ms after its last response before it will print the prompt and will be ready to receive another command. Also, the ElmScan 5 is not asynchronous, you must wait for the prompt before you can send another request. For fastest throughput, I would recommend not changing ST and changing AT to 2.

              Regards,

              Jason

              Comment


              • #8
                Originally posted by dgarrett View Post
                Jason from Scantool.net wrote this...

                Hi,

                One second seems reasonable for the 400ms timeout for ISO or KWP....
                I'd ask where, exactly, in SAE J1979 he is getting that 400 mS from.

                -jjf

                Comment


                • #9
                  Originally posted by jfitzpat View Post
                  I'd ask where, exactly, in SAE J1979 he is getting that 400 mS from.

                  -jjf
                  What's J1979 got to do with it? Jason got the 400 ms From dgarrett's post. Why he needs to set it so high, is a question you need to ask dgarrett.

                  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


                  • #10
                    I actually tried 100ms and 50ms but it made no difference. I would said 400ms so they would not tell me 50ms is too fast and was the root cause this issue, which was not the case.

                    Comment


                    • #11
                      Originally posted by Vitaliy View Post
                      What's J1979 got to do with it? Jason got the 400 ms From dgarrett's post. Why he needs to set it so high, is a question you need to ask dgarrett.
                      I can only go by what is posted here, not back stories on other forums. The first sentence of the quote, in isolation, is troubling.

                      Obviously, 400 mS is not reasonable for any '96 or newer US ISO vehicle, or any '01 or newer gasoline vehicle in the EU.

                      In addition, the math doesn't add up. 400 plus, say 100, equals 500, which would be two samples per second, not one.

                      As far as asking dgarrett. The whole point of the original post is he is getting terrible performance. I would start with 'divide and conquer', that is, isolate the performance bottleneck to ECU, interface, or code - but I don't know enough about the interface to give much in the way of helpful advice.

                      I can't imagine asking him 'why are you using slow settings' would be any more useful to him than telling him his performance is reasonable for the settings he has.

                      I would suggest trying a known app with the same interface and ECU and measuring performance. That would get at least some variables out of the equation.

                      -jjf

                      Comment


                      • #12
                        A comm log with timestamps would be indispensable.
                        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


                        • #13
                          I will try to post a log file later this week when time permits. Thanks for the help so far!

                          Comment


                          • #14
                            I've been using an OBDLink (ELM 327) for my project and found that the response speed of requests has nothing to do with the timeout. If you want a quicker timeout then send a CR to the com port after your own timeout (done on the PC) and it will cancel the last command sent to the ECU.

                            Most pre ~2004 vehicles I've tested with are pretty slow are responding to requests (E.g. 2003 Toyota Echo/Yaris 1.3lt, I only get about 4 responses a second).

                            I've also tested with a 2007 Honda Civic and 2007 Toyota Camry both are CAN 11/500. I can get around 20 responses a second. The CAN protocol stipulates that all requests should be answered within 50ms, hence the number of responses I am getting...

                            It really depends on your cars ECU as to how quickly it will respond. Another trick you can use is to increase the baud rate from 33,400 on an ELM 327 chipset to 115,000 or higher (500,000) by isuing the BRD XXX command. See the ELM 327 data sheet for info: http://www.elmelectronics.com/DSheets/ELM327DS.pdf

                            Comment


                            • #15
                              Originally posted by necros View Post
                              Most pre ~2004 vehicles I've tested with are pretty slow are responding to requests (E.g. 2003 Toyota Echo/Yaris 1.3lt, I only get about 4 responses a second).
                              That actually sounds a bit slow. My wife's '03 Lexus is faster.

                              Originally posted by necros View Post
                              I've also tested with a 2007 Honda Civic and 2007 Toyota Camry both are CAN 11/500. I can get around 20 responses a second. The CAN protocol stipulates that all requests should be answered within 50ms, hence the number of responses I am getting...
                              If you know how many responses you expect for a given PID, you can generally go faster. I posted a log showing something about MPG calculation that was 80+ samples per second from a Saturn ION.

                              The trick is to wait 50 mS for all responses OR all anticipated responses are received, whichever comes first.

                              Now that I think about it, that might be the difference on the ISO 9141 ECU's. J1979 actually gives you two ways to find the end of an ISO response, one being a timeout.

                              -jjf

                              Comment

                              Working...
                              X