Thread: Affordable OBD Simulator?

Hum, that might be it. Oh ubuntu 9.04 it looks like pts/0 is it, on 8.10 it was /dev/ptys0

That should link to ttyS0, try it. Look above for new source.

Ah, ok. I only have 9.04 here at work; at home [where I actually do my development work] I'm using 8.10

Gary (-;

Alright, the simulator should open /dev/ptmx and the program you're testing should open /dev/pts/1

Originally Posted by chunkyks

All,

Looking around, I came across this page: http://www.obd2cables.com/products/o...nt/simulators/, but they seem... well... "expensive".

Of the cheaper options on that page, that's still an awful lot of money for me, and I don't really know which one I should get if I can only get one. Can anyone suggest either more affordable options, or which of those is my best bet? I'd presume it's CAN, but my current car is CAN, and I'd like to have other devices to test... but really, I'm just confused.

Gary, what would you consider "affordable"? And what sort of features are you looking for?

Vitaliy

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.

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.

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 (-;

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.

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?

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?

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

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.

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.

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.

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?

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

Done.

3) Dials to change values

Done.

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.

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