Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: ECUsim 5100 OBD-II simulator

  1. #1
    VENDOR - ScanTool Vitaliy's Avatar
    Join Date
    Dec 2006
    Location
    Phoenix, AZ
    Posts
    624

    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. #2
    North of the land of Hey Huns
    Auto Apps:loading...

    Join Date
    Jun 2004
    Location
    Westminster, MD
    Posts
    2,144
    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

  3. #3
    VENDOR - ScanTool Vitaliy's Avatar
    Join Date
    Dec 2006
    Location
    Phoenix, AZ
    Posts
    624
    Quote 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.

  4. #4
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    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

  5. #5
    North of the land of Hey Huns
    Auto Apps:loading...

    Join Date
    Jun 2004
    Location
    Westminster, MD
    Posts
    2,144
    Quote 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

  6. #6
    VENDOR - ScanTool Vitaliy's Avatar
    Join Date
    Dec 2006
    Location
    Phoenix, AZ
    Posts
    624
    Quote 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.

  7. #7
    Newbie
    Join Date
    Mar 2010
    Posts
    8
    tanks for you

  8. #8
    Newbie
    Join Date
    Mar 2006
    Posts
    27
    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?

  9. #9
    Newbie
    Join Date
    Mar 2006
    Posts
    27
    bump ....any comments?

  10. #10
    North of the land of Hey Huns
    Auto Apps:loading...

    Join Date
    Jun 2004
    Location
    Westminster, MD
    Posts
    2,144
    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

Page 1 of 2 12 LastLast

Similar Threads

  1. Lilliput screen on Ubuntu
    By yam125 in forum Linux
    Replies: 13
    Last Post: 06-13-2011, 10:19 AM
  2. Free Software OBD II Simulator redux
    By chunkyks in forum Engine Management, OBD-II, Engine Diagnostics, etc.
    Replies: 5
    Last Post: 11-26-2009, 09:39 AM
  3. OBD II connector on an OBD I car
    By HearseNurse in forum Engine Management, OBD-II, Engine Diagnostics, etc.
    Replies: 6
    Last Post: 03-23-2009, 09:52 AM
  4. Replies: 2
    Last Post: 07-27-2008, 09:42 PM
  5. Replies: 0
    Last Post: 11-03-2007, 03:33 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •