Instructions to change fuel maps on 14CUX Griffith, Chimaera

Instructions to change fuel maps on 14CUX Griffith, Chimaera

Author
Discussion

davep

1,141 posts

283 months

Friday 28th March 2014
quotequote all
Forgot to mention I'd swapped ECUs immediately prior to this problem. I did disconnect RG and switched ignition off when changing ECUs.

First time I've noticed the cell colour scheme. Nice feature.

stevesprint

Original Poster:

1,114 posts

178 months

Sunday 30th March 2014
quotequote all
davep said:
I found this RG screenshot:
http://thumbsnap.com/IcKLBGDg
This is for a pre-cat Griffith with a R2422 tune version, look at the fuel map label, shown as Fuel Map 2 (which is correct for the car, green tune resistor), but the Multiplier, shown as 0x5DBE, is the wrong Multiplier, it's for Fuel Map 3. Look closer at the fuel map itself, it is Fuel Map 3 (yellow tune resistor, 910 Ohms)!
Dave, This is the standard fuel table and adjustment factor for a 400 pre-cat Griffith, BUT the idle is 100 rpm too low, so I decided to compare the TVR & LR 2422 data. The TVR idle is 700+100 and LR’s is 600+100, so this prom is possibly a Land Rover 2422 bin. On further investigation you can see the TVR & LR 2422 map 2 have the same fuel table and adjustment factor but I guess at the time in the UK Land Rovers were running map 5 while TVR ran map 2.

davep said:
I found this RG screenshot:
Allied to the above, I've also been doing some test runs and was feeling very pleased with myself until RG gave me this:

I would have thought if there was a comms interface problem more than one area of the screen would be garbage, not just the corrupted fuel map table and the Multiplier (0xFFFF !!!!).
Dave, I've seen this loads of time when changing proms but never mentioned it as I thought I was the only one swapping prom revisions and therefore lean't to close RoverGauge. Colin, you haven’t introduced this in version 6 as its the same in previous versions. It did also make me realise the orange shading is dynamic.

Dave is your voltage really 15.1? Do you run a serpentine alternator?

davep said:
To top it off, I've also a road speed issue to resolve, Dan has given me the fix but I've yet to schedule it in. Basically, the LT77 speedo transducer used on the early Griffith 4.x comes in two versions and the Stewart Warner speedo is configured accordingly. The transducers TVR (or gearbox supplier) fitted can be 4-pulse or 8-pulse (Orange drive), the 8-pulse being the most common one. Guess which one I've got, yep 4-pulse.

Many moons ago I enquired: "It'd be interesting to see if the differences in speed sensor signal frequency are accounted for in the 14CUX code." Answer, it appears, is no. So in RG, if you have road speed reading half of what it should be, and you have an LT77 gearbox using the original speed transducer, you have the 4-pulse version but 14CUX is coded for 8-pulse. Dan has already explained that this would only effect the 3 mph idle threshold, so it's no big deal.
Dave, you have the correct 4 pulse speed sensor for a Griffith and that’s how TVR over came the road speed limit. My old Griff LT77 sensor also produced 4 pulses per prop rev. When I fitted the T5 box I had 8 teeth on my new prop chopping wheel I use to hit the road speed limit at 85 mph (on a trackday) until I reduced down to 4 pulses per prop rev.

It would be interested to see Dan fix as Dan previously explained the road speed limit is held in the code which we now know is the same for TVR 2422 and LR 2422.

stevesprint

Original Poster:

1,114 posts

178 months

Sunday 30th March 2014
quotequote all
cmb said:
Ah, I think I have an idea about what happened. The algorithm that determines which data offsets are used by the ROM does this by comparing the first row of fuel map data at each of the two possible locations. Changing the maps could potentially confuse this algorithm, so I'm going to re-address it in the next release of the software.
Colin, I always wonder how you figured out if its an old or new code layout and thought you might of hard coded it based on the Revision number being 2967 and above. At one point I thought you must have coded RoverGauge with a list of all the revision numbers and the corresponding fuel table starting addresses.

