Affordable OBD Simulator? - Page 2

obdiinut · 06-06-2009, 03:21 PM

Just get an ECU at a junk yard and hook it up. you could get one for around $ 50.00 and you got yourself an OBD II simulator.

I have been toying around with developing an OBD II front end and thats what I got a 2005 Saturn ECU with the OBDPro interface - works like a charm.

chunkyks · 06-06-2009, 05:21 PM

Quote:

what would you consider "affordable"?

Not sure, really. In my head the reader is a far more complicated device than a simulator would be [a simulator's functionality is going to be a subset of a reader's functionality, with a couple of hardware dials to change values]; so I envisage a cap on the cost around the same place as a decent reader would be.

Quote:

And what sort of features are you looking for?

Something I can use to see whether or not obd gps logger is working, without walking to my car. I only just received my copy of J1979, so I'm not sure what formal subset is necessary yet.

Gary (-;

Vitaliy · 06-08-2009, 12:33 AM

Quote: Originally Posted by chunkyks

Not sure, really. In my head the reader is a far more complicated device than a simulator would be [a simulator's functionality is going to be a subset of a reader's functionality, with a couple of hardware dials to change values]; so I envisage a cap on the cost around the same place as a decent reader would be.

In fact, the opposite is true.

A simulator is far, far more complicated than a PC-based scan tool. ElmScan and OBDPros are basically just glorified protocol converters. ECU simulator has to not only implement the OBD transceivers, but simulate ECU functionality as well. There are ten modes, and Mode 1 and Mode 2 define hundreds of PIDs.

Before Ozen sims became available, the cheapest ECU simulator you could get, was in the $2500 range.

Quote:

Something I can use to see whether or not obd gps logger is working, without walking to my car. I only just received my copy of J1979, so I'm not sure what formal subset is necessary yet.

Gary (-;

We're working on a bare-bones simulator, which will be available for sale this summer. I would appreciate any thoughts on what features you would consider useful.

Best regards,

Vitaliy

PS Did you get my PM?

chunkyks · 06-08-2009, 03:10 PM

Quote:

ECU simulator has to not only implement the OBD transceivers, but simulate ECU functionality as well. There are ten modes, and Mode 1 and Mode 2 define hundreds of PIDs.

Many PIDs are defined, but simulators only run a subset [much like any real car!]; for example, the Ozen 1610 only support 18 PIDs in mode1, and three in mode2.

I don't wish to belittle any hardware developers, I'm in awe of anyone that can do hardware. My perception is just that anything a simulator does, a reader has to do also [eg, create ECU data and spit it out; a reader has to do the exact same in reverse] - and then a reader has to support additional functionality to communicate with the actual PC [eg, USB or bluetooth voodoo, other ELM witchery].

Anyways, I'm happy to accept that simulators are harder to build than readers, I just need to correct my mental model of how a simulator works - if it's not pulling numbers out of its ***, what *is* it doing? And how is that different to what a reader does in reverse?

Quote:

I would appreciate any thoughts on what features you would consider useful.

The most important feature of all is up-to-date, correct, detailed developer documentation. Without that, I have no interest in buying anything.

The features I specifically would find useful *right now* include:
1) Making sure it gracefully does something right at varying bit rates
2) A button to enable a MIL/error conditions through mode03, and honoring mode 04 to disable it again
3) Dials to change values

I realise this is probably incredibly hard, if not impossible, to actually do, but what I'd really like is a big ol' sliding switch that goes from "Borderline crippled 1996 vehicle" that supports a bare minimum number of PIDs, rates, and features, up to "modern CAN vehicle" that works at 500k, supports many-many ECUs and PIDs.

Of course, that's what the super expensive simulator I linked near the top of the thread does, and it uses multiple separate simulator boards to achieve it. So, yeah.

