raw data for MGF trip computer

http://www.ukmgparts.com
Ask the Gurus - Use this board to discuss problems or technical issues you have with your MGF/TF - there's always an expert around to help you!

Moderator: Committee Members

Forum rules
Not many rules really, this board being aimed at technical issues, it shouldn't fall foul (hopefully) of some of the more personal issues that can affect forums.

Rule 1 - Is that you need to think very carefully before posting anything technical or asking anything technical relating to the security system of the car - See 'Security Issues' sticky for more info.

Rule 2 - We (MGF Register) do not support copyright infringement and therefore references to CD ROM, PDF versions or paper copies of the workshop manual (for instance) should not be posted on the forum. We don't want to get into trouble and we'd rather sell you a genuine hard copy through our Regalia shop anyway! :)

Because advice is honestly and freely given in this technical section, much of it will be amateur experienced based, so any information is given in good faith and is not guaranteed as correct.
User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Tue Aug 18, 2015 3:23 pm

I think in the interest of keeping the wiring "tidy", it's best to just collect all the sensor readings in the rear of the car and then run one "all-in-one" cable/loom up to the front of the car where all of its wires will connect straight to the trip computer.

For example, sensor cable can have eight wires and more in it. I've used it for similar projects, it's highly flexible and very heat/cold/wear resistant. I've got a big Conrad shop three minutes from my home where I can just buy it by the metre, as well as most of the other small parts and components that this project will require ;)

Anyway, with the sensor cable, you could pick up the following from the rear of the car:

- fuel injection signal
- crankshaft sensor signal
- speed transducer signal
- fuel gauge signal
- as a bonus, a low coolant warning sensor could be installed while I am at it.
- ...

I could probably just pick up the fuel gauge reading at the instrument cluster, but again, in the interest of keeping things tidy, I will probably just tap into it right at the petrol tank.

I've got a million other ideas for this project at the moment, but first of all I am going to have to get started at all... :D I am right in the middle of programming an alarm system for my Audi using the same Atmega microcontroller, because some mugs tried to steal it over night a few weeks ago... but that's going nicely now, so I will probably be able to start the MG trip computer in earnest in about a month's time.

:arrow: This is probably the display I am going to use. A 2.2-inch diagonal should be plenty to display readably all the data you want the system to show, plus maybe a little fun can be had with it by giving it a "welcome screen" with an animated MG logo... again, all this isn't witchcraft, such a welcome screen will mean 10 extra lines of C code, although first you have to create the animation as a series of bitmap files with some sort of Photoshop-like software.

The screen will go in the centre console in lieu of the hazard lights switch; I will move the switch to the bottom of the centre console where the cigarette lighter is now. I will use a hazard switch from a Rover 75, as somebody has done before: http://s44.photobucket.com/user/Scarlet ... l.jpg.html . The added bonus would be having the panic button from the Rover included.
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
Rob Bell
Committee Member
Posts: 14422
Joined: Tue Oct 02, 2007 2:36 pm
MGF Register Region: South East
Model of Car: MGF 1.8i + MGF Shed!

Re: raw data for MGF trip computer

Post by Rob Bell » Tue Aug 18, 2015 5:44 pm

The screen will go in the centre console in lieu of the hazard lights switch; I will move the switch to the bottom of the centre console where the cigarette lighter is now. I will use a hazard switch from a Rover 75, as somebody has done before: http://s44.photobucket.com/user/Scarlet ... l.jpg.html . The added bonus would be having the panic button from the Rover included.
Yes, Andy Phillips did this some while back, and it still looks really good - particularly in his car with plenty of wood! :D

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Tue Aug 25, 2015 11:50 am

At the moment I am still busy designing the Atmega-based alarm system in my Audi before I can begin any meaningful work on the MG trip computer, but whilst rummaging around the relay panel under the steering wheel in my Audi yesterday, I had a good look at the lamp check unit; this is a cigarette pack-sized relay which tells the Audi's Driver Information System when an exterior light bulb is broken:

