Bug in LTOBD2ProtocolISO15765_4

[mlawlerau]

I think there is a bug in LTOBD2ProtocolISO15765_4 where it incorrectly applies the "Clunky workaround for mode 06 behavior".

I noticed that my app was showing weird decoded values for LTOBD2PID_SHORT_TERM_FUEL_TRIM_1_06 vs LTOBD2PID_SHORT_TERM_FUEL_TRIM_2_08. PID

I noticed that pid 0x08 works fine, but pid 0x06 was sometimes giving strange results. 06 is the magic pid number to trigger the bug.

I tracked it down to the section where the protocol applies "clunky workaround". This causes it to (in some cases) decode incorrect values.

i.e. given a command: 0106, response: 7E80341067C -> that should be a single 0x7C response value which should be dec 124.

However, this workaround code, causes the library to apply the "decrementing the numberOfBytesInCommand" which engages the 'originalCommandCorrective' modifier, which causes it to return two numbers [ 06, 124 ] in the payload.

This means when you are expecting a single byte for this command and take the first byte in the payload, ala 'decodeSingleByteDoubleValueWithOffset' then you'll decode the 06 and get the wrong value.

The workaround seems to be reading the sid and pid incorrectly. In response '7E80341067C' it thinks the sid=6 and the pid =7c, but actually the sid is 01 and the pid is 06. Perhaps there are too many +1's being applied to the headerLength in this function.

[mlawlerau]

Are we ok just to comment this bit of code out if we are not using Mode 06?