Instructions to change fuel maps on 14CUX Griffith, Chimaera

[griffnz]

Having read the last few posts I thought it time to hook up my rovergauge cable and have a look at my Griff 500. It's a 1996 NZ new with no cat or lambda from new as I understand it. Looks like it's running on fuel map2 and I get a checksum error light on. The ecu has a 'GIZZMO tuning' sticker on it so it may have been played with. Am seeing if I can find out anything about that..

[MikeG]

Hi Guys,

I have enabled lambda measurement in RG setup and set lambda trim to long term. Main display does not appear to have changed with lambda trim still showing 0%. However, both left and right lambdas are showing up as faults. I think this must dismiss the possibility of an oscillator in circuit mimicking the lambda and mean that all adaptions have been carried out within the map (in my simplistic thinking). Below are the resultant screen captures.






Many thanks for all your input. I am learning a lot about RoverGauge and it's application from this thread.

Regards
Mike
PS Happy Thanksgiving to Dan and his family

[davep]

MikeG, sorry to be a nuisance could you repeat the previous screen captures but with the tune resistor disconnected (selects Map 0 or the LimpHome map)? The Long Term trim bars should read -100% when you do this. Also I guess that with the code showing permanent Lambda error codes you also have the car's MIL lamp disconnected?

griffnz, your Griffith 500 is running the good old open loop map, Map 2, in other words a 500 pre-cat, no cats, no Lambdas. Nice! There's an easy fix for the checksum error, it's all explained on stevesprint's most excellent website: http://www.stevesprint.com/remap-14cux

Whilst on the subject of $C0A0 here's a screen capture that confuses me:



Long term trim adjustment when running Map 2. And no it's not been Paintshopped.

[blitzracing]

MikeG said:

Hi Guys,

I have enabled lambda measurement in RG setup and set lambda trim to long term. Main display does not appear to have changed with lambda trim still showing 0%. However, both left and right lambdas are showing up as faults. I think this must dismiss the possibility of an oscillator in circuit mimicking the lambda and mean that all adaptions have been carried out within the map (in my simplistic thinking). Below are the resultant screen captures.






Many thanks for all your input. I am learning a lot about RoverGauge and it's application from this thread.

Regards
Mike
PS Happy Thanksgiving to Dan and his family

Something as simple as not having had an ECU reset still holding onto the fault codes from a past life? With no lambda's on the cat map (5) you will see very high trim levels as the ECU tries to get the probes to respond before it throws a Lambda fault code. I does not make a lot of sense on map 2 to have these codes.

[MikeG]

Hi,

Dave, I will try and run the further test you suggested this weekend and then post up the results.
Regarding the MIL lamp, I do not know if it was disconnected (did not TVR do this on some cars to prevent nuisance call backs?). However, would not the MIL indicator on RG flag up if there was a signal to turn on the MIL lamp? As you can see the MIL flag on my RG screen is clear.

Nearly forgot - in answer to Blitzracing, the ECU was reset earlier in the year when I changed the battery and did other work on the car.

Mike

Edited by MikeG on Thursday 27th November 13:43

[danbourassa]

I took a quick peek at Mike's file. Although it's a tune I did not have, there seems to be nothing special about it. As we now know, it is processing in closed loop and the Lambda error codes are set. Dave, thanks for being more observant than me about the greyed out trim bars.

Mike, your MIL is disabled. This is standard with the TVR R2967 tune. RoverGauge monitors the MPU register bit that drives the output circuitry to the lamp. This line is never asserted when the MIL is disabled in the PROM, so RG was correct in not showing this illuminated. I'm quite sure you are running the wrong map and you should be running 1, 2 or 3. If you are not happy with the results, you should clone map 5 into one of these open maps. I can help you with this if you want.