Image

This could be used to implement something similar in the MG. These relays are surprisingly cheap these days if you buy them used; they can be had from as little as £5 (plus p&p) from eBay Germany. Mine even checks the third brake light... although, to get that particular feature to work in the MG, I would have to completely rewire the third brake light, because save for the third brake light itself, this relay generally measures differences in current between pairs of lights; if for example the headlamp light bulb on the left breaks, it no longer draws power and thus there is a current difference between the left and the right side. If I keep the third brake light wired as it is, simply attached to the wire for the left hand side brake light, even with all three brake lights working there will always be a difference in currents between the left side and the right side.

I know quite a few MG drivers who scoff at Audi as a matter of principle... ;) but I will use a good number of Audi parts for this trip computer system because it will save a lot of time compared to cooking up my own solutions.
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
Rob Bell
Committee Member
Posts: 14422
Joined: Tue Oct 02, 2007 2:36 pm
MGF Register Region: South East
Model of Car: MGF 1.8i + MGF Shed!

Re: raw data for MGF trip computer

Post by Rob Bell » Tue Aug 25, 2015 12:58 pm

Nice idea! Will be interesting to see how this little gizmo comes together :D

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Tue Aug 25, 2015 1:46 pm

Well, this will be a major project and I don't expect completion before next summer. It won't be difficult per se, I'll just have to figure out a lot of electrical/electronic details which aren't fully known yet, through measuring and trial and error... programming the microcontroller, soldering the whole thing together and installing the system in my car with all the additional sensors/relays shouldn't take more than a month or two.

But we'll see ;)
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Wed Aug 03, 2016 7:51 pm

Good news, everyone...

I have actually started the project.

If you speak German, here's a run-down of the project specifics so far:

http://mgboard.de/viewtopic.php?f=3&t=11758

I am in the process of developing a modular architecture for this car computer, with a module in the back of the car measuring injection cycles right at the injectors, as well as the vehicle speed off a transmission hall sensor, and the fuel tank level. There will be a display module in the front of the car, which will receive data from the measuring module via I2C data bus, evaluate it, do calculations with it, and then display your fuel consumption data on a little 2.2'' TFT display, probably this one here: https://www.adafruit.com/product/1480.

Due to this modular setup, it's thinkable in the future to add functions like a light bulb monitor, or displaying things like outside and inside air temperature... but that's in the future.


So far, I've measured the injection signal with a scope:

Image

Basically, as you can see, the injectors are switched to GND by the engine control unit to open. When the injection interval is up (usually around 2 milliseconds), the injectors are switched back to 13 volts.

By counting the number of milliseconds that an injector was open during a given time interval, I can work out how much fuel was injected, because the capacity of these Bosch made injectors is known and is about 200 ml/min for MPI injectors and 210 ml/min for VVC injectors. For example, if I add up injection intervals once every 3 seconds and during those three seconds the injectors were open 450 milliseconds, then I just have to multiply that by the injector's flow capacity per millisecond, and I can then extrapolate that to litres per hour.

Also, I have looked at the speed signal, which can be tapped into at the panel under the steering wheel... this could be used to calculate miles per gallon or litres per 100 kilometres:

Image

Unfortunately, being that I've got an MkI, the speed signal is, erm, underwhelmingly accurate. The above screenshot was taken at a deliberately constant 20 mph. As we know, the speed signal on the MkI is conveyed from the transmission using an old fashioned speedo wire. The turns of the wire drive a magnetic inductor inside the speedometer which produces this square wave, but the same way that the speedometer needle tends to "twitch" on MkI cars, the signal that the speedometer produces is kind of "all over the place" and it's close to impossible to get a tidy, steady square wave at a given constant speed. It gets better from about 50 to 60 mph upwards, but what good is a fuel consumption metre if it's only accurate above 50 mph... :P

