Go Back   EcoModder Forum > EcoModding > Instrumentation > OpenGauge / MPGuino FE computer
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 10-06-2010, 10:08 PM   #1 (permalink)
EcoModding Lurker
 
Join Date: Oct 2010
Location: Chicago
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
: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?

  Reply With Quote
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 10-25-2010, 11:35 AM   #2 (permalink)
OBDuino coder
 
Magister's Avatar
 
Join Date: Jun 2008
Location: Montréal, QC
Posts: 212

Titine - '13 Hyundai Sonata Hybrid
Thanks: 3
Thanked 10 Times in 8 Posts
I tested the ELM327 only with CAN, so for the others headers I didn't know if they worked or not, it seems not
__________________
2013 Hyundai Sonata Hybrid
  Reply With Quote
Old 10-25-2010, 12:10 PM   #3 (permalink)
EcoModding Lurker
 
Join Date: Oct 2010
Location: Chicago
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
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?
  Reply With Quote
Old 10-27-2010, 03:56 PM   #4 (permalink)
OBDuino coder
 
Magister's Avatar
 
Join Date: Jun 2008
Location: Montréal, QC
Posts: 212

Titine - '13 Hyundai Sonata Hybrid
Thanks: 3
Thanked 10 Times in 8 Posts
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!
__________________
2013 Hyundai Sonata Hybrid
  Reply With Quote
Old 10-27-2010, 10:54 PM   #5 (permalink)
EcoModding Lurker
 
Join Date: Oct 2010
Location: Chicago
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
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":

#ifdef ISO_9141
// ISO header
buf[0]=0x68;
buf[1]=0x6A; // 0x68 0x6A is an OBD-II request
buf[2]=0xF1; // our requester’s address (off-board tool)
which is different from what is used in the elm_init version on or about line 1060:
elm_command(str, PSTR("ATDPN\r"));
// str[0] should be 'A' for automatic
// set header to talk directly to ECU#1
if(str[1]=='1') // PWM
elm_command(str, PSTR("ATSHE410F1\r"));
else if(str[1]=='2') // VPW
elm_command(str, PSTR("ATSHA810F1\r"));
else if(str[1]=='3') // ISO 9141
elm_command(str, PSTR("ATSH6C10F1\r"));
else if(str[1]=='6') // CAN 11 bits
elm_command(str, PSTR("ATSH7E0\r"));
else if(str[1]=='7') // CAN 29 bits
elm_command(str, PSTR("ATSHDA10F1\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
Physical address values for modules within vehicles have not been assigned by either ISO 9141 or ISO 14230. This is especially true of modules using either of the 5-baud initialization protocols. Annex A.1 of ISO 14230-2 “Physical Addresses” which states that “Addresses are controlled by vehicle manufacturers” along with the ISO 9141 definition of the how the address byte is constructed. For ISO 14230 fast init addresses, Annex B of the same document states “Addresses...may be the same as used for 5 baud initialization or be in accordance with SAE J2178, Part 1”. Note that SAE J2178 is a standard for J1850 Class B network communications. Accordingly, as with J1850, testers should not ‘expect’ particular vehicle ECU addresses or make assumptions about the role of a vehicle ECU based on its address. For example, engine ECUs commonly use 10 as an address but there are many vehicles that do not use 10 for the engine ECU or may use 10 for another vehicle ECU.

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?
  Reply With Quote
Old 10-29-2010, 10:19 AM   #6 (permalink)
OBDuino coder
 
Magister's Avatar
 
Join Date: Jun 2008
Location: Montréal, QC
Posts: 212

Titine - '13 Hyundai Sonata Hybrid
Thanks: 3
Thanked 10 Times in 8 Posts
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".
__________________
2013 Hyundai Sonata Hybrid
  Reply With Quote
Old 09-07-2011, 04:31 AM   #7 (permalink)
EcoModding Lurker
 
Join Date: Sep 2011
Location: boxmeer
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
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
  Reply With Quote
Old 05-14-2012, 12:53 PM   #8 (permalink)
EcoModding Lurker
 
Join Date: May 2012
Location: Oakville
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
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!

  Reply With Quote
Reply  Post New Thread


Tags
atsh, headers, obduino, ovduino32k, volvo

Thread Tools




Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com