jsmcortina wrote:gurov wrote: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.