I could just upgrade to a MkII/TF instrument cluster with the electronic speed transducer... I've even got a working TF instrument cluster collecting dust here on the top of my cupboard. But I would very much like to keep my analog cream coloured dials ;) So I've bought an electrical hall sensor on eBay today which goes right in between the transmission and the speedometer wire, and it should produce a more reliable speed signal.

Moreover, I've built a test rig here at home to develop the circuits:

Image

The breadboard on the left serves the function of what's called a bit banger... it simulates the square waves that are present in the car and on which my fuel consumption measurements will be based. The breadboard in the middle is home to the actual measuring module (still under development), and the board on the right is my first attempt at building the display module (the finished version will have the above mentioned TFT colour screen).

As you can see, the project is based on the Arduino IDE framework.

Once these "proofs of concept" work and have all the bells and whistles of the finished product, I will then carefully solder all the components neatly onto (probably) perfboards, put them in module boxes and wire them up in the car. I've made good progress with this project in a relatively short amount of time, but I don't expect the finished project to be installed before next spring. There is still a whole heap of things that I need to think through and come up with solutions for. But hey, even the longest journey begins with the first steps... ;)
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Thu Apr 20, 2017 12:23 pm

*dusting off this thread*

My trip computer project is still ongoing, and I have made very considerable progress with it.

Right now, it's still in its "breadboard phase", meaning it consists of a test rig which simulates what will eventually be the real thing.

I have created what I call an engine stats module, which will gather engine and vehicle data such as fuel injection, engine revs, the vehicle's current speed, and things like oil and coolant temperature. This module will be linked up via the I2C protocol to a head unit module in the dashboard, which houses the little TFT display on which the data is displayed.

This is what the trip computer's TFT display will probably end up looking like (still in experimental phase, but already processing actual data):

Image

This is a 1.44'' TFT colour display. There will be different screen menus that you can navigate back and forth, and which will give you information such as your momentary fuel consumption, your remaining fuel, your precise current vehicle speed, engine revs, fuel range, etc. The plan is to install it inside the rev counter housing in the instrument cluster. Alternatively, a slightly bigger display could be mounted where the hazard light switch is now, and then move that switch onto the centre tunnel.

As most MGFs do not have OBDII and because the non-standard, sparsely documented Rover OBDI protocol would take too much time and effort to hack and reverse engineer, this trip computer will indeed rely on gathering all these measurements itself, straight at the source(s). Moreover, Rover's OBD-I variant does not include any vehicle speed, oil temperature and fuel tank level parameters, so to get these off a non-OBD-II, "pre-MEMS 3" MGF, you will have to tap into the sensors and senders anyway. In the coming months, at some point, I will build a perfboard prototype of the engine stats module.

There are ready made OBD-II breakout boards, which could be useful down the line for building an OBD-II capable version of the trip computer, and then accessing the desired data straight through the OBD-II port of newer MGFs and TFs (MEMS 3): https://www.sparkfun.com/products/9555. But that's a story for another time... ;)

I have also made a "convenience module", which will monitor things like outside and inside temperature, broken headlamp light bulbs, and open doors and lids. But at the moment, getting the engine stats module to deliver reliable data is the main focus.
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
Rob Bell
Committee Member
Posts: 14422
Joined: Tue Oct 02, 2007 2:36 pm
MGF Register Region: South East
Model of Car: MGF 1.8i + MGF Shed!

Re: raw data for MGF trip computer

Post by Rob Bell » Fri Apr 21, 2017 1:25 pm

Really pleased to see this progressing so well! I really like the little screen you've made up :thumbsu:

RSR92
Posts: 320
Joined: Sun Jun 26, 2016 10:39 pm
MGF Register Region: Cotswolds
Model of Car: MGF 1.8MPi MY2000
Location: Tewkesbury

Re: raw data for MGF trip computer

Post by RSR92 » Fri Apr 21, 2017 4:42 pm