Colin, I didn't tell you about this issue as I figured RoverGauge works out the prom layout once at execution and I didn't expect you to slow down connect/disconnect for everyone just in case Steve has changed the revision.

cmb said:
The cell background colors are directly derived from the value in the cell (i.e. higher value uses higher color saturation.)
Very nice touch, thnanks

davep

1,141 posts

283 months

Sunday 30th March 2014
quotequote all
Steve, I think some 4.x Griffiths had 4 pulse and some 8 pulse sensors:

http://mobile.pistonheads.com/co/uk/gassing/topic....

Looks like I've got the correct sensor for my car in the spares bin.

Main voltage reads 13.2 Vdc for one prom and 15.1 Vdc for R2422. Alternator is a standard Marelli. I'll have to do a code comparison and see if there any differences.

stevesprint

Original Poster:

1,114 posts

178 months

Sunday 30th March 2014
quotequote all
danbourassa said:
Steve, that's one way to do it, or you could look in reset.asm to find this:

;----------------------------
; Init map 0 ADC table ; code branches here when fuel map is unlocked
;----------------------------
.LC92F ldx #$C082 ; default ADC control table
stx adcMuxTableStart

For map 2, just change the #$C082 to #$C473 (or preferably LC473 if your data file has this label).
Dan, your little mod in reset.asm worked as expected and proved an interesting point. If I remember correctly when I run map 5 with this tweak turning on the ignition each time overwrote the long term trim, that makes sense doesn't it.

Dan, You’ll be pleased to hear since I’ve had your rebuild project I’ve stopped hacking the bins in hex and started working on the assembler files which is much easier.

I still can’t believe I now have commented source code, a compiler that's been ported to Windows and first class online support. That's all unheard of in the real IT world!!!

stevesprint

Original Poster:

1,114 posts

178 months

Monday 31st March 2014
quotequote all
danbourassa said:
The only reason they would have left shifted the CO trim this way and written it to both long term trim locations HAD TO BE direct control of the long term trim. It works too perfectly to be anything else. It must have been a mode that was used for code development and test and there was a procedure for getting into this mode, which Steve found, of course.
Dan, after further testing I’ve proved this mode is nothing to do with changing tune resisters as last week I reset my ECU and stuck with tune 5 and tested with R2967 and R3833 which both produced the same results. Basically, I’ve now been running with a pair of very old narrow band sensors for about a month and never seen a Lambda fault code until I set the CO trim voltage down to zero. So maybe the CO trim need to be set to zero for closed loop to control the long term trim or was I getting a fault because my AFR was so lean its beyond the long trim range?

Mark, When I reset my ECU and have another go what would you expect the long term trim to do before throwing an error?

It’s a shame if the CO trim has to be 0 as it means I can’t just simply switch resisters to switch maps as I would also have to adjust the CO trim each time. 0V for map 5 long term trim control and about 1.5 voltages for 13.5 AFR for open loop. Dan, I can feel another code mod coming on.

blitzracing

6,387 posts

219 months

Monday 31st March 2014
quotequote all
stevesprint said:
Dan, after further testing I’ve proved this mode is nothing to do with changing tune resisters as last week I reset my ECU and stuck with tune 5 and tested with R2967 and R3833 which both produced the same results. Basically, I’ve now been running with a pair of very old narrow band sensors for about a month and never seen a Lambda fault code until I set the CO trim voltage down to zero. So maybe the CO trim need to be set to zero for closed loop to control the long term trim or was I getting a fault because my AFR was so lean its beyond the long trim range?

Mark, When I reset my ECU and have another go what would you expect the long term trim to do before throwing an error?

