The MGF Register Forums

Hello,

one of my projects "far down the line" is at some point to create a trip computer for the MGF which essentially displays fuel consumption, fuel range and speed data, maybe along with coolant temperature and other things. This could be done fairly simply using the Arduino platform with an Atmel Atmega chip programmed in C that can read and process analog and digital sensor readings and display them on a matrix display.

So far I've measured the fuel gauge with a multimeter, which shows a resistance of about 10 ohms when the petrol tank is completely full and about 120 ohms when it's completely empty. That is already very useful information. What other "raw data" like that is present in the MGF's electric architecture that could be tapped into for a project like this? Is there any way you can get a momentary fuel consumption reading from the ECU, which could be useful in calculating range data? And is it possible to obtain a speed reading from the ECU if you've got an MkI with the analog instrument cluster?

Again, this is one of my not-so-near-term projects, but I have started tentatively gathering ideas for it.

What a good idea

Nice one! But you'll meet a lot of unexpected issues that are hard to solve.
For the speedo:
In my Mk1 F I prepared a connection for a trip master. There is a part available that you mount in between two parts of the mechanical speedo cable and has connections for wiring it up to the tripmaster.

Found it in the next picture on the Dutch specialists website to wire up a Brantz to the speedo cable

http://www.handawebshop.eu/Webwinkel-Pr ... ate=dialog

It doesn't come cheap at € 45,- without counterparts.

Interesting project - I've considered going from MEMS 2.0 to MEMS 3 just to get the same info (and so I can remap )

There is a feed to the EPAS that gives a digital speed related output, I used it for the cruise control on the mk1, IIRC it is a white/orange trace wire and can be found in the loom on the O/S of the car. Have a search for cruise control fitting guides (there is one on the t bar - link below, or possible .org, there might be others).

Keep us informed, I'm sure lots of folks will find this interesting.