Yeah this is absolutelty awesome, I have the dashcommand app which works okay but something like this would be a dream to have!
X-Reg MGF 1.8MPi in LQW: Trophy 160 Airbox, Citroen Washer Jets, Japanparts Dampers, 52mm T/B and Alloy Inlet Manifold
Pending: Replace Cat and B/B, Performance Filter element, Cold air feed from N/s vent

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Fri Apr 21, 2017 9:19 pm

Glad you like it...

One of the things I am trying to do right now is to try to simplify a few of my initial designs. Because it's a consideration to end up with something that somebody else who is handy with a soldering iron and needle nose pliers could actually recreate. ;) I plan to do a full documentation once the project is completed, including the programming source codes and perfboard schematics.

But that will very likely not be until (early?) next year. This is a giant project, and if I had known how giant it would turn out, I probably wouldn't have taken it on... but we say that about many things in life, don't we... :P

I must say I feel like I had a good day when I created some of the artwork...

Image Image Image Image

The screen will give out warnings when faults are detected. With a beep from an onboard 15mm subminiature speaker. And the welcome logo will appear with a soft dim-up when you turn the ignition. I'm not 100 percent sure yet what a soft top check module would look like, but I like the warning icon I've made for it... :lol:

As I said, the next big step is going to be to get the engine data module off the ground. I'm kind of jealous of people with newer MGFs or TFs at this point; if the F had had OBD-II at least from MY 1998 when mine was made, then it would have saved me months of research and experimenting... doing the whole thing for an OBD-II car should be considerably easier, especially because of the ready made OBD-II module in my post above. (if any of you are into Arduino-type physical computing, that module should make a great toy ;) :lol: )
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Fri Nov 10, 2017 5:03 pm

Just an update, before this project goes on hiatus again for a few weeks -

I have made prototypes for an engine data module and a convenience module on respective perfboards.

Image

The engine data module will gather data such as injected fuel per time interval, engine revs, fuel tank level, oil and coolant temperature, as well as vehicle speed. Oh, and it will also keep an eye on the expansion tank. You know, the coolant level sensor.

This engine data module will be located somewhere around the soft top compartment, probably near the T bar. It will forward the gathered data via I2C data line to the display module in the front of the car, where it will be processed and displayed on a small TFT screen. I decided to split the trip computer up into different modules early on in the project, because as we've got the engine in the back, you would otherwise have to run quite a few more wires from the back of the car to the dashboard. With the I2C data bus, all that will be needed is three wires between the front and the back of the car, i.e. 12 volts, I2C SDA (system data) and I2C SCL (system clock). Well, maybe also a GND lead, because microelectronics tend to be fickle and it might not hurt to make sure the components will be properly grounded against each other.

Also, if there is ever going to be an OBDII-compatible variant of this trip computer, then the modular setup will be beneficial because you could simply swap out my non-OBD engine data module for a still to be developed OBDII one.

What is more, it takes a good bit of system resources to keep track of all the fuel injection, engine revs, speed and other data, and do all the calculations with it that will produce the figures that actually get printed out on the screen. So it's worth the extra effort to farm that out to a separate module. The display module will then only receive the finished calculated figures via I2C. Because the display module itself will be quite busy processing all the elaborate graphics and would probably suffer noticeable lags, which would result in longer screen refresh latencies etc. Retrieving I2C data also takes time and resources, but according to my tests, the system load is much less.

Again to limit the amount of wiring that will have to be run through the length and breadth of the car, there is also a separate "convenience module".

Image

Located around the inside fuse panel, it will monitor inside and outside temperatures, for which waterproof DS18B20 temperature sensors will be installed both around the front grille and inside the passenger compartment (probably in a small cutout in the MkII centre console bezel right above the various switches). It will also monitor the windscreen wash tank, for which a special windscreen wash pump will be installed (Audi part no. 4A0 955 651 B) which has a built-in "third lead" that goes to GND when the level is low, quite similar to the coolant expansion tank. And also, I will install lamp check modules to monitor headlamps, taillights and brake lights. You can get BOSCH-made lamp check units that were installed in early Audi A3/A4/A6 for a fiver on eBay (Audi part no. 4B0 919 471). They are basically invasive current sensors, and they will alert when there is a fault on any of those lights.

