JejuSoul / OBD-PIDs-for-HKMC-EVs

Setting up Torque Pro to show OBD data on Hyundai / Kia Electric Vehicles
236 stars 142 forks source link

How to request Hyundai Kona SoC via PEAK PCAN-USB #44

Open madshadsen opened 4 years ago

madshadsen commented 4 years ago

I'm trying to extract State of Charge from my Hyundai Kona 2019 with my PEAK PCAN-USB device.

To do so, I've looked at the Kona PID section and I've tried to construct my request frame based on the information. However, I seem to be encountering some challenges.

My request frame

7E4   |   03 22 01 01 AA AA AA AA

Observed response

7EC   |  10 3E 62 01 01 FF F7 E7

Expected response (based on the BMS sheet in the Google sheet)

7EC   |  10 3E 62 01 01 FF F7 E7
7EC   |  21 FF BC 16 AE 43 08 00
7EC   |  22 00 00 0F CF 09 08 08
7EC   |  23 08 08 09 00 00 0A CE
7EC   |  24 30 CE 4A 00 00 78 00
7EC   |  25 00 15 B2 00 00 12 F4
7EC   |  26 00 00 08 40 00 00 06
7EC   |  27 D1 00 05 F7 06 09 00
7EC   |  28 03 00 00 00 00 03 E8

In other words, I'm only getting the first frame response, but I'm missing all of the following (21-28) frames. Is somebody able to explain what I'm missing in my request setup?

I'm thinking if this is perhaps related to UDS and the transport protocol. If so, is anyone able to explain what my communication flow should look like in order to receive the full set of response frames?

Thank you.

noradtux commented 4 years ago

If that adapter doesn't handle the ISO-TP protocol you need to send the flow control frame to trigger sending of the rest of the frames.

madshadsen commented 4 years ago

@noradtux Thanks for clarifying, I also figured it was something like that.

My current setup was done with just sending a manual single-shot message into the CAN bus using the program PCAN-View. But I was hoping to use this as an opportunity to better understand the ISO-TP protocol.

I've done some reading on ISO-TP, but I'm a bit unsure what the communication flow should look like to achieve the full output in this case. Can you clarify what the control frame would look like for this case? And if other communication flows would be necessary.

Thanks a lot.

noradtux commented 4 years ago

Basically you send 30 00 00 00 00 00 00 00 (hex) with the same can id used with the original request after receiving the frame that started with 10. That needs to happen within some milliseconds. The other can controller will then send you all pending data without delay (that can be changed by setting some of those 00 to other values. Don't quite remember ...)

See my python implementation https://github.com/noradtux/evnotipi/blob/master/dongle/SocketCAN.py, lines 264 ff.

madshadsen commented 4 years ago

Ok thanks a lot for the input. So if I understand correctly, the flow should be as follows:

7E4   |   03 22 01 01 AA AA AA AA

7EC   |  10 3E 62 01 01 FF F7 E7
(within X ms after this message send the following frame)
7E4   |  30 00 00 00 00 00 00 00

7EC   |  21 FF BC 16 AE 43 08 00
7EC   |  22 00 00 0F CF 09 08 08
7EC   |  23 08 08 09 00 00 0A CE
7EC   |  24 30 CE 4A 00 00 78 00
7EC   |  25 00 15 B2 00 00 12 F4
7EC   |  26 00 00 08 40 00 00 06
7EC   |  27 D1 00 05 F7 06 09 00
7EC   |  28 03 00 00 00 00 03 E8

So in other words, it should theoretically be possible to get the full remaining frames broadcasted by the vehicle if I simply am able to send the flow control frame within X ms after the receival of the 7EC | 10 3E 62 01 01 FF F7 E7 frame, with no other communication dynamics required?

A few extra questions if you have time:

1) Is there a way to know for certain how fast the flow control frame should be sent after the first response frame is received?

2) Also, is the flow control frame always in the format below for this type of operation? Or is it supposed to be dynamic based on the content of the first response frame?

Response_CAN_ID | 30 00 00 00 00 00 00 00

3) Is it necessary to "end" the conversation with some sort of frame - or to send another control frame after a few of the extra response frames are received?

Thanks again.

noradtux commented 4 years ago
  1. No, I don't know.
  2. Please have a look at https://en.wikipedia.org/wiki/ISO-TP
  3. No. By setting bits 0-3 of the first byte to 0 you request all remaining data. You can set a block size and a frame-delay.
VishalAhuja1989 commented 4 years ago

Basically you send 30 00 00 00 00 00 00 00 (hex) with the same can id used with the original request after receiving the frame that started with 10. That needs to happen within some milliseconds. The other can controller will then send you all pending data without delay (that can be changed by setting some of those 00 to other values. Don't quite remember ...)

See my python implementation https://github.com/noradtux/evnotipi/blob/master/dongle/SocketCAN.py, lines 264 ff.

Hi Nora, Could not find the python code which you mentioned here, can you plz help..