Gavin (griffnz), thanks for posting. This helps to confirm, as Jools mentioned, the existence of late Griffs without the closed loop setup. I'm curious about this. Was TVR trying to save money? Were they concerned about availability of unleaded fuel? Did they think that running open made for a better car? (It probably does.) I also noticed that your checksum byte is $68 or $6B (it's a bit fuzzy). Either way, it's another I'd like to have in my collection and it would make SIX different tunes sharing the R2967 tune number!

[MikeG]

Hi,

Following on from Dan's comments I made up a tune resistor to select map 2 and have just tried it out. RoverGauge gives the following:



On closer inspection it appears that the map codes from line 4 down are the same as my map 5 and lines 1, 2 and 3 are the same as griffnz's map 2. I will need to give the car a full run to check that all is OK and if I need to change anything else.
Having battled my way through the "Black Friday" rush, the resistor I bought from Maplins turns out to be 390ohm but luckily does select map 2 OK. May change that to the correct 470ohm unit later.

All your knowledge and advice is much appreciated.
Mike

[griffnz]

Dave - thanks for the link, I will have a read.
Dan - checksum fixer says 6B. I'll save my ROM image, and PM to you.

[stevesprint]

griffnz said:

Having read the last few posts I thought it time to hook up my rovergauge cable and have a look at my Griff 500. It's a 1996 NZ new with no cat or lambda from new as I understand it. Looks like it's running on fuel map2 and I get a checksum error light on. The ecu has a 'GIZZMO tuning' sticker on it so it may have been played with. Am seeing if I can find out anything about that..

GriffNZ
Thanks for sharing your interesting Griff with us.

Sounds like “GIZZMO tuning” caused your checksum error when they altered your prom as TVR usually corrected the checksum. I wouldn’t worry too much as it’s not the code of death that we were all once lead to believe.

However, its now very easy to correct with a chip read/writer and the 14CUX Toolkit or if you don’t wish to install the correct .Net Framework then you can use Dan’s standalone command line program called finalize. For further information on the chip writer & Toolkit please have a look at http://www.stevesprint.com/remap-14cux/gadgets.htm... . I’ll also add a link and instructions for Dan’s finalize program as I’m sure Dan won’t mind.

Should you require further information or assistance please do not hesitate ask.

[griffnz]

Thanks Steve. As yet I've had no success in tracking down any info from gizzmo tuning but good to know the checksum error is not an issue for the car

I downloaded some of the tools from the links on your site yesterday, including TunerPro and the utility that had the checksum fixer in it. I also read, and re-read, most of the info on your site, including the bits about the tune files. I downloaded the extended fuel map in the latest code version to have a look in TunerPro. When I looked at a fuel map in TunerPro the column headers were still showing the same rpms as my map (at least as far as I could tell. I hope I loaded up files correctly.) My assumption is that's just a heading set in the the xdf(?) and that somewhere else in the code/tune is something that says "move fuelling to the next column when rpm input is x' and you've changed the x value, and I assume that x is constant across the rev range. Of course I could be very wrong about that......

I've not got any EPROM rewrite hardware, or a wideband O2 sensor, so I'm just looking at these things to learn more at this stage and I've got a lot of learning to do.

[stevesprint]

griffnz said:

Thanks Steve. As yet I've had no success in tracking down any info from gizzmo tuning but good to know the checksum error is not an issue for the car

Google found this company www.gizzmoelectronics.co.nz ???

griffnz said:

I downloaded some of the tools from the links on your site yesterday, including TunerPro and the utility that had the checksum fixer in it. I also read, and re-read, most of the info on your site, including the bits about the tune files. I downloaded the extended fuel map in the latest code version to have a look in TunerPro. When I looked at a fuel map in TunerPro the column headers were still showing the same rpms as my map (at least as far as I could tell. I hope I loaded up files correctly.) My assumption is that's just a heading set in the the xdf(?) and that somewhere else in the code/tune is something that says "move fuelling to the next column when rpm input is x' and you've changed the x value, and I assume that x is constant across the rev range. Of course I could be very wrong about that......

