Instructions to change fuel maps on 14CUX Griffith, Chimaera

[blitzracing]

stevesprint said:

I like the sounds of that as the 4.3’s have the largest fuel map multiplier and the same calc fuel table row as the 500's. hummm I wonder why – over fuelling to make them smoother.

I think its because of the issue with the exhaust gas getting back into the plenum at low rpm with a performance cam, so it contaminates incoming fresh air. This leads to poor combustion, and adding a bit more fuel seems to mask the issue.

[davep]

stevesprint said:

Dave, I personally thought TVR deliberately setup the precats rich to make the engines run smoother .... the TVR 2422 code is identical to LR 2422 ...

blitzracing said:

I think its because of the issue with the exhaust gas getting back into the plenum at low rpm with a performance cam, so it contaminates incoming fresh air. This leads to poor combustion, and adding a bit more fuel seems to mask the issue.

Steve, Mark, any ideas where this fuel enrichment takes place if not in the ECU/EPROM?

Steve, I like your Limp Home for closed loop theory, must check that out.

stevesprint said:

I like the sounds of that as the 4.3’s have the largest fuel map multiplier and the same calc fuel table row as the 500's. hummm I wonder why – over fuelling to make them smoother.

Where have you seen code showing 430s have the largest multiplier Steve?

[stevesprint]

blitzracing said:

I think its because of the issue with the exhaust gas getting back into the plenum at low rpm with a performance cam, so it contaminates incoming fresh air. This leads to poor combustion, and adding a bit more fuel seems to mask the issue.

Thanks Mark, I learn something everyday.

davep said:

Steve, Mark, any ideas where this fuel enrichment takes place if not in the ECU/EPROM?

It can only be in the ECU.

davep said:

Steve, I like your Limp Home for closed loop theory, must check that out.

It’s more of a gut feeling based on my limited knowledge and experiments, we really need to check with the Oracle.

davep said:

Where have you seen code showing 430s have the largest multiplier Steve?

I’m so anal I spend my evenings searching through the bin’s in HexEditor and then make notes in a speadsheet. For the precat’s (2422 map2) look at offset 3D1 or 43D1 and for the later (2967 map5) TVR's look at address 72F or 472F.

The fuel multipliers are as follows:-
400 Precat - 5D BE
430 Precat - 6B 6C
400 CAT - 56 CC - (CAT 400 has a lower multiplier than the precat 400 and TVR quote the same bhp)
450 CAT - 69 78 - (Interesting a 450 has a higher multiplier than a 500)
500 CAT - 67 84 - (1994 & 1995)

[davep]

stevesprint said:

davep said:

Steve, Mark, any ideas where this fuel enrichment takes place if not in the ECU/EPROM?

It can only be in the ECU.

But your bin Hex check of TVR and LR 2422s showed no differences so looks like all Fuel Map 2 users had this fuel enrichment feature, not just TVRs.

stevesprint said:

I’m so anal I spend my evenings searching through the bin’s in HexEditor and then make notes in a speadsheet. For the precat’s (2422 map2) look at offset 3D1 or 43D1 and for the later (2967 map5) TVR's look at address 72F or 472F.

The fuel multipliers are as follows:-
400 Precat - 5D BE
430 Precat - 6B 6C
400 CAT - 56 CC - (CAT 400 has a lower multiplier than the precat 400 and TVR quote the same bhp)
450 CAT - 69 78 - (Interesting a 450 has a higher multiplier than a 500)
500 CAT - 67 84 - (1994 & 1995)

Blimey you're right, it was staring me in the face and it never registered. This could be the cause for the 430 pre-cat loads-a-fuel feature. Now I can get on trying your bin out on my car.

[stevesprint]

robertf03 said:

Ok, maybe this was obvious to some, but it looks like the scalar is the most important part of setting up these maps. I believe it is some mathmatical combo of target AFR and cylinder size

The actual fuel table appears just to be an adjustment of % load divided by fuel needed. It looks like it coincides with the engine sweet spot based on camshaft and heads

a quick table that divides the % of fuel (fuel cell value /256) / engine load based on MAF

Robert,
It would be cool if it really is a combo of target AFR and cylinder size.

I’ve copied my fuel table into excel and created another table with your equation in every cell multiplied by a constant. The trouble is my constant appears to be 4.3 litres times 25 not 5300 as in your examle. Therefore please can you confirm the equation in each cell should be "((fuel cell value /256) / engine load) x constant", maybe the constant is different for my 4.3.

Cheers
Steve

[stevesprint]

davep said:

But your bin Hex check of TVR and LR 2422s showed no differences so looks like all Fuel Map 2 users had this fuel enrichment feature, not just TVRs.

Sorry, I failed to point out that I was only comparing the code which starts at offset 800. The LR and TVR fuel tables are very different as you would expect.
Cheers for now
Steve

[danbourassa]

stevesprint said:

Dave, I wouldn’t worry to much about the old TVR 2422 code as my car runs much better on the later code and the most noticeable improvement is the idle is held slightly higher while coasting and finally drops to idle once stationary. This makes feathering the throttle at slow speed smoother. Interestingly the TVR 2422 code is identical to LR 2422 except 1 byte at address 2B8E, which I can’t workout as Dan has been working on the later and better code, and quite right too.

Steve, if the byte difference is $FF versus $C0, I believe you found an error in the early 2422 code. Here is the difference:

Bad code:
EB8D : FE FF 9E    ldx  XFF9E  ; load X
EB90 : DF 94       stx  X0094  ; store X

Good Code:
       FE C0 9E    ldx  XC09E
       DF 94       stx  X0094 

The bad code shows the address, the binary data and assembly language in that order. The intent is to initialize two contiguous byte locations in RAM with fixed data. This is done by loading the 16-bit index register with the two bytes of data and then storing the register contents at locations X0094/95.

The later code pulls the value $0002 from XC09E (in the data section of the PROM) and stores $00 in X0094 and $02 in X0095. Very normal.

The older code appears to have a corrupted address upper byte ($FF instead of $C0). The location XFF9E is an unused area of the PROM, so $FFFF was getting loaded and the value $FF was getting written to both X0094 and X0095.

