:turtle: OBDuino WORKS! headers needed to be changed
I looked and I hope this is the right way to be posting this:
I have a Sept. 1995 Volvo 850 turbo with 80,000 miles. (Sept 1995 ->1996 model year => OBD II variant ISO 9141-2) I tried to build my own with a proper ELM327, failed miserably probobly because I wasn't properly grounding/+5ving the pins for the unused protocals. I came into a prebuilt circuit on Ebay for $25. It still didn't work. After futzing around I determined that the problem was in the 'ELM_INIT()' function and changing at '10F1' to a '6AF1' fixed the problem. after the do while loop, after the 'ATDPN' command, the ATSH 6810F1 command for Protocol 3 (ISO 9141-2) was causing problems. After this command I would get 'NO DATA' from all subsequent commands. First I tried 'ATSH 686AF1' instead of 'NO DATA' I started getting responses from 2 different computers in my old car which confused the OBDuino. Eventually I found that 'ATSH 686AF0' was the magic phrase that worked. I still don't really understand why this is the correct header or if this is the correct header for cars other than mine on the ISO 9141-2 variant, but I wanted to share the change I needed so that if other people are struggling with this that they investigate the headers. I wonder if most of the development on the ELM portion of the code is related to the CAN protocol and if the ISO 9141-2 portion of the ELM init is largely untested? Have others had luck with the default 'Set Header' (ATSH) command in the code base? |
I tested the ELM327 only with CAN, so for the others headers I didn't know if they worked or not, it seems not :)
|
thanks
That was what I suspected. That the elm was mostly being used by people with CAN protocols and the other protocols might be less tested.
I would recommend changing the header value for ISO 9141-2 in the default code base, but I really am not 100% sure the one that worked for my car works for others. Is there any way you can find a friend with an older car to test? |
686AF0 will work, as well as 686AF1 for instance.
68 is a functionnal request 6A is functionnal code to request info F1 is our requesters's address. More than one ECU could answer to this message, but the ELM is filtering them I guess. You should be able to talk directly to the right ECU with a physical addressing 6C10F1 6C is physical addressing node to node 10 is the ECU F1 is our address Note easy to find info on the net about this, I hope I got it right! |
maybe.
based my experience with my particular car, for my Volvo 850 manufactured in Sept. 1995, ATSH 686AF0 worked. ATSH 686AF1 did not. AT 6C10F1 did not. Other people's millage may vary for other cars.
part of what put me onto this is if you examine the non-ELM portion of obduino32k on or about lines 1146-1151 you can see that they use "68 6A F1": which is different from what is used in the elm_init version on or about line 1060: elm_command(str, PSTR("ATDPN\r"));Also I searched and found this article which may shed some more authoritative light on the issue, I think on some protocols developed after ISO 9141-2 these things were more standardized: (I'm too new to post a link, so you'll need to copy/edit/paste:) http colon //www dot obdclearinghouse dot com/index.php?body=get_file&id=1343 Address Bytes Based on the fact that different cars may require different header values, perhaps rather than 'if ISO-9141 then XX XX XX' we want to do something like: 'if ISO-9141 then try xx xx xx. Then test, if success then proceed, else test failed, then try xx xx xx, if success then proceed ... we could start with the most common 'right answer' and work our way onto more obscure ones. I think, Magister, you are correct that 6C10F1 is likely to be the most common correct answer. I believe that 686AF1 is the 2nd most common correct answer. I found that in my case 686AF0 was the correct answer. I will attempt to write a version of the code that does this testing (should be pretty easy) However, once I do that, how would I go about getting that change accepted into the trunk version, or even tested by other people on other cars first? |
Strange that F0 works for you but not F1, as it's the "source address" in the packet so the ECU should answer back to the sender, anyway, not easy to find info on header...
If you modify the code, you can test it locally, and by after I can include it in the repository in "google code". |
Hello,
I'm new to the forum from the Netherlands. I have a question about the header: connected ELM327 to my Jaguar and with header 6a 6b f1 I receive the physical address of the ECU in the response header $11. Changed the header to 6c 11 f1, because i need mode $11: reset ECU or TCM. But with header 6c 11 f1 I get NO DATA. In J1850 it says, that I should get the same response with functionally or physically addressing. 6a 6b f1 09 02 works and give VIN 6c 11 f1 09 02 NO DATA What am I doing wrong? Greetings from the Netherlands. Peter |
Hi,
I'm also new to obduino. Just built it using a 16MHz ATMega 328 arduino and the MC33290 chip. I got the code uploaded OK in Arduino 1.0 (v198), plugged it in to my OBDII and got my 02 Civic to connect via 14230_slow but that's all it will do. No data are displayed, it either goes to the alarm screen (if enabled) or to the main screen with the values but shows no values for anything. The Rx LED is not flashing. Is there anything I'm missing here? I re-checked all my soldering and it seems just fine. How can the obduino connect and then not get any data? Do I need to reset some of the byte delays etc? If anyone has any suggestions or has made this work on an 02 civic, pls let me know! Thanks! |
All times are GMT -4. The time now is 06:35 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com