rusefi.com

Hi,

Is there a possibility to implement ISO 9141-2 Diagnostics to the code? Probably a shot in the dark, but I'm optimistic

https://en.wikipedia.org/wiki/On-board_diagnostics
ISO 9141-2 - is that the one commonly known as "K-line"

I think my Miata has it
But there are currently no plans to work on in.

Why old ISO if there is a faster, simpler and more versatile CAN ?

Odesláno z mého SM-A320FL pomocí Tapatalk

I looked at this a while back, OBD2 Mode 1 (live data) is mostly implemented already. It would need a small rewrite to implement two byte PIDs if extended diagnostics were required - the OBD2 specification is rather limited.

Please be careful when implementing OBDII.
If rusefi could be used to "cheat" emissions, there may be regulatory concerns.

Tomin wrote:Why old ISO if there is a faster, simpler and more versatile CAN ?

I wanted full plug and play and the stock vehicle wasn't wired for CANBus but had a comprehensive diagnostic capability that used KWP2000. I also wanted it to be compatible with the manufacturer's handheld scan tool and a scangauge or similar - if you select '1998 -> MX5 -> 1.6' on the scan tool it selects KWP.

stefanst wrote:Please be careful when implementing OBDII. If rusefi could be used to "cheat" emissions, there may be regulatory concerns.

Implementing ISO diagnostics isn't the same as implementing OBD2, the ISO standards are not 'OBD2 standards' but international standards - OBD2 merely mandates the use of subsets of those standards. There are millions of vehicles out there that use ISO diagnostics but are not OBD2. The correct way to implement them is to set PID 1C Mode 1 to return 'Not OBD Compliant' or to not implement that PID (its only mandated by OBD2).

I should have said 'live data' not fault codes. I have corrected my post above.

It's not a big problem to implement ISO protokol, But It's Not so Simple like added Two wires in the OBD connector. If you really want implement it, You Can try Google with "Stern iso protocol". There are sources somewhere.

Tomin wrote:It's not a big problem to implement ISO protokol, But It's Not so Simple like added Two wires in the OBD connector. If you really want implement it, You Can try Google with "Stern iso protocol". There are sources somewhere.

There are better circuits on the internet, it looks like the comparator circuit violates the common mode specification of the comparator and the reference is biased at 10% of battery voltage which is unusual and with no hysteresis it is not very robust. My preference is to use the L9637 because it offers built in protection, the majority of the circuits on the web have an open collector output with no protection or do not have the correct 510 Ohm pull-up resistor.

510 ohm must be in a scanner ONLY, not in an ecu.

What's the point of implementing ISO9141-2 when we have CAN bus?

I assume @ wants to stay as bmw e36 as possible?

@ are you set on this or would you be ok with can bus? Can bus is more common and faster. You should be able to use normal scan tools for diagnosis. However keep in mind the goal is diagnostics and not spoofing. Basically of the shelf scan tools would report thinks like rpm, temperature and some day perhaps long term and short term fuel trim. However it would not report regulatory items including cat ok, vin, ECT.

One interresting thing to support 9141 is that it could act as a "reader" from the stock ECU to "clone" the original ignition and injection maps and use it as a stock tuning base for your car and engine. I think it would be pretty simple to implement eg.: Lets say we switch rusefi to a learning mode, in wich when you drive it will not read from maps but read the parameter from K-line and write to the correct map field in rusefi. (Many LPG installations use this learning feature to reconstruct petrol maps). And when we have lets say 70% coverage of the map, we can interpolate the rest and voila we have an "original clone" map for our engine and we can start to fine tune.

Btw. is there any software that can to this task - read PIDs and reconstruct maps for a generic K-Line interface for PC? I think there would be some???

Is there a reason why that information would not be available in CAN and is available in 9141?

I've wanted to develop a "play recorder" which is basically just a Frankenso. Basically, make a short extension to the existing OEM harness connector, and sniff the injector pulses and sniff the various analog inputs,ect. Simply recording this data to a SD card. Then this log could be sent to a developer, who could then remotely play it back to an frankenso, or perhaps even just play the numbers back to a discovery board. Then you could off line tune until your tune matches the existing play file. At that point you could then re-flash the firmware and tune into the frankenso that originally recorded the OEM engine, disconnect the OEM ECU, and your off to the races. However that's a bit more pie in the sky. Lots of work to make that happen.

Many older cars do have only K line, or even when they have CAN, it is only used for instruments panel/internal backplane and can or can not output all internal variables. In K line you have a "standardized" PID set, what every or lets say nearly every engine must output, when requested.
I know the pros of can - it is faster and can be hardware implemented in many MCUs, but you have standardized only the physical message frame, not the data in there, and it is for every make different.

No, CAN PIDs are standardized, just like K-line, KWP2000, etc etc.
Both can have custom PIDs but the message format is the same.

nighthunter wrote:One interresting thing to support 9141 is that it could act as a "reader" from the stock ECU to "clone" the original ignition and injection maps and use it as a stock tuning base for your car and engine. I think it would be pretty simple to implement eg.: Lets say we switch rusefi to a learning mode, in wich when you drive it will not read from maps but read the parameter from K-line and write to the correct map field in rusefi. (Many LPG installations use this learning feature to reconstruct petrol maps). And when we have lets say 70% coverage of the map, we can interpolate the rest and voila we have an "original clone" map for our engine and we can start to fine tune.
Btw. is there any software that can to this task - read PIDs and reconstruct maps for a generic K-Line interface for PC? I think there would be some???

The problem is that K-Line diagnostics is very slow. The OBD2 spec calls for 100ms delay between messages which limits the maximum number of PIDs to around 8.5 per second but I have found that using the Windows with a Virtual Com Port slows that to around 6 PIDs/sec and around 4 PIDs/sec using a Bluetooth dongle. So if you're accelerating hard then your parameters are going to be some way out of sync. OBD2 also doesn't output injector PW as standard. Every OBD2 ECU that I've worked with also has a proprietary protocol to access more diagnostics, faster.
You should also take into account the much greater number of maps in an OEM ECU - you won't simply be reconstructing the original map but averaging a number of different maps.

I don't know if this is still true or not any more, but once upon a time, I understand that VW did 2X on the baud rate, which access the enabled a special OBD. It was all the same information, but had additional layers of information, like sensor adaptations, etc.