Well the programming side of it will be a piece of cake in relative terms, the Atmel Atmega328 that sits on the Arduino Uno board (see here: https://www.arduino.cc/en/Main/arduinoBoardUno) was specifically designed to read analog and digital input that can be fed directly through one of its input pins, and do operations of varying degrees of complexity with it which can then be passed on using one of the chip's output pins. Atmega chip clones have even been used by carmakers themselves for this very purpose, to read, check and influence electronic data in a modern car.

For those of you who are familiar with programming, this is how it basically works with the Arduino/Atmel:

https://www.arduino.cc/en/Tutorial/TFTDisplayText

There is a whole Arduino "scene" and plenty of auxiliary hardware you can use for your own projects, and I think the latest is that they've now got TFT displays the size of a stamp that are capable of coloured pictograms which you can design yourself (might even come in handy for illustrated "open door warnings" that you get in more upmarket cars today ).


The bigger worry will be obtaining the proper input data, as I said. Fuel range, for example, is calculated in most cars with a factory trip computer by calculating your actual fuel consumption over the last 20 miles or so and extrapolating that value into the future. The fuel gauge itself/on its own is too unreliable even in most modern cars to produce meaningful range information, although some trip computers will tell you how many litres (they think ) are left in your tank. That means practical and useable range information will depend on getting fuel consumption data from the ECU. Likewise for momentary consumption information. And not to mention that you will somehow have to be able to tell the Atmega how many miles you have driven (my suspicion is that that WILL require upgrading to an MkII electronic speedometer because the latter comes with that digital transmission sensor).

And data that is present and can be obtained from the MGF's circuitry might have to be analysed using an oscilloscope first; not every kind of input data will simply come as a variation in electrical resistance like the fuel gauge. Fuel consumption raw data can come as some sort of PWM signal (although I am not sure how that was done with the MPI injection system), so you'll have to know what you're looking for first and how to extract the information you need from such a signal.


So again, programming it and doing calculations with your data and putting the results on a screen is no problem at all... the challenge is to get the necessary data and be able to do something with it.

Thoughts and ideas will be welcome anytime.

talkingcars wrote:...
There is a feed to the EPAS that gives a digital speed related output, I used it for the cruise control on the mk1, IIRC it is a white/orange trace wire and can be found in the loom on the O/S of the car....

You're right this is an easier solution, saving a lot of money

Getting your project to work out MPG will be an interesting challenge, but you have engine speed, road speed and also injector duration?

Estimating range can be made complicated too given the shape of the fuel tank, but I would be tempted to assuming is was a regular box shape rather than the bow-tie shape it actually is...

Rob Bell wrote:Getting your project to work out MPG will be an interesting challenge, but you have engine speed, road speed and also injector duration?

hm... do we have them, or is that a question?

Well anyway, one of the main things before this project gets even remotely off the ground is knowing what sensors and sensor readings can be tapped into, and if it's therefore feasible at all. I guess that's still a possibility, that it just can't be done...

It'd be interesting how the digital odometer calculates mileage. In the end, all it has is the rpm from the transmission, doesn't it?

What I would find quite convenient would be if the idea of a trip computer was expanded to be more like a "Driver Information System" that tells you that you're low on screen wash, that a door is open or that your headlamp light bulb is broken. Or because it's a convertible, maybe a warning that your top isn't firmly shut All those things could be done regardless of what sensor readings from the engine are available.

If you are able to tap into the injector signal, then yes, you would have it. The other way to do this would be to tap into the MEMS OBD interface, but you'd need some skill to read the data packets to get this information... Raw data may be more straightforward.

Odometer is based purely on the gearbox output speed as you rightly say.

All the other ideas are certainly do-able - just a question of having the appropriate sensors (or making use of the sensors already there)

Rob Bell wrote:All the other ideas are certainly do-able - just a question of having the appropriate sensors (or making use of the sensors already there)

Well the "low screen wash" warning could be done by swapping the pump at the bottom of the screen wash tank for one with a sensor. I'm not sure Rover ever produced one like that, but looking at pictures of the pump used in the MGF/TF, there is a chance you could get a pump with a sensor from an old Audi 80 to fit... For an "open boot" warning, you could simply use the switch in the boot lid that turns the boot light on and off. Not sure really how it's done with the doors... where are the light switches in the door frames?

Broken light bulb warnings are a bit more complicated to implement. I know how it is done in (old) Audis, they've got "lamp check units", which are simply electromagnetic relay switches. They are in "zero position" when, say, the low-beam headlights on both sides are in working order and they are both either switched on or off. When one of the light bulbs breaks, it no longer draws power, which causes a relay switch inside the check unit to switch over and thus activate a "broken light bulb" signal (it has the disadvantage of not being able to detect when BOTH light bulbs of a circuit have gone).

In the spirit of not wanting to reinvent the wheel, maybe you could simply use this relay, which monitors the headlights, tail lights and brake lights all in one:

http://www.ebay.de/itm/Audi-VW-100-A6-C ... 541ebb5c05


An important question would be where to place the display with which all that data is conveyed to the driver. I have seen mods where people have moved the hazard lights switch from between the oil temp gauge and the clock to somewhere else. The hazard lights switch slot should be big enough for a small OLED screen. Right now, the Adafruit 0.96'' OLED screen seems just about perfect: https://blog.adafruit.com/2012/03/14/tu ... -tutorial/

The hazard lights switch being a bit more rectangular, you could even accomodate push buttons to operate it under the screen.

ok I think I found something very useful on Dieter's MGF page pertaining to fuel consumption and how to measure it:

http://www.mgfcar.de/library/ENGINE_MAN ... MS_1.9.htm

The four fuel injectors are fitted between the pressurised fuel rail and inlet manifold. Each injector comprises a solenoid operated needle valve and a specially designed nozzle to ensure good fuel atomisation. The injectors are controlled in grouped mode with 2 & 3 being grouped and 1 & 4 being grouped, with the injectors in each group being operated alternatively. The ECM determines when to operate the injectors based on the signal it receives from the crankshaft position sensor. The ECM provides an earth signal for the period the injectors are required to be open, the injector solenoids are energised and fuel is sprayed into the inlet manifold onto the back of the inlet valves. The ECM carefully meters the amount of fuel injected by adjusting the injector opening period (pulse width).

In other words, the ECU sends an analog electrical PWM signal to the injectors through a wire. That means it can be tapped into by directly connecting a wire from your DIY trip computer to the injection pin on the ECU and interpreting the signal. The Atmega328P chip which will (or would) be the basis for this project comes with native PWM support. But the first thing to do will probably be to hook an oscilloscope up to the injection pin on the ECU and see what the signal actually looks like, and especially how it changes when you rev the engine.

Now the only question is, how much fuel, in millilitres or whatever, is actually injected during one pulse cycle? That's the crucial question which will decide whether or not you can do any meaningful fuel consumption calculations. But if you find a way to figure that out, and how injection quantities change and correlate with pulse width, it'll be no witchcraft from there.

EDIT:

I've just found a large list of technical specs for Bosch injectors like the ones that were used in the MGF; according to this http://accurateis.com/store/23641354-In ... w-data.pdf , the Bosch 0280150749 fuel injectors have a maximum capacity of 227 cubic centimetres per minute. Now THIS information could really get the ball rolling!

Gerrit, all the information needed will be transmitted from the ECU to the diagnostic port. As James said, it will be much easier to fiddle with them when you swap over to MEMS 3, as then you have the well documented EOBD protocol available. On the other hand, Phillip has done a great job of setting up the pscan interface for the earlier MEMS units (starting at MEMS 1.6 afaik) so I guess he would be the one to talk to for any protocol geek talk.

Mykel wrote:Gerrit, all the information needed will be transmitted from the ECU to the diagnostic port. As James said, it will be much easier to fiddle with them when you swap over to MEMS 3

true enough; on the other hand, once I'd know the correlation between pulse width and injection volume per cycle, it would quite literally just be a few simple lines of C code to calculate fuel consumption. Without needing to upgrade to MEMS3.

AFAIK, upgrading to MEMS3 from 1.9 (I do have an MkI MGF!) needs a whole lot more work than simply swapping the ECU. And if all you really want is to calculate a fuel consumption signal, it seems a bit much. Under MEMS1.9, you also already have a speed signal that you can use to calculate an MPG value. And a throttle position signal and an RPM signal, if you really want to jam pack your trip computer display with useless data...

Also, I'd probably still have to come up with some C code to parse the readouts from MEMS3 into data that the Atmega chip will be able to process, as they are completely different platforms. So there'd be no work saved there.

There are OBDII interfaces for the Arduino/Atmega platform that plug straight into your OBDII socket, but that would have the disadvantage of having to unplug the interface everytime you'd connect a Testbook or something.

So in summary, to me it still seems the best way to go to calculate fuel consumption using the injector PWM signal. It may not be as accurate as anything you get from the MEMS3 or OBDII, but it'd be enough if it was just about accurate to the first decimal.

Should be able to work this out from the fuel pressure (nominal 3.0bar) and pulse duration, and knowing the flow rate at that pressure (Bosch flow data is available on the internet - and I have posted this on here somewhere... :lol;)

Rob Bell wrote:and I have posted this on here somewhere... :lol;)