It’s a shame if the CO trim has to be 0 as it means I can’t just simply switch resisters to switch maps as I would also have to adjust the CO trim each time. 0V for map 5 long term trim control and about 1.5 voltages for 13.5 AFR for open loop. Dan, I can feel another code mod coming on.
Take a step backards- just reset the ECU to zero the long term trim on the cat map, then let the car idle for a few mins when hot and observe the long term trim- it should start at 0 and slowly move until its correct at less than 100%. Im sure you wont see the CO trim affecting this if you do an ECU reset first. 100% trim means you are out of trim range if its that lean.

davep

1,141 posts

283 months

Monday 31st March 2014
quotequote all
stevesprint said:
It would be interested to see Dan fix as Dan previously explained the road speed limit is held in the code which we now know is the same for TVR 2422 and LR 2422.
Steve, the PistonHeads Reply to Topic screens are not capable of handling more than one pair of format code example tags, the syntax handling appears to be all to cock. So I've shown the fix as a single block of code with Dan's options embedded, I'm sure you'll get the gist:

Not road speed limit related but:

Dan said:
The road speed does not, as far as I know, have an impact on fueling however the idle mode threshold is important. It should switch at 4 MPH or about 3 KPH. You're lucky that the road speed is off by half instead of some odd amount. There are 2 ways to fix this easily:


1) If you look at the bottom of roadSpeed.asm you will find this line

inc $2002 ; increment X2002 when road speed is not zero

You can duplicate this line so that the variable gets incremented twice.

2) This is a more efficient way. If you look near the top of the file, you will see this line:

.LD38D stab roadSpeed ; store actual road speed (or 176 KPH limit)

You should change this to:

.LD38D aslb ; double the value
stab roadSpeed ; then store it
Interestingly, I know you rate my R2422 as being too old but during recent test runs involving different tune versions the R2422 comes out as my favourite. It makes the car absolutely fly and produces the TVR traits I like (pops and bangs on overrun for instance), doesn't do a lot for consumption mind. So I've decided to put the above fix (option 2) into my R2422.

davep

1,141 posts

283 months

Monday 31st March 2014
quotequote all
cmb said:
It looks to me like the fuel map is stored at a slightly different offset than one of the offsets supported by RoverGauge. In the older firmware revisions, fuel map 2 is stored at $0351, and in the newer revisions, it's $0379. If the map starts at a lower offset than one of these, I would expect that you'd see the problem in the screenshot. Something has shifted the values in the data section around.

The multiplier is shown as $FFFF because it's read from the two bytes that immediately follow the 128 bytes the software interprets as the map. In this case, those bytes happen to be FF FF.
Colin, I've now realised what the problem was. I changed from a new PROM (fuel map 2 offset $0379) to an old offset version PROM and RoverGauge simply continued displaying data from $C379 to $C3FA/B, which is $56 $54 .... $FFFF in the old version PROM, even though I'd done a Disconnect and ignition off.


Edited by davep on Monday 31st March 17:44

stevesprint

Original Poster:

1,114 posts

178 months

Tuesday 1st April 2014
quotequote all
danbourassa said:
stevesprint said:
What would happen if I copied MAP2’s ADC control list over the limp-home ADC control list?
Steve, that's one way to do it, or you could look in reset.asm to find this:

;----------------------------
; Init map 0 ADC table ; code branches here when fuel map is unlocked
;----------------------------
.LC92F ldx #$C082 ; default ADC control table
stx adcMuxTableStart

For map 2, just change the #$C082 to #$C473 (or preferably LC473 if your data file has this label).
Dan, I’ve finally realised why my AFM CO trim is adjusting the long term trim and to be honest I’m now starting to feel a bit of a muppet but at least I'm brave enough to admit my mistake and I worked it out for myself.

