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 » Fri Dec 01, 2017 11:46 pm

To illustrate a bit more the magnitude of this project, here are some slides I have made so far as part of my project documentation:

Here's an overview of the different modules and components that I plan to install in my MG (click on images for a larger view):

Image

Here you can see the modular design of the trip computer. The engine data module in the back of the car will transmit all the gathered data to the trip computer head unit in the front of the car. This will be done using the I2C standard. Likewise, the convenience module will also transmit data to the head unit via I2C. Think of I2C as a low-rent alternative to CAN. Yes, I know, not even nearly the same, but it helps to think along those lines.

Note the (hopefully visually appealing) logo I have made for the project...

Image

This is meant to keep trademark worries to a minimum when the time comes that the whole project will be published "open-source" for anybody to recreate for free. No amount of profit that could realistically be made from selling fully-assembled MG trip computers would reimburse me for the two years I have already spent developing it. So I will be offering all the schematics, microcrontroller program codes and other data for download, for free. And all graphics will contain this logo and variations of it in lieu of the official MG logo.

Anyway, moving on, I don't have a slide for the trip computer head unit with the TFT display yet, as I'm in the process of migrating that module to a much more powerful ESP32 microcontroller, which will offer 32-bit dual-core technology at 230 MHz. But what I do have is a schematic for the engine data module:

Image

This is the most complex part of the project so far in terms of hardware and wiring. It is where all the engine data is gathered. I never bothered to try to reverse engineer the Rover OBDI codes to get my data that way, but then, under OBDI, a lot of data that's readily available in OBDII isn't generated in the first place, such as engine oil temperature, injection timing and vehicle speed. My module measures all that.

Also, if there is ever going to be an OBDII variant of my trip computer, naturally there will be no engine data module. Instead, I will connect an OBDII interface module to the car's OBDII port. They can be had for around £20 from Sparkfun.

Next, we've got the convenience module.

Image

This is where data such as inside and outside air temperature or the health of the exterior lights is monitored. Also, I will install a windscreen wash pump with a "third lead", which will sense when the windscreen wash level is low. I've already posted pictures of perfboard prototypes both of the convenience module and the engine data module further up in this thread.

And now here is a more detailed desciption of those wondrous lamp check modules. In short, they are a low-cost (when bought used) all-in-one solution to monitor your car's exterior lamps, and they were used in many Audi/VW vehicles in the mid-1990s to mid-2000s.

Image

I will need two of these. The wiring of the lights is markedly different in Audi/VW cars compared to the looms found in MGFs and TFs. So much so that the easiest way to implement lamp check functionality is actually to install one such unit in the front of the car near the fuse panel under the steering wheel, which will only monitor the headlamps, and a second unit in the boot of the car where the brake- and taillight looms divide towards the individual lamps.

Well, and finally, I've got the MkI speed transducer that I have also already mentioned.

Image

This speed transducer is necessary for MkI cars with the cable speedo, because like I said, you will not get a speed signal from the cable speedo that is accurate enough to do precise calculations with, such as fuel consumption, average speed, etc. On pre-OBDII MGF MkII, the factory speed transducer will be sufficient to measure speed accurately.



That's all, folks... ;)

I am always open to ideas and suggestions.
'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 » Sun Dec 03, 2017 12:08 am

Good progress but a couple of thoughts...

There is a speed signal in the mk1, IIRC it comes from the speedo head and is used for ABS, I took a signal from here for my cruise control.

I don't think there is a oil temp sensor in any car.
It is a value in MEMS 3 but not actually read by anything.

Won't the washer fluid sensor just tell you when the tank is empty. IMHO you need a separate sensor for this function.

James
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 Dec 03, 2017 12:35 pm

talkingcars wrote:There is a speed signal in the mk1, IIRC it comes from the speedo head and is used for ABS, I took a signal from here for my cruise control.
Yes, there is a speed signal present in the MkI. It is generated by the speedo cable driving a magnetic coil inside the instrument cluster, which then produces a square wave similar to that of the MkII/TF electronic transducer. This speed signal is then fed into the ABS electrics.

The problem, like I said, is that the cable speedo is too unreliable for exact speed measurements. My cable has definitelly seen better days and the speedo needle twitches up and down markedly at low speed, and this can also be seen in this screenshot I posted a while ago:

Image

This is at 20 mph. As you can see, the square wave intervals have a lot of variance, all at the same nominal speed. Granted, not every speedo cable will be as rusty as mine, but it also means that IF a speedo cable is getting to where it needs replacing, the data calculated by the trip computer will no longer be accurate. An electronic speed transducer fitted to the transmission in between it and the cable speedo will prevent that problem from ever happening.

