Interest in AVR OBDII Scanner?

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I wanted to find out if anyone has any interest in working on an AVR OBDII scan tool? I'm currently working on another project (writing new firmware for the Fantazein Clock to rx data over serial port to display new/stock/weather tickers :idea: ) but I'm thinking of trying to do this when I get done.
I'm really referring to the straight up OBDII from cars from 96 (some before 96, like mine)and later. I know there is a CAN version of OBD on some late model cars, but this isn't what I'm referring to. OBDII uses PWM, if I remember correctly, so reading that is the trick. As far as I know, most Atmel chips can do PWM, no?
Well, I wanted to start a thread and see if anyone might have any interest in it. The check engine light in my car came on the other day and I went and bought the Actron AutoScanner ($150 :shock:) and when I opened it up there wasn't much to it. Just a few buttons and an LCD. I'll probably return it since it's too expensive and I'd like to make my own. Of course, I'll try to gather some info on it first. ;)

Thanks,
Jason

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ELM sells a pic or something that converts j1850 or whatever to rs232... $25 chip.... also check out simtel engineering section for a complete obdii program....

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There have been several past threads. Do a Forum search on "obd obdii obd2"; in particular http://2313.avrfreaks.net/phpBB2...

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My company bought one of the ELM boards and it was a huge disappointment. The management had huge visions of monitoring all the idiot lights and be able to generate vehicle maintenance reports. The I started writing the software and it turns out it just monitors vehicle emission stuff. Wow, you mean I can monitor the throttle position! Oxygen sensor 2A failed, better call in the Marines. My boss' vehichle even had the service engine soon light come on but since it wasn't because of any emission related failure, he had to go to an auto shop to find out why it was on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Depends which manufacturer you wish to communicate with.

For GM 96+ use the Motorola XC68HC58, it does EVERYTHING for you on the J1850 bus side, just an SPI interface to talk to the AVR. No restrictions like the ELM device.

I think OKI make something for FORD cars similar to the HC58.

Not sure what the Japanese use?.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Basically, GM use VPW, Ford use PWM, Chrysler use ISO9141 as do most Japanese and European manufacturers. They are all sorta the same, just different :) All are slightly different methodologies or implementation of PWM encoding.

Using GM's VPW as an example... A logical low short pulse is a "zero", a logical low long pulse is a "one". A logical high short pulse is a "one", a logical high long pulse is a "zero". So, to send a byte of data, there is a voltage transition for every bit - high, low, high, low, high, low ad infinitum. The width of the pulse determines whether it's a 1 or a 0. Just to make things interesting, GM also use two different data-rates. 1x which is 10.4kbps and 4x which is 41.6kbps Some commands and responses work in mode-1 ( 1x ) whereas others require mode-4 ( 4x )

In theory, it wouldn't be that much different to coding a software UART. You would code a basic ODB-II handler that would cope with the various PWM methodolgies and timing modes so that your upper levels thought they were talking to a device like a UART. That probably didn't come out right, but I know what I mean :)

There is a lot of confusing and misleading info on the net and I have not found one site which has a clear and detailed explanation of anything. The ELM chips look okay on the surface but once you know a little about the various OBD systems you will realise that they are very limited in what you can and can't do with them and they are bloody expensive for what they do. Doing embeded work using an AVR, it should be possible to code the basic PWM encoding methods ( GM / Ford / Chrysler ) inside the AVR without to much hassle. The only real issue is in finding out exactly what is what and what is trash.

You should be able to sort out the electrical interface side of it quite easily by looking at the various schematics and other info that you can find on the net. There isn't much to that side of things as it is basically just a 12v to 5v interface which has been made to look more complex than it really is. They do this by using funny terms like K-line, L-line and the like.

The few people who have sorted this out all work quite hard to keep it quite a bit secret and mysterious which leads me to think that there really isn't that much to it. They are doing this so they can gouge people for stuff like the ELM chips and their various scanner interfaces.

This is something I intend to look into quite seriously in the not to distant future. However, at the moment, I've got a product I need to get out the door and being my first AVR project, I've got quite a learning curve ahead of me.

When I do start on this, I will be tacking it from a commercial perspective. Although, being an in-house and self funded thing, I will happily share info with other parties if they can help me. In other words, to me the whole OBD-II thing is just a means to an end. I will need to crack it to get my product out the door but the success or failure of my product does not rely upon keeping the OBD-II stuff secret.

So, Yeah, I'm interested in doing something Jason. I can't see any need to use things like the devices vimfuego2 mentioned. There is no reason why a fully functional converter couldn't be placed in an AVRtiny with some very simple level converters on the outside. If you just wanted an OBD-II to Async-serial interface, that would be all you'd need. If however you wanted to do a project using OBD-II, you could then just port the code to a larger device and do the OBD-II coms and your project inside the same AVR.

Right now though, I'm at step one with the AVR. I'm trying to get a handle on the chips themselves and the architecture, asm/C tools etc. I've been playing with the STK500 for a couple of weeks and my JTAGICE2 should arrive sometime this week. I've started to build some proto-type boards for my first lot of stuff and I've coded a lot of things which will end up being thrown away as I learn they don't work properly. In short, my priorities right now is learning enough about the AVR PWM to dim a LED properly, so I'm a little way off of coding an OBD-II UART :)

