k-line speed study

[gauix4]

here are the logs made with software that uses k-line only it uses 17 data with an average sampling rate between 300ms and 400ms

ID,Time,SPEED,RPM,ECT,IAT,MAP,MAP(psi),MAF(Kg/h),MAF(Mg/Stk),SFT,LFT,KV,KC,KN,TP,IGN1,IGN2,IGN3,IGN4,INJ,IDC,AFR,Gear,Load
1,18:59:41.334,0,2086,89,34,512,-7.1,50,200,-14.8,-9.4,0.9,0,53,7,21.38,21.38,21.38,21.38,0,0,15.2,0,48.24
2,18:59:41.704,0,2104,89,34,508,-7.1,50,198,-13.3,-9.4,1.1,0,50,7,22.5,22.5,22.5,22.5,0,0,14.9,0,48.24
3,18:59:42.074,0,2104,89,34,511,-7.1,51,202,-12.5,-9.4,0.8,0,52,7,21,21,21,21,0,0,14.8,0,48.24
4,18:59:42.444,0,2138,89,34,503,-7.2,51,199,-7.2,-9.4,0.8,0,48,7,14.63,14.63,14.63,14.63,0,0,14.7,0,48.24
5,18:59:42.813,0,2142,88,34,465,-7.8,47,183,-9.2,-9.4,0.7,0,49,6,16.5,16.5,16.5,16.5,0,0,14.8,0,45.49
6,18:59:43.184,0,2153,88,34,454,-7.9,44,170,-10.6,-9.4,0.8,0,50,7,40.5,40.5,40.5,40.5,0,0,15.1,0,41.57
7,18:59:43.554,0,2173,88,34,518,-7,48,184,-4.9,-9.4,1,0,54,8,35.63,35.63,35.63,35.63,0,0,15.1,0,42.75
8,18:59:43.924,0,2174,88,34,540,-6.7,55,211,-5.4,-9.4,0.8,0,49,8,34.13,34.13,34.13,34.13,0,0,14.6,0,49.8
9,18:59:44.294,0,2190,88,34,533,-6.8,55,209,-6.9,-9.4,0.8,0,46,8,34.13,34.13,34.13,34.13,0,0,15,0,51.37
10,18:59:44.664,0,2206,88,34,526,-6.9,55,208,-8.8,-9.4,0.9,0,53,8,34.5,34.5,34.5,34.5,0,0,14.9,0,50.98
11,18:59:45.033,0,2230,88,34,519,-7,55,206,-14.8,-9.4,0.9,0,46,7,16.88,16.88,16.88,16.88,0,0,14.9,0,49.41
12,18:59:45.403,0,2237,88,34,471,-7.7,50,186,-16,-9.4,1,0,57,7,15.38,15.38,15.38,15.38,0,0,14.9,0,47.84
13,18:59:45.773,0,2251,88,34,455,-7.9,46,170,-15.6,-9.4,0.8,0,54,7,20.25,20.25,20.25,20.25,0,0,14.6,0,41.57
14,18:59:46.143,0,2264,88,33,452,-7.9,46,169,-14,-9.4,1.1,0,51,7,21.38,21.38,21.38,21.38,0,0,14.4,0,40
15,18:59:46.513,0,2267,88,33,449,-8,45,165,-10.2,-9.4,1,0,54,7,22.13,22.13,22.13,22.13,0,0,14.7,0,40
16,18:59:46.884,0,2268,88,33,448,-8,45,165,-11.5,-9.4,0.9,0,56,7,22.13,22.13,22.13,22.13,0,0,15.2,0,40
17,18:59:47.254,0,2279,88,33,446,-8,45,165,-17.8,-9.4,0.9,0,68,7,21.38,21.38,21.38,21.38,0,0,15.1,0,40
18,18:59:47.622,0,2276,88,33,437,-8.2,45,165,-16.6,-9.4,1,0,60,6,18.38,18.38,18.38,18.38,0,0,14.8,0,40
19,18:59:47.994,0,2263,88,33,400,-8.7,42,155,-16.8,-9.4,1,0,67,4,9.75,9.75,9.75,9.75,0,0,14.2,0,38.82
20,18:59:48.364,0,2229,88,33,356,-9.3,34,127,-14.9,-9.4,0.9,0,59,4,-16.88,-16.88,-16.88,-16.88,0,0,14.1,0,32.16

[gauix4]

I will see to make an analyzer and publish the information it returns

[iwanders]

Considering the sample request from the timing section.

In the first phase, the bytes necessary for the request are written on the Tx line, according to the specification there should be a 5 millisecond delay between each symbol. The duration of this delay is defined by INTERSYMBOL_WAIT. It is possible that the ECU still discerns the bytes correctly when this delay is lowered.