Gary (-;

PS Yeah, I found the message just now; the PM notification at the top of the page is pretty missable.I

Vitaliy · 06-09-2009, 02:06 AM

Quote: Originally Posted by chunkyks

Many PIDs are defined, but simulators only run a subset [much like any real car!]; for example, the Ozen 1610 only support 18 PIDs in mode1, and three in mode2.

I don't wish to belittle any hardware developers, I'm in awe of anyone that can do hardware. My perception is just that anything a simulator does, a reader has to do also [eg, create ECU data and spit it out; a reader has to do the exact same in reverse] - and then a reader has to support additional functionality to communicate with the actual PC [eg, USB or bluetooth voodoo, other ELM witchery].

FWIW, I don't feel belittled or offended a tiny bit, these are fair comments.

The big difference b/w a reader and an ECU Simulator is that the former does very little data manipulation, its main concern is converting OBD to RS232 and back. Note that I'm talking only about hardware here, not the complete hardware + software setup.

Adding USB and Bluetooth to an ELM327 is actually a piece of cake, relatively speaking. You just take a chip or a module, wire it up according to the diagram, and voila.

Quote:

Anyways, I'm happy to accept that simulators are harder to build than readers, I just need to correct my mental model of how a simulator works - if it's not pulling numbers out of its ***, what *is* it doing? And how is that different to what a reader does in reverse?

"Pulling numbers out of its ***" is different from properly simulating an ECU. An ECU sim has to store ECU information such as the VIN, address, ECU name, PIDs, DTCs (three different kinds), freeze frames. It must understand and process various types of requests. It must handle user input in the form of knobs, switches, and buttons. When you introduce support for multiple ECUs in the same simulator, things get even more complicated.

On the other hand, a scan tool (or more accurately, an OBD to PC interface) does not care about any of that stuff, it just takes bytes in one format and converts them into bytes in another format. This is of course a gross simplification, but it is the essence of what PC-based scan tools are about.

So in reality, ECU simulator framework sits on top of a scan tool base.

Quote:

The most important feature of all is up-to-date, correct, detailed developer documentation. Without that, I have no interest in buying anything.

Fair enough. We're finalizing the datasheet for our CAN PIM, I'll post it here tomorrow or the day after.

Quote:

The features I specifically would find useful *right now* include:
1) Making sure it gracefully does something right at varying bit rates

Can you explain what you mean?

Quote:

2) A button to enable a MIL/error conditions through mode03, and honoring mode 04 to disable it again

Done.

Quote:

3) Dials to change values

Done.

Quote:

I realise this is probably incredibly hard, if not impossible, to actually do, but what I'd really like is a big ol' sliding switch that goes from "Borderline crippled 1996 vehicle" that supports a bare minimum number of PIDs, rates, and features, up to "modern CAN vehicle" that works at 500k, supports many-many ECUs and PIDs.

It is hard, but possible. However, imagine that instead of a big ol' sliding switch, you have a command line interface that accepts commands that look like this:

Code:

ADD ECU1
USE ECU1
ADD DTC "P0100"
ADD PID 05, 01, 00
SET VIN "FAKE VIN"
...etc...

In other words, it allows you to create and configure virtual ECUs on the fly.

Quote:

Of course, that's what the super expensive simulator I linked near the top of the thread does, and it uses multiple separate simulator boards to achieve it. So, yeah.

Well no, not really. The simulator you linked to, uses multiple PIM boards to support multiple protocols. The number of ECUs/PIDs/DTCs is fixed, and they are not configurable.

It is still very useful for development, but who says it can't be made better?

Vitaliy

chunkyks · 06-09-2009, 12:26 PM

Interesting ideas. Since it provides a command-line interface, I presume it talks via USB?

If you are using a usb-to-serial converter for the job, it needs to be supported on all three major platforms [linux, OSX, windows]. pl2303 or ftdi are both really good for multiple platforms IME, but I'm sure there are many many more