Apparently, the ABS has no problem working with this kind of "give" in the signal accuracy. But any calculations like fuel mileage, momentary fuel consumption or range will be affected by this inaccuracy. Maybe you will then be shown something like 32.5 mpg instead of 31 mpg, so it's not going to be worlds apart from your actual consumption. But what is the point of calculating a figure like that if your underlying data isn't as accurate as possible ;)

Also, the MkI's own speed signal kind of seems like it is easily irritable, because in the beginning, I tried to get my speed reading from it as well, but any kind of current that you draw from it seems to have the potential to cause failures in other components. My EPAS went out a few times when I tried to connect an optocoupler to the speed signal. So it's best to just leave it alone and install that other speed transducer IMO, which will then only need to provide a signal to my trip computer.
talkingcars wrote:Won't the washer fluid sensor just tell you when the tank is empty. IMHO you need a separate sensor for this function.
The VW/Audi washer fluid pump that I will be using for this has a built-in level sensor. It has three leads, which means I will have to run one additional wire from the new pump through to the inside of the car and to my trip computer.

Here's a picture that explains it:

Image

A connector plug for this pump can be had from any breaker's for £2, maybe even for free. An additional hole in the fluid tank will have to be made, into which the top of the sensor will be inserted. There is a float inside the sensor unit, which switches a GND connection when the level is low. A rubber seal will be needed to prevent leaking, but every B&Q or Halford's should have one for 50p.
talkingcars wrote:I don't think there is a oil temp sensor in any car.
It is a value in MEMS 3 but not actually read by anything.

According to the schematics, the oil temperature sensor which is located near the oil filter should be an ordinary thermistor:

Image

This thermistor is connected to the oil temperature gauge. And I plan to simply tap into that thermistor. It will proably be an NTC (negative temperature coefficient) thermistor, as they usually are, meaning the resistance will go down as the thermistor becomes hotter. And I can measure this change in resistance with my microcontroller and interpret it accordingly as different values for the engine oil temperature.

A good bit of research to be done on that one still though... I hope I will get to it in spring when it gets warmer again, as my MGF is in hibernation at present. I will spend most of the winter programming the software for the head unit/display module.
'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 » Sat Dec 30, 2017 4:38 pm

UPDATE:

I just received my ESP32 dev board from China this week, and at the moment I am sort of toying with it and testing it out with bits of miscellaneous code to see what it can do.

Here's a photo:

Image

Note that the display in the picture is not the one that will actually be used. I just included it for scale. The actual display will be a SainSmart 128x160 1.8'' TFT. (see here) The screen itself will be the same size as the screen of this display, but it will be considerably smaller around the edges.

The great thing is that this ESP32 board is a low-footprint, highly-integrated system which has many very neat things right on-board. For example, you get wi-fi connectivity, you've got Bluetooth all built-in, and a few other things like being able to play 8-bit, 8-khz audio samples straight from the board via a speaker without additional hardware.

Most of all, it's got tons of memory. It contains 16 megabyte of flash, which means I can go completely wild with graphics if I decide to. They can all be stored right on the board, and I don't need an external SD card to load graphics from. The main limiting factor on the old 8-bit chip that I originally wanted for this project was very low memory for any kind of visual applications (no more than 64 KB). Also, because the ESP32 board runs at 230 MHZ CPU speed, there should be no noticeable lags at all in displaying full-frame images of any kind.

As I said, it has Bluetooth built-in. I didn't decide in favour of the ESP32 for that reason, but because it comes with Bluetooth either way, I am going to teach myself how to program an Android app, which is something I have never done before... :) The goal is to be able to connect your smartphone to the trip computer, and then do things like download data from the trip computer onto the phone for logging purposes. Also, such a smartphone app could be used to change the trip computer's background settings more conveniently. This will of course depend on how speedy my progress with teaching myself Android app programming will be. ;)

There has been a change of plan as to where the trip computer display will be mounted/located. It will probably not be mounted inside the instrument cluster, but in lieu of the analog clock in the centre console. The 128x160 px TFT display of the trip computer will just about fit within the dial face of a standard F/TF oil temperature gauge which would have to be bought extra. And the display will still be able to provide clock functionality, as the display could go into "clock mode" when needed. Like this, for example:

Image

An accurate analog clock like this could be done with just a few bits of ready-made code. And you could still display the time and date while the trip computer is in "display mode".