How did this code get released with this bug undetected? I have a theory. The two values X0094 and X0095 are used as signed bytes. The values are usually in the range of -1 to +3 and since the value $FF is -1 (two's complement), the initial value was very close and within the normal range.


As far as the better stepper motor performance, Lucas put a lot of effort into improving this over the code's development life. Later code has additional routines that don't exist in early code. TVR code had already been branched off to it's own development thread and didn't benefit from this work.

Edited by danbourassa on Monday 24th February 01:29

[davep]

danbourassa said:

Steve, if the byte difference is $FF versus $C0, I believe you found an error in the early 2422 code. Here is the difference:

Bad code:
EB8D : FE FF 9E    ldx  XFF9E  ; load X
EB90 : DF 94       stx  X0094  ; store X

Good Code:
       FE C0 9E    ldx  XC09E
       DF 94       stx  X0094 

The bad code shows the address, the binary data and assembly language in that order. The intent is to initialize two contiguous byte locations in RAM with fixed data. This is done by loading the 16-bit index register with the two bytes of data and then storing the register contents at locations X0094/95.

The later code pulls the value $0002 from XC09E (in the data section of the PROM) and stores $00 in X0094 and $02 in X0095. Very normal.

The older code appears to have a corrupted address upper byte ($FF instead of $C0). The location XFF9E is an unused area of the PROM, so $FFFF was getting loaded and the value $FF was getting written to both X0094 and X0095.

How did this code get released with this bug undetected? I have a theory. The two values X0094 and X0095 are used as signed bytes. The values are usually in the range of -1 to +3 and since the value $FF is -1 (two's complement), the initial value was very close and within the normal range.


As far as the better stepper motor performance, Lucas put a lot of effort into improving this over the code's development life. Later code has additional routines that don't exist in early code. TVR code had already been branched off to it's own development thread and didn't benefit from this work.

Edited by danbourassa on Monday 24th February 01:29

Dan, I'm probably being a bit dense here, but how did you arrive at PROM address EB8D/E from Steve's quoted address of 2B8D/E (wherever that is)? Is there some indexing going on?

[danbourassa]

davep said:

Dan, I'm probably being a bit dense here, but how did you arrive at PROM address EB8D/E from Steve's quoted address of 2B8D/E (wherever that is)? Is there some indexing going on?

Dave, when looking at the PROM binary file with a hex editor, the first address location is $0000. However, we tell the disassembler to start at address $C000 by using the command "org 0xC000" (usually in the symbol file). This duplicates the addressing of the 14CUX board. So just add the offset $C000 to $2B8D.

[davep]

danbourassa said:

Dave, when looking at the PROM binary file with a hex editor, the first address location is $0000. However, we tell the disassembler to start at address $C000 by using the command "org 0xC000" (usually in the symbol file). This duplicates the addressing of the 14CUX board. So just add the offset $C000 to $2B8D.

Thanks for that Dan, explains why I haven't managed to understand anything Hex editor Steve writes.

Remembered I actually have RoverGauge and not just ASM files today, so I had a thorough test session to check out the Tune Resistor/Limp Home Mode in open loop operation (pre-cat 430). Here’s a selection of the relevant screens and some observations:-

1. First screen shows: RG connected, ignition on, engine not running.



Idle bypass position is 100%.

2. This screen shows: engine at idle, tune resistor connected.



Idle bypass position is now 17%, error code 48 set for stepper motor fault. Tune field and Fuel Map RPM column headings missing.
There was no change when I pulled the tune resistor out of circuit other than the Tune Resistor fault code indicator being set. So no tune resistor selection is possible while the engine is running.

3. This screen shows: ignition off, ignition on, engine not running, tune resistor disconnected, and fault code screen.



The fuel map is now Limp Home (0) and there are changes in Idle bypass position (reverts to 100%) and the short term Lambda fuel trim values (-100%). So, in open loop mode with the Tune Resistor fault code set, the Limp Home map cannot be selected until an ignition off/on has been done. Limp Home is only used in the event of a tune resistor value related fault.

Reconnected the tune resistor, no change to the fuel map selection.

4. Finally: ignition off, ignition on, engine at idle, tune resistor reconnected.



Fuel map 2 selected, all fields correct and the Tune field and Fuel Map column headings have now appeared.

Edited by davep on Monday 24th February 22:33

[stevesprint]

danbourassa said:

Dave, when looking at the PROM binary file with a hex editor, the first address location is $0000. However, we tell the disassembler to start at address $C000 by using the command "org 0xC000" (usually in the symbol file). This duplicates the addressing of the 14CUX board. So just add the offset $C000 to $2B8D.

Dave, I’m very very sorry for any confusion caused. I guess Dan knows me well enough that I’m limited to talking in prom offsets which incidentally has proved perfect for analysing the fuel tables and setting up TunerPro. Now I’ve started looking at the assembly code I now realise the prom offset is irrelevant as all code references relate to the 14CUX board addresses. I’ll consider myself told off, only joking. In future I’ll be clearer about the addressing I’m using.

danbourassa said:

As far as the better stepper motor performance, Lucas put a lot of effort into improving this over the code's development life. Later code has additional routines that don't exist in early code. TVR code had already been branched off to it's own development thread and didn't benefit from this work.

Dave
Please don't get too excited about using my 2967 Prom as I’ve just revisited my notes and as usual Dan is absolutely right, it was LR 3833 that held the idle slightly higher while coasting. Nevertheless 2967 is a subtle improvement worth having plus the target idle is displayed in RoverGauge.

You maybe thinking why not just run the later code, well I did try the 430 main fuel table and multiplier only in LR 3383 but that was before I knew about the other tables like coolant and throttle. From reading my notes I can safely say the idle control was even better in 3833 but the warm up was pants and the over run was muted, this highlights the importance to copy all the tables include coolant and throttle.

Although my 4.3 drives very well on 2967 we'll need all the code improvements we can have once we start leaning off the fuel mixture. I wonder with the better idle control of the later code can we reduce the fuel mixture enough to stop precat Griffs from smelling of exhaust fumes or is that impossible due to the cam over lap that Mark kindly explained.

I can't wait to start re-testing the later code again once my Griff is back on the road in the spring with my new wideband Lambda probe and logger. We have a lot of 14CUX fun ahead.

[stevesprint]

danbourassa said:

Steve, if the byte difference is $FF versus $C0, I believe you found an error in the early 2422 code. Here is the difference:

Yes Dan that’s it, the TVR code has FF and the Land Rover code has C0

danbourassa said:

The later code pulls the value $0002 from XC09E (in the data section of the PROM) and stores $00 in X0094 and $02 in X0095. Very normal.

The older code appears to have a corrupted address upper byte ($FF instead of $C0). The location XFF9E is an unused area of the PROM, so $FFFF was getting loaded and the value $FF was getting written to both X0094 and X0095.

The later code meaning LR 2422 and the older code meaning TVR 2422. Amazing its an incorrect memory address, it’s definitely a bug TVR introduced as the checksum fixer is correct.
I guess you had to reverse engineer 2422 for RoverGauge.

[robertf03]

stevesprint said:

Robert,
It would be cool if it really is a combo of target AFR and cylinder size.

I’ve copied my fuel table into excel and created another table with your equation in every cell multiplied by a constant. The trouble is my constant appears to be 4.3 litres times 25 not 5300 as in your examle. Therefore please can you confirm the equation in each cell should be "((fuel cell value /256) / engine load) x constant", maybe the constant is different for my 4.3.

Cheers
Steve

If one were to replace the stock 18.5lb injectors with 24lb the multiplier should be scaled accordingly.

So I'm thinking its this:

Engine Size X Injector Size X Maximum AFR X Constant.

Who knows what units the original developers used, so the constant would make up for that. I could be way off and none of that would apply, but I doubt it. GM ECU's from the same era have a similar constant.

I scaled the 3360 fuel constant by dividing it by 2.8 and multiplying by 3.222 so I'd have something "safe" for the 4.6 cam break in. It drives great, but I just put it together this weekend. I'll get the wideband out this week and see how it looks.

[robertf03]

Something I've overlooked is the MAF multiplier value.

I'm sure that going from a 3.9 to a 4.6 is causing the current 3360 code to report a higher load cell than it actually should be in based on the engine displacement and probably running extremely rich before trims as a result.

What do you all think about this attempt:

I am going to hook a vacuum gauge to the manifold and live tune the MAF multiplier for the selected fuel cell until vacuum/ambient pressure = the % load rovergauge is reporting. I wish I would have done this with the stock engine and tune to see how close they correlate.

[stevesprint]

danbourassa said:

Steve, if the byte difference is $FF versus $C0, I believe you found an error in the early 2422 code. Here is the difference:

Dan, Its really good we find these errors and you help me understand them as it encourages me to study the code. Their are certainly a lot of data variables mixed in with Map 0 and I’m just surprised Map 0 doesn’t have the same data structure as the other maps with the extra data variables grouped together at the end of the data. Thanks again for the explanation and I understand what you mean.

[stevesprint]

robertf03 said:

Something I've overlooked is the MAF multiplier value.

I'm sure that going from a 3.9 to a 4.6 is causing the current 3360 code to report a higher load cell than it actually should be in based on the engine displacement and probably running extremely rich before trims as a result.

It certainly will, hopefully the following ‘Calc Fuel Table Row’ scalars will give you some ideas.

3.9 LR - B2
400 Precat - B2
400 CAT - B9
4.2 LR - B2
430 Precat - 91
450 CAT - 91
500 CAT - 91
Sorry, I actually think the list confuses the issue, if you weren’t running in an engine I would of suggested the obvious, trial and error on full load.

robertf03 said:

What do you all think about this attempt:

I am going to hook a vacuum gauge to the manifold and live tune the MAF multiplier for the selected fuel cell until vacuum/ambient pressure = the % load rovergauge is reporting. I wish I would have done this with the stock engine and tune to see how close they correlate.

“vacuum/ambient pressure = the % load” cunning plan go for it. When I was talking to Mark about programmable ignition he did explain vacuum is a more accurate means of measuring load than throttle pot position. Would you use idle as 25% load as in Dave’s screen shot above as overrun for max vacuum is 0% or negative load but the top row in RoverGauge is 12.5% load.

If this works could we consider replacing the AFM with a vacuum sensor like aftermarket ECU’s, it’s only a thought as I realise there would be electrical voltage and air temp issues.

[robertf03]

Was there ever a 4.2 rover offered in the UK? The 3361 chip is identical to 3360 except for map 5

The MAF scalar is different on map 5 for 3360 and 3361, unless I was looking at the wrong value

[stevesprint]

robertf03 said:

Was there ever a 4.2 rover offered in the UK? The 3361 chip is identical to 3360 except for map 5

The MAF scalar is different on map 5 for 3360 and 3361, unless I was looking at the wrong value

Yes, the Range Rover 4.2 was introduced in the UK in October 1992 but I'm not going to guess which PROM version is used.

I'm sure a man of your calibre can workout Map 5 row calc scalar is at PROM offset 7B9, after all you started the ball rolling with TunerPro. Anyway both R3360_94_3.9_High_CR and 3361RRC4.2 map5's row scalars are B2, I've just double checked. It's too late to start analysing the differences in map5 but please let me know if I can be of further assistance tomorrow. Bye for now.

Edited by stevesprint on Wednesday 26th February 08:26

[robertf03]

Goofed up on the offset. You are correct

[davep]

stevesprint said:

... Their are certainly a lot of data variables mixed in with Map 0 and I’m just surprised Map 0 doesn’t have the same data structure as the other maps with the extra data variables grouped together at the end of the data.

Steve, early programming convention usually required data definitions (DB - data byte and DW - data word) to be declared at the beginning of the code, and the fuel maps are simply data definitions. As to why 14CUX's individual non-map related data definitions suddenly appear immediately after Map 0's ADC table and not Map 5, we'll probably never know, but there would have been a logical reason for doing so (put all the important stuff at the beginning maybe).

Edited by davep on Wednesday 26th February 11:16