Also, I have been busy developing a screen design for MkI cars, as the icons in my previous posts were for the MkII. I will probably mount my own trip computer in the centre console where the hazard light switch sits at present. so I will be able to mount a bigger display.

Image

And this is what that would look like mounted in the centre console:

Image

Note: this is fuel tank level and range in litres and kilometres; the trip computer will probably have a settings option where you can switch between miles/gallons and kilometres/litres. Some basic maths within the microcontroller code should then do the trick. My car is an MkI, but I've installed a MkII/TF "walnut" centre console.


When will all this be finished? At the moment, I am looking at summer/autumn of the coming year. Still heaps of work to be done, from fiddling with fuel consumption and fuel tank measurements to getting accurate readings out of coolant and oil temperature sensors.

I won't have time in the next two to three weeks to work on the project any further, so this is where everything stands at the moment.
Last edited by MGF74 on Fri Nov 10, 2017 7:57 pm, edited 2 times in total.
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
talkingcars
Posts: 5766
Joined: Tue Mar 09, 2010 10:44 pm
MGF Register Region: South East
Model of Car: mk1 VVC
Location: West Sussex
Contact:

Re: raw data for MGF trip computer

Post by talkingcars » Fri Nov 10, 2017 7:12 pm

The more I see the more I like.
Home to black Alfa 159 3.2 V6 Q4, blue MGZR160, green MGF VVC and grey MGF 1.8i, and red MG Maestro T16.

MGF chatting on the Register and at http://www.the-t-bar.com

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Sun Nov 12, 2017 2:24 pm

There might also be a nighttime colour palette, meaning the trip computer will be connected to the light switch, and possibly also to a £1 photoresistor to determine if it's actually night or if you've only got the lights on during the day.

This is what that could look like:

Image

But that's going to take quite some time still. First, I am going to have to figure out a way how to store all the daytime and nighttime graphics on the display module chip. Because we're talking several dozen kilobytes here, and I can only realistically use 64 KB of the chip, an Atmel Atmega1284P, for graphics, or the device won't boot. I am probably going to have to work with 8-bit colour instead of 16-bit colour as it is at present. But if the 256 colours that 8-bit will give me are picked cleverly, you will still end up with "smooth around the edges" graphics.

That's to come in a couple of weeks, when I will have time to work on the project again.
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
Tipper
Posts: 720
Joined: Sat Dec 06, 2008 3:39 pm
MGF Register Region: Devon & Cornwall
Model of Car: RV8 + ZS180
Location: Exeter, Devon, UK

Re: raw data for MGF trip computer

Post by Tipper » Sun Nov 12, 2017 3:15 pm

This is looking really interesting, well done so far.

Can you help me with a couple of things?

1 I presume the engine speed signal has been taken from the ECU or is it from the tachometer?

2 Similarly I note the car speed is from the MGF speedo. How many pulses/mile(or km) are provided by the speedo?

Later cars have an electronic speed sender to provide this signal (Hall effect transducer fitted to the gearbox) but I can't find out how many pulses are sent from those either. I'm hoping you may have come across this in your investigations.

By way of explanation, I am looking into fitting EPAS to my RV8 using the MGF EPAS steering column so need these signals to feed into the MGF EPAS ECU.

Thanks

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Sun Nov 12, 2017 4:43 pm

Tipper wrote:This is looking really interesting, well done so far.

Can you help me with a couple of things?

1 I presume the engine speed signal has been taken from the ECU or is it from the tachometer?