Gary (-;

Vitaliy · 06-10-2009, 08:32 PM

Quote: Originally Posted by chunkyks

Interesting ideas. Since it provides a command-line interface, I presume it talks via USB?

If you are using a usb-to-serial converter for the job, it needs to be supported on all three major platforms [linux, OSX, windows]. pl2303 or ftdi are both really good for multiple platforms IME, but I'm sure there are many many more

Gary (-;

The main board uses FT232RL (an FTDI part) to convert UART to VCP.

The terminal settings are 38400 8,N,1.

Vitaliy

chunkyks · 06-17-2009, 02:53 AM

So, I wrote an ELM327 simulator. It's in the same repo as obdgpslogger, the introductory post [with some of the major features listed] is here: http://www.mp3car.com/vbulletin/obdi...ml#post1321903

I borrowed excessively from malcolm2073's code linked in this thread, so the fact that it *works* is directly attributable to him. Individual features, I'll take credit for, but the core posix voodoo is ripped almost directly from his [very readable] codebase.

Gary (-;

cnotesdip · 07-19-2009, 04:35 AM

I am looking for some software which can Simulate all the vehicles protocols like the ECU simulators offered by scantool.net but instead i need it to work of a pc and i need it to use a obd 2 connector. Any ideas can anybody help?

p2psmurf · 07-20-2009, 12:46 PM

cnotesdip, what kind of hardware do you have available you for this project?
Or do you want it to connect directly from the PC without any additional hardware?

cnotesdip · 07-20-2009, 01:09 PM

Quote: Originally Posted by p2psmurf

cnotesdip, what kind of hardware do you have available you for this project?
Or do you want it to connect directly from the PC without any additional hardware?

Yeah i dont have any additional hardware i already use stand alone simulators but i need to use one for each protocol i want a pc software that can simulate multiple simulators

p2psmurf · 07-20-2009, 02:15 PM

Without hardware that is going to be a bit of a problem.
PC-communication differs from Car communication on a hardware level.
I do not know of any Pc-program or hardware that is capable of simulating the J1850 protocols. So, you will need to develop some internal or external hardware that is capable of communicating with J1850 VPW and PWM.
For the can-protocol you need a can-chip and transceiver because the signals are too fast for the PC either on an internal board or in an external device.
The software of course you will have to write yourself.
Stil interested?

chunkyks · 07-20-2009, 04:36 PM

cnotesdip: OK, we got the message [all twenty or thirty of them]. Please stop emailing me and cross-posting on these forums, asking the same thing.

Are you asking about hardware or software? If you want to build hardware, I've no idea how to help, or why you can't just use www.ozenelektronik.com or scantool.net stuff.

If you want to build software, do you want something that simulates an ELM327 attached to something [in which case most protocol stuff will mostly be hidden and opaque], or do you want something that simulates actual ECUs? There are a few ELM327 software sims out there.

If you're trying to simulate actual ECUs, I don't know of any software to do that, and nor am I particularly interested in such a thing. What are you attaching it to on the receiving end? It seems like you want some kind of rich software thing that you can connect an OBDII reader to? What do you need that for?

Perhaps if you could explain what you're trying to achieve rather than how you're trying to do it, it would be easier to help you out.

Gary (-;

cnotesdip · 07-21-2009, 12:16 AM

Quote: Originally Posted by chunkyks

cnotesdip: OK, we got the message [all twenty or thirty of them]. Please stop emailing me and cross-posting on these forums, asking the same thing.

Are you asking about hardware or software? If you want to build hardware, I've no idea how to help, or why you can't just use www.ozenelektronik.com or scantool.net stuff.

If you want to build software, do you want something that simulates an ELM327 attached to something [in which case most protocol stuff will mostly be hidden and opaque], or do you want something that simulates actual ECUs? There are a few ELM327 software sims out there.

If you're trying to simulate actual ECUs, I don't know of any software to do that, and nor am I particularly interested in such a thing. What are you attaching it to on the receiving end? It seems like you want some kind of rich software thing that you can connect an OBDII reader to? What do you need that for?

Perhaps if you could explain what you're trying to achieve rather than how you're trying to do it, it would be easier to help you out.

Gary (-;

Scantool.net offers the Simulators but for each specific protocol you need to buy one, in addition to this the Simulators are very limited i need a simulator that can be able to sent out a VIN Number im using the simulators for testing on a scantool im trying to developed. What i wanted to do if possible is hook up my pc to a car using the obd connector and copy all its information like the sensors protocols vin number and so on then i could use that info to simulate the car hook it up to a scantool and test it but i dont know if this is possible. It would be nice if scantool.net made a multiprotocol simulator that you could edit using a pc.

p2psmurf · 07-21-2009, 09:29 AM

cnotesdip, if you can write the software for a scanner, you can also write your own simulator. I did the same, so it is possible.
But you do need to solve the hardware problem. You just cannot connect a PC to a car or a scanner directly.

User Name		Remember Me?
Password