21 Turbo Renault 21 Turbo and Alpine A610 Fuel Computer issue/solution!

[r5gordini]

A bit of background. I have had three fuel computers fail on me in about a year! The problem seems to be the LCD. I suppose it's just unrealistic to expect a 20 year old LCD, let alone one engineered by Renault, to work perfectly!

I got my thinking cap on and came up with the idea of using an Arduino single board computer to replace the Renault computer. After a weekend's work, I have come up with the following. So far I have just got the fuel gauge working. Next bit (mpg, trip, etc.) is a bit harder.

There are several advantages to this method of solving the problem:

1. Modern electronics: easily upgraded and replaced
2: Modern display technology: my solution uses lovely OLED. No backlight required!
3. Flexible: we can program and calibrate it to our needs. Different injectors? No problem. Different wheel diameters? No problem!

For me, a working fuel gauge is a must, which I have got working today. It still needs a bit of calibration. After that, I intend to add (in complexity order):

1. Temperature in degrees celcius!
2. Speed in mph. Average speed
3. Trip distance
4. Mpg
5. Miles left in tank

So how did I do it? Took an old 21 computer, desoldered the connection block:



Soldered it onto some veroboard:



Did some wiring on the verobard to connect up to the Arduino:



Wrote a bit of software to interpret the fuel sender's output. Graphed its resistance, working out an interpolated fuel reading. Used the software I use every day at work. Needs to be calibrated a but better but this is a rough start:



Um... Wired up the power pins and plugged it in!



I am very happy about the result and am excited about the project. It's going to take me a while to get where I want, but I will keep going!



Sent from my HTC One_M8 using Tapatalk

 

[jamesc]

Great work, very useful

...
Wrote a bit of software to interpret the fuel sender's output....

In the same way a lesser man may write - 'made a cup of tea'

 

[Big Steve - Raider]

VERY clever! :ay:

 

[r5gordini]

Yes - I am so fed up with unreliable fuel computers - something's got to be done! There's some other work out there on the 'Net about producing a fuel computer so I'm going to crib that for some of the other functions, but none of them read a fuel sender, so that's the bit I did. The hard bit is going to be bashing the code together for my bit and their bit - they also had the luxury of multiple buttons for different functions, but we only have two buttons - reset and function.
My plan is to encase it in the original fuel computer's box so it becomes a plug and play solution. I will leave a USB lead hanging so I can update the software and calibration, but once it's wired up to the cars sensors, the hardware bit should stay fixed. Oh and I'm going to replace the Arduino development board with a smaller version.
And thank you for your kind comments
I hope there is considerable interest in this in the community!

 

[andybond]

That is a beard project.

I FULLY approve and give it the beard seal of approval.

I am in awe !

 

[Turbjj]

Excellent Work!!!

 

[DaveL485]

I think I want your babies.

We can build this to fix the Adaptronic issue too. I want it.

(Adaptronic issue = when we fit the aftermarket ECU, we lose the fuel signal from the OE ECU, and as it's a complex signal we can't replicate it from the Adaptronic. I think it's one pulse from every 160 grams of fuel or something. We had a thread on it a while ago. With this, we could simply interpret from a signal the Adaptronic could give out )

 

[r5gordini]

Exactly - those were my thoughts too! Do you have any more specs on the number of pulses per wheel revolution/mile/km or similar?
I will continue to work on it as a project in the evenings. Next thing to do is wire it up to the speed sensor and fuel injector signal. And then write or adapt existing interrupt-driven code that can count the speed sensor and fuel injection signals.

I note you only think you want my babies! I'd really prefer to hear that from a woman

 

[DaveL485]

Next thing to do is wire it up to the speed sensor

Thats pretty simple as it's a direct feed of the speedo head, there are two wires off a plastic bit at the top of the speedo as it plugs into the instrument panel. It'll be one pulse per rotation so if you measure pulses at 20 and 40mph say, you can extrapolate the linear pulse line.

Fuel injection: The OE ECU sends a pulse to the trip computer for 160mm³ of fuel. The stock ECU knows the flow rate for standard injectors & the opening times/duration of the injectors and calculates the fuel used then send a pulse for every 160mm³.
So for the OE setup, one pulse = 160mm³ fuel used. If you can program that in and multiply it by a factor of 1, for bigger injectors you can increase the multiplication factor to compensate for the fuel delivery increase.

Adaptronic wise it would be the actual ECU fuel pulse, or something based on that. I'll see what config I can do around it.

 

[DaveL485]

Fuel level wise, the OE computer stabilises the digital reading so it doesnt move around with the fuel sloshing about in the tank by incorporating the flow into the calculation, this might prove to be a pain, so how about for fuel level we stabilise it with something like a 30-second loop with an average of one reading per second for 29 seconds and the 30th second it updates the display... so...

Dim flevel As Integer
Dim x As Integer
Dim TankRead As Integer
flevel = 1
x = 1
Do While x < 30
TankRead = (level reading)
flevel = Average((x / flevel), TankRead)
Application.Wait (Now + TimeValue("0:00:01"))
x = x + 1
Loop
UpdateDisplay flevel '(converted to L or G)

You can see below how it stabilises the reading more and more as it goes down the average loop.


The reason I suggest this is that my computer reads the tank level without stabilisation now that it's lost the ECU feed and I get the raw level reading. It moves around a lot in corners, + and - a gallon or more if i'm booting it. Normal needles are buffered to prevent this, thats why they move slowly....it's dampened to prevent them going up and down with corners.

Excuse my vba scribblings, If i'm interfering just tell me to shove off

 

[r5gordini]

No worries Dave!
It's been a couple of days - I've been busy. Yes, I already have something that averages the reading for the fuel sensor, but it takes a bit too much memory at the moment, so will need some optimising. You only get 2K of global variable storage space! Think I can probably find something more optimal.

I got the speedo sensor code working this evening! I cribbed someone else's code but I wanted to take the minimum possible from it and also to understand it and move it into my codebase. That took some doing! It's interrupt driven - the first interrupt fires when the speedo sensor goes from low to high. Then a timer executes and waits a short while, then the sensor is checked again. At least that is the theory from the existing code. I now have to translate clicks into RPM into speed.

I'm fairly confident I understand the electronics of the speed sensor - it's documented in the manuals for the A610, so I will wire it up, via a zener diode to a digital input on the Arduino. The zener is at 5.1 V so it seems to allow no more than 5V to be sent to the digital input pin. Handy!

The need for the computer is more pressing on the A610 but the 21 is easier to pull apart, so it's that car that I'm using for my test bed. Unfortunately it's not so easy to jack up all the driven wheels as there are 4 of them! I want to jack them up to test the speed sensor! Might as well bung it in and go for a quick spin up the road, although it would be easier to debug in the garage (esp as it's now started raining)!

 