2 Similarly I note the car speed is from the MGF speedo. How many pulses/mile(or km) are provided by the speedo?
I measured my MkI's own speed signal off that one yellow/green (?) wire under the steering column early on in the project. The problem is that because of the MKI's cable based speedo, that signal will always be prone to "irregularities". You have probably seen the phaenomenon of the "twitching" speedometer needle on weathered MkI cars (mine has the same problem). Even with a brand new speedo cable, you will probably never have consistent pulse lengths at any speed. They will be off to both sides especially at lower speeds (notice how speedo needles generally tend to stabilise at higher speeds and stop twitching).

Here's the cable speedo signal at 20 mph, to illustrate what I mean:

Image

The solution? Fit a hall effect sensor in between the transmission and your speedometer cable. I bought one off eBay, it's from a manufacturer called ERA Spares. It just screws onto the transmission and has another thread on top to screw on the speedometer cable. They can be tricky to get to work though, it took me a few failed attempts (including loads of profanity shouted at the sensor :lol: ) to figure out how to wire mine up:

Image

The problem is going to be that this speed transducer will probably have different pulse lengths from the later factory MG/Rover hall effect sensor. Either you are going to have to convert your car to an MkII instrument cluster as well, or you are going to have to see if this speed transducer works with your EPAS regardless.

For my project, I had to do a test drive and see what pulse lengths I've got at different speeds. It's kind of an advantage living in Germany for something like that, because I was able to bring the speed all the way up to 120 mph on my local Autobahn stretch here to get my measurements... ;) You could probably do those measurements on a car lift as well and then just take the reading from the speedometer as reference. But I wanted true GPS speed as my reference, so there was nothing for it but to barrel down the empty Autobahn 7 at breakneck speeds one Saturday morning at 2am, with my laptop in the passenger seat clocking the transducer :D

You've given me an idea for a side project though. In theory, it should be possible to translate the pulse lengths from this speed transducer into those found on a factory Rover/MG one. You'd just have to write a few lines of microcontroller code that senses the fitted ERA Spares transducer's pulses on the input side, and then give out a pulse signal on the output side that mimics the factory Rover one.

If that's something that would be interesting for people looking to upgrade an MkI to MEMS3, let me know. In the course of this project, I will have to take pulse measurements from an MkII/TF hall effect speed transducer anyway, so at some point I will have that data anyway.


EDIT: This will probably be the welcome screen on the MkII variant of the trip computer... I've just put it as my new avatar... ;)

Image
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
Tipper
Posts: 720
Joined: Sat Dec 06, 2008 3:39 pm
MGF Register Region: Devon & Cornwall
Model of Car: RV8 + ZS180
Location: Exeter, Devon, UK

Re: raw data for MGF trip computer

Post by Tipper » Sun Nov 12, 2017 5:13 pm

Thanks for that. I think I can add your info into my conversion ideas.

Again for info, I have already changed the RV8 km/h speedo for an electronic version in MPH because this is required for UK use. This is because my RV8 is a Japanese spec car re-imported to the UK as many are. You can get a converted speedo or even new but both are expensive and the electronic one is about half the cost. It's a Siemens VDO Vision series. VDO also make a matching Tacho which I have also bought as the original flips to full scale all the time. The match with the originals is good.

I used the speed sensor that the RV8 uses for the engine management for a test but this too is cable driven being fitted just before the speedo head and the electronic speedo wobbles about all over the place! My solution is to change to a Land Rover sensor which is directly gearbox mounted and thus do away with the cable altogether and go electronic.

Thus I intend that 3 pulse signals are derived from it and protected using Schottky 'barrier' diodes. The 3 signals are for the new electronic speedo, the engine management ECU (the speed signal tells the ECU when the car is coming to a halt and winds open the idling air valve to stop stalling) and the EPAS control box, because the MGF EPAS is speed sensitive which I wish to retain. The original speed sensor provides 8000 pulses/mile, I am reliably informed, and this seems correct based on my test installation of the new speedo. I have yet to establish the new speed sensor's pulse/mile rate but am hoping it's the same.

