OBD2 support discussion

[thokes82]

The datalogging stuff is interesting, but how commercially useful is it? i.e. will new customers appear in droves if we have OBD2 support for datalogging?

James

100percent Yes. Because it lifts Ms3 to an area where there is not so much competition.
I mean, you implemented Anti Lag for three to four people...

[24c]

I know of one European company that makes a range of higher input/output ECUs with CAN, aka J1939 ODB2 support, and they use this to interface with a Wideband sensor module. T.heir baseline modules don't do CANBUS

Mike

[b20vtechb]

i think this would be an awesome feature and really open the megasquirt up to alot of other devices.

[Marek]

The real question is, in what way OBD2 support would be useful?

James

The sort of thing which will always be useful, though not necesarily an OBD issue, is to monitor inconsistencies, e.g. if you have 6 injectors and five of them are using on average 1.1amps but one of them is using 3 amps, then you'd like to know; if you have six spark channels and one of them similarly is inconsistent, then flag it and act on it.

I have just fitted 12 EGT sensors into my engine - just because I could - I thought it'd be interesting. A recent datalog shows that when I was running on lpg, one of the EGTs dropped to 135'C whilst the others all carried on moving in sync with each other. When I switched to petrol much later, the datalog showed that the EGT immediately jumped back into step:- conclusion? I have a problem with one of my 12 LPG injectors, but not with the corresponding petrol injector - they are both fed by the same peak and hold driver. It sometimes takes a lot of effort to find a misfire when you have a lot of cylinders and simply knowing that one cylinder looks like it doesn't read back the same as the others instantly tells you where to look to sort out a problem.

If this means using a large number of inputs, then it's an ideal candidate for bundling onto Jean's IOextender and supporting it via that device.

kind regards
Marek

[thokes82]

The real question is, in what way OBD2 support would be useful?

James

The sort of thing which will always be useful, though not necesarily an OBD issue, is to monitor inconsistencies, e.g. if you have 6 injectors and five of them are using on average 1.1amps but one of them is using 3 amps, then you'd like to know; if you have six spark channels and one of them similarly is inconsistent, then flag it and act on it.

I have just fitted 12 EGT sensors into my engine - just because I could - I thought it'd be interesting. A recent datalog shows that when I was running on lpg, one of the EGTs dropped to 135'C whilst the others all carried on moving in sync with each other. When I switched to petrol much later, the datalog showed that the EGT immediately jumped back into step:- conclusion? I have a problem with one of my 12 LPG injectors, but not with the corresponding petrol injector - they are both fed by the same peak and hold driver. It sometimes takes a lot of effort to find a misfire when you have a lot of cylinders and simply knowing that one cylinder looks like it doesn't read back the same as the others instantly tells you where to look to sort out a problem.

If this means using a large number of inputs, then it's an ideal candidate for bundling onto Jean's IOextender and supporting it via that device.

kind regards
Marek

What does this have to do with the discussion in this thread?

[racingmini_mtl]

If this means using a large number of inputs, then it's an ideal candidate for bundling onto Jean's IOextender and supporting it via that device.

If you have ideas about what that would look like, you might want to start a new thread in the "Expansion boards" section or, better yet, on my forum. But it wouldn't be an OBD2 solution.

Jean

[Marek]

Dear Anon,
What does it have to do with....?

Without reading between the lines too much, there is some suggestion from the developer that providing an open source solution to OBD support via MS directly may be unattractive for legal reasons. OBD support could be considered without the ability to misuse the source code if it were packaged onto custom firmware on an IOXcard. This leaves MS and B&G completely "clean" of the suggestion that they may be in some way be complicit to faking data and no source needs to be released by anybody.

My response is a direct answer to James's question - it is an example of how on board diagnostics are already being partially implemented in the form of Megalogviewer. People without MS want OBD support because they don't have an easy way to datalog and analyse their ECUs - we are already blessed with something which is covering much of the same ground but not in the same format.

I'm not sure it'd benefit to to hive it off to a separate topic - I'm pointing out that what may seem simple and achievable to a 4 cylinder user may be close to unsupportable when all the options in MS are used concurrently. It is headed as a discussion, which means you can talk around the topic in the hope of approaching it from different angles.

