Several parameters related to timing are given by the specification, some others are beyond our influence. To understand how a request works, lets consider the case the 0x0D PID is requested, this represents the vehicle's speed. Requesting the value of a PID consists of two phases, the first is the request phase the second the response.
In the first phase, the bytes necessary for the request are written on the Tx line, according to the specification there should be a 5 millisecond delay between each symbol. It is possible that the ECU still discerns the bytes correctly when this delay is lowered.
The transceiver IC puts the waveform seen on the Tx line on the K-line. However, a echo of this waveform is also provided as output of the transceiver IC and is seen on the Rx of the serial port.
Because this is not part of the response we have to deal with this echo. This is done by using the readBytes method to read the same number of bytes as were sent during the request. Because the serial port used should contain a hardware buffer, very little time is spent in this readBytes call, as all the bytes from the echo should already be available and the function returns when the requested number of bytes has been read.
After the echo has been read, the waiting game begins as we wait for the ECU to answer. According to the specification this is atleast 30 milliseconds, this duration which is the major part of a request duration is something that cannot be influenced. Because this number is known beforehand the readBytes method can be used.
According to the specification the ECU should also pause between sending the bytes, but this is not necessarily the case. The number of bytes to be received for each phase is known beforehand so the readBytes method can be used; it ensures that we stop reading immediately after the expected amount has been read.
There is no delay parameter for the minimum duration between two requests, that is up to the user. The library supports reading diagnostic trouble codes from the ECU the ones associated to the malfunction indicator light.
This was made possible with extensive testing by Produmann , under issue 9. To accomodate this a method is implemented that handles a variable length request to the ECU. In this variable length response, each trouble code is represented by two bytes. These two bytes can then be retrieved from the buffer and converted into a human readable trouble code with letter and 4 digits for example P , which can then be printed to the serial port.
An example on how to read the diagnostic trouble codes is available, see readDTC. The following trouble-code related modes are supported: Reading stored trouble codes mode 0x03 , clearing trouble codes mode 0x04 and reading pending trouble codes mode 0x The ISO protocol uses the same physical layer as , the support for this protocol was developed under issue The provided functionality should be the same regardless of the protocol used.
Skip to content. Star MIT License. Branches Tags. Could not load branches. Could not load tags. The checksum is the sum of the bytes with mod See this link for a list of PIDs:. The response is almost similar. The data field reflects actual data which will probably change every request.
The following are example responses with 0x00 as data which is verhicle speed 0. The verhicle will supply the circuit with 12 volt via pins 5 and 16 of the ODB2 connector. The voltage regulator will create 5 volt out of this for the microcontroller and LCD. K-line signals of pin 7 will be converted to appropriate levels via an interface of resistors and a transistor. On port RC7 you can connect a buzzer optional. When the engine coolant temperature PID 0x05 exceeds the 93 degrees this port will be enabled.
A routine for displaying and clearing stored diagnostic trouble codes is included. This can be initiated by pressing the switch for 2 seconds. This routine is untested and will most probably not work. Feel free to try if you have a car with trouble codes.
The 5 baud init is also called "slow init". There is also a "fast init". The fast init does not use the 5 baud init as descibed above but starts directly at A StartCommunication request 0xc1, 0x33, 0xf1, 0x81, 0x66 must be submitted prior submitting requests.
I don't have a car which supports this fast init so maybe someone can help including it in this code to help others. For programming the 16f microcontroller you need a programmer like pickit2 or pickit3. If you are interested but not able to buid yourself just contact me. Maybe I can help with a programmed microcontroller or complete kit.
But none of the c code sources. Otherwise seems interesting project. Tried with Vivaldi and Brave browser the situation is the same. Reply 2 months ago. I was also wondering. Using my phone and chrome. When I went down to see more questions, suddenly the page reloaded and showed the code.
Man thanks for your step to step explanation, I was having a lot of problems to communicate with the car and your pictures with the data transfer help me to figure it out what I was doing wrong! Thank you very much! Regards from Brazil! Reply 5 months ago. Good Morning! A good article and good work. I have a question about initialization and about the bytes sent. In this case I must perform the initialization sending the byte 0x33 at 5 bits per second correct. The vehicle will respond with byte 0x How should the key byte be inverted in the microcontroller this part of the process I didn't understand.
And in the case of requests, after initialization and only send the byte sequence, for example. Could you clarify these doubts for me. I think you are using Saleae Logic Analyzer software. Can you tell me how you were able to decode the K-Line frames since there is no built-in decoder for that in Saleae logic.
In fact I couldn't find any decoder anywhere can you show me how you did that so I can debug mine. Question 1 year ago. Hello RichardvdK, I've reproduced your example and it worked great, thanks so much for sharing this awesome work. I'm trying to get a scope that can be used to assist in development for ISO and I noticed it looked like you were using one for your project. Would you be able to share what equipment you used that was able to decode ISO so well?
Reply 1 year ago. In case anyone else is stuck, just use a regular scope with uart decoding and set the idle level to high rather than the standard low. That'll get ya going. Question 1 year ago on Step 3. Hey Richard I did this project and Works as It expected. I am not able to attach pictures here. I did not understand a part of code when the PWM is turned on. Could you explain that part of code. Thanks for advance! Answer 1 year ago. Hi Diego, thanks for asking.
It is about lines till Here a while loop is used to have smooth transition between different values of Calculated Engine Load. So if it goes from e. Not from 50 to in one go. Question 2 years ago on Step 5. Question 2 years ago. Reply 3 years ago. Hi, since there are about hundreds of different protocol flavours around it will most probably not work. It needs investigation. Probably it will work after making some small changes in timing and responses. Question 3 years ago.
0コメント