Cheers, Brenton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brenton_S15 wrote:

So, Yeah, I'm interested in doing something Jason. I can't see any need to use things like the devices vimfuego2 mentioned.

You WILL once you get right into it, I think this is where chips like the ELM can't deliver.
Reading fault codes and clearing them is one thing, pulling data from the vehicle at full rate is a much different story.
Just read through the data sheet on the XC68HC58 and realise there is ALOT going on at bit level on the VPW bus, it takes care of all that, all the AVR see's is an INT and a full message from the VPW bus, for the $3.00 that they cost you are really making life hard for yourself not using them, oh, and they do all level shifting for you.
If nothing else, read the data sheet on the 68HC58 and then decide if you think you can code all that into the AVR.

Cheers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vimfuego2 wrote:
for the $3.00 that they cost you are really making life hard for yourself not using them, oh, and they do all level shifting for you.
If nothing else, read the data sheet on the 68HC58 ..[]..

Hi Vimfuego2,

At only $3- I'd be mad not to :) Only one little problem. I can't find it anywhere.
Have you got a link ?

Cheers, Brenton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brenton_S15 wrote:

Hi Vimfuego2,

At only $3- I'd be mad not to :) Only one little problem. I can't find it anywhere.
Have you got a link ?

Cheers, Brenton

Ahh, since Motorola / On-Semi changed names AGAIN to Freescale the older data sheets have all gone. PM me your email address and I'll send it (about 700Kb).

Cheers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd be interested in that datsheet as well, would it be OK if I PM you my e-mail address too?

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is some info here

http://www.diy-efi.org/gmecm/ecm...

I think this is the same uC even if its MC not XC
http://www.diy-efi.org/gmecm/ecm...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey,

There are several suppliers with that chip in stock, do a quick search at www.findchips.com for a list of all of them.

If you are looking to make a scan tool, note that there is actually four protocols you need to be concerned with. 1996 and onward use one of three different protocols, and just now the CAN protocol is comming out. Check at http://www.obdii.com/ for some starting information. That chip (68HC58) seems only able to do the VPW method, so it is not going to be a do-all.

if you just want to buy a Scan tool, I just got the one at http://www.ghg.net/dharrison/obd... for someone, seems pretty good! Its got a micro in it to do the OBD-II communications, which communicates to your computer. You can get a fair amount of information out of it, even moreso if you've got a Ford vehicle because it has the extended codes.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the offer vimfuego2, I followed the link provided by Bingo600. I can't find anything on the Freescale site and their search is useless. Do you know it Motorola have anything which handles the other variations ?

c_oflynn, I am aware of both CAN and LIN which are both making inroads into the auto market. Using someone elses scanner would be a bit tough when you're trying to design a product which does something other than just display numbers and have it retail for under $100- :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brenton_S15 wrote:
So, Yeah, I'm interested in doing something Jason. I can't see any need to use things like the devices vimfuego2 mentioned. There is no reason why a fully functional converter couldn't be placed in an AVRtiny with some very simple level converters on the outside. If you just wanted an OBD-II to Async-serial interface, that would be all you'd need. If however you wanted to do a project using OBD-II, you could then just port the code to a larger device and do the OBD-II coms and your project inside the same AVR.

Hey,
That sounds good. I think in a few weeks I'll be looking into this, depending on how my current project goes. I'd be happy to share any information with you. Are you looking at doing just a scanner to read and clear codes, or full data logging? I'm more interested in just the reading/clearing of codes. As an intern at Honda, I worked on some CAN software and OBD was a part of it. Seeing as how that works, and is the future I'm not sure I want to do more than the bare minimum. :D

Thanks to everyone for all the information. It would appear as if I've got a lot of research to do with this. I will probably focus on the ISO9141for the time being seeing as I'm an import kind of guy...no not ricer guy :shock: I'm sure I'll have many more questions when the time comes.

Jason

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn wrote:
if you just want to buy a Scan tool, I just got the one at http://www.ghg.net/dharrison/obd... for someone, seems pretty good! Its got a micro in it to do the OBD-II communications, which communicates to your computer.

I've seen that website and it seems pretty slick, but the price is kind of steep. I don't know, I guess it does a lot more than I'm interested in, but if that's what you are looking for then, I suppose it's a steal. What do you use it for? Diag? Tinkering, etc?

Jason

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Well its for my brother, who uses it for all of the above! I really liked that place because they provide LOTS of info - technical info on OBD-II, Codes, and even the protocol that they use to communicate with their Scan tool!

The USB version just has an Igor-Plug in it.

If you just want the scan codes though it is overkill...

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My car's bus is based on J1850 VPW, actual I use one of the ELM chips :roll: as interface, but I want my own open source interface in an AVR, so here is the idea:

Use an AVR with 16-bit timer @ 1us increment. The bus input connected to INT0. Since the VPW stream is NRZ, use level change trigger for INT0.

The bus is LOW when idle. Now wait for an L->H change at StartOfFrame > INT0 trigger's > start the timer > level change H->L > INT0 trigger's > read timer value > compare value with pulse timing table (SOF >163 and <240 us)
... and so on. For "1" or "0" data bit the pin level and time must be compared.

To send an stream toogle one output pin with times using the 16-bit timer.

Any other idea's or comments :?: