K-Line Serial Decoding Support?

Ask any questions about using PicoScope 6 Automotive software here.
Post Reply
ashtray1987
OneWave
OneWave
Posts: 48
Joined: Tue Jul 25, 2017 11:52 am

K-Line Serial Decoding Support?

Post by ashtray1987 »

Hi Guys,

Does Pico 6 software offer K-Line Serial Decoding?

Thank you
Ash

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 1581
Joined: Sun Aug 25, 2013 7:22 am

Re: K-Line Serial Decoding Support?

Post by Steve Smith »

Hello and thank you for the post

Unfortunately the PS serial decoder suite does not cover the K-Line protocol

Depending on what you need to decode, the following links may be of help regarding ODB via K-Line
viewtopic.php?p=100985#p100985

There are some introductory K-Line structure notes here
https://www.picoauto.com/library/automo ... sts/k-line

This link is awesome https://www.irjet.net/archives/V4/i7/IRJET-V4I7181.pdf

I hope this helps, take care...Steve

ben.martins
Pico Staff Member
Pico Staff Member
Posts: 539
Joined: Tue May 16, 2017 1:02 pm

Re: K-Line Serial Decoding Support?

Post by ben.martins »

Hi Ash,

Thanks for posting this as along with decoding LIN and SENT into meaningful data, K (& L) Line is another that is on my potential hit list.

Whilst I've yet to fully jump in to researching this, the links Steve has already sent provide some interesting information on K Line as well as the following link that sparked my interest - https://www.nxp.com/files-static/traini ... MM_WBT.pdf.

In this document you'll notice that K Line, as with most others communication signalling is using the Manchester type of signal coding. Whilst we don't direct decode K-Line as we do with CAN, we do now have Manchester as a serial decoder. Providing we can correctly enter the right information this should mean we can decode.

I've yet to get a K Line signal to try this out on though so it's very much theoretical rather than proven. If you have a K-Line capture maybe we can take a look and see if we can get the Manchester decoder to work.

Kind regards

Ben

KimAndersen
TwoWaves
TwoWaves
Posts: 246
Joined: Fri Nov 30, 2012 2:53 pm
Location: Denmark

Re: K-Line Serial Decoding Support?

Post by KimAndersen »

Hi Ashtray1987

As Ben mentioned - try uploading your K-line psdata file and explain to us what your problem is or what you would like to know and maybe I can help you a little. :wink:

Regards
Kim

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 1581
Joined: Sun Aug 25, 2013 7:22 am

Re: K-Line Serial Decoding Support?

Post by Steve Smith »

Hi Ben, nice one.

Here is a K-Line capture of a successful exchange between NVH and a vehicle using ELM327

https://drive.google.com/file/d/1VKYwBi ... sp=sharing

I have the accompanying NVH trace file for this capture (with OBD logging active) so we can compare the Hex data with your decoded data

This is going to be great.

ashtray1987
OneWave
OneWave
Posts: 48
Joined: Tue Jul 25, 2017 11:52 am

Re: K-Line Serial Decoding Support?

Post by ashtray1987 »

Hi Guys,

Thanks for the feedback.

I have attached two waveforms from an electronic ignition switch to steering lock actuator on a W204 Mercedes.

We don't really have any technical documentation on this bus, but I believe it is K-line. We often have issues with programming of these devices, and this data line could be an area we can check for integrity. The issue is I don't have any decoding information for this bus.

In one of the recordings 1 of the nodes was disconnected, this drops the carrier voltage down to below 5V, but I would like to know if there was a way of interpreting the Frame IDs just as it is with CAN, then we can decide if a node is missing from the bus.

Cheers for your help.
Ash
Attachments
known good pin 5 removed.psdata
(621.58 KiB) Downloaded 488 times
known good.psdata
(515.63 KiB) Downloaded 486 times

ben.martins
Pico Staff Member
Pico Staff Member
Posts: 539
Joined: Tue May 16, 2017 1:02 pm

Re: K-Line Serial Decoding Support?

Post by ben.martins »

Hi Ash,

Sorry for the delay on this and thank you for your captures.

Needless to say this has been a journey to say the least and K-Line decoding is, how can I put it politely, interesting.

I will follow this up in more detail once I can make sense of all my notes but to let you start having a play with the decoding ability, I've worked out that the R232/UART decoder will get us to where we need to be. There is some figuring out to do to understand the request and response that is going on especially when there is a scan tool involved. The biggest hurdle with K-line is the packets can be constructed in a number of different ways and it all relies on the information in the Key bytes found in a response from a scan tool request, which allow us to construct the data into something meaningful.

I'm still working on this at the moment but if the OEM has put it in place, we should also be able to identify a byte that represents the node ID.

Still a way to go on this but I wanted to let you know it's not been forgotten about.

Kind regards

Ben

ben.martins
Pico Staff Member
Pico Staff Member
Posts: 539
Joined: Tue May 16, 2017 1:02 pm

Re: K-Line Serial Decoding Support?

Post by ben.martins »

Apologies again for the delay in getting this up here. It's been a bit of a discovery! Thanks to Ash here for bring the concept of decoding K-Line to the fore front with a valid reason as to why you would want. I apologies for the length of time it has taken to get here but I’m hoping to share with you what I’ve found and what you can see using Pico when looking at signals associated with the K-Line BUS. The majority of this work has been done using the file Steve Smith kindly posted - https://drive.google.com/file/d/1VKYwBi ... LdIuh/view.

There are a number of resources available freely on the internet should anyone wish to carry out their own research. 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 that I’ve found which can be associated with 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

This information can be found in the following document - https://www.nxp.com/files-static/traini ... MM_WBT.pdf

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 been extremely valuable for the rest of this document - https://www.obdclearinghouse.com/Files/ ... ileID=1380.

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.
Init identify.png
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.
UART decode 1.png
UART decode 2.png
UART decode 3.png
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.
Fast INIT.png
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.
Baud rate.png
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
Request.png
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 –
Response.png
For more information on Key Bytes please see the following document –
Key Bytes.png
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 –
1st data request.png
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.
Request response overview.png
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!
INIT with Export.png
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.
Request response with NVH loggin.png
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.
Export with engine speed.png
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

AndyM535
OneWave
OneWave
Posts: 15
Joined: Mon Aug 05, 2019 10:11 pm

Re: K-Line Serial Decoding Support?

Post by AndyM535 »

I came across a book called 'The Car hacker's handbook' that explains this too.

Does this mean that nvh can now get the RPM using k-line?

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 1581
Joined: Sun Aug 25, 2013 7:22 am

Re: K-Line Serial Decoding Support?

Post by Steve Smith »

Hello and thank you for the post

NVH will obtain RPM and Road Speed via K-Line but there are a number of caveats.

The following link will help topic22257.html where the vehicle itself may not respond to typical requests for RPM or Road Speed. (EDC15 /EDC 16U1)

The other is the integrity of the Scan Tool in use and stability during communication.

A genuine ELM 327 is a cost effect solution for a number of vehicles (not all) when using NVH. However, a number of replicas we have encountered generate a real headache when using NVH; Sometimes connecting, then dropping connection, other times not connecting at all.

I hope this helps and thank you so much Ben for the hard work and hours/days spent decoding K-Line. We are very lucky indeed to have such support

Take care.....Steve

Post Reply