kind regards
Marek

[aarc240]

Before even considering OBD2 a much more useful enhancement would be a non-volatile storage of fault conditions.
I guess everyone realises that without this it isn't actually possible to create a truly OBD or OBD2 compliant device ?
Jean is right that OEM dash boards use proprietary interfaces, we have 3 differet brand cars (BMW, Chrysler & GM Holden) and none are even similar to the others.
The one real advantage those cars have over our MS3'd Datsuns are they store the error codes without the need for a damned laptop in the car !

[Matt Cramer]

Before even considering OBD2 a much more useful enhancement would be a non-volatile storage of fault conditions.

It might be possible to store them in the real time clock module; it has a small amount of battery powered RAM.

[93supercoupe]

Assuming it doesnt put Megasquirt as a company at risk, why would the concern of people faking OBD2 testing stop you from implementing a feature that could be useful in other ways? Like CAN gauges and such? Thats of course you guys find it worth the development of the feature.

[hardline]

If you are worried about emissions faking, dont implement the emissions monitors, the dtc's, and the crc32 code that verifies code integrity. All I would use this for is outputting standard obd2 address datastreams. Most 97-04 Fords use the OBD2 databus running the SAE J1850 PWM protocol to run their dashboards. I can verify this on the Focus and the Mustang. They switched in 05-07 depending on the model line to ISO 15765-4 CAN, which can be addressed directly by MS3 on the pre1.4 Alpha codes.

[aarc240]

Be wary of assumptions that one division of one compamy is representative of all their divisions, let alone other manufacturers.
"Most 97-04 Fords use ..." doesn't apply to the c**p Ford built in Oz, in fact those builds didn't even know what OBD was, let alone OBD2 !
What the OEM's did is largely dictated by their perception of market stranglehold and State mandated requirements.
To really utilise OEM stuff is likely to cause a lot of headaches for the developers, yet will still result in anything late enough to have such stuff being emmissions illegal just about anywhere.

Getting MS3 to talk to OEM panels can be done externally with add-on hardware like an Arduino to translate the MS3 CAN output to something the OEM panel understands.
All that does is hide the illegal modification (replacement un-certified ECU) from the inspectors.

IMHO, the ability to store error codes in a form later usable in TunerStudio (enhanced?) is about the most important first step.

[gurov]

i'm not sure why the conversation went to the panels, those mostly talk internal CAN bus, not even the same protocol that gets talked to OBD2.

About the CRC32, from reimplementing the BMW obd2 protocol, that's needed to get it to even talk to the scanner.

You don't need NVRAM to implement obd2 "compatibility", all you have to do is return results saying there are no faults, and everything is fine, I think that's the real concern here.

"Check engine light on" is a single bit that has to be returned for other stuff to function. Following bits in that same response indicate whether tests have passed and are present. Someone with ill intentions would simply have to modify what's returned there to indicate "everything is fine, nothing is ruined", and you would have a vehicle capable of passing the basic code check (no check engine light, not stored DTCS)

There are further PIDS that have to be returned for emission testing, but once the basic code is in MS3 codebase, it would just take some semi-intelligent copy/paste to extend it to match what the emission testing device wants.

As I've said before, this isn't totally rocket science once basic communications between ecu/scanner have been established and exchange of some data has taken place. With 5 baud init, the hardest part is the handshake. Those are likely not even present with CAN communications, which is likely what should be used.

None of it is encrypted, none of it is authenticated, it's all in plain text, documented and open standard.

[jsmcortina]

gurov,
Yes to all of the above.

James

[dsatchell]

If you want an example of a use for OBD2 outputs just look at the PLX Devices multi-gauge. I have 2 of these I would love to but in my car. It is an 88 model that I will be running with a MS3. My car doesn't have OBD at all so I can't use the multi-gauge. But if the MS3 would output an OBD2 signal then I could pipe it into the multi-gauge and have access to many more sensor readings than straight from the MS3.

This is what I have been waiting for and dreaming of!

David.