Instructions to change fuel maps on 14CUX Griffith, Chimaera

[danbourassa]

MPO said:

I have a manual fan override switch that I’m sure most of us have by now. When I use the manual override my RPM’s increase by about 50 RPM… Not ideal when you want to keep the engine speed down in traffic jams and almost defeats the object really IMHO. Is there setting option to adjust this in the 14CUX code?

There are several inputs to the ECU that affect the base idle. The 14CUX software monitors Park/Drive/Neutral (auto only), heated screen and A/C load. 50 is the idle difference used for the A/C load input, so I suspect your fan motor is connected to pin 21 of the ECU. You can either break this connection or change the byte at 015C from $32 to $00. Personally, I think it's more fun to change the software.

[davep]

danbourassa said:

Dave, the define block goes in your data file along with your fuel maps and other defines. Steve's post looks correct. You should build and test with the old baudrate first. Put a couple of shortcuts on your desktop and name them accordingly. For the high baud icon, add "-d" at the end of the Target line under Properties.

I like this new feature Dan! At the moment I'm using RoverGauge log files (.csv) with VirtualDyno and the higher baud rate will make for far more accuracy. I'm only doing the VirtualDyno exercise for a bit of fun but I'm looking at maybe using it as a tool for distributor tuning.

When I get time I'm still flowcharting various areas of the code also I've briefly looked at your RPM macro, and it looks to be a very neat fix to the long division problem. When the winter months set in I'll be able to allocate more time to 14CUX.

[MPO]

danbourassa said:

MPO said:

I have a manual fan override switch that I’m sure most of us have by now. When I use the manual override my RPM’s increase by about 50 RPM… Not ideal when you want to keep the engine speed down in traffic jams and almost defeats the object really IMHO. Is there setting option to adjust this in the 14CUX code?

There are several inputs to the ECU that affect the base idle. The 14CUX software monitors Park/Drive/Neutral (auto only), heated screen and A/C load. 50 is the idle difference used for the A/C load input, so I suspect your fan motor is connected to pin 21 of the ECU. You can either break this connection or change the byte at 015C from $32 to $00. Personally, I think it's more fun to change the software.

Thanks Dan, I've updated my XDF to test this, If it works, I'll update the code via the rebuild software :-)

[cmb]

New version, 0.7.6. This one simply adds a command line parameter ( -l ) that starts logging automatically. Probably most useful when used in conjunction with the auto-connect parameter, like so:

 rovergauge.exe -a -l 

It's available in the usual places:
https://github.com/colinbourassa/rovergauge/releas...
or
https://drive.google.com/folderview?id=0B83FOZ5t1n...

[danbourassa]

davep said:

When I get time I'm still flowcharting various areas of the code also I've briefly looked at your RPM macro, and it looks to be a very neat fix to the long division problem.

For those interested, the RPM macro that Dave mentioned is a change I'm proposing for the 14CUX software. There is a divide operation which converts spark pulse period to RPM. In the old days, this had to be done by a bit by bit shift and subtract loop. In this case, the divisor is a 24-bit number so the loop repeats 24 times and takes about 1100 microSeconds to complete. This is a very long time. At just 2000 RPM this is about 15% of the available processing time and at the rev limit it approaches half the available time! Obviously, this wouldn't do, so the developers bypassed this operation at about 2000 RPM. Above this speed, any code that needs to make a decision regarding engine speed uses the spark period directly instead of the RPM.

When I looked at this division code, I realized that it was generic and based on an example in a Motorola applications guide. The 14CUX, however, uses just a small range of values. The dividend is fixed at 7,500,000 and the divisor is the range of spark period values between idle and 2000 RPM. As a result, the first 12 iterations of this loop do nothing useful. My code change pre-shifts some values and runs just the last half of the loop. This easy improvement is apparently something the Lucas developers just simply missed.

Making this change will, of course, free up processing time for other things such as serial port servicing. I don't know if the RoverGauge user will notice the improvement in real time but I'm sure that log files will show an increased data rate and I'm expecting the difference to be even greater when using the high baud rate option.

[MPO]

cmb said:

New version, 0.7.6. This one simply adds a command line parameter ( -l ) that starts logging automatically. Probably most useful when used in conjunction with the auto-connect parameter, like so:

 rovergauge.exe -a -l 