So wait between each transmitted byte is INTERSYMBOL_WAIT, equal to 5 ms.

For the request, 5 bytes (each 8 bits), with 4 INTERSYMBOL_WAIT periods: 5 * 8 * (1/10400) + 4 * 0.005 = 0.024s. Followed by the response, of 7 bytes (each 8 bits), with 6 INTERSYMBOL_WAIT periods: 7 * 8 *( 1 / 10400) + 6 * 0.005 = 0.035s.

Total of request + response: 0.024s + 0.035s = 59ms, per request.

it uses 17 data with an average sampling rate between 300ms and 400ms

Lets assume that is an average 350ms, 350ms / 17 = 20.6ms. That's three times faster than the specification allows (assuming equal length requests). :thinking:

Lower values of INTERSYMBOL_WAIT give different durations for the requests:

INTERSYMBOL_WAIT = 5: 5 * 8 * (1/10400) + 4 * 0.005 + 7 * 8 *( 1 / 10400) + 6 * 0.005 = 0.059 = 59ms
INTERSYMBOL_WAIT = 4: 5 * 8 * (1/10400) + 4 * 0.004 + 7 * 8 *( 1 / 10400) + 6 * 0.004 = 0.049 = 49ms
INTERSYMBOL_WAIT = 3: 5 * 8 * (1/10400) + 4 * 0.003 + 7 * 8 *( 1 / 10400) + 6 * 0.003 = 0.039 = 39ms
INTERSYMBOL_WAIT = 2: 5 * 8 * (1/10400) + 4 * 0.002 + 7 * 8 *( 1 / 10400) + 6 * 0.002 = 0.029 = 29ms
INTERSYMBOL_WAIT = 1: 5 * 8 * (1/10400) + 4 * 0.001 + 7 * 8 *( 1 / 10400) + 6 * 0.001 = 0.019 = 19ms

My hunch, they set INTERSYMBOL_WAIT to 1ms, change this line to:

#define OBD9141_INTERSYMBOL_WAIT 1

And retry?

[gauix4]

I had already done this and you could see that it was going a little faster to say it three times I very much doubt it no offense i think there is a problem of time management because the example i gave you for the esp32 we have about 8 give in one second

unfortunately I can't try to compare because it's proprietary software with a proprietary USB Adapter however I can make a comparison with the serial monitor by asking several requests and then comparing them once the modification is done I'll see if I can do that tomorrow

[gauix4]

@iwanders do you have any software or something that i can analyze with my esp32 or an arduino uno/mega i didn't find anything interesting and i tried but we don't have the recorder so that I can send you the data that I collected on the proprietary adapter

thanks

[iwanders]

I'm not sure I understand, I think you need software to enable the esp32 or arduino to record?

I said this in this comment;

Perhaps you can make a logic analyzer from an esp32? Use the adapter from amazon, and connect the logic analyzer to the Rx signal.

That https://github.com/EUA/ESP32_LogicAnalyzer looks promising for recording the signal? I've never used it, but it seems to be compatible with sigrok, from the screenshot it uses: Pulseview (Linux, Windows installers), through the standard SUMP protocol.

Then

• Record the K-line with proprietary adapter.
• Record the K-line with the ESP32 / OBD9141.h system.

We compare the differences in timing and see how the proprietary adaptor is so fast.

[gauix4]

thank you very much for your reply sorry for the inconvenience here is what I was able to find with INPA software and its k+dcan adapter inpa-initalisation-read-throttle-position.sr.zip

[iwanders]

:open_mouth:

Well, that's all looking super odd. There's no 5 baud init like here. No init at all.

With 10400 baud we have frame errors, so I used 10000, because the sampling rate was 20 kHz only?

With that we obtain...

2950ms: 13 04 00 17
2980ms: 13 04 00 17

5000ms: b8 ff 13 f1 01 a2 f9 ff
6000ms: b8 ff 13 f1 01 02 f9 ff # probably same as 5000ms?

7000ms: b8 4d f7 02 1a 80 c4
7115ms - 7394ms: ... lots of data
7500ms: b8 4d f7 02 1a 80 c4
7545ms - 7820ms: ... lots of data
7900ms: b8 4d f7 02 1a 80 c4
7980ms - 8254ms: ... lots of data
Repeat

request_response_pair.txt

inpa_init_anotated.sr.gz

Even accounting for some bit errors or framing offsets from the sampling at just 20000Hz. I don't think this is 9141-2? Or it must be some special mode I've never seen before, the lots of data is really really lots of data.

I don't see how we would split that data into PID's. It'll require significant reverse engineering to figure that out I think, this doesn't look like standard 9141-2 OBD pid requests :disappointed:

[gauix4]

