Instructions to change fuel maps on 14CUX Griffith, Chimaera
Discussion
Ah, could be a R2157, also explains why the checksum appears wrong in the toolkit. I use a Willem programmer and haven't had any issues with it, the R2666 compares identical to the R2666 from Dan's repository. The chip I select for reading is 27C128. The hand written label could also be 2157, the first number is not written very clearly (could be a 2 or a 3). Also explains why the ROM uses the old offset. There seems to be more corrupted as fixing the ID alone does not fix the checksum.
For the xdf and roms, please share alike. I'll also be using all your work
.
Edit: Maybe I did something wrong when reading, I'll try to read it again when I'm back home.
For the xdf and roms, please share alike. I'll also be using all your work
.Edit: Maybe I did something wrong when reading, I'll try to read it again when I'm back home.
Edited by TomcatErik on Friday 30th January 09:38
JOA said:
There is another question I have really been wanting to ask you guys. What is the difference between High Compression and Low Compression tunes? My Range Rover had a 3.9L Low Comp engine in it when I bought it, but I replaced it with a higher compression 4.0L from a 1996 discovery. The new engine is the same displacement, really the same engine, just higher compression so I did not expect it to need different fueling.
I have been looking at some of the differences between the high compression (9.35 CR) and low compression (8.13 CR) versions of the 3.9L engine. The workshop manual, not surprisingly, quotes slightly higher power at slightly higher RPM for the high CR engine. But it also specifies different spark plugs and a different distributor. The centrifugal curve is quite different. That being the case, we should also expect differences between R3360 code (high CR) and R3362 code (low CR) and there are, in fact, differences not only in the basic fuel map but also in the warm-up tables, acceleration/deceleration tables, etc.My research indicates that the CR was 9.35 for the UK when the Range Rover was introduced to the USA with the 8.13 CR. They may have lowered it for the US market for emissions reasons (lower NOx, I think). The CR eventually became 9.35 in the US for the 93 model year. It seems that engine efficiency and fuel consumption was the reason for this.
The 4.0L is a better engine than the 3.9L. The block was redesigned for cross-bolting and extra stiffening. I think they also eliminated the lowest row of head bolts that were doing more harm than good. Joel, I think you should use a high compression tune (R3360 or later) but also make sure you also have the correct advance curve.
Dan - bit of a revisit to the earlier bit on over riding the long term trim setting. Although Ive done it with fake lambda signals- its not proved reliable, so how hard is it to simply use a little software routine to reset any long trim trim values say every 30 seconds? Is it simply a case of firing a value into the storage ram location that's been identified, or is it more complex?
blitzracing said:
Dan - bit of a revisit to the earlier bit on over riding the long term trim setting. Although Ive done it with fake lambda signals- its not proved reliable, so how hard is it to simply use a little software routine to reset any long trim trim values say every 30 seconds? Is it simply a case of firing a value into the storage ram location that's been identified, or is it more complex?
MarkI once enabled the CO trim screw for map 5 which meant the long trim was constantly overwritten by the CO trim value. Then setting the CO trim to 1.25v would permanently hold the long trim at zero or did you particularly want it reset every 30 seconds?
Email me a bin if you want to give it ago.
Steve
Steve's idea might work although you will probably end up with two routines in the code that are writing to the same long term trim locations. One being the trim voltage measurement and the other being the automatic closed loop process. I'm guessing that the CO trim voltage routine would write at a much faster rate but the results could still be messy.
Lucas actually provided a means of turning off long term trim. The byte value at location $C0A0 (file offset $00A0) is normally $80. Change this to $00 (clearing bit 7) and the application of the long term trim should be bypassed. It may still be calculated and RoverGauge may still show a non-neutral value, but it will simply not be added to the fuel value. Dave, since I've never tried this myself, can you look at this to verify what I'm claiming?
Lucas actually provided a means of turning off long term trim. The byte value at location $C0A0 (file offset $00A0) is normally $80. Change this to $00 (clearing bit 7) and the application of the long term trim should be bypassed. It may still be calculated and RoverGauge may still show a non-neutral value, but it will simply not be added to the fuel value. Dave, since I've never tried this myself, can you look at this to verify what I'm claiming?
So as a useful tool, we could add this location and value to the .xdf file as label it as "bypass LT trim" ? The idea being you could simply set this before mapping, and then re enable it afterwards? It maybe pure folly, as I suspect in the real world the long term trim does not cause any problems if dont let the car idle after resetting the ECU to zero the trim but I just like having a stable platform to work with.
I would imagine that if you were creating a bespoke map then disabling the long term trim and not re-enabling it shouldn't cause any issues, until that is the engine tune changes slightly and there ecu then can't re-adapt.
there's plenty of people inadvertantly disabling the long term trim themselves anyway by fitting lower temperature thermostats and otter switch bypasses on the dashboard so that their ecus never see the long term trim set-on temperature. Presumably these cars all run fine ?
there's plenty of people inadvertantly disabling the long term trim themselves anyway by fitting lower temperature thermostats and otter switch bypasses on the dashboard so that their ecus never see the long term trim set-on temperature. Presumably these cars all run fine ?
spitfire4v8 said:
... there's plenty of people inadvertantly disabling the long term trim themselves anyway by fitting lower temperature thermostats and otter switch bypasses on the dashboard so that their ecus never see the long term trim set-on temperature. Presumably these cars all run fine ?
Jools they would have to have very low temperature rated thermostats fitted or be capable of running with very little or no throttle for sustained periods. The individual conditions for forcing open loop and simply negating the need to adjust long term trim are:- Fuel map 1, 2 or 3 selected (should cause 0xC099 to be set with a non-zero value)
- MAF > 2.0 Volts AND Coolant Temp < 50 degrees C
- TPS > 40% AND Coolant Temp < 50 degrees C
- MAF fault occurs
- Throttle pot is > 91% (approx 4.6 Volts)
- RPM > 3400
- Engine speed is at the predefined RPM limit value
- Low engine RPM, less than 505 RPM
- Road speed is low
- Engine in startup fuelling state.
Similarly, there are two sets of combined conditions for ignoring long term trim.
Set 1:
- Road speed is greater than 4 KPH, AND
- Throttle pot signal is less than throttle pot minimum (plus a small working margin) AND
- Coolant temperature is cooler than 83 degrees C.
Set 2:
- Throttle pot signal is less than throttle pot minimum (plus a small working margin) AND
- Automatic gearbox is in neutral not drive AND
- Road speed is less than 4 KPH, AND
- Coolant temperature is cooler than 40 degrees C.
danbourassa said:
Steve's idea might work although you will probably end up with two routines in the code that are writing to the same long term trim locations. One being the trim voltage measurement and the other being the automatic closed loop process. I'm guessing that the CO trim voltage routine would write at a much faster rate but the results could still be messy.
Lucas actually provided a means of turning off long term trim. The byte value at location $C0A0 (file offset $00A0) is normally $80. Change this to $00 (clearing bit 7) and the application of the long term trim should be bypassed. It may still be calculated and RoverGauge may still show a non-neutral value, but it will simply not be added to the fuel value. Dave, since I've never tried this myself, can you look at this to verify what I'm claiming?
I can, and, as you say a zero value in $C0A0 would conveniently take out Phase 2 Fuel Compensation, but it may also have an impact on LF171, which is called by Long Term Trim Adjustment much earlier in the ICI (part of flowchart process 35), so this could take some time as these are gray areas for me. Lucas actually provided a means of turning off long term trim. The byte value at location $C0A0 (file offset $00A0) is normally $80. Change this to $00 (clearing bit 7) and the application of the long term trim should be bypassed. It may still be calculated and RoverGauge may still show a non-neutral value, but it will simply not be added to the fuel value. Dave, since I've never tried this myself, can you look at this to verify what I'm claiming?
Edited by davep on Monday 2nd February 00:08
Mark & Paul
I’ve added “Enable long term trim (Map 4 & 5)” to TunePro under the new “Flags” heading. I’ve called it enable instead of bypass, as there is a new tick box that you untick to bypass it. I’ve also fixed the main table column headings so they always display the correct RPM points for standard and extended tables. It also contains the throttle opening/closing and temperature enrichment tables plus TomcatErik additions like TuneID, MIL enable and overrun fuelling. You can download it from http://www.stevesprint.com/remap-14cux/gadgets.htm...
Dan’s approach is much better as it simply stops the code applying the long trim when calculating the injector pulse, even though the long trim will still be calculated. You also won’t have to mess around with the CO trim screw. When I tested $00A0 = 00 in November last year I was confident the long trim wasn’t applied to the injector pulse calculations but I wasn’t so sure about the short trim, See page 35.
We also have a third option that in addition also disables the short term trim.
Enjoy, Steve
I’ve added “Enable long term trim (Map 4 & 5)” to TunePro under the new “Flags” heading. I’ve called it enable instead of bypass, as there is a new tick box that you untick to bypass it. I’ve also fixed the main table column headings so they always display the correct RPM points for standard and extended tables. It also contains the throttle opening/closing and temperature enrichment tables plus TomcatErik additions like TuneID, MIL enable and overrun fuelling. You can download it from http://www.stevesprint.com/remap-14cux/gadgets.htm...
danbourassa said:
Lucas actually provided a means of turning off long-term trim. The byte value at location $C0A0 (file offset $00A0) is normally $80. Change this to $00 (clearing bit 7) and the application of the long-term trim should be bypassed. It may still be calculated and RoverGauge may still show a non-neutral value, but it will simply not be added to the fuel value. Dave, since I've never tried this myself, can you look at this to verify what I'm claiming?
Mark,Dan’s approach is much better as it simply stops the code applying the long trim when calculating the injector pulse, even though the long trim will still be calculated. You also won’t have to mess around with the CO trim screw. When I tested $00A0 = 00 in November last year I was confident the long trim wasn’t applied to the injector pulse calculations but I wasn’t so sure about the short trim, See page 35.
danbourassa said:
Steve's idea might work although you will probably end up with two routines in the code that are writing to the same long-term trim locations. One being the trim voltage measurement and the other being the automatic closed loop process. I'm guessing that the CO trim voltage routine would write at a much faster rate but the results could still be messy.
Dan has a very good point but luckily when I tested map5 with the CO trim screw enabled the CO trim screw took priority and I actually had manual control of the long term trim while running map5. As you know the long trim is only recalculated at idle after two minutes and even then the CO trim still took priority.We also have a third option that in addition also disables the short term trim.
stevesprint said:
danbourassa said:
I'm now convinced that the CO trim is the open loop equivalent of the long-term trim. Adjusted manually by the user but applied by software in the same way.
This confirms copying map5 to map2 and setting the CO Trim to 1.25v (the mid point) is an effective way to disable lambda control. Edited by stevesprint on Sunday 1st February 21:20
Hoover. said:
.....be good see it cracked 
HooverIt was cracked last year and as a result Jools remapped 12 Giffs/Chimmys last year including a couple with larger Air Flow Meters. We can now do most things an engine tuner would hope for from the 14CUX. I’m sorry we were to late to save your 14CUX. We are now enjoying helping others, toying with minor refinements and learning more about the program code.
It was good to catch up with you at Neil Garner.
Best Wishes
Steve
blitzracing said:
Thanks Steve you have saved me the pain of messing around with any more transistor oscillators- I could get to like this software stuff.
Pleasure, You know I'll always give you a hand over the phone or at the TVR pub meeting.As you know the 14CUX so well I'm sure you’ll instantly reconise the contents of Dan’s data files for the software. It’s a very convenient way to document and track your changes plus you don’t have to understand the program. You can download a copy via one of the links at the bottom of this page. http://www.stevesprint.com/remap-14cux/bins
WeLL, I've done some testing yesterday with the reprogrammed ECU, using the 6200rpm TVR4.3 ROM of Steve. The noisy map (mpa 2) is indeed very noise during overrun, the car sounds like a group N rally car (there is only a small freeflow silencer in the exhaust). I did some tests on the road and have a couple of questions:
1) During idling it is on row 2/3 60%/40% (950rpm during idle), is this oke or should it be at least 90% on row 2?
2) Using full throttle it never reaches bottom row, with soft highlight I can that it uses the bottom row but never as major setting. I do have the idea that it reaches the 2nd to last row too early. Is this possible?
3) How far can we go with the map multipliers (assuming highest map value is xFF) before the injectors will be at 100% duty cycle?
4) What is the cc/min rating of the stock ERR772A injectors?
5) The rovergauge speedo is reading 0kmph, therefore I suspect the speedo signal is not connected. How does this influence the ECU, as there are some comparisons on the road speed in software?
6) There appears to be a small dip at 6000rpm, is this because the CPU can't keep up at high rpm?
I do not completely trust the AFR meter in the car, but it is still running lean so I will be playing a bit more with the map multiplier to get the coarse setting right. AFR is now between 13 and 15, my target is to have it between 12 and 13.5 over the entire map.
By the way, the car pulls like a bear already, I suspect it did run very lean previously.
1) During idling it is on row 2/3 60%/40% (950rpm during idle), is this oke or should it be at least 90% on row 2?
2) Using full throttle it never reaches bottom row, with soft highlight I can that it uses the bottom row but never as major setting. I do have the idea that it reaches the 2nd to last row too early. Is this possible?
3) How far can we go with the map multipliers (assuming highest map value is xFF) before the injectors will be at 100% duty cycle?
4) What is the cc/min rating of the stock ERR772A injectors?
5) The rovergauge speedo is reading 0kmph, therefore I suspect the speedo signal is not connected. How does this influence the ECU, as there are some comparisons on the road speed in software?
6) There appears to be a small dip at 6000rpm, is this because the CPU can't keep up at high rpm?
I do not completely trust the AFR meter in the car, but it is still running lean so I will be playing a bit more with the map multiplier to get the coarse setting right. AFR is now between 13 and 15, my target is to have it between 12 and 13.5 over the entire map.
By the way, the car pulls like a bear already, I suspect it did run very lean previously.
danbourassa said:
... Lucas actually provided a means of turning off long term trim. The byte value at location $C0A0 (file offset $00A0) is normally $80. Change this to $00 (clearing bit 7) and the application of the long term trim should be bypassed. It may still be calculated and RoverGauge may still show a non-neutral value, but it will simply not be added to the fuel value. Dave, since I've never tried this myself, can you look at this to verify what I'm claiming?
Things were going reasonably well until I tried to assign function descriptions to control bits bits_0089.2:0 in Adjust Long Term Trim value (35). I can find where these bits are cleared and checked throughout the code but where they are actually set eludes me. In my searching I eventually ended up in 'closed loop code to be studied' (27), and now I appreciate why it needs to be studied! Once right and left bank startup timers have timed out and indexed addressing setup, the elusive bits_89.2:0 are checked and cleared, but it is their actual function that I cannot fathom. I think they may have something to do with where the engine is in terms of startup and running status as they are checked again further down in (35) even though they've been cleared in (27). So back to (27), and once MAF level and ECT < 87 degrees C are validated then comes an exercise in indexed addressing par excellence (LE1B2 - LE216), which is where I got a headache and gave up!So in answer to your request Dan, I'd say yes in all likelihood the Long Term Trim adjust value is still calculated regardless of Phase 2 Fuel Compensation being bypassed or not.
Edited by davep on Thursday 5th February 00:09
TomcatErik said:
WeLL, I've done some testing yesterday with the reprogrammed ECU, using the 6200rpm TVR4.3 ROM of Steve. The noisy map (mpa 2) is indeed very noise during overrun, the car sounds like a group N rally car (there is only a small freeflow silencer in the exhaust). I did some tests on the road and have a couple of questions:
1) During idling it is on row 2/3 60%/40% (950rpm during idle), is this oke or should it be at least 90% on row 2?
2) Using full throttle it never reaches bottom row, with soft highlight I can that it uses the bottom row but never as major setting. I do have the idea that it reaches the 2nd to last row too early. Is this possible?
3) How far can we go with the map multipliers (assuming highest map value is xFF) before the injectors will be at 100% duty cycle?
4) What is the cc/min rating of the stock ERR772A injectors?
5) The rovergauge speedo is reading 0kmph, therefore I suspect the speedo signal is not connected. How does this influence the ECU, as there are some comparisons on the road speed in software?
6) There appears to be a small dip at 6000rpm, is this because the CPU can't keep up at high rpm?
I do not completely trust the AFR meter in the car, but it is still running lean so I will be playing a bit more with the map multiplier to get the coarse setting right. AFR is now between 13 and 15, my target is to have it between 12 and 13.5 over the entire map.
By the way, the car pulls like a bear already, I suspect it did run very lean previously.
1) During idling it is on row 2/3 60%/40% (950rpm during idle), is this oke or should it be at least 90% on row 2?
2) Using full throttle it never reaches bottom row, with soft highlight I can that it uses the bottom row but never as major setting. I do have the idea that it reaches the 2nd to last row too early. Is this possible?
3) How far can we go with the map multipliers (assuming highest map value is xFF) before the injectors will be at 100% duty cycle?
4) What is the cc/min rating of the stock ERR772A injectors?
5) The rovergauge speedo is reading 0kmph, therefore I suspect the speedo signal is not connected. How does this influence the ECU, as there are some comparisons on the road speed in software?
6) There appears to be a small dip at 6000rpm, is this because the CPU can't keep up at high rpm?
I do not completely trust the AFR meter in the car, but it is still running lean so I will be playing a bit more with the map multiplier to get the coarse setting right. AFR is now between 13 and 15, my target is to have it between 12 and 13.5 over the entire map.
By the way, the car pulls like a bear already, I suspect it did run very lean previously.
I’m glad you like the new overrun sound track, if its too much you know how to change the RPM set point in TunerPro or you could quieten it down by slightly enriching the top row.
I’ll answer what I can
1) You may be able to move the idle row and improve the bottom row usage by playing around with “TABLE 1-5 MAF Scalar” & “TABLE 1-5 MAF Scalar Offset” in TunerPro. The scalar increases/decrease the scale and the offset move the mid point of the table.
2) I wouldn’t expect a 3.9L to flow enough air to hit the bottom row of the 4.3 fuel table. You need to run a 3.9 map that will have the correct table scalars for a 3.9. I’ve already put together a R3562 with an extend RPM table for a 3.9L/4L and I’m looking for volunteers to test it, hint hint.
3) Don’t know but Jools had no trouble mapping a 5.3L with a larger AFM.
4) Don’t know but more than enough for a Griff 500
5) If your speedo isn’t connected you would know about it as the ECU software would deliberately stall the engine at idle to make you fix the speedo.
6) The small AFR dip is caused by the extended table not being completely smooth between the RPM set points. It’s so small it’s not a major issue but maybe one day I’ll have another go at smoothing it out. Have a look at my AFR graph on page 3 on http://www.pistonheads.com/gassing/topic.asp?h=3&a...
davep said:
So in answer to your request Dan, I'd say yes in all likelihood the Long Term Trim adjust value is still calculated regardless of Phase 2 Fuel Compensation being bypassed or not.
While discussing my AFR readings, with Mark Blitz, that shows the long trim is not applied with A0=00 he explained the long trim maxes out in RoverGauge because the ECU code keeps adding long trim to correct the AFR and can’t as the long trim is not actually applied. As my AFR gauge and RoverGauge readings show its not applied I’m now convinced A0=00 bypasses the application of the long trim, it's more than just a hunch . Its also interesting to note A0=00 suppresses the fault codes.stevesprint said:
While discussing my AFR readings, with Mark Blitz, ... he explained the long trim maxes out in RoverGauge because the ECU code keeps adding long trim to correct the AFR ....
Mark did you see this in the ECU code and where it is done or did you come to this conclusion from observing the LT trim progress bars in the RoverGauge screen?davep said:
stevesprint said:
While discussing my AFR readings, with Mark Blitz, ... he explained the long trim maxes out in RoverGauge because the ECU code keeps adding long trim to correct the AFR ....
Mark did you see this in the ECU code and where it is done or did you come to this conclusion from observing the LT trim progress bars in the RoverGauge screen?Both the long term trims started in the middle (0%) and after 2 minutes at idle started moving at the same time in opposite directions at the normal rate until 100%. At first it looked very spooky (it was the night after Halloween see page 35), but now Marks explaination makes perfect sense as one of my long trims is normally plus and the other normally minus. The code calculated the need for more long trim but as it wasn’t being applied kept on calculating more long trim until they reached +/- 100%.
It’s a bit like if I gave you alcohol free beer without you knowing it’s alcohol free you’ll keep drinking and drinking it until you run out as it has no effect. Sorry, you can tell what’s on my mind, wheres the fridge?
Cheers !!!
Steve
Gassing Station | Griffith | Top of Page | What's New | My Stuff