Announcement

Collapse
No announcement yet.

ECUsim 5100 OBD-II simulator

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

  • ECUsim 5100 OBD-II simulator

    We just launched ECUsim 5100, our latest and greatest OBD simulator.



    The biggest difference from the previous generation is that each PIM supports all OBD-II protocols, and the protocol can be set by the user in software. Another big difference is that the sim now supports configuration commands (for now, only a limited number, but we plan to add more).

    For more details, see the User Guide.
    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.

  • #2
    Congrats on the release, very cool product.
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

    Comment


    • #3
      Originally posted by malcom2073 View Post
      Congrats on the release, very cool product.
      Thank you.

      By the way, the internal structure is object-oriented, in fact behind the scenes the ECUs, PIDs, trouble codes, etc are created dynamically at runtime. The knobs are also fully configurable, including scaling and which PID they're assigned to.

      So theoretically it shouldn't be too hard to expose this functionality through the command interface so people can create and configure their own ECUs. Not sure if there is enough interest in this sort of thing to justify the effort, however.

      Your feedback is welcome.

      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


      • #4
        Wow, that's awesome.

        Congratulations on getting such a thing out the door; hardware people always impress me :-D

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

        Comment


        • #5
          Originally posted by Vitaliy View Post
          Thank you.

          By the way, the internal structure is object-oriented, in fact behind the scenes the ECUs, PIDs, trouble codes, etc are created dynamically at runtime. The knobs are also fully configurable, including scaling and which PID they're assigned to.

          So theoretically it shouldn't be too hard to expose this functionality through the command interface so people can create and configure their own ECUs. Not sure if there is enough interest in this sort of thing to justify the effort, however.

          Your feedback is welcome.

          Vitaliy

          By "create and configure their own ECU's", do you perhaps mean give the ability to have the PC set over the USB interface values to be returned for PID's?

          One of the huge selling points of chunky_ks's software obd simulator is that it can read back log files recorded from a real vehicle (Via his obdgpslogger software) as well as allow you to dynamically set PID values (Rather than having to fiddle with knobs). I suspect it would be advantageous to be able to feed a log file over the USB interface to the ECUsim 5100 so you can see real values that a car would return coming over the bus, and have a scantool interpret them appropriately. Useful for things like MPG calculations, HP/Torque functions, things you can actually measure in a car and verify the tool being developed is returning the proper values based on the simulator's output.

          Perhaps having something along the lines of the PC being able to set a certain PID to a certain value over USB and if the ECUsim does not receive an update to that PID over a pre-set (user configurable of course) period of time then it would revert to either default, or the hardware knob's value? This would also allow the user to vary some of the hard-set parameters that there are no knobs for (Testing alarms for various PID's), or setting custom trouble codes.
          "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
          RevFE
          My Shop

          Comment


          • #6
            Originally posted by malcom2073 View Post
            By "create and configure their own ECU's", do you perhaps mean give the ability to have the PC set over the USB interface values to be returned for PID's?
            In a narrow sense, yes.

            Right now there are three ECU objects each of which has attributes such as address, VIN, CALID, MIL status. The ECU object also owns or uses other objects: DTCs, freeze frames, modes. In turn, these sub-objects can own or use other objects, for instance a Mode1 object owns PID objects.

            So for instance, when you add a DTC, it does work behind the scenes to make sure that you don't simply get a response to mode 03 request, but that the MODE 01, PID 01 request is set as well. And when you add more DTCs, the way the messages are put together is handled automatically.

            Compare this to how things are normally done, where the request-response pairs are simply hardcoded. When you want to add more DTCs, you have to delete your old responses, and set up new ones.

            This is a simple example, it gets quite a bit more complicated. The bottom line is, this paradigm ensures that we don't make silly mistakes like forget to change the destination address for responses that come from an address different from F1, or accept invalid requests just because the first two bytes are correct (I've seen both in other sims). It also means that the ECUsim is more interactive.

            One of the huge selling points of chunky_ks's software obd simulator is that it can read back log files recorded from a real vehicle (Via his obdgpslogger software) as well as allow you to dynamically set PID values (Rather than having to fiddle with knobs). I suspect it would be advantageous to be able to feed a log file over the USB interface to the ECUsim 5100 so you can see real values that a car would return coming over the bus, and have a scantool interpret them appropriately. Useful for things like MPG calculations, HP/Torque functions, things you can actually measure in a car and verify the tool being developed is returning the proper values based on the simulator's output.
            We've been mulling over this for quite some time. The problem is, you don't really need a stand alone simulator to accomplish this, all you need is a "dumb" OBD to RS232 interpreter. So in theory if someone was really interested, we could tweak OBDLink to allow it to function in simulator mode: listen for ISO inits, and transparently pass messages back and forth.


            Perhaps having something along the lines of the PC being able to set a certain PID to a certain value over USB and if the ECUsim does not receive an update to that PID over a pre-set (user configurable of course) period of time then it would revert to either default, or the hardware knob's value? This would also allow the user to vary some of the hard-set parameters that there are no knobs for (Testing alarms for various PID's), or setting custom trouble codes.
            Somebody else asked for this functionality a long time ago. Instead of reverting back to some default value, why not leave it at the last value set by the PC?

            This functionality is already there, in the sense that I can un-assign a knob from a PID and assign the PID a fixed value in source code. The tricky part is coming up with a sensible command set to allow the user to do this from a terminal prompt.

            One way would be to do it like this (I'm doing this from memory so perhaps I'm forgetting some of the parameters):

            ADDPID <ECU_ID>, <PID_MODE>, <PID_NUM>, <BYTE_COUNT>
            SETPID <ECU_ID>, <PID_MODE>, <PID_NUM>, <DATA>

            Where it gets really messy is when you want to (re)assign a knob to a PID. You have to specify a bunch of things besides the ones listed above (knob number, scaling, offset, etc).

            Setting the VIN is the easiest of all:

            SETVIN <ECU_ID>, <VIN_NUMBER>

            It's all doable, of course. We just need to wait and see if the revenue stream is enough to fund the development.

            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
              tanks for you

              Comment


              • #8
                hmmm i wonder if this will work for me?


                i have a nistune ECU in my infiniti G20, I also have a 1996, & a custom Flywheel, ALL other G20's 95 & down use a 108 tooth flywheel, so that the base i started with to have my cusotm one done, only problem is in 1996 they switched to a 109 tooth flywheel, & put a Crank position sensor in the front of the trans to "watch the flywheel" (its a magnetic HAL sensor) SO in short, the FW trips a MIL light.

                I basically want to dump my bin/adr file from my ECU & modify the code, to remove the part dealing with the sensor in the trans, OR make it so that the current signal recived from the sensor bcomes the proper signla, thus NOT throwing a MIL,


                only problem is i cant find any GOOD info on ODB2 (ISO...ummm i forget)

                the car dirves fine & everything is well, EXCPET when emissions time comes around, & i either swap in a stock FW, or i GET stickers from a buddy.


                @ 1 point i was just going to write a ODB2 app that would then pipe DTC ready info via a serial cable wired into the ODB2 port, so if you out a scanner on it, all monitors came back ready...but....i never got really far....


                can anyone help me?

                Comment


                • #9
                  bump ....any comments?

                  Comment


                  • #10
                    Bypassing the emiissions stuff in that way is quite illegal, so probably won't be discussed here.
                    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                    RevFE
                    My Shop

                    Comment


                    • #11
                      Not only illegal, but I'd imagine it's fairly obvious if it's been tampered with. It'll be doubly obvious when the guy with the device plugged in revs the engine and sees the revs not change on your OBDII device.

                      As a whole, you're unlikely to get help with something that's pretty clearly clandestine on these forums.q

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

                      Comment


                      • #12
                        As a purely theoretical comment, if you *really* wanted to bypass emissions, you would want a man-in-the-middle setup. In other words, OBD on both sides, with an intelligent chip in the middle that passes the messages back and forth, and substitutes the data you want changed.
                        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
                          BTW, this type of device would be next to impossible to detect using the usual means (VIN, CALID, PID signature).
                          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
                            about the engine revving....i have a buddy that works @ a shop,....he said as long as it plugs in & then gives all triggers are good, he will pass...but there can be no CEL light/code...

                            ok maybe my wording is wrong....im not looking to defraud the system....its just that the flywheel i run on my car trips a cel....so im trying to get around that....

                            i have been pouring over the firmware of my euc trying to isolate that specific code & delete....but have been unsucessful....i managed to rip out the stuff for EGR & rear o2.
                            btw this is a track car basically, but i use it onm the weekends, & driving to the track.,..since i dont have a trailier

                            Comment


                            • #15
                              screen shot

                              screen shot
                              Attached Files

                              Comment

                              Working...
                              X