Your assumption is bang on, you can see the extended column headings in the first screen shot on page 35 of this thread. I would of thought its possible to make the column headings in TunePro dynamic, I’ll have a look when I get a chance as I've been distracted recently by another project. I’m sorry I neglected TunerPro once Dan published the assembler program source code to re-compile the original prom files. That said TunerPro is a great user-friendly interface for the prom that can re-calculate the checksum every time you save your chip bin file.

griffnz said:

I've not got any EPROM rewrite hardware, or a wideband O2 sensor, so I'm just looking at these things to learn more at this stage and I've got a lot of learning to do.

As you’ve familiarised yourself with TunerPro, and chip programmers are as cheap as chips it would be worth you buying one just to correct your checksum.

This programmer is only for 32bit windows
http://www.ebay.com/itm/200720553952?ru=http%3A%2F...

or this one is for 32 and 64 bit Windows
http://www.ebay.com/itm/151401330433?ru=http%3A%2F...

It is very satisfying fixing your own issues and it sounds like you’ll enjoy learning, Good Luck and keep the questions coming.

[stevesprint]

Shock Horror
I’ve found another 4-cylinder car that runs the 14CUX, you’ll understand the horror when you realise it’s not one of Britain finest examples.

http://www.ebay.co.uk/itm/380418000087?_trksid=p20...

[griffnz]

Thanks Steve. Yep, found gizzmo online and emailed them. Just waiting to see if they have any records of work done. May take the plunge soon with the hardware required.

[stevesprint]

Colin and Dan
Thank you both for helping me offline to understand the formula to calculate the Checksum fixer. I'm grateful for your patience with me and hopefully I've now got the following formula correct plus I also now realise only the least 2 significant bytes of the sum total are used.

New Checksum Fixer = Old Checksum Fixer - Sum of all bytes in bin file + 1

Cheers, Steve

[cmb]

stevesprint said:

Colin and Dan
Thank you both for helping me offline to understand the formula to calculate the Checksum fixer. I'm grateful for your patience with me and hopefully I've now got the following formula correct plus I also now realise only the least 2 significant bytes of the sum total are used.

New Checksum Fixer = Old Checksum Fixer - Sum of all bytes in bin file + 1

Cheers, Steve

I just want to note that this is all done with 8-bit math -- the summation and the fixer values each only occupy a single byte, so rollover will happen when it's being computed.

[stevesprint]

cmb said:

I just want to note that this is all done with 8-bit math -- the summation and the fixer values each only occupy a single byte, so rollover will happen when it's being computed.

Sorry my mistake, I must have been thinking 2 hex digits at the time for example 'FF' which I realise is one (8-bit) byte, therefore I got my bytes and hex digits confused, sorry if I confused anyone.

[jjohnson23]

I hope you have all had a good Christmas and I also hope you have a good 2015.
Some time ago I asked for some help and thanks to Steve Sprint who sent me an eprom I was able to repair the damage I did to my 14cux circuit board(too heavy handed removing the original prom).
Well for xmas I have been given a TOP853 eprom programmer(she must have turned a deaf ear to the wideband lambda) and have taken an image of the eprom Steve gave me,just waiting on the eeproms I ordered and I can start playing.
On the subject of the airflow meter,if I wished to fit a 20am unit instead of the 3am,which way do I go with the offseT as there is no table,only a scalar using the steveskarls xdf.
I know the values are around 15% less but as I see a value at the moment of 30(001e in hex)in Tunerpro I assume I have to make the adjustment down rather than up,is this correct?
By the way Steve,the TVR eprom works ok in the ecu and shows on rover gauge but the TOP853 would not read it for some reason even though it acknowledged it was mounted,I presume it is something I have overlooked.
An excellent set of bins by the way,you are a gent for sharing them.

Edited by jjohnson23 on Tuesday 30th December 22:30

[stevesprint]

jjohnson23 said:

if I wished to fit a 20am unit instead of the 3am, which way do I go with the offset as there is no table, only a scalar using the steveskarls xdf. I know the values are around 15% less but as I see a value at the moment of 30(001e in hex)in Tunerpro

