OBD2 support discussion

[MWPau]

The risk of someone modify the source to fake emissions results is a real problem. Probably enough that the whole OBD2 support idea will be scrapped.

Just out of interest, why is it a real problem?
Surely there i no way that you guys (MS devel team) could be held accountable if someone did that.
Someone could already do that with the source-code if they really wanted to (though it would be much more difficult as is).

[jsmcortina]

While it is true that someone could create an emission faking OBD2 implementation, they would have to create it all and we wouldn't have any involvement. However, if we provide the basics of OBD2 it would be significantly easier to create the fake stuff and perhaps we could be seen to have paved the way.

James

[nuvolarossa]

MS will never be able to be 100% compliant to obd-2 laws. I mean not without faking some data at some point or investing LOTS of resources/money.
It's illegal, and some countries kick hard about emissions.
If you want to implement it fully, it's true that protocols are standard and easy to mimic, but obd laws define its workflow. And strategies are tight:
e.g. ecu is supposed to throw a cel if idle doesn't reach target within 200 milliseconds; pre/post cat sensors, evap system, NO WAY.
All described in long documents. Lots of strategies to implement to be 100% obd2 compliant.
Lots of differents/requirements between years.
Then there are five obd2 protocols... which one ms would use?
One of the US ones, or the ISO/euro one? Then it could happen at emission test euro cars working only with US obd tools, or US cars working with euro tools. Would it be suspect?

If you would implement it, you'll have to input fake data at some point to stay in the specifications.
Faking data and being caught=risk of big law problems in some countries.

Imho totally not worth/not achievable (speaking about inspection stuff). MS can't compete with oem budgets.

Then I know the inspection guy would notice nothing. I know there are many ways to pass emissions too.
Luckily the country I live in couldn't care less about obd readings. Emissions should stay in a range, that's all, they don't need to know about errors in ecu.

:::::::

about obd2 for gauges... shadow dash is way more powerful than everything on the market.
Then now there is CAN too, do you really need other?

It's better to spend time and money on usability and manuals to describe all customization scenarios, both firmware and TS/shadowdash.
And maybe develop some cool "official" CAN gauges.

[jsmcortina]

As mentioned before there is no way we would ever fake emissions readings.

There is subset of OBD2 for realtime data reporting that doesn't relate to the diagnostics and could possibly be implemented truthfully.

James

[OliverH]

I always hoped to see OBD2 support in future. I've a project in mind to lift an old air cooled VW to an EURO emission class to have less trouble over in Europe with smog areas. In Germany fir example you need at least euro1 or 2 compliant gasoline engines to enter big cities. Only old timer labeled cars can also enter without higher emission approvals. Having a not in Germany registered car makes it more difficult.
Having gauges is one part of the story having an OBD-2 car also means to have an error storage.
What would be possible with OBD2 and what is not realistic? If I remember right EURO 1/2 doesn't need OBD-2. I'm right now on the track to build up the engine (to get the car street legal in original setup) and than like to change the engine/ EFI later on with the EURO stuff. So I've to decide to go on with MS or convert over to good old Saab Trionic 7 which offers OBD-2 and nice stuff like ion sensing. Software is also available.

[racingmini_mtl]

Oliver,

Read James' post just above yours. It should be clear.

Jean

[Nitroking]

James would it be possible to write the code in a separate file and not provide that code to the rest of the MS devs?

[KJ_Miller_Cycle]

A great feature would be to interface MS3 and obdII in order to develop tables based off of live real time data from the OBDII protocol.

A great example of the use in in a parallel install retaining OBD-II computer and MS for fuel and spark etc. So this could be beneficial: MS3 "looks" at ignition timing based off of the stock obdii ecu and outputs that value to MS to then either develop and ignition table or run timing based off the obdii ecu. THIS would absolutely be beneficial to developer. I am working with an engine that has freak ignition timing, so I recorded live data off the obd2 ecu and MS3 at the same time and frame by frame I developed a near stock ignition table. My described method took many many hours to develop a good initial ignition map.

So IF MS interfaced OBDii this would be an ideal method to develop any table based off of live data. Very powerful.

Remember: Engineers spend many many hours/days/mounts to develop a excellent driveability and this would be a great initial start.

[Nitroking]

So you mean wiring them in parallel, MS3 +B, GND, 2 OBD communication tables and work like a sniffer to create the ideal "base map".. I like this idea.. Very smart..

[KJ_Miller_Cycle]

A great feature would be to interface MS3 and obdII in order to develop tables based off of live real time data from the OBDII protocol.