It's available in the usual places:
https://github.com/colinbourassa/rovergauge/releas...
or
https://drive.google.com/folderview?id=0B83FOZ5t1n...

Nice one Colin, just what I need to automate my logging, I look forward to trying it this weekend. Thanks :-)

[MPO]

MPO said:

cmb said:

New version, 0.7.6. This one simply adds a command line parameter ( -l ) that starts logging automatically. Probably most useful when used in conjunction with the auto-connect parameter, like so:

 rovergauge.exe -a -l 

It's available in the usual places:
https://github.com/colinbourassa/rovergauge/releas...
or
https://drive.google.com/folderview?id=0B83FOZ5t1n...

Nice one Colin, just what I need to automate my logging, I look forward to trying it this weekend. Thanks :-)

Good news, this is working well. I Just added this to Steve's WB LC2 script and made a few WB LC2 Date & Time stamp tweaks to the log filename. "Happy Days!" Thanks Colin :-)

Edited by MPO on Tuesday 18th August 21:51

[jjohnson23]

I have been distracted away from the forum for the last few months due to events beyond my control but have been driving around with a modded eeprom made from an image Stevesprint sent me (for a 3528 cc engine).No way to test it other than by seat of the pants at the moment but much better than any of the 3.9 images in terms of driveability so I consider it a success.
The question I have to ask is what is the most recent XDF for Tunerpro?I like to play!
Steve,I can`t thankyou enough for the help by the way.

[stevesprint]

jjohnson23 said:

I have been distracted away from the forum for the last few months due to events beyond my control but have been driving around with a modded eeprom made from an image Stevesprint sent me (for a 3528 cc engine).No way to test it other than by seat of the pants at the moment but much better than any of the 3.9 images in terms of driveability so I consider it a success.
The question I have to ask is what is the most recent XDF for Tunerpro?I like to play!
Steve,I can`t thankyou enough for the help by the way.

Pleasure & here you go
http://www.stevesprint.com/remap-14cux/TunerPro-xd...
Should you require further info or assistance please don't hesitate to ask.
Steve

[stevesprint]

davep said:

My approach to adjusting a precise base idle that suits my car was: (1) drop idle down so as to induce stalling when coming off the throttle and to a rest (an initial quarter of a turn in my case), then (2) incrementing base idle with very, very fine adjustments until the idle RPM holds steady at 930 - 1000. This has worked for me as there's no RPM surge on start-up and no high lingering. What I've also noticed with the current settings is there is a distinct audible Helmholtz resonance from the plenum/inlet manifold at idle, so this could be an indication that the pulse frequency is 'tuned' to its sweet spot.

Dave.
Thanks for you explanation above, as a result of your post and enjoying a blast in your Griff at Millbrook I've since gone back to the standard coolant based idle control table and lowered my base idle. This re-introduced the hot starting issue above 87 degs c as the stepper closes to 36% before cranking and is normally full open below 87deg c before cranking. It's amazing 1 deg c difference before cranking makes a 64% difference to the stepper motors position, Dave I guess your engine runs cooler than mine.
As another Precat owner was also experiencing this same hot start issue with his factory chip I decided to investigate and ended up changing one line of code in idleControl.asm so the stepper is held 100% open before cranking up to 114 deg c. I changed the following at line 149
from
cmpb $C17E ; inside coolant temp table (value is $23)
to
cmpb $C17C ; Steve, was $C17E (from 87 Deg c to 0B=114 Deg c)

Before cranking the code checks the water temp again the temp valve in the coolant based idle control table at prom offset $17E (87 deg c), which you can see I changed to $17C (114deg c). I didn't simply change the value in the table as $17E is used in 12 other places in the code including things like the purge valve control. I've also lowered the value at prom offer $15C to keep the idle down immediately after cranking.

The advantage of this approach is you can reliability turn down your base idle to lowers the warming up and coasting idle.

As I've been successfully running this fix for the last few weeks and also had positive feed back from the Precat owner who kindly tested it I've decided to make it available with two different 400 versions via the links below.
www.stevesprint.com/remap-14cux/bins/R3652_400_550...
www.stevesprint.com/remap-14cux/bins/R3652_400_625...
www.stevesprint.com/remap-14cux/bins/R3652_430_625...