Time will tell if all this works well!

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Sun Nov 12, 2017 5:35 pm

Tipper wrote:The original speed sensor provides 8000 pulses/mile, I am reliably informed, and this seems correct based on my test installation of the new speedo. I have yet to establish the new speed sensor's pulse/mile rate but am hoping it's the same.
There is a chance that that isn't generally true.

My ERA sensor has a non-linear speed to pulse ratio. That in itself seemed so weird to me that I actually repeated my test drive twice. In short, the faster you go, the less the decrease in pulse length becomes.

Here's what I mean:

Image

On the x axis, you've got the speed in kph, and on the y axis the interval lengths between rising edges of the pulse signal in milliseconds. I've back tested this with a programmed microcontroller (an Arduino Uno board) calculating the speed back from the measured pulse lengths, and my findings were confirmed.

So basically, how many pulses you've got per mile depends on how fast you are actually going. Maybe also on your factory Rover/MG hall effect transducer, I don't know. But the electronic speedo will probably parse the speed transducer signal in one way or another to calculate the kind of speed in mph that it gives out on the odometer. There will be some kind of relation between the incoming pulses and what you see displayed. Linear or not.

I'm not sure how my findings with my transducer can be explained, probably some sort of electrical/mechanical latencies within the ERA hall effect sensor itself. Maybe there's somebody on here who knows a bit more about electrical engineering? I've heard of temperature-related "drift" on hall effect sensors, but not of signal drift in relation to signal frequency.
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
Tipper
Posts: 720
Joined: Sat Dec 06, 2008 3:39 pm
MGF Register Region: Devon & Cornwall
Model of Car: RV8 + ZS180
Location: Exeter, Devon, UK

Re: raw data for MGF trip computer

Post by Tipper » Sun Nov 12, 2017 10:51 pm

MGF74 wrote:
So basically, how many pulses you've got per mile depends on how fast you are actually going.
No, the pulses per mile will always be the same as it is a simple ratio of wheel circumference and its rotation. It's the speed of the pulses that changes which will be measured and interpreted by the electronic speedo, the EPAS controller and the engine management ECU. These all being for my RV8 of course.

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Sun Nov 12, 2017 11:11 pm

Tipper wrote:No, the pulses per mile will always be the same as it is a simple ratio of wheel circumference and its rotation. It's the speed of the pulses that changes which will be measured and interpreted by the electronic speedo, the EPAS controller and the engine management ECU. These all being for my RV8 of course.
You're right and I had an error in thinking there... :?

Of course it's physically impossible for the hall effect sensor to spin faster than your wheel (disregarding axle ratio maybe?). But if you go by pulse length, then I had that non-linear curve on my aftermarket sensor. Again, my guess is that there is some sort of electromagnetic latency lag effect involved as the moving parts spin over the sensor. And maybe that latency just becomes less disproportionally as the wheels spin faster.

Still haven't fully got my head around that though, tbh...
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
MGF74
Posts: 297
Joined: Mon Jun 03, 2013 11:29 am
MGF Register Region: Europe

Re: raw data for MGF trip computer

Post by MGF74 » Tue Nov 14, 2017 1:22 pm

I've got a technical question myself now;

have any of you disassembled an MkI instrument cluster and had a look at what's behind the dial faces? The reason is that I've had questions from people whether it's possible to mount the trip computer display inside the rev counter. About like this:

Image

This rev counter is obviously from a TF, and I got it from the local breaker's here once.

As it turns out, TF and probably also MkII dials are polymer foil cutouts glued onto a clear plastic/perspex carrier:

Image

So you'd probably just have to cut a square out from the dial face and leave the 3mm clear plastic behind it the way it is, and mount the display onto it from the back, if you know what I mean.

I did have my MkI instrument cluster out a few years ago, but I can't remember if it too looks like that from behind.
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

Post Reply