A great example of the use in in a parallel install retaining OBD-II computer and MS for fuel and spark etc. So this could be beneficial: MS3 "looks" at ignition timing based off of the stock obdii ecu and outputs that value to MS to then either develop and ignition table or run timing based off the obdii ecu. THIS would absolutely be beneficial to developer. I am working with an engine that has freak ignition timing, so I recorded live data off the obd2 ecu and MS3 at the same time and frame by frame I developed a near stock ignition table. My described method took many many hours to develop a good initial ignition map.

So IF MS interfaced OBDii this would be an ideal method to develop any table based off of live data. Very powerful.

Remember: Engineers spend many many hours/days/mounts to develop a excellent driveability and this would be a great initial start.

Also the obdII ecu has a calibrated MAF curve. So live data of mass flow rate can be used (g/s) and could be sent to MS3 to generate a MAF curve based on the OEM obd2 ecu.

To generate a MAF curve for my mazda KJ engine, I recorded live video of the OBDii output (g/s) and MS MAF volts. REVIEWED the video and plotted the data in EXCEL and created a best fit power curve, then used the equation to plot the 50-ish point for the MAF curve.

So another bit of valuable info for the OBDii ecu.

RECAP: good use for obd2 and MS3 interface: GENERATE TABLE/CURVES (ignition timing and MAF flow/volt curve.)

[mr_minnis]

I am no way a developer or anything. I am a casual user.

There is always many ways of doing the same thing. I know the pro m system supports OBD2. Although ford and pro m are the only ones with the source code.

Until I read this thread, I thought it was a cool idea. I never thought about faking the emissions. That could lead to trouble. The only thing I can think of would be an alternative way to connect a laptop ( with an adapter) or program the unit with some sort of handheld device. Given MS already has something like that: shadow dash and Bluetooth and USB, I think a more efficient use of resources would be updating Manuals to reflect current firmware. Of coarse there are many other things that could be done.

The gauges idea is pretty good also.

[gurov]

So I'm working on an arduino interface to ms3 + obd2 + stock can bus. Application is BMW e46. Obd2 in the car that's under the dash is 10.4 kbps over a bi-directional serial LIN interface, this gets about 3-4 samples per second via actual obd2 interface to the compliant plug. Far too slow for anything realtime, and honestly somewhat useless. Only purpose for this data that I see would be eliminating the need to tap/calibrate air/water temps for input into ms3 for simpler installation. For tight coupling in the car between stock ecu and ms3, perhaps some of the data could be used to ease integration. Logging timing advance at conditions as calculated by the ecu versus what the ms3 is calculating.

It would not be enough to pull maf data or even tps data at these rates. Logging reference points alongside actual data might be the best use of actual obd2 data.

My project uses st1110 chip which is an elm clone and supports all the standards + keepalive and interfaces over simple UART. This is why I use arduino mega which has 4 serial ports and makes this easy.

With st1110 you do not have to worry about any kind of obd2 faking issues as its basically an obd2 interface that follows standards for interfacing with stock ecu.

Interfacing with the reader the other way (pretending to be obd2 compliant) would pave the way for faking test results, as its simply not that difficult to do as is. Especially in older cars that have very limited support for obd2 levels of variables (iso9141-2 carb mode, for example)

Honestly though, if the devs aren't willing to introduce the obd2 support of any kind, its not rocket surgery to add it. Everything is open, with enough documentation.

Obd2 source into ms3 via can is pretty trivial

For emulating obd2, freematics makes a product that can be interfaced with over serial to set state of variables returned. It emulates all the obd2 protocols with great success, so some people out there are not too concerned with what someone might do with their technology

[jsmcortina]

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

James

[gurov]

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

James

Legit reasons for emulating: multitudes of dashes, scan tools, diag tools, data loggers, torque app on the phone does some fancy calculations and has neat gauges /dash support. Maybe a more permanent install that taps into the exposed obd2 connevtor , and a can-bus driver that talks via elm327 interface to get rid of the serial and use 500kbps-1mbps throughput. Ms could respond to a configurable can id and emulate just enough of what elm talks to to encapsulate the ms protocol to open a ton of wireless connectivity options that work with stock vehicles (I.e. all the cheap Bluetooth obd2 adapters).

This would require tuner studio mods, and I'm honestly not too sure of the payout of raising the comm speed when sdlogging exists.

Gray area: those insurance loggers that watch how much you drive for different rates(this is getting into the shady territory though)

Super Shady area: emission faking, although this is more complicated than just outputting no check engine light, no Dtc's. The light itself has to behave in accordance testing standards, so if the light doesn't light up, or stays lit, and obd2 claims otherwise, its a red flag. There are also readiness and test passing variable that's returned (0x01 0x01 request) that are looked at.