This just leaves lowering the coasting idle after you first move off from cold to sort and reducing the mixture immediately after cranking to reduce the black un-burnt fuel spitting out of the exhaust when cold.

[stevesprint]

During recent logging sessions I’ve realise the logging speed increase I mentioned in a previous post was not only due to doubling the serial port speed but also by reducing the numbers of sensor logged. As a result I've edited my previous post regard logging with a double speed serial port.

Colin
I've noticed if you first log with all sensors selected and then de-select some the de-selected sensors are constantly logged at their last known values and not set to zero and could be misleading. I'll let you or Glyn decide if the de-selected sensors are best stripped out of the log or set to zero.

Dan
When running the serial port at double speed are the data frame settings still 8N1 including flow control. I'm trying to run TunerPro's map tracing function with the 14CUX serial port running at double speed as it was never reliable at 7812.5 and could have been because TunerPro doesn't support decimal speeds.

[PeteGriff]

stevesprint said:

…..As I've been successfully running this fix for the last few weeks and also had positive feed back from the Precat owner who kindly tested it I've decided to make it available with two different 400 versions via the links below.
www.stevesprint.com/remap-14cux/bins/R3652_400_550...
www.stevesprint.com/remap-14cux/bins/R3652_400_625...
www.stevesprint.com/remap-14cux/bins/R3652_430_625...

This just leaves lowering the coasting idle after you first move off from cold to sort and reducing the mixture immediately after cranking to reduce the black un-burnt fuel spitting out of the exhaust when cold.

Hi Steve, is this an update pin the 'tune' I am running that you supplied a few months ago? All the best, Pete

[stevesprint]

PeteGriff said:

Hi Steve, is this an update to the 'tune' I am running that you supplied a few months ago? All the best, Pete

Peter
Due to popular demand I’ve gone back to your prefer version and adopted DaveP’s approach of lowering the base idle (set on the plenum) to lower the rev hold while slowing down & reduce the hot start idle. Therefore, I can confirm this latest version is the same as your current version with the following enhancements.

Overrun popping enable from 4,000 rpm down (prom offset $137)
Lowered starting idle hot and cold (prom offset $15D)
Fuel table extended from 6200 to 6250 with smooth transitions between the cells (offset $800+)
Hot start fix to enable base idle to be lowered even further down. (in the code)
Map 2 - TVR 430 map plus richer top row at 1,400rpm for smoothness then leaner above to induce overrun popping. Also not so rich on full load above 4,400rpm (as per my rolling graph from the 2014 Growl).

I’ve also made the following change that may not effect you.
Map 1 – Standard TVR factory 430 map but with disabled CO trim.
Map 3 – TVR 430 map plus richer top row between 1,400 & 2100rpm for extra smoothness
Map 5 – TVR Chimmy 450 cat map, suits 430 with lambdas probes (long lambda trims less than 20%)
MIL lamp enabled (Prom offset $7C2)

Therefore to lower your rev hold when slowing down and reduce your starting idle you need to run this latest version and also lower your base idle set on the plenum (clockwise).

I’ve personally been running this version for 2 weeks with no dramas and I’ve already received positive feedback from a precat owner with a really loud exhaust who said his exhaust on overrun now sounds like a machine gun!! Sadly it’s not so dramatic with my standard exhaust.

Good Luck and I welcome any feedback.

[Hoover.]

Steve having been away at the Griff Grumble this weekend all I can say keep going with toying, seemed to be few v happy people of your maps ... no good to me now, but for the rest keep going please

[stevesprint]

Glyn
Sorry, I never thanked you properly for emailing me a copy your standard Land Rover R3116 4.2 chip. It certainly must be the factory R3116 if the chip is still soldered on the PCB and you had to read it via RoverGauge.

I find it interesting to note the AFM scalars in all LR 4.2 chips are the same as the 3.9 AFM scalar of B2 or B9 which you can see in my spreadsheet at http://www.stevesprint.com/remap-14cux/LR-TVR-sett... . Only TVR changed AFM scalar dramatically for the 4.3’s and larger capacity engines.

