Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
madshadsen opened this issue Jun 17, 2020 · 6 comments
Open

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

madshadsen opened this issue Jun 17, 2020 · 6 comments

Comments

@madshadsen
Copy link

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
Copy link

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
Copy link
Author

@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
Copy link

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
Copy link
Author

madshadsen commented Jun 18, 2020

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
  1. 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
Copy link

  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
Copy link

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..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants