Instructions to change fuel maps on 14CUX Griffith, Chimaera

[spitfire4v8]

If you are going down the route of changing your prom information you will need a chip burner and a supply of blank or erasable chips anyway .. so then you can burn your own prom and try your ecu again. Steve Sprint has all the info you need on his excellent resource site. Chips are a few pounds each

[blitzracing]

A bad eprom with thorw up a checksum error in the ECU diagnostics. I can blow you a standard fuel map chip if you let me know the engine size.

[spitfire4v8]

Increased idle speed on the move ..

do we have any information on the increase in stepper motor position when on the move?
I'm led to believe that this is an emissions-led strategy to reduce the immediate large vacuum when releasing the throttle .. my understanding is that this reduces the sudden vapourisation of any fuel that has collected on the inlet port runners as the throttle is shut and the vacuum increases ..

The sudden vapourisation of the fuel that would normally occur here is reduced by bleeding air through the stepper to reduce the effect of closing the throttle abruptly. The idle speed is then targetted once the road speed has dropped and the ecu assumes the car is stationary once more.

Do we know what controls it ? I can't remember reading anything directly relating to this so far (but my memory is appalling and reading this whole thread on my phone is going to prove irksome to say the least!)
cheers all

[blitzracing]

Thats a lot more techical than the reason I heard- it was to stop rear wheel lock ups between down shifts (??)

Edited by blitzracing on Tuesday 18th November 16:19

[stevesprint]

jjohnson23 said:

Will Rovergauge connect to a 14cux without the fuel eprom fitted?

No, because the software that drives the com port is on the eprom. The eprom contains all the 14CUX software and fuel data, therefore starting without it is like starting a computer without a hard disk.

[stevesprint]

spitfire4v8 said:

do we have any information on the increase in stepper motor position when on the move?

Interesting question, I thought it is held slightly higher on the move to help smooth the idle and stop the rpm’s dipping when suddenly closing the throttle.

I’ll have a look at some log files to see if the stepper varies with road speed while on the move. I know it varies with engine temperature while cranking.

Jools,
Do any after market EFi systems also hold the idle slightly higher while on the move or is it unique to the 14CUX? I realise some systems control the idle speed with the ignition timing, therefore do they tweak the timing to also give the idle a soft landing when suddenly coming off the gas?

[MikeG]

Hi and thanks for all the work and information on the 14CUX.
My own Griffith 500 is running Tune R2967 fuel map 5 which I assume is adapted to run with no cats as the engine has the standard serpentine block with what looks like the standard headers and Y piece except there are no cats fitted and there are no lambda bosses welded into the headers; i.e no lambda sensors. The car is 1995 model and I have owned it since 1997 and it continues to run without fault. I have a RoverGauge screen dump I can post if it is of interest.
Any information on how this fuel map is likely to have been adapted to run without cats would be much appreciated?
Mike

[spitfire4v8]

stevesprint said:

spitfire4v8 said:

do we have any information on the increase in stepper motor position when on the move?

Interesting question, I thought it is held slightly higher on the move to help smooth the idle and stop the rpm’s dipping when suddenly closing the throttle.

I’ll have a look at some log files to see if the stepper varies with road speed while on the move. I know it varies with engine temperature while cranking.

Jools,
Do any after market EFi systems also hold the idle slightly higher while on the move or is it unique to the 14CUX? I realise some systems control the idle speed with the ignition timing, therefore do they tweak the timing to also give the idle a soft landing when suddenly coming off the gas?

A bit more info .. got a griff in at the moment ..
rovergauge shows the stepper percentage position varying with throttle inputs, no idea if the stepper is actually replicating these percentages accurately though as they change in rovergauge very quickly, but the stepper can move quickly when it wants to
Anyway constant throttle at more than idle revs causes the stepper to close down not open as I thought! However rapid on and off movements of the throttle causes the stepper to gradually open up .. it seems that there's more influence given to the stepper opening than closing under transient throttle conditions such that the general trend there seems to be a gradually opening stepper motor. However once a generally static open throttle position is achieved then the stepper starts to close down again.
the whole proceedure is more complicated / stupid* than I first thought.

• delete as applicable

[Sardonicus]

spitfire4v8 said:

A bit more info .. got a griff in at the moment ..
rovergauge shows the stepper percentage position varying with throttle inputs, no idea if the stepper is actually replicating these percentages accurately though as they change in rovergauge very quickly, but the stepper can move quickly when it wants to
Anyway constant throttle at more than idle revs causes the stepper to close down not open as I thought! However rapid on and off movements of the throttle causes the stepper to gradually open up .. it seems that there's more influence given to the stepper opening than closing under transient throttle conditions such that the general trend there seems to be a gradually opening stepper motor. However once a generally static open throttle position is achieved then the stepper starts to close down again.
the whole proceedure is more complicated / stupid* than I first thought.

• delete as applicable

That makes sense seeing as some have documented improvements i.e less shunting when unplugging the stepper motor (or cleaning/freeing up) even though the Lambda probes make corrections they dont that rapidly by which time the throttle may have been moved then the whole cycle resumes again good spot

[danbourassa]

MikeG said:

My own Griffith 500 is running Tune R2967 fuel map 5 which I assume is adapted to run with no cats as the engine has the standard serpentine block with what looks like the standard headers and Y piece except there are no cats fitted and there are no lambda bosses welded into the headers; i.e no lambda sensors. The car is 1995 model and I have owned it since 1997 and it continues to run without fault. I have a RoverGauge screen dump I can post if it is of interest.
Any information on how this fuel map is likely to have been adapted to run without cats would be much appreciated?
Mike

Hi Mike,
I've been very sure about some things before and have been dead wrong, but that hasn't slowed me down.

Map 5 is a closed loop map and is processing the Lambda inputs. If you have no fault codes, you may have a small box somewhere in your car that contains an oscillator circuit that is supplying a square-wave input in place of the Lambda sensors. Can you post the screen dump?

By the way, this approach can be used on the down-stream sensors on newer cars (OBD II) to fool the ECU into thinking that the catalytic converters are still good after they have failed. But I would never do this, of course.

[MikeG]

Hi Dan,

Many thanks for your quick response. I am fairly certain that there is no oscillator box wired into the car to fool the ECU into thinking that lambda sensors are fitted, I could be wrong though! The fuel chip in the ECU has a hand written lable that says "500 non-cat" which makes me think that the map/code has been adapted so that it at least does not go into limp home mode without lambda sensors feeding into a closed loop control. RoverGauge screen dump below (I hope):


Many Regards
Mike

[danbourassa]

Mike,
You are probably correct that there is no oscillator. I believe that this would give you short term values close to zero but not necessarily zero. The values you have are exactly zero which is consistent with an open map. RoverGauge is showing the short term values because map 5 is normally closed loop. It appears that you have an unusual PROM (I would love to have a copy of the binary). The checksum byte of $1A also indicates that this PROM is unusual. I'm very curious about how this was done. I can't believe it was done by changing the code section. Recently we have discussed, in this thread, data bytes in the data section of the PROM that seem to be used to control the code path. There is a bit that can be set (or cleared) to force open loop under all map conditions. I'm guessing that this was done for your PROM. Up until now, I thought that this bit was just used for code development or factory testing. (Looks like I'm wrong again!)

RoverGauge may need to be updated to be aware of this bit.

[blitzracing]

I tried doing the oscillator thing in place of the lambda probes, but its very difficult to generate perfect zero trim. Basically if the mark / space ratio is not a perfect match then the ECU keeps adding more and more fuel trim bit by bit, albeit very slowly. It would be a very hard way of locking the trim at zero long term.

[spitfire4v8]

Mike was your car originally an export model for Jersey / Guernsey or similar?
There were models made for certain export markets that didn't have cats or lambda sensors ..
If you take an image of the prom in rovergauge and send it to Dan he can spend his evenings looking through the code, quietly nodding and smiling to himself as he unlocks the secrets within

[stevesprint]

MikeG said:

Hi and thanks for all the work and information on the 14CUX.
My own Griffith 500 is running Tune R2967 fuel map 5 which I assume is adapted to run with no cats as the engine has the standard serpentine block with what looks like the standard headers and Y piece except there are no cats fitted and there are no lambda bosses welded into the headers; i.e no lambda sensors. The car is 1995 model and I have owned it since 1997 and it continues to run without fault. I have a RoverGauge screen dump I can post if it is of interest.
Any information on how this fuel map is likely to have been adapted to run without cats would be much appreciated?
Mike

Mike
Thanks for sharing your unusual and fascinating tune chip with us. We would all be very grateful if you would be kind enough to extract a copy of your chip via RoverGauge and email it to Dan as I’m sure we could learn something from it and also possibly answer your question.
When you say "it continues to run without fault" do you also mean without a fault code in RoverGauge? Sorry to be so meticulous.

Dan,
I notice the code path control flag in the data we discussed is used to stop the Lambda reading being applied to the fuelling but does $C0A0 actually stop the Lambda short and long trims being calculated in the first place? Tomorrow night I’ll search for $C0A0 in the code and try to follow your detailed comments, I'll have a look even if you or Dave beat me to it as Mike's tune sounds fascinating.
Cheers for now, Steve

