ISO 14230-2 PDF

Include cancelled standards. Select the first category of products searched and follow the instructions. Road vehicles. Diagnostic systems. Keyword protocol

Author:Sharg Digal
Language:English (Spanish)
Published (Last):17 September 2009
PDF File Size:9.12 Mb
ePub File Size:1.56 Mb
Price:Free* [*Free Regsitration Required]

GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together. Have a question about this project?

Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Already on GitHub? Sign in to your account. First I have to tell your library makes it easy. So now the questions. I don't have one of the ICs readily available they are order be about a week to get but I found another circuit that is floating around out there on the web, see attached:. In looking through the lib I know that it can't really be used directly to drive the circuit.

But if I wanted to use this circuit instead of the chip I would have to change several functions. Any suggestions? You shouldn't have to change anything, for the library it doesn't matter what type of transceiver chip or circuit is used.

As long as the Tx and Rx pins both support digitalWrite and can function as a Serial port at baud it should all just work. That being said, the schematic you have it a bit problematic, since the K-line is a 12v data line, it is connected to the Rx pin on your microcontroller through just a 10k resistor. That means that there's still 12v connected to your microcontroller, although at low current, it will likely exceed the microcontroller's maximum rating.

At the very minimum I would use a voltage divider to drop the K-line from 12v to your microcontrollers level. The bus is a low speed one, so you can get away with a simple voltage divider to drop the voltage, I also used a voltage divider to record the logic analyzer traces.

Okay, remember that that is untested code, see 5. The branch contains quite some debugging statements intended to diagnose problem, please report back on your findings and output from those. If it works I'd love to hear about it because I can then merge it into the master branch.

If it doesn't work, please also get back with your findings, we may be able to fix the issues you encounter by inspecting the code and output. What microcontroller are you intending to use? Was looking at the code a little closer after I posted actually didn't see anything I needed to change so not planning on any changes.

I using a Teensy 3. Thanks for the explanation - not very good with circuits as you can tell, that's why I posted the schematic : I will try a simple voltage divider and give it a try tomorrow.

Its a little late here now to try it. Do I still need the rest of the circuit? Actually probably not. Just looked at the other circuit I found:.

I will definitely get back to you on the results of my testing. Like I said I have one of chips coming and should be here next week so at least I am using the same circuit as you have. If it works with a simple voltage divider I will let you know as well. Just looked at the other circuit I found. Looks much better, that's a voltage divider that drops 12v to 4. I'd make it drop to 3. But yeah, I think this should work. Look forward to hearing about your findings. I tried the circuit this morning but no luck.

The following is what showed on the serial monitor:. Going to do two things this weekend: 1 rewire the circuit and 2 bring out my multimeter with me to the car to see what I am getting when connected.

I tried that too but same results. To be honest, would rather used that rather than the voltage divider, but I can't resist. From what I was reading that seems to be what my car is using Hyundai Sonata I did find another circuit on line that I thought you might find interesting.

Two quick comments, please also try the normal initialisation, some cars respond to both initialisations. Also, I don't quite remember of the top of my head if the actual protocol for KWP is the same as for , we may have to do some more work. Secondly, because you have a working OBDlink on hand, it may be helpful to test the Rx side of your circuitry by trying to listen to the working OBD reader you have while it does communication with the bus.

Not only will it help verify the Rx side of your circuit, but it will also provide us with information on how we should be communicating with the bus. A small program that just blocks on Serial3.

Testing the Tx side of your circuit should be fairly straightforward, just check if the K-line goes low if you set the teensy pin low. Using a splitter odb cable I attached the teensy to one side and the odblink to the other and just using serial3. Using a different OS is likely not going to make a difference. If you are unable to sniff the data, it sounds like the interface circuitry doesn't work as it should.

Maybe it always pulls the bus low? You may have to remove the pullup to 12v from your circuit, if another device on the K-line provides the pullup. Though I doubt this would be as impactful as losing the connection.

For the heck of it since I had finished putting the third circuit together I finally got it to read the k-line. While I don't think the circuit is right it finally not only wrote the init but it got a message back. Most of the time it was all zeros since init was not successful but periodically it would return:. Nothing new yet.

Back again. I finally got the sn65 chip. Wired it up and gave it a test and no go. Pretty sure the wiring is correct.

Did a bench test of voltages. First thoughts, did you ensure the EN pin on the Sn65 is pulled high and that nwake is connected to ground? About 1. K line should idle at 12v and when active is should go to ground. Setting Tx to high should make the Kline ground, I thought the sn65 had some timeout mechanism in case the mcu locks up or something, it may not hold it at ground indefinitely.

If K-line does not idle at 12v, you need the pullup R1 in the readme. If it doesn't go to ground it may already be pulled up quite a lot, you may want to remove R1 if you had it. Though I'm pretty sure the Sn65 chip can sink a sufficient amount, even with two pullups. Just connect the K-line add no resistors to the Sn65 and hook the Sn65 up to the serial port of your teensy.

Initialiser the serial port at a baudrate of and try to listen in. After your last set of comments rechecked the wiring and had one issue. Also forgot to change something back in the sketch. Anyway I did get a response back over the K-line after the initialization message was sent:. Your read8 function is looking at element 5 which would correspond to one of the key bytes. Shouldn't it be buffer[4] instead of buffer[5]?

Then it would be success since is c1. The bytes after R: are the raw bytes as read. Checksum is addition of all bytes before the checksum. We expected one byte too many, it is correct if we discard the last 0 byte:. From this webpage I get that the length byte may be omitted in case the format byte specifies the length. So in that care the length byte from your table drops out, and we would indeed see on position 4.

So, that's pretty exciting, the physical layer is confirmed good and the KWP init may even be working. We need to fix the incorrect expected response length, either by changing the 7 into a 6 here or by rebasing the branch and using the variable length response method I added for the DTC support. Alternatively we could write a KWP request that actually handles the length byte correctly and reads that from the first byte, that would be the ideal situation. Shouldn't be too hard to do it properly, I'll likely take a stab at it.

Do we know whether the protocol after the initialisation is identical to ? Or are the requests a different format than the obd ones? Best way to figure this out is probably to listen in on the working OBD device you have. Or just assuming it's identical and giving it a go. In 6be33b3 I've done the following:. Decided to just give it a go until we get past initialization.

Results were the same for some reason it still shows initialization success: 0 and just keeps looping. Response is the same. Going to add some more debug statements but just wanted to post this for now. Update; Added some debugging statements to your readKWP function and think the problem might be in the checksum:.


ISO 14230-2:2013


1N5818 PDF

AFNOR Editions Online Store






Related Articles