Announcement

Collapse
No announcement yet.

ScanXL v/s OBD2007

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

  • ScanXL v/s OBD2007

    Anyone have any comments comparing these two softwares ? ScanXL Standard and OBD2007.
    Would be nice to see a shootout so to speak - pros and cons etc.. especially what feature/capability is in one but not the other.

  • #2
    The last time I checked, one very big difference was that ScanXL supports a bunch of vendor specific information for Ford and GM vehicles, while OBD2007 does not.

    Comment


    • #3
      would ScanXL work with any hardware interface or is it limited to OBDLink and ELMSCAN 5 interfaces only ?

      Comment


      • #4
        ScanXL may work with other interfaces, but I think it's fair to say that it works best with OBD interfaces from ScanTool.net.

        ScanXL takes advantage of OBDLink's enhanced command set to provide access to modules that are normally not accessible by most ELM327 interfaces and clones.
        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


        • #5
          I can think of several advantages that ScanXL has over OBD2007. Of course, ScanXL is our product so I am obviously biased.

          Just off the top of my head, here is a small list of some of the benefits of ScanXL:

          - Supports not only ELM compatible interfaces, but also J2534 compliant interfaces and Innovate Motorsports new OT-2 interface.
          - ScanXL supports custom calculated PIDs using our built-in Javascript engine.
          - Supports many aux. input devices (such as wideband O2 sensors) that can be data logged right along side OBD-II data (this is a ScanXL Pro only feature).
          - ScanXL supports at least 6 different brands of 802.11 WiFi OBD-II interfaces. Although I can't say for sure, but it looks like OBD2007 does not support any of the new 802.11 WiFi ELM interfaces.
          - ScanXL supports manufacturer enhanced diagnostics for many vehicle types (including Ford, GM, & Mazda) and we're releasing support for even more all the time.
          - ScanXL has no built-in limitations on data logging. You can data log as many PIDs as you like for as long as you like. In fact, some of the automakers themselves use our software in their end-of-line and other testing where they do data logging for hours on end.
          - ScanXL is a self-contained install. It does not rely on a several hundred megabyte installation of the .NET framework. Which means it works on all versions of Windows back to Windows 95/NT and does not require any other components to run.
          Brian @ Palmer Performance Engineering, Inc.
          http://www.palmerperformance.com

          Comment


          • #6
            Originally posted by Vitaliy View Post
            ScanXL may work with other interfaces, but I think it's fair to say that it works best with OBD interfaces from ScanTool.net.
            I suppose that it would only be "fair" if we determined what, exactly, you mean by "best". In terms of, say, reads-per-second, all ELM based devices are pretty slow.

            Originally posted by Vitaliy View Post
            ScanXL takes advantage of OBDLink's enhanced command set to provide access to modules that are normally not accessible by most ELM327 interfaces and clones.
            That is interesting to me. I've looked at ScanXL accessing vendor specific stuff on Ford and GM using our Wi-Fi interface, but I'm not all that familiar with the ELM RS-232 command set. Skimming it, it is not clear to me that there are any glaring holes. Some performance bottlenecks, yes, but no obvious obstacles to access, unless it is filter options or something.

            But PPE would obviously be in the best position to make the best recommendations for particular user needs. Software wise, for me it is no contest, but I am coming from a strong tuning/performance point of view. For me, even more important than vendor specific functions, ScanXL does a good job of integrating information from gear like our widebands, not just with our OBD-II interfaces, but with others as well. Access to vendor specific modules and diagnostic codes, access to critical tuning info... That is, for my purposes, a serious tool.

            If a user is only interested in eye candy, criteria is a lot different. Then any software value add is in a different area. Certainly it isn't in basic J1979 operations, since many (though obviously not all) HW vendors do what we do and give away that sort of basic software functionality for free.

            -jjf

            Comment


            • #7
              Originally posted by jfitzpat View Post
              I suppose that it would only be "fair" if we determined what, exactly, you mean by "best".
              When you get an ELM327 clone you don't know whether it's going to work at all.

              In terms of, say, reads-per-second, all ELM based devices are pretty slow.
              We clocked OBDLink at speeds in excess of 80 PIDs/sec, without PID stuffing. But then of course OBDLink is not an ELM based device.

              That is interesting to me. I've looked at ScanXL accessing vendor specific stuff on Ford and GM using our Wi-Fi interface, but I'm not all that familiar with the ELM RS-232 command set. Skimming it, it is not clear to me that there are any glaring holes. Some performance bottlenecks, yes, but no obvious obstacles to access, unless it is filter options or something.
              I will let PPE comment if they want.

              You can get an idea of the extra functionality, if you look at the ST command set:

              http://www.scantool.net/scantool/dow...stn11xx-ds.pdf

              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


              • #8
                Originally posted by Vitaliy View Post
                When you get an ELM327 clone you don't know whether it's going to work at all.
                Exactly my point, you seem to be using a VERY narrow definition of 'best'. ScanXL supports more than just ELM (ex. J2534 drivers), and that includes some outstanding interfaces.

                Originally posted by Vitaliy View Post
                We clocked OBDLink at speeds in excess of 80 PIDs/sec, without PID stuffing. But then of course OBDLink is not an ELM based device.
                That seems wholly reasonable. I get 80+ (straight up mode 1 requests) out of my daughter's Saturn ION (I actually posted a log from the same car in a thread on MPG calculation) and it isn't the fastest ECU I've seen.

                Originally posted by Vitaliy View Post
                You can get an idea of the extra functionality, if you look at the ST command set:
                I hadn't realized that designating handshaking pairs in CAN wasn't a standard ELM thing. That would be a big issue for some vendor specific stuff. But, again, I'm not terribly familiar with the ELM serial command set (which you appear to emulate). I had both a legacy support requirement, and a requirement to get 80+ type speed over wireless connections and, as appealing as simply duplicating an existing interface can be, I didn't think it was a very good fit for either of those criteria.

                -jjf

                Comment


                • #9
                  jfitzpat,

                  IIRC J2434 interfaces start at $400, and the low end ones (e.g., Mongoose) support one protocol at a time. I think the price point is out of the range of most people here.

                  Out of curiosity, what is the fastest ECU you've seen?

                  Vitaliy

                  PS I may have asked you before, what is the name of your company?
                  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
                    Originally posted by Vitaliy View Post
                    IIRC J2434 interfaces start at $400, and the low end ones (e.g., Mongoose) support one protocol at a time. I think the price point is out of the range of most people here.
                    That's quite false. I can think of three J2534 passthru interfaces off the top of my head that are sub $200. One is CAN only, but the other two are CAN, J1850, ISO. One even provides extra voltages for ECU reflashing of at least one vehicle make.

                    Originally posted by Vitaliy View Post
                    Out of curiosity, what is the fastest ECU you've seen?
                    Probably the Bosch lean burn stuff. It primarily screams because diagnostic communication has it's own dedicated MPU. That said, I've only seen it on a test engine.

                    Originally posted by Vitaliy View Post
                    PS I may have asked you before, what is the name of your company?
                    Well, plenty here have figured it out, but I don't feel right pushing it myself. I'm an engineer, not a salesman. This way, I can just stick to technical facts that people can verify for themselves. Like above, I have no direct fiduciary interest in any of the three interfaces I can think of, but I did provide engineering assistance on one (an "Open" initiative) and the other two are from companies, like Palmer, whose users also often use various products I do have a fiduciary interest in (albeit indirect).

                    So, I just note that, contrary to your claim, they exist. Knowing full well that my claim can be pretty quickly confirmed with Google. Ideal, no, of course it would be more natural to self promote. But I don't like the slippery slope.

                    Not to rehash the past, but that is likely why our technical exchanges so far have generally not gone to your liking. You are wearing a 'brand' hat, which has constraints. I'm only focussing on technicalities, which puts you at a disadvantage in a technical exchange. In other words, I only have to worry about how my assertions line up with measurable, objective fact. You have to consider how facts, or at least their presentation, reflect on brand or impact consumer decisions.

                    -jjf

                    Comment


                    • #11
                      jfitzpat,

                      I can't help but be slightly annoyed by your "I won't tell you because I'm so modest" attitude.

                      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


                      • #12
                        Originally posted by Vitaliy View Post
                        We clocked OBDLink at speeds in excess of 80 PIDs/sec, without PID stuffing.
                        Can you please elaborate on that ? Was that with CAN ? or a pre-CAN type (ISO, etc..)
                        This kinda ties into another question I had about both OBDLink and ScanXL - what kind of sampling rate can I expect on a ISO9141-2 vehicle (honda) using this hardware+software combination ?

                        Comment


                        • #13
                          Originally posted by It's A Honda View Post
                          Can you please elaborate on that ? Was that with CAN ? or a pre-CAN type (ISO, etc..)
                          This was a CAN ECU.

                          This kinda ties into another question I had about both OBDLink and ScanXL - what kind of sampling rate can I expect on a ISO9141-2 vehicle (honda) using this hardware+software combination ?
                          I've seen it go to 8 samples/second on some vehicles. On others you barely get 2-3 samples per second. Unfortunately, ISO9141 wasn't designed for speed.

                          Vitlaiy
                          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
                            This 80 PIDs per second... I've never seen that with any bluetooth dongle or car, but I don't have an OBDLink. Do you know whether that scan rate was possible because of the OBDLink or because of the particular vehicle you were connected to?

                            Comment


                            • #15
                              Originally posted by It's A Honda View Post
                              Can you please elaborate on that ? Was that with CAN ? or a pre-CAN type (ISO, etc..)
                              This kinda ties into another question I had about both OBDLink and ScanXL - what kind of sampling rate can I expect on a ISO9141-2 vehicle (honda) using this hardware+software combination ?
                              Slow, and it has nothing to do with the software or interface, and everything to do with ISO 9141.

                              To get RPM, it takes 14 bytes, 6 sent, 8 received. At ISO baud rates, it takes about 14 mS (.014 seconds) for those bytes to travel the wire. If we divided 1.0 by that, we'd have a good sample rate, but it isn't that simple. The spec requires that the test tool a) put a 5 mS (.005 second) delay between each byte sent and b) wait 55 mS (.055 second) between requests.

                              So, we have .014 + .025 (5 delays) + 0.055 = .094.

                              That's already a 10th of a second, and it doesn't include byte gaps in the response, and time used actually processing the response. It varies a bit, but with an '01 - '04 Honda, that would typically be about .040 seconds for RPM, or .094 + .040 = .134 seconds, or about 7.5 samples per second.

                              -jjf

                              Comment

                              Working...
                              X