[MikeG]

Hi,

I have emailed Dan so that I may send him a copy of my Rom image.
My car is a 1995 model 500HC which I have owned since 1997. It is a serpentine engine with T5 gearbox. I had the non-Cat headers and Y piece (also including the ECU upgrade) along with the exhaust replaced after I bought the car and was told that it was TVRs own parts from a non-Cat export model. This ties up with the specification of the headers and Y piece, as apart from the lack of Cats and lambda mountings they look exactly like the serpentine standard units. So I guess that may tie up with the Channel Islands specification.
I have not checked via RoverGauge for faults as the car runs great both on track/open road and in traffic. When I next get a moment I will check and post regarding any flagged ECU faults.

Hope this helps
Mike

[davep]

Guys, as far as I can make out $C0A0 (a data byte defined in the LimpHome map data section as $80 in all the tunes I've seen) is used to enable or disable Long Trim adjustment only and has nothing to do with Short Trim, and this is done at various times in the ICI:

- phase 2 Compensation
- LF171 (misc routine), where the $80 value is ANDed to set bit 7 to zero (long term disabled)
- another misc routine, where the $80 value is shifted out to verify bit 7 is zero (long term disabled).

So with $C0A0 set for $FF, Long Term adjustment will always be enabled, and with a value $00 always disabled.

What the second and third routines do exactly in the resultant branches I'm not sure, needs flowcharting to be absolutely sure.

MikeG could you do a RoverGauge screen capture with the Lambda trim value option set for 'Long term' and did you have the Lambda trim option selected (Options/Edit settings...) when you did the screen capture?

danbourassa said:

Mike,
You are probably correct that there is no oscillator. I believe that this would give you short term values close to zero but not necessarily zero. The values you have are exactly zero which is consistent with an open map. RoverGauge is showing the short term values because map 5 is normally closed loop. It appears that you have an unusual PROM (I would love to have a copy of the binary). The checksum byte of $1A also indicates that this PROM is unusual. I'm very curious about how this was done. I can't believe it was done by changing the code section. Recently we have discussed, in this thread, data bytes in the data section of the PROM that seem to be used to control the code path. There is a bit that can be set (or cleared) to force open loop under all map conditions. I'm guessing that this was done for your PROM. Up until now, I thought that this bit was just used for code development or factory testing. (Looks like I'm wrong again!)

RoverGauge may need to be updated to be aware of this bit.

Dan, looking at the dimmed (disabled?) labels in MikeG's screen capture it appears RoverGauge differentiates between an open loop map and a closed loop map (permanently?) in open loop mode when determining what or how to display labels in the Lambda trim/CO trim fields, is this done in one of the closed/open loop check?

Edited by davep on Wednesday 26th November 14:25

[MikeG]

Dave,

I should get a chance to run my Griff up tomorrow morning so will try and get the RoverGauge screen capture that you have asked for. I recall that when I set up RG that I disabled the lambda readings for obvious reasons. I will however try the settings you have asked for and post the resulting screen dump.

Mike
PS Dan should have received a copy of my Rom image by now.

[danbourassa]

MikeG said:

Dan should have received a copy of my Rom image by now.

I got it, Mike. Thanks. It'll be a couple of days before I look at it due to the Thanksgiving holiday.

[stevesprint]

davep said:

looking at the dimmed (disabled?) labels in MikeG's screen capture

Dave, I’m impressed you spotted Mike’s Lambda trims are grayed out which indicates Mike disable them in the settings. I would of thought Colin coded RG maps 4 & 5 as cat maps because maps 4 & 5 are hard coded in the 14CUX as cats maps.

davep said:

Guys, as far as I can make out $C0A0 (a data byte defined in the LimpHome map data section as $80 in all the tunes I've seen) is used to enable or disable Long Trim adjustment only and has nothing to do with Short Trim, and this is done at various times in the ICI:

- phase 2 Compensation
- LF171 (misc routine), where the $80 value is ANDed to set bit 7 to zero (long term disabled)
- another misc routine, where the $80 value is shifted out to verify bit 7 is zero (long term disabled).

Dave,
Ah, I see the 'code control byte' (Prom offset 0A0) uses bits 7 to stop the trim being applied to the fuelling calculations and bits 0 to 4 to alter the trim calculations, it’s neat the way assembler use and manipulates all 16 bits individually.

Bits 0 to 4 may may alter some of the trim calculations but I'm not convinced it would also stop the Lambda fault codes? Therefore does the 'code control byte' (C0A0) indirectly effect the value of X0087 that controls when to run open and closed loop and the lambda fault codes?

It will be very interesting to hear if Mike is getting Lambda fault codes.