R3361 and R3384 & R3116 all have the same 4.2 cat map main fuel scalar of 6590 including 3116's non-cat map is also for a 4.2, but I see R3361 and R3384’s non-cat map scalars are for 3.9, interesting. This makes me think all development could have been done for 3.9s and then the 4.2 map was copied in afterwards. Also R3116’s Tune ID is 1A14 which is unique.

Dan,
I'm very impressed we can re-build R3116’s code with
BUILD_R3383 = 1 and NEW_STYLE_AC_CODE = 0
instead of
BUILD_R3383 = 1 and NEW_STYLE_AC_CODE = 1
for R3833. I guess its called progress that R3116 code is the same as R3833 but less the new style A/C code.

The factory R3116 can now be downloaded from my bins web page at www.stevesprint.com/remap-14cux/bins along with the Chimmaera 430BV CAT map I received from 67FOX that I’ve always been waiting for, I've summarised R2967_16 here http://www.pistonheads.com/gassing/topic.asp?h=0&a... as it was worth the wait.

I've also created the data build files for R3116 and R2967_16 and can be downloaded from
www.stevesprint.com/remap-14cux/bins/data_R3116.as...
www.stevesprint.com/remap-14cux/bins/data_R2967_16...
Cheers for now, Steve.

[stevesprint]

Hoover. said:

Steve having been away at the Griff Grumble this weekend all I can say keep going with toying, seemed to be few v happy people of your maps ... no good to me now, but for the rest keep going please

Thanks for the positive feedback, I have received a thank you email and hear everyone enjoyed the new overrun sound track.
Steve

[jjohnson23]

I have just bought a 14cux and taken a reading via Rovergauge.
It is image R2161 which if I remember from previous posts is a very old revision.
If I remove the prom from the board and fit a socket is it going to be a problem making up a suitable eprom image?
By the way it only cost a few quid so I am willing to give it a go.

[blitzracing]

Read page 1 of this post- it covers the bits and bytes. A programmer is about £35 and chips are about £2 for an Eprom,(27C256) or £8 for an EEprom (a reprogrammable chip)

[jjohnson23]

I`m sorry for poor post,I am aware of the different fuel table offsets but things like the speed limiter and rpm scaling are my concern.
I take it that the offsets for these may be different.

[MPO]

stevesprint said:

Glyn
Sorry, I never thanked you properly for emailing me a copy your standard Land Rover R3116 4.2 chip. It certainly must be the factory R3116 if the chip is still soldered on the PCB and you had to read it via RoverGauge.

I find it interesting to note the AFM scalars in all LR 4.2 chips are the same as the 3.9 AFM scalar of B2 or B9 which you can see in my spreadsheet at http://www.stevesprint.com/remap-14cux/LR-TVR-sett... . Only TVR changed AFM scalar dramatically for the 4.3’s and larger capacity engines.

R3361 and R3384 & R3116 all have the same 4.2 cat map main fuel scalar of 6590 including 3116's non-cat map is also for a 4.2, but I see R3361 and R3384’s non-cat map scalars are for 3.9, interesting. This makes me think all development could have been done for 3.9s and then the 4.2 map was copied in afterwards. Also R3116’s Tune ID is 1A14 which is unique.

Dan,
I'm very impressed we can re-build R3116’s code with
BUILD_R3383 = 1 and NEW_STYLE_AC_CODE = 0
instead of
BUILD_R3383 = 1 and NEW_STYLE_AC_CODE = 1
for R3833. I guess its called progress that R3116 code is the same as R3833 but less the new style A/C code.

The factory R3116 can now be downloaded from my bins web page at www.stevesprint.com/remap-14cux/bins along with the Chimmaera 430BV CAT map I received from 67FOX that I’ve always been waiting for, I've summarised R2967_16 here http://www.pistonheads.com/gassing/topic.asp?h=0&a... as it was worth the wait.

I've also created the data build files for R3116 and R2967_16 and can be downloaded from
www.stevesprint.com/remap-14cux/bins/data_R3116.as...
www.stevesprint.com/remap-14cux/bins/data_R2967_16...
Cheers for now, Steve.

Steve

No problem, happy to help, yes it original and I hope it provides further insight into the 14CUX mechanics. It only took 2 mins to download, so if anyone else finds a new TVR or RR Version Shout!. :-)

Cheers

Glyn (MPO)