search

jacobschaer / python-doipclient

Pure Python ISO 13400 Client
MIT License
151 stars 50 forks source link

help me about the DIDpayload #23

Closed pixiufighting closed 1 year ago

pixiufighting commented 1 year ago

I can't find why the user_data change ? and I want to know how to change my code? df5968a25fa3aa48c51f98dabf10f29

pixiufighting commented 1 year ago

this is my code,and use the python-udsoncan. image

jacobschaer commented 1 year ago

Your DIDCodec says f190 is a 15 byte ASCII string. According to your log, the ecu responded with an incomplete DID response. udsconcan kept polling hoping to find the rest of the bytes, but the ECU never sent more. Hence the two timeouts.

I believe udsoncan and doipclient are behaving correctly and your ecu is wrong or the DID definition is wrong

pixiufighting commented 1 year ago

I don't think so. I recheck this bug,and find the requestid"0x22" don't struck.back to use,maybe this is a question about udsoncanCodeC.I'll try to change my way. Thankyou .

pixiufighting commented 1 year ago

this question maybe is the request always sends the b'"' instead of "\x22". I don't know how to solve it. Could you give me a hand? Thank you.

jacobschaer commented 1 year ago

[hex(ord(x)) for x in b'"\xf1\x90'] => ['0x22', '0xf1', 0x90']

The ECU should respond with DiagnosticMessagePositiveAcknowledgement followed by DiagnosticMessage with the user_data set to: 0x62 0xf1 0x90 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

Where xx's are the 15 bytes of your DID

The request is fine your ECU just isn't responding. If you know this works in a prior revision of the doipclient, we can compare. You can use wireshark to confirm if the ECU is just responding uncharacteristically late.

pixiufighting commented 1 year ago

Thank you for your help, I solve the problem with change the session's P2 time and receive the data correctly. Thankyou!!!!!!!!!