Believe it or not your little code mod above gave me a huge clue, because and please don’t laugh, I copied R2422 Map-2 complete with the full data structure into maps 1 to 5 of R2967 but now I realise that means I’ve copied the open loop ADC control list into a closed loop ADC control list.
Precat R2422 MAP 2 that I copied over the chimmy 400 map 5
LC7A9 DB $87,$86,$02,$03,$84,$02,$8D,$88,$02,$8B,$80,$85,$81,$09,$8E,$FA ; ADC
Chimaera 400CAT MAP 5
LC7A9 DB $87,$86,$02,$03,$84,$02,$8D,$88,$02,$8B,$80,$85,$81,$8E,$FA,$FA ; ADC
I hope you are not too cross with me for confusing you, Dave & Mark and I'm sorry for any sleepless nights I caused but at least I've learnt a lot.

NOTHING VENTURED NOTHING GAINED!!!

Edited by stevesprint on Tuesday 1st April 08:47

danbourassa

246 posts

136 months

Tuesday 1st April 2014
quotequote all
Well that explains how it happened. It wasn't a bug in the 14CUX software after all. I'm still glad it happened, though. It has given me more insight and I'm newly convinced that the CO trim and long term trim are potentially coupled for a reason. I only wish I knew the reason.

cmb

103 posts

174 months

Tuesday 1st April 2014
quotequote all
davep said:
Colin, I've now realised what the problem was. I changed from a new PROM (fuel map 2 offset $0379) to an old offset version PROM and RoverGauge simply continued displaying data from $C379 to $C3FA/B, which is $56 $54 .... $FFFF in the old version PROM, even though I'd done a Disconnect and ignition off.

Edited by davep on Monday 31st March 17:44
It's actually good that this happened, because it prompted me to make a change that will cause RoverGauge to forget the data offsets when you disconnect. They will now be re-determined upon connecting again.

Until the next version is released, you would need to close and re-open RoverGauge to force it to use the right offsets.

stevesprint

Original Poster:

1,114 posts

178 months

Wednesday 2nd April 2014
quotequote all
Colin, Any chance you can display the full double word of the TUNE_IDENT.
Thanks
Steve

cmb

103 posts

174 months

Thursday 3rd April 2014
quotequote all
stevesprint said:
Colin, Any chance you can display the full double word of the TUNE_IDENT.
Thanks
Steve
Absolutely. I'm not even sure why I originally coded it to return only 8 bits worth.

This'll be in the next release too.

davep

1,141 posts

283 months

Friday 4th April 2014
quotequote all
stevesprint said:
It would be interested to see Dan fix as Dan previously explained the road speed limit is held in the code which we now know is the same for TVR 2422 and LR 2422.
Not road speed limit related but:

Dan said:
The road speed does not, as far as I know, have an impact on fueling however the idle mode threshold is important. It should switch at 4 MPH or about 3 KPH. You're lucky that the road speed is off by half instead of some odd amount. There are 2 ways to fix this easily:


1) If you look at the bottom of roadSpeed.asm you will find this line

inc $2002 ; increment X2002 when road speed is not zero

You can duplicate this line so that the variable gets incremented twice.

2) This is a more efficient way. If you look near the top of the file, you will see this line:

.LD38D stab roadSpeed ; store actual road speed (or 176 KPH limit)

You should change this to:

.LD38D aslb ; double the value
stab roadSpeed ; then store it
What a fine fellow Dan is! Through his sterling efforts we get detailed fix options, so that we can alter, with confidence, the 14CUX code at assembler level (ASM), build a new binary file (BIN) using his automated assemble/build suite all ready for burning into PROM. Once in PROM and mounted in the ECU the results can then be fully tested in real time with Colin's RoverGauge. Marvellous.

cmb

103 posts

174 months

Sunday 6th April 2014
quotequote all
I just uploaded RoverGauge version 0.7.0 to the Google Drive. Here's the changelog:
  • Added display for injector pulse width / duty cycle
  • Added option to display more accurate "soft" fuel map cell highlight
  • Fixed fuel map multiplier display bug
  • Fixed 16-bit "Ident" value width
  • Changed to better detection of old vs. new data segment offsets
  • Changed to more efficient scheduler for updating sensor data
