Chipkit Max32 with KWP FAST Protocol

[zakirsheik]

Hi,

I am using this library to read my vehicle which works with KWP FAST Protocol.
I am using the hardware from Macchina (https://www.macchina.cc/catalog)
The MCU that I use is a Chipkit Max 32.
I am not able to get any communication with my ECU. The debug prints the following.

"Looping
Before 25 ms / 25 ms startup.
Enable port.
init_success:0
Looping
Before 25 ms / 25 ms startup.
Enable port.
init_success:0"

[iwanders]

Please read this post as a start. For some first pointers on debugging this, I see you already enabled debugging 👍 .

The KWP fast protocol has not had the same level of testing as the 5 baud init, it was developed in #11, but it may need some different values for other cars? I'm not too sure, if you have access to a working bluetooth obd scanner that can be sniffed that would be ideal.

Did you post in the Macchina forum as well? Some other people in that community may have experiences with KWP Fast and may be able to help you out for this protocol in particular.

[zakirsheik]

I do hold a ELM based OBD Dongle, When I connect with Torque app it is showing the protocol as 'KWP FAST' and it is reading the parameters like RPM, Speed etc. I do not have an idea on how to sniff out the communications, I do have a logic analyzer with me.

I did post my query in the Macchina Forum but since my Arduino board(Chipkit based) is different from what they use, they do not have a clue on it and I am on my own.

[iwanders]

I do hold a ELM based OBD Dongle, When I connect with Torque app it is showing the protocol as 'KWP FAST' and it is reading the parameters like RPM, Speed etc. I do not have an idea on how to sniff out the communications, I do have a logic analyzer with me.

Excellent! So you have a working OBD dongle and you have a logic analyzer 🎉 That improves our chances on getting this working immensely. The easiest way to figure out what we are doing incorrectly in the handshake is to sniff the OBD dongle connecting to the car and compare that data to what our code does. The OBD port itself is 12v, your logic analyzer may not be able to go that high, you can either use an SN65HVDA195 chip and connect your logic analyzer to the RXD pin, or just use a voltage divider to go from 12v to 5v. I would go for the latter, it's easy, passive and works without problems, I've developed this entire library that way; By comparing the traces of an OBD dongle, captured with a simple voltage divider and a Saleae logic analyzer.

So, my suggestion is, make a voltage divider to drop from 12v to 5v. Connect the input of that to the K-line of the OBD port, the ground to the OBD ground. Then the reduced voltage output from the divider to your logic analyzer and record the communication on the K-line while the OBD dongle connects and reads the RPM. You can decode the data by setting up a protocol analyzer, set it to serial and manual baudrate at 10400. If it's a Saleae logic analyzer or some other file I would be able to open feel free to upload it to this issue. Otherwise timestamps + bytes would probably be good enough.

After you've captured the data from the obd dongle we know what it should be, ideally you'd make a capture of what your hardware does then we can compare and make fixes to the software to try to make it work.

[zakirsheik]

"record the communication on the K-line while the OBD dongle connects and reads the RPM"
How exactly can I do this, is it with a help of OBD splitter cable ? Once I connect my OBD ELM dongle, I do not have access to the K-line, right ?

[iwanders]

How exactly can I do this, is it with a help of OBD splitter cable ? Once I connect my OBD ELM dongle, I do not have access to the K-line, right ?

In any way you can, in general it's possible to reach the pins from the rear of the OBD port as it is mounted in your car. Alternatively you could use a splitter cable yes, since the OBD ELM dongle only really needs 3 connections (ground, battery and K-line) you can even cobble together something with a few clamps on the dongle and wires going into the port. I bought a few OBD dongles and took one apart to obtain the 'plug' side of it and connected wires to that with clamps that I could attach to my PCB and second OBD dongle. You can also buy an extension cord and cut it in two to get access to the data line. Be careful and be safe, when in doubt get an OBD splitter cable and a plug such that you can sniff the K-line in a safe manner without risk of cables falling out or clamps failing. Stay within your abilities, take your time and doublecheck everything.

[iwanders]

@aster94 just reached out in another issue, he/she has a library that's specifically tailored towards KWP, it may be worth to give that a try, it has a slightly different initialization than my library.

[zakirsheik]

@iwanders Thanks for the tip, I will give a try to @aster94 code and see if it gets info from my Vehicle ECU.
Meanwhile I am also working on getting the vehicle traces using a Logic analyzer.

A quick question on your library, I read that you used Hardware Serial in Teensy board and Software serial for Arduino based boards, till now I have tried your library only using a Hardware Serial from Chipkit Max32 and I have my own doubts on Chipkit Internal Pullup resistors, do you suggest to use Software Serial from Arduino based boards ? I am having a Wemos D1 Mini and I can try SoftwareSerial example from your library. Any thoughts ?

[iwanders]

till now I have tried your library only using a Hardware Serial from Chipkit Max32 and I have my own doubts on Chipkit Internal Pullup resistors, do you suggest to use Software Serial from Arduino based boards ? I am having a Wemos D1 Mini and I can try SoftwareSerial example from your library. Any thoughts ?

I expect any hardware serial implementation to work more reliably than a software serial implementation. I cannot comment on the ESP8266 software serial's performance. If you doubt the pullups you can always add a 4.7k or 10k pullup in addition to what the chip does, that's definitely worth a try. Trying on different hardware is worth a try of course, especially if there's doubts about the Max32 board.

[zakirsheik]

@iwanders Sorry for posting after a longtime, since it took some time for me to order the splitter cable from China. I was able to setup a voltage divider from K-Line and analyze the signals using a Logic Analyzer and attached are the screen shots of Initialization and the recordings.
From my understanding it looks like a KWP Fast Init with 25ms low and 25ms high followed by the start communication request C1 33 F1 81 66. These recordings are made using Pulseview(Sigrok), hope you would be able to analyze and comment your thoughts. Thanks.

recording2.zip
recording1.zip

[iwanders]

Sorry for posting after a longtime, since it took some time for me to order the splitter cable from China. I was able to setup a voltage divider from K-Line and analyze the signals using a Logic Analyzer and attached are the screen shots of Initialization and the recordings.

No worries, cool that you got the recordings going.

From my understanding it looks like a KWP Fast Init with 25ms low and 25ms high followed by the start communication request C1 33 F1 81 66. These recordings are made using Pulseview(Sigrok), hope you would be able to analyze and comment your thoughts. Thanks.

Hmm, I looked at recording 1:

At A-B we see 25ms LOW, then B-C 25ms HIGH, then communication to the ECU at C is:

A-B: 25ms LOW
B-C: 25ms HIGH
C (communication   to ECU): 0xC1, 0x33, 0xF1, 0x81, 0x66
D (communication from ECU): 0x83, 0xF1, 0x11, 0xC1, 0xE9, 0x8F, 0xBE
E (communication   to ECU): 0xC2, 0x33, 0xF1, 0x01, 0x0D, 0xF4
F (communication from ECU): 0x83, 0xF1, 0x11, 0x41, 0x0D, 0x00, 0xD3

C does correspond to the initKWP start.
D has a 4th byte that's checked to be 0xC1, the checksum is correct (check in python with; hex(sum([0x83, 0xF1, 0x11, 0xC1, 0xE9, 0x8F]) % 256)) and the length is correct.
E and F correspond to a valid speed PID request and response.

All looks good on the trace side? What is the problem here? Does the microcontroller say that it's incorrect? Because these traces look exactly how one would expect them.