Asking obd2 for stuff: depending on speed, could aid in getting ms installed, avoid installation of some sensors (vehicle speed/temperatures/tps/o2 sensors). Just casually logging/passing acquired data from obd2 into ms.



Basically, it wouldn't be useful in the main code base, and should be implemented as a separate device/code that talks to main code via existing interface

[Nitroking]

James just make a monitoring OBD so that some race loggers like racechrono can work and so that one can easily access values via his phone and an elm Bluetooth dongle in case of a problem.

[gurov]

James just make a monitoring OBD so that some race loggers like racechrono can work and so that one can easily access values via his phone and an elm Bluetooth dongle in case of a problem.

unfortunately, this is basically an OBD2 server emulator, with only a handful of things needed to get the emission-faking code in. it might be doable with normal MS3 CAN-BUS, it would just have to talk OBD2 protocol.

OBD2 has a very specific handshake procedure, which is honestly kind of the only difficult thing about it (at least for bitbang 5 baud init on KWP/ISO9141-2). Once that's done, and the basic code for obd2 data transfer is established, it would be a lot less work to keep implementing the obd2 modes that relay emission/malfunction information.

[jsmcortina]

Once that's done, and the basic code for obd2 data transfer is established, it would be a lot less work to keep implementing the obd2 modes that relay emission/malfunction information.

That's the main concern I have, I don't want to open the door to someone faking emissions.

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

[gurov]

Once that's done, and the basic code for obd2 data transfer is established, it would be a lot less work to keep implementing the obd2 modes that relay emission/malfunction information.

That's the main concern I have, I don't want to open the door to someone faking emissions.

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

on the other hand, it's not exactly straight forward to emulate all the OBD2 stuff, consider this:

0x01 0x01 query to OBD2, results in 4 bytes returned:

1st byte:

bits 0-6 are number of DTCs stored
bit 7 = check engine light ON/OFF

2nd byte:

tests ,availability/completenees

Test available Test incomplete
Misfire B0 B4
Fuel System B1 B5
Components B2 B6

3rd and 4th byte are actual emission tests, whether they're present, pass or fail.

FINE, so this part is easy to fake, it's just 4 bytes, return that the CEL isn't on, and that the tests are present and they're passing. hooray. hopefully the place doing the testing actually looks at some other stuff, but again, who knows.

like for example:

0x01 0x00 query returns 4 bytes once again that tell you what PIDS are supported, bit encoded.

then there's 0x01 0x20, 0x01 0x40, 0x01 0x60 , etc. to see further map of supported pids,

all the pids are defined by the standard (http://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_1_PID_00)

it could be conceivable that you could write the basic support with only mode 0x01 present that relays all the data to the datalogger. there's other modes that report other emission stuff, vin number, calibration ids (no clue), freeze frame for DTC, etc. the obd2 standard is pretty expansive, so if you implement JUST the basics, you're not really stopping the skillful person from faking emissions. most of these guys won't go digging around in the code and implement 8 more modes that respond with close enough data, or proxy it to a standby ECU (which would require that proxy to be built into the MS codebase)

once they're to that point, they know what they're doing, and your small implementation of basic mode 01 support really didn't give them anything useful.

YES, it's security via obscurity. but honestly, IF i was to fake emissions using a megasquirt, i wouldn't go digging around in the codebase itself, i'd get an arduino with 4 serial ports, some CAN transcievers, and some LIN transcievers, write a sniffer, and a proxy to respond to queries by proxying stuff to a stock ecu while correcting things that do not pass.

I think it would be neat to attract people with OBD2 loggers/dashes/whatever by giving them mode 1 support with all the parameters that MS supports, but i doubt it would haul a ton of them in, unless there's a bunch of plug and play megasquirt boxes that start to get built.

bottom line, a $10 bluetooth dongle, 4 wires (canh canl gnd pwr) from MS to dongle, + any smartphone with bluetooth + velcro = instant gauge you can place anywhere, like boost, for example, or throttle, or whatever. or a bunch of gauges.

i'd get more behind that than racing dataloggers or whatever. and it goes along with the cheapness and utility of megasquirt.

[gurov]

for actual products/roadmap

$8 bluetooth obd2 dongle - http://www.amazon.com/ELM-Bluetooth-Dia ... +bluetooth
$5 app (torque pro) - https://play.google.com/store/apps/deta ... rque&hl=en

for a rather painless dashboard app, that would be separate from the tuning laptop, if there was one, so dash replacements with a cheap android tablet wouldn't be too big of a stretch:



you get instant integration with all the phone things, like camera, gps, accelerometers, internet, etc:

[mazdaspeed]

would be great for my dyno to log and graph various ecu parameters