KW2000 connection aborts with invalid complement

[mvglasow]

Steps to reproduce

Connect to an ECU which communicates using KWP2000 over K-line and perform a ReadIdent. ECUs I have tried (all of them in a 2005 Audi A4, type 8E/B7):

• 0x56, Radio/navigation RNS-E, part no. 8E0035192C
• 0x77, Telephone (part no. should be one of 8P0862335*)

Expected result

Connection is successful and the ECU responds with its identification data (at least dealer part no., identification string).

Actual result:

$ kw1281test ACDCBLAH 10400 56 ReadIdent
KW1281Test: Yesterday's diagnostics...Today.

Version 0.80-beta (https://github.com/gmenounos/kw1281test/releases)
Args: A50285BI 10400 56 ReadIdent
OSVersion: Unix 5.15.0.67
.NET Version: 7.0.0
Culture: en-US
Opening FTDI serial port A50285BI
Sending wakeup message
Wakeup duration: 2.000000008 seconds
Reading sync byte
Keyword Lsb $EF
Keyword Msb $8F
Protocol is KW 2031 (8N1)
Caught: System.InvalidOperationException Received complement $29 but expected $A9
Unhandled exception: System.InvalidOperationException: Received complement $29 but expected $A9
   at BitFab.KW1281Test.KwpCommon.ReadComplement(Byte) in C:\Users\gmeno\src\kw1281test\KwpCommon.cs:line 117
   at BitFab.KW1281Test.KwpCommon.WakeUp(Byte, Boolean) in C:\Users\gmeno\src\kw1281test\KwpCommon.cs:line 95
   at BitFab.KW1281Test.Tester.Kwp1281Wakeup(Boolean ) in C:\Users\gmeno\src\kw1281test\Tester.cs:line 32
   at BitFab.KW1281Test.Program.Run(String[]) in C:\Users\gmeno\src\kw1281test\Program.cs:line 256
   at BitFab.KW1281Test.Program.Main(String[]) in C:\Users\gmeno\src\kw1281test\Program.cs:line 26

$ kw1281test ACDCBLAH 10400 77 ReadIdent
KW1281Test: Yesterday's diagnostics...Today.

Version 0.80-beta (https://github.com/gmenounos/kw1281test/releases)
Args: A50285BI 10400 77 ReadIdent
OSVersion: Unix 5.15.0.67
.NET Version: 7.0.0
Culture: en-US
Opening FTDI serial port A50285BI
Sending wakeup message
Wakeup duration: 2 seconds
Reading sync byte
Keyword Lsb $6B
Keyword Msb $8F
Protocol is KW 2027 (8N1)
Caught: System.InvalidOperationException Received complement $08 but expected $88
Unhandled exception: System.InvalidOperationException: Received complement $08 but expected $88
   at BitFab.KW1281Test.KwpCommon.ReadComplement(Byte) in C:\Users\gmeno\src\kw1281test\KwpCommon.cs:line 117
   at BitFab.KW1281Test.KwpCommon.WakeUp(Byte, Boolean) in C:\Users\gmeno\src\kw1281test\KwpCommon.cs:line 95
   at BitFab.KW1281Test.Tester.Kwp1281Wakeup(Boolean ) in C:\Users\gmeno\src\kw1281test\Tester.cs:line 32
   at BitFab.KW1281Test.Program.Run(String[]) in C:\Users\gmeno\src\kw1281test\Program.cs:line 256
   at BitFab.KW1281Test.Program.Main(String[]) in C:\Users\gmeno\src\kw1281test\Program.cs:line 26

Software environment

kwp1281test 0.80-beta, Ubuntu 22.04, libftd2xx.so.1.4.27

Additional information

In order to rule out an incorrect baud rate, I retried the operation with a different baud rate (9600 instead of 10400), which resulted in the code tripping on the sync bit – which indicates the baud rate should have been correct.

In both cases, the actual and expected values differ by 0x80. This looks to me as if 7o1 input has been interpreted as 8n1 (as far as I know, bit order is from least to most significant, parity byte last, thus 0x80 would be the parity bit).

The received byte appears to be the complement of the ECU address (received | address == 0x7F, expected | address == 0xFF).

According to https://www.blafusel.de/obd/vag_kw2000.html (section Initialisierung), communication from the two keyword bytes up to the inverted ECU address uses seven data bits, odd parity. Once the inverted controller address has been transmitted, communication switches to 8 data bits, no parity.

So for the inverted controller address, after determining its 8-bit complement, we would need to calculate the parity of the complement, and if it is even, flip the most significant bit.

This would also mean the issue would currently affect only half of all addresses. Since the RNS-E listens on two addresses (0x37 for navigation, 0x56 for radio) with identical behavior, I tried 0x37 as well. This time the connection proceeds four lines further into Tester.cs, before aborting because the protocol is not recognized.