Project: Mpg And Temperaure Gauge

[St Thicket]

As previously seen in the topic: Rav4.2 Milage Computer Information, this is a project where I'll try to make my own gauge for reading fuel consumption and also ambient temperature on my RAV4. I'm not saying that I'll succeed, but I'll try my best, and I've come far in my investigations.

Signals are found in this connector:

As far as I can see, the only signals that are interesting for me are pins 12 to 16, containing temperature, fuel consumption and speed.

On big struggle was to fint the correct male connector to fit the female connector inside vehicle. I called my dealer, but they could not supply other than the female... bummer. But clever as I am :D I just bought a standard stereo converter, and modified it to fit the centerpiece of the connector. This will not make any difference for me, since all of the signals I need are located in the centerpiece.

Before:

After:

(I wish I had a macro lens)

I basically made a 5 mm wide gap on each side of the connector, and it fits perfectly! The converter is made by "soundsystems", an italian company.

When this was done, I insterted 5 leads into the appropriate places, so that I can use the desired signals as mentioned above. I also pulled out the ignition power and ground, so that I can build my prototype and easily test it out. For easy connection, I have used an ordinary 9-pin D-sub connector. This will allow me to connect to the car without having to pull out my stereo every time.

My next plan is to make a test rig with a micro controller, a power supply and a LCD display, so that I can read see what types of signals the car produces. But first I have to figure out how to wire up the interface.

I'm starting to get excited about this whole project :)

aren't you?

I would like to thank all the people who have contributed this far, and I will appreciate any input or feedback that you may have.

[Hoovie]

I'll be watching this thread with interest

One thing which I think you will need to be able to do is a simple calibration as the data coming from those signals seem to be reliably inaccurate (i.e Inaccurate in a predictable way)

[St Thicket]

One thing which I think you will need to be able to do is a simple calibration as the data coming from those signals seem to be reliably inaccurate (i.e Inaccurate in a predictable way)

I can imagine that things aren't exactly as they should...

My biggest challenge is to know how much fuel that is injected when the fuel valve is open. I can't find any information on this anywhere.

If anyone know the diameter of the diesel injector nozzle, please let me know. From this, I can easily calculate the consumption by measuring the time it's open together with the fuel pressure.

[anchorman]

Maybe shcm can answer this as he understands the info taken for the trip computer. I don't know if it can be done very accurately as the SG, viscosity and calorific value of the fuel will vary.

[shcm]

Been discussed a little already - Privately, so it doesn't scare those of a nervous disposition :D.

I don't seem to have the injector mechy specs though.

[St Thicket]

Small update, mostly to save some notes I've made myself. My son loves tearing paper, so it's best to keep these things electronicly.

The D-sub connector I've wired up has this configuration:

1. +12v (ignition)

2. NC

3. NC

4. Injector driver pulse

5. Injector voltage

6. Thermistor

7. Thermistor

8. Speed Pulse

9. Ground

I've ordered a 2x16 character LCD for testing purposes, and some 7-segment displays for the final gauge... Hopefully, my first prototype will be ready in a couple of weeks.

[bitman]

what if we could get our hands on a schema of the standard radio head? there must be some info to use from?

[St Thicket]

what if we could get our hands on a schema of the standard radio head? there must be some info to use from?

The only information I can get from the schematics would be how to wire up the interfaces. There is most likely a microcontroller that processes the signals, and I doubt that the internal program is explained in the schematics.

I received a service manual from tblo163. He sent me the manual for 58802, but this is not very similar to mine. I've looked through it, and I don't think I can use it.

My biggest challenge is to interpret the pulse width, since it will both change width and frequency (due to engine rev and load). I suspect that a mean value of the signal is the simplest way, but would it be accurate enough? I also have to sample the signal fast enough to be able to read the whole signal. This would be challenging, since the engine can have up to 5000 rpm, and 4 ingitions for every rev, which is 20,000 ignitions pr minute, and 333 ignitions pr second. But the nyquist theorem states that a sample frequency must be at least twice the frequensy that is being sampled. Considering this, I must have at least 666 Hz sample frequecy... and since my car is from Hell, that makes perfect sence :D No, seriosly, I think a sample frequency between 1 and 1,5 kHz could be sufficient, since i need more than two samples for each ignition.

[shcm]

My biggest challenge is to interpret the pulse width, since it will both change width and frequency (due to engine rev and load). I suspect that a mean value of the signal is the simplest way, but would it be accurate enough? I also have to sample the signal fast enough to be able to read the whole signal. This would be challenging, since the engine can have up to 5000 rpm, and 4 ingitions for every rev, which is 20,000 ignitions pr minute, and 333 ignitions pr second. But the nyquist theorem states that a sample frequency must be at least twice the frequensy that is being sampled. Considering this, I must have at least 666 Hz sample frequecy... and since my car is from Hell, that makes perfect sence :D No, seriosly, I think a sample frequency between 1 and 1,5 kHz could be sufficient, since i need more than two samples for each ignition.

If you are still planning to use the 16F628A, is there any problem using the capture module (CCP)?

Let the micro hardware take the strain. What about capture TMR1 value on the rising edge, this generates an interrupt. Store the timer value. Change to capture on falling edge. On the next interrupt, store the TMR1 value again. From the two stored TMR1 values you have the pulse width to 16 bits of precision.

Think there should be enough time between interrupts to do the calcs. Have I forgotten something that might be a problem?

The CCP on the 16F628 is a bit crude, but good enough. Some of the higher end micros for automotive will capture on both falling and rising edges, which would make this easier.

Think you may have lost many people when you mentioned Nyquist :D, but I also predict a lot of :yawn: from my comments above :D

Now, should we have mentioned Shannon as well .............?

Cheers

[St Thicket]

If you are still planning to use the 16F628A, is there any problem using the capture module (CCP)?

You are right! Why not? I actually thought about it during lunch break today, and now you convinced me that this is the right way

I plan to use the 18F4550 or 18F2550 (datasheet download), mostly because I already have a couple of each. It might be extravagant, but I'd like to use what I have. I think the 2550 is the most likely, due to its small size and the fact that I do not need many I/Os.

Now, should we have mentioned Shannon as well .............?

Well, without him, we might not even talk about uCs, would we?

[shcm]

Opps, forgot you said it would be the 2550. Also forgot, you'll probably want to do CCP with two pins (injector & vehicle speed)............and luckily the 2550 has two CCP modules