Hey guys! I just had a quick question about the OBDII project. I've recreated it and made very slight modifications to the code (ie: left out the km to mph conversion and the C to F conversion since I'm Candanadian) but it only semi-works. When I plug the unit in it displays the "Waiting..." message and when I turn my car on it displays the temp, rpm, speed, etc just as it should BUT it doesn't refresh/update this info. It just displays the initial values. I have been attempting to solve this problem myself, but looking in the main program the function calls are all within the while(1) loop so it would seem to me that it should keep refreshing. The only thing I happened to notice is that there is some commented out code in the source code:

SIGNAL(SIG_PIN_CHANGE1) { ......blah blah cut a bunch of code here..... // restart timer and clear match flag (for next time) //if((TIFR1 & (1<<OCF1A)) != 0) // TIFR1 |= (1<<OCF1A); ......

I'm not sure if I just need to uncomment this, I didn't want to try it since I'm uber-paranoid about my car's computer lol. Admittedly my uC skills aren't the greatest (this is actually only my 2nd uC project) but I was wondering if there was something obvious I'm doing wrong? I can post the full source code I'm trying to use if that'll help? But it's basically the exact same, I just commented out a few divisions for unit conversions. I'm not sure if your code is working as intended and I'm just slow, or if it's supposed to be constantly updating and I'm just slow :) Please help so my car can has cheeseburger! :P Thanks!

Paul L.

...uhhh, I just realized it might be important to point out that I'm trying this on a 2005 GMC Jimmy, and I did make sure it uses VPW before attempting this.

Hi decept905,

Admittedly, debugging the OBDII project was pretty nasty. The fact that you are getting one reading is promising, and points to the fact that there is probably something wrong with the timings. If you are on windows, try downloading the latest version of [WinAVR] (http://sourceforge.net/project/showfiles.php?group_id=68108&package_id=66543) The version that shipped with the kit did some weird things to the timings (gave me quite a headache when I was developing the LED Heart). Let me know if that fixes anything. If not go ahead and post your code, maybe us or someone else can find whats up.

Humberto

Actually, the box I do my uC dev on is a linux machine and I just use gedit and GCC. I'll go log in on that box in a bit and post the code I'm using.

Ok so this bulletin board neeing 4 spaces before each source code line is officially terribad when you're trying to paste a huge program. I've dumped it online instead. You can grab it here

All of the code is directly from the site except the changes I made which are located in "main" and within the while(1) loop. Any help would be greatly appreciated. I'm going to try a few more things on this end and see what I can come up with.

Update: I attempted another test. Again, it reads correctly when the unit is first powered on. If I'm driving it'll pull up the proper speed, temp, rpm, etc. If my roommate turns it off/on it'll update as I drive. If he doesn't, it just stays there without updating. Here's the strange thing I noticed. Once the vehicle is powered off the speed and rpm go to zero while the temp continues to update (although REAL slowly... I'd say like 5 secs or so between updates). I'm just wondering, were any modifications made to either delay.c or uart.c that would adjust prescalers or something to work with this project? I had heavily modified the files for a past project so I simply copied my "libnerdkits" folder from the CD back over my modified ones to make sure everything was back the way it was when I first got the kit.

Another update: So I downloaded the newest version of WinAVR to try and compile it through there. This time I used unmodified source code directly from the site and programmed the uC. I get the exact same result. Not sure if anybody has any idea as to what some possible causes are, but I think I'm going to borrow my roommate's logic analyzer and try to see all of the data that's being sent/received. It's going to suck b/c it doesn't support VPW so I'm going to have to manually decode each transmission but it should give me an idea of what's going on based on the timing.

Thread Necromancy for the win! :D Ok, so I've been working with other controllers and projects in my spare time and at work. I've recently written some programs to get CAN communication working between nodes on the AT90CAN32 chips and I experienced a problem similar to my original problem in this thread (OBDII reader gets 1 value, then craps out and does nothing for a while... updates sporadically). My problem with the CAN controllers was just that I was an idiot and forgot to set the clock fuse bits to the same settings which caused timing problems. I was just wondering if you guys could post the fuse settings that were used for this project so that I can make sure mine are all set properly? This is basically the last thing I can think to check before I abandon this and just start from scratch. Thanks!

Hi dcept905,

The fuse bit settings on the ATmega168 we used were identical to those we ship every chip with -- take a look at the "bootloader/fuses_mike.txt" file in your NerdKits code folder for a full listing and explanation. But since these should be the same as the chip you're using, I doubt this would be a problem.

As Humberto mentioned earlier, we had a lot of trouble with the timing on this OBDII system, and I do remember a point at which we would only get one reading and then sporadic updates. Can you take a look at the two updates inside the read_ID(...) function -- one delay_us(100) and one delay_ms(30) (currently commented out) and try experimenting with those values? In particular, try uncommenting the delay_ms(30) and let me know if that changes things.

Mike

Cool, thx I'll give it a shot when I get some time. Somewhat related, here's a video of a CAN version of this that my friend and I made using an AT90CAN32 chip. It's so much easier when the manufacturer doesn't use stupid VPW :P

http://www.vimeo.com/5341030

Gentlemen,

Decision made, this is a project worth undertaking.

I noticed in the nerdkits store, that there is no specific kit nor did I find a schematic.

Mike and Humberto, could you put one together, kit that is? With the small proto board?

Tell me the price and we'll do some more commerce. I want to order a few more mcus as well.

I'm going to put it on my 1996 Ford F150 4x4 with the 302c.i. engine.

Any hints on what signal version their OBDII computer uses? I have a diagnostics handheld, and it works, but this looks like a lot of fun.

Thanks for any help.

Hi Mike,

The OBDii project was a very fun project to do, with a very cool result, but like we mentioned before it was pretty hard and not with out its frustrating moments. We do not have the time or resources to put a "kit" for this together right now. Besides, if we made a kit for it I would ruin all the fun of figuring it out yourself =).

As a step in the right direction I believe most Ford cars use the PWM OBDii protocol. If I remember correctly it is a lot like the VPW protocol that we already implemented.

Let us know how your project gets along!

Humberto

Ok Humberto, fair enough.

I'll get the parts from the store.

Thanks!

I'll pass this along for referencing how to find which protocol your car may use:

http://www.scantool.net/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=3

http://www.scantool.net/images/diagrams/j1962f_pinout.gif

Hey Mike,

I'm not sure if you're still working on this or not, but there are several options that will save you a whole lot of time over doing all of the low-level protocol work yourself. First off, there's the ELM327 chip (google it) which does all of the heavy lifting for you and has a simple interface. For newer vehicles that use the CAN protocol you can use specialized Atmels like the AT90CAN32. I've done a few projects with these (video: http://www.vimeo.com/5341030) and they work great. I do plan on getting back to a low-level VPW project in the future just to go through the whole process myself, but as it stands I just have too much on the go for the time investment it would take. Best of luck with your projects!

Cheers!

Paul L.

http://killerprojects.wordpress.com

Thanks!

Yeah, I'm still on it.

I want to include gas mileage.

I will check all of that out.