Open madshadsen opened 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.
@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.
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.
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.
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..
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
Observed response
Expected response (based on the BMS sheet in the Google sheet)
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.