All told, this is what the screens of the MkI will progably look like:

Image

The vast system resources of the ESP32 compared to the 8-bit Atmega1284 which I was originally going to use mean that even these relatively elaborate graphics will be a doddle. And all the time I will save by not having to cook down my graphics to 64 KB can be spent on programming the Android Bluetooth app, as far as I am concerned... :D
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

User avatar
John SS
Posts: 493
Joined: Thu Nov 28, 2013 4:05 pm
MGF Register Region: Midlands
Model of Car: 2000 MGF VVC
Location: Calver Derbyshire

Re: raw data for MGF trip computer

Post by John SS » Mon Jan 01, 2018 8:26 pm

Loving this thread. Only understand 1% of it but the graphics look great!

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 Jan 03, 2018 6:59 pm

Right... well, I think what went a bit over everybody's head was that I forgot to mention that I was unhappy with the microchip hardware that I was initially going to use to power the trip computer display. Not that it will tell most people anything, but the chip was an Atmel Atmega 1284P. The problem is that the basic design of these chips goes back over 20 years. And therefore, it just isn't sufficient to do anything "demanding" by today's standards with them. There are still loads of simple tasks that they still do quite well today. The engine data module uses a smaller variant, the Atmega 328P, to keep track of all the data from the engine bay, and it does so without a problem.

But you run into limitations of these microcontrollers at every turn if you want to do visually appealing graphics or really any kind of multimedia content. The 1284 has only 64 kilobytes of built-in memory that can be used for graphics. Doing the kinds of things that I want to do just became a bigger headache with every day that passed. And all the full-screen warnings like the "frost" warning in my last post had to be loaded from an external microSD card, just like the one in your smartphone, which not only added a possible failure point to the system, but also, it took every full-screen image about a third of a second to be fully displayed line-by-line on the screen. Which may not seem much, but it was a "niggle" for me nonetheless.

So the last word in multimedia-ready mobile microchip design for these applications is now the Espressif ESP32. Which is what I just bought. And it's a thing of wonder in relative terms. It features a dual-core microprocessor that runs at 240 MHz. And it comes with up to 16 MB of flash memory instead of just 64 kilobytes. I just don't have to worry about where to put my pretty little graphics anymore. There is an abundance of memory space now right on the chip, and everything can be loaded straight from flash and displayed on the screen with no noticeable lag whatsoever. There's even enough room to include some sound files now, so that warnings can be given out with a proper gong or other sound instead of just monotone beeps.

And, as I said, it does Bluetooth. You can connect a phone to it and download data and what-have-you... depending on how far I will be willing to take it, it could almost give you the same kind of functionality as Mems Diag. But the Bluetooth thing isn't going to be my main focus with this trip computer. The main focus is having a display in your car that gives you real-time data on the state of your vehicle, like any modern-day trip computer system.
'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 » Wed Jan 03, 2018 9:30 pm

MGF74 wrote:Right... well, I think what went a bit over everybody's head......
Don't worry, I for one am following with interest.
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 » Wed Jan 03, 2018 10:30 pm

What I meant was, I understand completely that it can be hard for other people to follow when you're so immersed in the subject matter that really only you understand the whole project anymore... if that... :D

I am right now waiting for a replacement ESP32 board, as my current one went kaboom when I unsuccessfully tried to put together a simple audio amplifier circuit for it. And I ordered a few more parts. One is the new SainSmart TFT display. The other is a ready-made audio amplifier circuit breakout, which will probably be cheaper than having to buy new ESP32 boards all the time due to failed circuitry experiments... :D In order to make sound files audible, the audio signal from the ESP32 needs to be amplified so that it can be passed to a 28 mm miniature speaker which will also be part of the display module circuit.

All of these parts will probably arrive here some time next week. And then I will get coding, my hope is that I will have a working complete beta version for the display module software by spring. Then when my MG comes out of hibernation, I will still have to do some tweaking on the engine data module. And if all goes well, we're looking at late summer/early autumn as the point in time when the project will be all finished.

One slightly crazier idea which I keep trying to suppress in the back of my head is to record warnings in voice form. So that you've got a voice saying "Low fuel" or "Low coolant". It's certainly possible with the ESP32, and not difficult to implement at all. Maybe I will do it in my own voice, which you have to imagine as a native German speaking in a watered-down Midwestern U.S. accent. :D
'98 MGF 1.8i MPI (weekend/summer/fun car)
'99 Audi A4 1.8T saloon (daily driver)

Post Reply