Well Master Yoda, finding some of your old, valuable information on here is about the same as finding the odd part in your - uhm - garage, I guess. Not that mine is any better, tbh.

Still, even with keeping the MEMS 1.9, I’d try to get Phillip on board. He knows two important things, for once the secrets of Rovertalk over the Magic Pink Wire, and also the use of Kickstarter to fund a project. Basically, a trip computer is not so much different from a diagnostic tool. Why would you want to invent the wheel twice?

no, I am not trying to reinvent the wheel... the thing still is, once you've got some sort of data that you can feed into your Arduino/Atmega architecture, all you have to do is wire it up and dump about 300, maybe 400 lines (it sounds like a lot but it really isn't when you're in the midst of it) of C code onto the Atmega chip to have a full range of information put out on a display, like MPG, range, remaining fuel, and momentary consumption. Programming it will take a few weeks, but will not be difficult. Something to do over the coming winter.

And I am not the first person to have the idea of implementing something like it in a car; in fact, this guy here did something very similar to what I am planning, except he salvaged a monochrome LCD display from an old Nokia phone, and I would use a not wildly expensive high-resolution 1.5'' OLED colour display. I've got in touch with him, and he has offered to help with questions I might have.

His description is well worth a read, as is the C code he supplied at the bottom of it. He looked at injection cycle lengths using a Citroen-specific Testbook-like device, but his way of calculating fuel consumption was more "roundabout" if I understood correctly; he didn't use the signal from the ECU to the injectors directly (PSA Peugeot Citroen engine, but quite similar specs as our MG engines; 1.8-litre, 16V DOHC MPI, "grouped" injectors), but instead he worked out a linear correlation between engine RPM and injection time in milliseconds as measured with his "Citroen Testbook", and then, he used that RPM signal from the transmission (again, very similar sounding to the MGF) to calculate fuel consumption "indirectly".