The injector pulse width is now displayed in the lower right, and if you're also measuring RPM, you will see pulse width duty cycle as well. The latter is represented as a percentage of the time available during one injector firing cycle.

The "soft" fuel map cell highlight displays the weighted average that the ECU computes over four cells in the map, rather than the previous method of simply highlighting a single cell. This is an option that you can turn on/off in the Options box.

As always, let me know if you find any bugs or have any questions.

Edited by cmb on Monday 7th April 00:28

davep

1,141 posts

283 months

Monday 7th April 2014
quotequote all
Looks good with the new features Colin, thanks.

With regard to injector duty cycle I'm still trying to figure out under what conditions the fueling and non-fueling ICI interrupts and their respective 8 or 6 road speed sampling rates are used.

There's no MAF CO trim voltage displayed in open loop (continues to display Lambda trims), has this been dropped for the 0.7.0 version?

Edited by davep on Monday 7th April 14:38

danbourassa

246 posts

136 months

Monday 7th April 2014
quotequote all
davep said:
There's no MAF CO trim voltage displayed in open loop (continues to display Lambda trims), has this been dropped for the 0.7.0 version?
It was my job to test before release and I missed this. It must have got broken somehow.

danbourassa

246 posts

136 months

Monday 7th April 2014
quotequote all
davep said:
With regard to injector duty cycle I'm still trying to figure out under what conditions the fueling and non-fueling ICI interrupts and their respective 8 or 6 road speed sampling rates are used.
Dave, while Colin is fixing RG, do you mind if I ramble a bit before I answer?

This is not timed fuel injection. These early systems were not much different than carburetors in that the fuel, more often than not, just collects near the back side of closed intake valve and waits for the engine to come around. In fact, the relationship between any single cylinder and the timing of the injectors starts in a random way. It has a 1 in 8 chance of coming up in a particular way. Interestingly, it may be the firing of an odd bank cylinder that triggers an even bank injector pulse (and vice versa). I sometimes wonder, assuming you had a weak cylinder or otherwise unevenly worn engine, if there could be a timing relationship that could make matters better (or worse). It would be interesting to be able to tell the 14CUX to skip a spark and shift the timing relationship to see if we can tell the difference. I think I'll put it on my TODO list.

So, there needs to be a shot of fuel injected toward each intake valve for every engine cycle. This is why a bank of injectors is fired for every 4th spark. There are two bits in the interrupt that are toggled in a binary counting pattern (0,1,2,3,0,1,...) that keep track of this. Let's call them A and B.

A B Interrupt
---------------------
0 0 Right Bank (fuel)
0 1 Right Bank (no-fuel)
1 0 Left Bank (fuel)
1 1 Left Bank (no-fuel)
0 0 Right Bank (fuel)
0 1 ...and so on

The non-fuel interrupt does less and returns to the main loop sooner than the fuel interrupt, since some of the code is skipped. VSS state sampling code is distributed throughout the interrupt and a couple of VSS samples are skipped along with the code. That's the only reason the short interrupt has fewer samples.

I mentioned earlier in this thread about R3365 (Defender) VSS sampling being done a bit more efficiently. That code has additional samples (I believe 9 in the long interrupt and an additional one in the main loop). Lucas seemed to be aware of both the strobing problem and the burden that VSS sampling was placing on the processor. I think R3365 is a step in the right direction.



Edited by danbourassa on Monday 7th April 17:14

cmb

103 posts

174 months

Tuesday 8th April 2014
quotequote all
davep said:
There's no MAF CO trim voltage displayed in open loop (continues to display Lambda trims), has this been dropped for the 0.7.0 version?
This was definitely a bug. I'm running the build now and I'll upload the new version shortly.

Edit: OK, version 0.7.1 is now available and should fix this problem.

Edited by cmb on Tuesday 8th April 01:37