Paul, I'm impressed; you certainly have been paying attention to this thread. Sounds like you've read Jools's post on page 13 copied below and realised with the 20AM's 15% lower output voltage you’ll no longer hit the bottom row of the fuel table on full power and therefore have to change the fuel table AFM/row index scalar and offset first.

The AFM/Row scalars for 4.3L, 450, 500 are all 91 whereas the 4 Litre AFM scalar is higher with B2 or B9, therefore I would of thought you'll need to go higher with the scalar. I'm sure it would be safe to start with the 4-litre AFM/Row scalar of B2 as 4 Litres are very roughly 15% smaller. In TunerPro it’s called “TABLE x Row Scalar – Colour” and there is one for each map.

You've obviously also noticed from Jools's excellent explanation on page 13 copied below that just changing the scalar alone to hit the bottom row with a 20AM will also moves the idle row from 2 to 2.5 and therefore also have to adjust the ‘AFM/row offset’, called "TABLE 1-5 MAF Scalar Offset" in TunerPro. I personally haven't tested the AFM/row offset, so I don't know which way you should change it or how much of an issue it causes leaving the idle at row 2.5. Please let us know how it goes.

spitfire4v8 on Page 13 said:

Hi Steve and Dan .. yes I've been using the afm row scalars and fuel multpliers successfully. The offset sounds interesting though because I have noticed that when rescaling the afm rows that yes i can get the afm to reach the 8th row of the fuel table but it starts further up the rows on idle .. hard to explain but on changing to the 20am i was using , say, row 2 at idle and row 6 at full throttle .. then rescaling the afm allows me to use row 8 on full throttle but the idle is now on row 2.5 if you see what I mean .. ie the use of the fuel map is scaled up by a fixed percentage. Being able to trim the idle map position back to row 2 at idle and still be able to get to row 8 on full throttle by a combination of offset and afm scalar twiddling would be ideal.

Paul, as you know once the MAF/Row is scaled and offset correctly you can then adjust the main fuel table multiplier called “TABLE x MAIN SCALAR – colour” in TunerPro so there are ‘FF’ in the max power cells as per Jools's (spitfire4v8) post on page 16 copied below.

spitfire4v8 on Page 16 said:

What I have been doing is to massage the fuel multiplier to get the fuelling correct at the richest point on full throttle power runs on the dyno with FF in the load sites passed through during the run, then leaving the multiplier alone and going back and correcting all the other fuel map sites to get the mixture where I want it.

In this way you can maximise the resolution of the fuel map which becomes important when you are dealing with small numbers in the fuel map around idle and trailing throttle.

blitzracing on Page 13 said:

The 20AM runs consistently about 15% lower voltage output for any given airflow

Mark, Thanks for confirming the 20AM output it CONSISTENTLY 15% lower and therefore confirms its a good alternative.

[stevesprint]

jjohnson23 said:

By the way Steve,the TVR eprom works ok in the ecu and shows on rover gauge but the TOP853 would not read it for some reason even though it acknowledged it was mounted,I presume it is something I have overlooked.

Sorry to hear you missed out on the Wideband AFR sensor/gauge/logger but at least you received the chip programmer, one step at a time.

It might be worth trying the following chip manufactures and chip types even if you have different makes of chips. Plus I'm sure you're aware the TOP853 chip programmer only works on 32 bit versions of Windows.

EPROM - Select TI TMS27C256
EEPROM - Select ATMEL AT28C256

If it still doesn't work please do not hesitate to pm.

[jjohnson23]

Steve,I should have mentioned that the eprom you sent me was read by the TOP853,so I need to experiment on the TVR eprom.
Out of interest I did a comparison of R2967 with MIL lamp enabled and R2666 which is a std Range rover 3.9 eprom using Tunerpro and found that there is a hell of a lot of differences,a fair few of which are not defined.I had no idea there would be so many differences.
The guys have done a hell of a job getting as far as they have and I cannot thank them enough.