Again and as always thank you very much for your answer and for taking the time to answer me personally with your code I can't reach less than 1.3s for 17 data https://youtu.be/AYiHjN-IgrU

yes the sampling rate was 20kHz I can do it again with many more if you want

It's been almost 15 days of relentless trying to find what other protocol can go through K-line I can only find ISO9141 My mini cooper S R53 (2005) is part of the BMW group and I think they have their own protocol because the adapter only works on BMW and Mini but again when I look on the side of BMW I only turn on ISO9141 there may be KWP2000 but I did not find anything on that side the only thing I'm actually watching right now is this https://github.com/uholeschak/ediabaslib

[iwanders]

yes the sampling rate was 20kHz I can do it again with many more if you want

Nah, I think we got the information we need, it's just... something different :/

personally with your code I can't reach less than 1.3s for 17 data

Yeah, I see that bummer.

My mini cooper S R53 (2005) is part of the BMW group and I think they have their own protocol because the adapter only works on BMW and Mini

I think you're right, that would explain the very long data blocks we got.

[gauix4]

I found the source code of my adapter I also have all the id I am super happy https://github.com/uholeschak/ediabaslib/blob/master/EdiabasLib/UdsFileReader/UdsReader.cs

Do you mind helping me in this project ? of course i will reward you for this if you agree can you tell me how much would you like I know how to code a little and I manage a little but I know that I am clearly not at your level and I mainly use Visual Studio code any other support is unknown to me I'm not sure I'll be able to do this alone in a reasonable time.

[iwanders]

Do you mind helping me in this project ? of course i will reward you for this if you agree can you tell me how much would you like

Nope, I've done all I can to help here. I've got a fulltime job and am currently not for hire for additional work.

I know how to code a little and I manage a little but I know that I am clearly not at your level and I mainly use Visual Studio code any other support is unknown to me I'm not sure I'll be able to do this alone in a reasonable time.

Some general advice; always push your limits to expand your skillset, but don't try to do things too far away from your current level, that makes it difficult and hard to keep motivated. Do work on projects you are passionate about and that push your skills.

Marking this issue as done, the remainder is not related to OBD9141-2.

[gauix4]

@iwanders sorry for not taking the time to answer I was developing the display https://youtu.be/MYhseVD6s9I

I went back to looking for the protocol they use this high speed in reality it is the KWP2000 protocol ISO 9141 also has this function on some cars there is a slow function or the 5 baud initialization and ask there is also the fast initialization http://raviprashanthsn-technical.blogspot.com/2013/10/kwp2000-basic-information.html

for the IDs I don't know yet if it's the same

[iwanders]

@gauix4 , very cool! Love the reaction at the start of the video. I exactly know that feeling ^_^

It could be kwp2000 slow init, initialisation procedure for that was (relatively recently) added under #42. Worth a shot?

[gauix4]

@iwanders yes it's cool but I go through the can bus and unfortunately I don't have the data I want I can get them only by KWP2000

I will make in the next few hours a modification on your code because there is a very big problem of time management I do not understand why did you use delay instead of millis ?

[iwanders]

I will make in the next few hours a modification on your code because there is a very big problem of time management I do not understand why did you use delay instead of millis ?

Classical synchronous vs asynchronous programming decision. This was easy at the time, for me it worked fine, because I wasn't doing anything in parallel to the requests. Writing asynchronous code always involves adding state machines to keep track of where you are in the logic / steps. No need to make a PR for this, I have no desire to change the 'threading model' of this library at this stage.

Only the init should have delays, after that all requests go through readBytes, which you should be able to change into an available() call or something, to prevent blocking while the ECU is sending the response.

Good luck :)

[gauix4]

@iwanders
thank you for your answer I will study your code I am not as good as you but I think I understand what you wrote :) I need kpw2000 rather fast what I'm interested in and to have data as quickly as possible :) unlike ISO9141 there is more data on the WKP2000 so I hope to progress in the next few days to succeed at least having communication with my ECU

[gauix4]

@iwanders impossible to have a communication or a link with the KWP protocol I tested the low and the fast both did not work for me.

// startCommunicationRequest message:
uint8_t message[4] = {0xC1, 0x33, 0xF1, 0x81}; // where do you find this do you have any information please :) 
// checksum (0x66) is calculated by request method.

the first image and with my special adapter the second is kwp fast we can see that there are similarities

K + DCAN

KWP fast protocol

[iwanders]

where do you find this do you have any information please

Don't remember, but the 'blame' button allows you to review which commit last touched the line. Looks like it went in in PR 12 which has links to some issues with long discussions, you may be able to find more information there.

In the logic analyzers, try adding a UART analyser at 10400 baud rate, that should decode the symbols for you, making it easier to discern similarities or dissimilarities.