One thing that is clear is that despite its age, K-Line isn’t quite as straight forward as you would hope/think! One of the biggest challenges we face when trying to decode K-Line is that different OEM’s had different ways of encoding and decoding the messages.
Below are some key facts relating to K-Line (ISO 9141):
• K-Line supports data rates between 5Bits/s to 50Kbits/s
• Bi-directional half duplex BUS communication
• Manchester type of signal coding
• Single ended BUS
Our next issue is that there are a number of different formats that can be used with K-Line. I often make sense of that statement by saying the language is the same but they have different accents! Trying to differentiate is a big hurdle and one that has caught me out when trying to decode Steve’s capture and it all comes down to the initialisation sequence when a scan tool is connected to the vehicle. The other thing to remember when looking through this PSDATA file is this was taken whilst attempting to communicate with the Pico NVH software in order to obtain engine and road speed. This document has proven extremely valuable.
The following information is drawn from there. There are 3 protocols that can be used and whilst there is some overlap in similarity, they are separate and distinct. The 3 in question are -
1. K-Line (ISO 9141) with 5 Baud initialization
2. KWP2000 (ISO 14230) with 5 Baud initialization
3. KWP2000 (ISO 14230) with fast initialization
The fact we are attempting to communicate with NVH is important. This is because NVH will try a number of different ways to communicate till there is a response and NVH supports both ISO 9141 and ISO 14230.
Knowing that the type of coding is based on the Manchester type of signalling I thought to try this decoder in PicoScope. Sadly, though this wasn’t possible. Due to the different header and payload data lengths within K-Line, it isn’t possible to set the data length in the Manchester decoder as it changes with each packet. The other coding that is mentioned a lot is UART – Universal Asynchronous Receiver/Transmitter. Using this allows us to decode each individual byte but unfortunately doesn’t show us how the packet is constructed. This is still extremely useful though in understanding how this network communicates.
Let’s start with the ISO 9141 initialization sequence using both Pico and the document above along with applying a UART decoder. From the document we know that it is using 5 Baud speed along with a particular sequence to look for which involves a 2 second transmission where there will be a high level lasting 400ms. We can identify this in Pico and verify using the time rulers.
Knowing this is the area of interest we can now apply the decoder and to eliminate any confusion we can set the decoder to work between the rulers in this area.
According to the document this is the scan tool putting the address 33 out onto the bus at 5 Baud which lasts a total of 2 seconds. This should then be followed by a response from an ECU with a synchronization byte 55 which should happen between 20 and 300ms. I’ve deliberately set my time rulers at 2.300 seconds to show that there is no response from the vehicle.
Because there isn’t response and we are communicating with NVH, NVH then moves on to the next protocol, in this case ISO 14230. We know that there are 2 types of ISO 14230, one using 5 Baud and the other using fast initialization. Being that the 5 Baud version follows the same initialization as ISO 9141, there should be the sync byte 300ms after the address 33 is put onto the network. With this still missing we move straight to the KWP2000 fast init.
This sequence begins with a wake-up pattern last 50ms which is immediately followed by a start communication request from the scan tool to the vehicle.
TECH TIP
The differing data rates make it particular difficult to decode on as we need to determine this first. There is simple way to find the Baud rate of any network using the rulers in Pico. First locate the smallest bit in a packet of data and place a time ruler each edge of the bit. From here take note of the frequency in the ruler legend and this will give you your Baud rate.
10.4KHz can be translated to 10.4KBaud. Take note of this as it’s important when applying any decoder.
Again, using the PDF document along with the UART decoder we can start to see relationship between the document and what Pico is showing us. The first piece of information from the scan tool according to the document this data is formed with the following bytes –
1. C1 – Format Byte
2. 33 – Target address
3. F1 – Source address
4. 81 – Start communication request ID
5. 66 – Checksum
This is exactly the decoded data found using UART decoder in Pico and follows precisely after the 50ms wake up call.
The response from the ECU follows a similar format but includes additionally information in the form of key bytes. The key bytes are present in all 3 types of initialization and are vital to determine whether the ISO 9141 or ISO 14230 is to be used in the proceeding communication between the vehicle and the tester. For ISO 9141 the key bytes will be either 08 08 or 94 94 but for ISO 14230 there are around 19 different types! For OBD communication using ISO 14230 it is required that the only key bytes used are 8F E9. Following the same pattern for the request the response should like this –
1. Format byte
2. Target address
3. Source address
4. Service ID
5. Key byte 1
6. Key byte 2
7. Checksum
Looking at the proceeding data in Pico we can see the following –
For more information on Key Bytes, please see this document.
Following on from this initialization sequence there is the first data request from the scan tool. This could differ depending on what you are trying to look. As we are using this for NVH we are looking for Engine and Road speed which are found in the Service 1 PID 00. The request from the scan tool must follow the standard as set by the key bytes for the correct header. For the vehicle we are using in this example we know the key bytes are 8FE9 and the correct request from a scan should be C2 33 F1 01 00 C4. This can also be seen in Pico –
When you zoom out of the capture you can start to see the pattern between request from the scan tool and the response from the vehicle.
I have to thank Kim Anderson here as the following information was made much easier having Kim’s input into decoding this data. Kim has kindly started to put together a spreadsheet which uses the exported data from Pico. When you start to pick through the data the patterns start to become clear!
When you also look at the trace file captured with NVH you can also spot the relationship between the decoded data in Pico and what the OBD logging is within the trace file.
We can then go further using the trace file as we can determine that the two request 0C and 0D are for engine and road speed respectively.
What we can start to do now though is actually identify which ECU is talking back to the scan tool making an educated guess! We are asking for engine and road speed so it would be a pretty good assumption to say the source address labelled as 10 in the above table is in fact our engine ECU.
Going forward to decode K-Line accurately will have to be done when a scan tool connected as this give us those important key bytes following an initialization between the vehicle and scan tool. From here we can see how the data is going to be presented and what information is available. To get as much information as possible the settings we’re recommending would be 5s/div and a sample rate of around 2MS/s. This will give plenty of detail the bits in order to decode.
I hope this helps and shows how despite not having a dedicated decoder in Pico, we can still use the tools to extract more information from a raw signal. Thanks again to Kim Anderson, Barney Donohew and Steve Smith for helping put this together.
Kind regards
Ben