vortmax

I had an idea that I believe to be very possible, but don't have an idea about where to start.

In my truck (dodge dakota), there is a spot in the center console in the ceiling for a factory trip computer. The factory module interacts directly with the PCM via the PCI bus to get the info that it displays (outside temp, mileage, ect).

I would like to take a simple 2 line character LCD screen and a PIC micro controller and build my own computer that can read off the PCI bus, but display what I want it to.

My big goal for this project is to have an overhead computer that has similar functionality to the factory trip computer (read the parameters sent to the stock module), as well as display other tuning parameters that I choose and be able to catch a CEL and display it on the fly (if a code pops while driving, the display pops up the code number, the code description, and the reading coming off of the sensor in question).

So, can anyone with experience hacking the pci bus on a dodge point me in the right direction (or at least tell me that this isn't going to be ridiculously hard).

MP3Car.com

 

Moysie

Hi mate,

Ok.......Im not too sure exactly what you know about any parts of the project, so i appologise if i offend you by going through some of the basics. If on the other hand i go over something which you dont quite understand, let me know and i'll try my best to help you out.

Ok first thing is first, Im not totaly clued up on all the details of dodge's diagnostic/obd compatibility. Do you know if your dodge is OBD/ OBDII compliant?

If it is OBD/ OBDII compliant then you shall have an diagnostics socket somewhere within the vehicle. Usualy under the dash, not too sure about dodge (check your manual)
Then for starters you can purchase and hook-up a diagnostic "scantool" such as Elm 327or OBDlink by scantool.net
The scantool plugs into the OBD diagnostics socket on your vehicle and links to a computer. The computer sends commands to the scantool which will read the parapmeters of the enigine e.g. RPM, engine load etc.
This would enable you to complete the In-car computer part of your question where you can read the vehicle parapmeters

As for the PIC, you would have to write an application program for the computer to send commands to the LCD via the PIC. One of the programs i have used for this type of project is visual basic by microsoft (Express version FREE to download from microsoft). It is fairly simple to use.

Once the computer can send commands to the PIC, the PIC has to be able interpret and action these comands as you require (I.E. Send codes to the LCD) You would have to write a program for the PIC.

You will also need to know how to connect all the electronic components together to function correctly. The PIC i have used is the PICAXE from www.rev-ed.co.uk/picaxe/
They provide great datasheets on all the programming commands, Input/output components and how they are conected etc.

I certainly would not say this was a very easy project. It would certainly be achievable but time consuming. There is probably a few things that you would have to learn about to carry out this project.

Let me know what you think about what i have writen (good or bad), if there is any questions let me know and i'll try my best to help you out.

Regards Mike

vortmax

thanks Michael,

I have decent experience in software programming, and I'm conversational in electronics, so the technical side of the project won't be too much of a stretch.

I've actually done some digging since I posted this and it looks like much of the development work has been done. There is a project called MPGuino that is software for the Arduino platform, which is essentially a multi-channel DAC with a microcontroller. The only difference is that the code is designed to use an ELM chip to perform the translation from OBDII to something legible. It has all of the routines needed to write to a multi-line LCD and to interact (read and write) with the PCM over various protocols. The downside is that I'm limited to what parameters the ELM chip can read, and since I won't be sniffing the bus, I won't be able to capture codes on the fly, but it makes the build easier. Besides, the raw protocol seems to be locked up fairly well (without buying it), so trying to figure out which headers to watch for in the raw data stream may be an exercise in futility anyway.

MP3Car.com