[r5gordini]

Another thought - is it not easier to do a simple mpg calculation by doing distance/fuel used? Since we have a fuel sender, just take the difference between the level at the beginning of the trip and the level now and monitor the amount used, or is it not accurate enough? Should be easy to detect when the fuel tank has been filled. Just save the current value to EEPROM regularly, then if it's significantly higher than that the next time we start, it's obviously been filled up.
I think standard EFI sends a pulse for injector on and injector off, but I might be wrong.

 

[andybond]

I am not sure it could monitor that level of use. Might be too fine ?
Could you sample the flow of the injectors every 100ms - total it up and store it every second , total that every 10 second , then every minute etc.
If you know what flow rate of the injectors are then in theory you should be able to work out how much fuel was used , and how much was in at the start ?

 

[DaveL485]

I think using the ECU fuel feed would be a ballache, and considering the amount of use/relevance the MPG number has now with these being enthusiast cars we can extrapolate it from the level reading without much worry. Do we even need it at all? A 'nice to have', more than anything imo. A digital speedo reading in mph or kmh would also be nice, which we should be able to do right?

MPG wise then, could be as simple as [Distance travelled] / [Fuel used since last reset]. Why would we even need to allow for refuelling?
If Speed = Distance / Time then
Distance = Speed x Time and
Time = Distance / Speed

So if we record (Active meaning ignition on):
Active Time from last reset as a rolling integer
Active Average speed from last reset
Fuel consumed since last reset (On update of fuel level, add something that does
FuelConsumed = (FuelConsumed + (OldLevel - Newlevel)) but only do that if OldLevel > NewLevel. It'll then skip the update for the first loop after a refuel.

We can get distance by Speed x Time.
We then get MPG with Distance/FuelConsumed.

Or something

 

[andybond]

Fuel consumed since last reset (On update of fuel level, add something that does

I am not sure that is accurate enough ?

If you know how many times the injectors pulse and what CC they are pulsing at the time you could work out very accurately what was used ..

 

[r5gordini]

Well... Let's try it and see! If I connect up the sensors correctly, it's only software, so can be changed at any time.
I'm hoping to get a few mins to connect up the speed sensor today.

 

[jamesc]

I am not sure that is accurate enough ?

If you know how many times the injectors pulse and what CC they are pulsing at the time you could work out very accurately what was used ..

I know that is how my Volvo works as the average MPG is miles out after fitting larger injectors...

 

[r5gordini]

Yep - it is the standard way of doing things. I suppose it would be good to have an accurate MPG for the mileage remaining display!
Another thing to work out is how to turn the low fuel light on. It seems the OE computer does that. I'll have to work out whether it's a +ve feed or an earth and then knock something up to turn it on when there's less than a gallon remaining.

 

[andybond]

less than a gallon remaining.

You Sir like living dangerously.

I love the amber gamble game

 

[r5gordini]

Hehe! I can now report that the speed sensor is working! Well, it's working in that I can record the "clicks" of it, but there seem to be a lot more pulses than I expected and my speedo code doesn't work. My function selection code is also broken, but, hey, it's progress! It's "just" software now.
I can use the same principle to read the injector pulses as I used for the speed sensor. When moving to Adaptronic, we will need a different method of calculating fuel flow.