Again, it's not witchcraft. It's "tap into a consumption signal or generate data correlating with it --> log that data/do calculations with it --> dump it out on a screen --> refresh every 1 to 5 seconds to your liking". Done.


And I've already found the relevant injector specs:

MGF74 wrote:according to this http://accurateis.com/store/23641354-In ... w-data.pdf , the Bosch 0280150749 fuel injectors have a maximum capacity of 227 cubic centimetres per minute. Now THIS information could really get the ball rolling!

EDIT:

I've dug my way through the electrical library, and this is what I found:




This is where I'll get the data to feed my trip computer . And because I will simply have to tap the wires right at the ECU module connector plugs, it means I will only have to run one single four- or five-wire DIY loom (depending on what other data I want to retrieve) from the back of the car to the front, where the control module for the trip computer will be located.

This is going to be a major project and I don't expect presentable results before next spring, but as it stands, I see no major insurmountable obstacles in its feasbilility.


One more question: I am thinking about investing in an entry-level oscilloscope (no more than 80-100 quid) to analyse the signals so I will know how to process them. Are digital USB oscilloscopes worth their money, which can be had from about £50, or should I buy a used stand-alone "hardware" oscilloscope??

Mykel wrote:

Rob Bell wrote:and I have posted this on here somewhere... :lol;)

Well Master Yoda, finding some of your old, valuable information on here is about the same as finding the odd part in your - uhm - garage, I guess. Not that mine is any better, tbh.

Still, even with keeping the MEMS 1.9, I’d try to get Phillip on board. He knows two important things, for once the secrets of Rovertalk over the Magic Pink Wire, and also the use of Kickstarter to fund a project. Basically, a trip computer is not so much different from a diagnostic tool. Why would you want to invent the wheel twice?

Hmm... you're probably right Mykel: I need to update my website!

Mykel wrote: and also the use of Kickstarter to fund a project.

I'm not sure I understand... you're saying I should go on Kickstarter to fund this project?

It'd be hardly worth the bother. All parts combined, this project will be about €300. Which won't be counting months of long weekend hours spent over the winter programming the C code for it, but that's just as well, because programming is one of my hobbies. And some of you here do spend more than 300 euros on a single project for your MG

Maybe once the trip computer will be completed, I'll put a how-to in the public domain including the C code.

Also, I am now reading up on how to connect several Atmega328P ICs together; it'd reduce workload on a single processor. I will probably be running one IC as master, and up to three or four identical ICs as slave via I2C protocol. This modular architecture from the start will mean that the trip computer will be expandable; I would start out with one slave IC to monitor engine and fuel data and to perform data logging (using maybe a 4 GB MicroSD card) for average MPG and fuel range*), and then just let the master IC request that data from the slave IC as needed and put it on the display.

Other functions that could be added to this modular architecture further down the line in the future would be things like one separate slave IC for monitoring open doors and boot lid and bonnet, a low windscreen wash warning, and as I have mentioned exterior lamp warnings. What would also be pretty cool would be to tie GPS functionality into the architecture. "Plug and play" GPS modules for the Atmega/Arduino can be had for about 20 quid. It'd be a doddle using such a module to give you a GPS speed readout as well as position and bearing data. The list goes on, but of course all that would be much further in the future. First of all, I am going to have to get a simple master-slave architecture up and running which will in the beginning only give out fuel data.


*) My current thoughts on fuel range calculations: Let the trip computer measure injection intervals of one cylinder continuously (thus generating maybe 3000 data points a minute, depending on average RPM), store those 3000 data points on the SD card as a flatfile log, then every minute calculate an average over that one minute, discard the 3000 data points, and store only the minute-by-minute average on the SD card in a flatfile log together with the distance that the car moved during that minute. When the master IC requests fuel range data from the slave IC, let the slave IC calculate from the log file how much fuel was used during the last 20 miles, and then put that in relation to the current fuel gauge level reading.

MGF74 wrote:........This is where I'll get the data to feed my trip computer . And because I will simply have to tap the wires right at the ECU module connector plugs, it means I will only have to run one single four- or five-wire DIY loom (depending on what other data I want to retrieve) from the back of the car to the front, where the control module for the trip computer will be located.......

Do you have aircon?
If not is the wiring in the main loom?
It may run from a white plug next to the nearside of the glove box to the plugs that link the main loom to the engine loom, I have the details at home so can supply them next week if needed.

Cars with ABS and the HLBL will have the AC loom there.