Instructions to change fuel maps on 14CUX Griffith, Chimaera
Discussion
The rows and columns in RoverGauge start with zero, not one. This may seem odd to some (no pun intended), but it's a common practice in the software world. Also, the highlighted values on the screen are rounded to the closest cell but the log values are truncated. I imagine Colin did this to avoid jitter in the data.
Thanks Dan, its making sense now. Just to clear up one more thing, when idling & at operating temperature, with no throttle I’m mostly seeing row 1 in use rather than row 0 (this is more obvious in further RoverGauge logs I have). Shouldn’t the engine be idling on row 0 (most of the time)? If so what need to be done to correct this?
As I’m still on a high from the TVR driving experience at the Millbrook Proving Ground here’s a few pictures to brighten up this thread. What a blast, especially late in the afternoon when it was deserted and DaveP and I lost count of the number of times we drove the Alpine hill circuit, the speed bowl and tested our 0 to 100+ in a safe environment.
Now back to business.
Dave, I’m very impressed with your 4.6 and your other mods. I particularly noticed the smoothness of your engine with R3652 and your low starting and lingering idle while slowing down that you fine-tuned via the base idle. Unfortunately when I lowered my base idle earlier this year I couldn’t start above 87 deg c as the stepper closes up before cranking above 87 Deg. However, you've made me realise lowering the lingering via the base idle works better then adjusting the whole of the coolant based idle table, therefore I'll have to revisit adjusting my base idle especially now I’ve leant how to fix the hot start idle above 87 deg c. Upgrading from R2967 to R3652 does unfortunately raise the lingering and starting idle and as I'm trying to avoid any hardware changes I may need some more help in the winter to revisit the complex idle control code.
Colin, Thanks for the RoverGauge update.
Dan, Good to see your back.
Cheers, Steve
Now back to business.
Dave, I’m very impressed with your 4.6 and your other mods. I particularly noticed the smoothness of your engine with R3652 and your low starting and lingering idle while slowing down that you fine-tuned via the base idle. Unfortunately when I lowered my base idle earlier this year I couldn’t start above 87 deg c as the stepper closes up before cranking above 87 Deg. However, you've made me realise lowering the lingering via the base idle works better then adjusting the whole of the coolant based idle table, therefore I'll have to revisit adjusting my base idle especially now I’ve leant how to fix the hot start idle above 87 deg c. Upgrading from R2967 to R3652 does unfortunately raise the lingering and starting idle and as I'm trying to avoid any hardware changes I may need some more help in the winter to revisit the complex idle control code.
Colin, Thanks for the RoverGauge update.
Dan, Good to see your back.
Cheers, Steve
Edited by stevesprint on Tuesday 21st July 21:28
Colin and Dan
MPO has raised a valid point. You can see from the screen shot below my idle is 99% one row down and 1% (faint shading) on the top row and currentFuelMapRow in the log is 0. Therefore, is currentFuelMapRow in the log always rounded down? Would it be possible to round currentFuelMapCol & row up and down without turning off "Soft" fuel map cell highlight. In addition would it be possible to have an options to turn currentFuelMapCol/row decimal places on or off?
MPO has raised a valid point. You can see from the screen shot below my idle is 99% one row down and 1% (faint shading) on the top row and currentFuelMapRow in the log is 0. Therefore, is currentFuelMapRow in the log always rounded down? Would it be possible to round currentFuelMapCol & row up and down without turning off "Soft" fuel map cell highlight. In addition would it be possible to have an options to turn currentFuelMapCol/row decimal places on or off?
#time,roadSpeed,engineSpeed,waterTemp,fuelTemp,throttlePos,mafPercentage,idleBypassPos,mainVoltage,currentFuelMapIndex,currentFuelMapRow,currentFuelMapCol,targetIdle,lambdaTrimOdd,lambdaTrimEven,pulseWidthMs
18:31:40.555,0,947,80,31,0.0537634,0.0370735,0.255556,13.50,2,0,5,950,0,0,2.994
18:31:41.204,0,945,80,31,0.0537634,0.0399075,0.255556,13.50,2,0,5,950,0,0,2.994
18:31:41.827,0,955,80,31,0.0537634,0.0369578,0.255556,13.50,2,0,5,950,0,0,3.002
18:31:42.467,0,916,80,31,0.0537634,0.0388086,0.255556,13.50,2,0,5,950,0,0,3.008
18:31:43.059,0,956,80,31,0.0537634,0.0388086,0.255556,13.50,2,0,5,950,0,0,2.874
18:31:43.753,0,933,80,31,0.0537634,0.0385772,0.255556,13.50,2,0,5,950,0,0,2.997
18:31:44.323,0,943,80,31,0.0537634,0.0383459,0.255556,13.50,2,0,5,950,0,0,2.994
18:31:44.986,0,956,80,31,0.0537634,0.0383459,0.255556,13.50,2,0,5,950,0,0,2.939
18:31:45.605,0,980,80,31,0.0537634,0.0388086,0.255556,13.50,2,0,5,950,0,0,2.92
stevesprint said:
Dave, I’m very impressed with your 4.6 and your other mods. I particularly noticed the smoothness of your engine with R3652 and your low starting and lingering idle while slowing down that you fine-tuned via the base idle. Unfortunately when I lowered my base idle earlier this year I couldn’t start above 87 deg c as the stepper closes up before cranking above 87 Deg. However, you've made me realise lowering the lingering via the base idle works better then adjusting the whole of the coolant based idle table, therefore I'll have to revisit adjusting my base idle especially now I’ve leant how to fix the hot start idle above 87 deg c. Upgrading from R2967 to R3652 does unfortunately raise the lingering and starting idle and as I'm trying to avoid any hardware changes I may need some more help in the winter to revisit the complex idle control code.
Colin, Thanks for the RoverGauge update.
Dan, Good to see your back.
Cheers, Steve
Steve, yes it was a very fine day for driving, talking (well mostly listening) about techie stuff and meeting fellow enthusiasts. Thoroughly enjoyed it. Really impressed with your car, especially the T5 gear change, very slick.Colin, Thanks for the RoverGauge update.
Dan, Good to see your back.
Cheers, Steve
Edited by stevesprint on Tuesday 21st July 21:28
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.
Edited by davep on Sunday 26th July 15:51
stevesprint said:
Colin and Dan
MPO has raised a valid point. You can see from the screen shot below my idle is 99% one row down and 1% (faint shading) on the top row and currentFuelMapRow in the log is 0. Therefore, is currentFuelMapRow in the log always rounded down? Would it be possible to round currentFuelMapCol & row up and down without turning off "Soft" fuel map cell highlight. In addition would it be possible to have an options to turn currentFuelMapCol/row decimal places on or off?
It does look like the log file is missing the row/column weighting information. When the active cell is highlighted on the graphical display, it is actually rounded up or down based on the weighting. If you have the 'soft' highlight turned on, then you see the weighting that the ECU is using, without any need to round up or down.MPO has raised a valid point. You can see from the screen shot below my idle is 99% one row down and 1% (faint shading) on the top row and currentFuelMapRow in the log is 0. Therefore, is currentFuelMapRow in the log always rounded down? Would it be possible to round currentFuelMapCol & row up and down without turning off "Soft" fuel map cell highlight. In addition would it be possible to have an options to turn currentFuelMapCol/row decimal places on or off?
For the next release, I'll plan to add the missing information to the log file. I think the best way to do this would be to represent the row and column indices as fractional values rather than integers. Then you'd be able to see a row index of 1.85 (for example) instead of it being rounded down to 1 or up to 2.
MPO said:
I’m looking at Scalar’s and would like to know how they work and if we can/how to tweak them to assist us when re-mapping with TunerPro. Can anyone offer any advice and wisdom? :-)
Here's Jools answer from page 16spitfire4v8 said:
The fuel map multiplier in my mind changes the time allocated to each bit (normally termed microseconds per bit in other aftermarket ecus). What I have been doing is to massage the fuel multiplier to get the fuelling correct at the richest point on full throttle power runs on the dyno with FF in the load sites passed through during the run, then leaving the multiplier alone and going back and correcting all the other fuel map sites to get the mixture where I want it.
In this way you can maximise the resolution of the fuel map which becomes important when you are dealing with small numbers in the fuel map around idle and trailing throttle.
The multiplier therefore does become engine size dependant because a big engine will draw more air, will require more fuel, or in the case of the multiplier part - more microseconds of fuel squirted per bit.
Make sense to anyone?
In this way you can maximise the resolution of the fuel map which becomes important when you are dealing with small numbers in the fuel map around idle and trailing throttle.
The multiplier therefore does become engine size dependant because a big engine will draw more air, will require more fuel, or in the case of the multiplier part - more microseconds of fuel squirted per bit.
Make sense to anyone?
stevesprint said:
MPO said:
I’m looking at Scalar’s and would like to know how they work and if we can/how to tweak them to assist us when re-mapping with TunerPro. Can anyone offer any advice and wisdom? :-)
Here's Jools answer from page 16spitfire4v8 said:
The fuel map multiplier in my mind changes the time allocated to each bit (normally termed microseconds per bit in other aftermarket ecus). What I have been doing is to massage the fuel multiplier to get the fuelling correct at the richest point on full throttle power runs on the dyno with FF in the load sites passed through during the run, then leaving the multiplier alone and going back and correcting all the other fuel map sites to get the mixture where I want it.
In this way you can maximise the resolution of the fuel map which becomes important when you are dealing with small numbers in the fuel map around idle and trailing throttle.
The multiplier therefore does become engine size dependant because a big engine will draw more air, will require more fuel, or in the case of the multiplier part - more microseconds of fuel squirted per bit.
Make sense to anyone?
In this way you can maximise the resolution of the fuel map which becomes important when you are dealing with small numbers in the fuel map around idle and trailing throttle.
The multiplier therefore does become engine size dependant because a big engine will draw more air, will require more fuel, or in the case of the multiplier part - more microseconds of fuel squirted per bit.
Make sense to anyone?
Does anyone know what impact the ROW SCALAR has on fueling when changing it, I notice the 500 is 91 and the 4* are 91-B2? and does it have to be 91 or B2?
I just built and released RoverGauge 0.7.5:
https://drive.google.com/drive/folders/0B83FOZ5t1n...
or
https://github.com/colinbourassa/rovergauge/releas...
There are a couple new features:
https://drive.google.com/drive/folders/0B83FOZ5t1n...
or
https://github.com/colinbourassa/rovergauge/releas...
There are a couple new features:
- The fuel map row and column in the log file are now fractional (rather than being rounded down).
- If you pass "-a" as a command line parameter, the application will automatically connect on startup, just as if you pressed the Connect button. This may be useful for people who are running RoverGauge on a tablet or integrated car computer.
Colin
Excellent and thanks again for the 1st class support.
Would it be possible to add a button to reset the ECU's battery Backed RAM so we don't have to pull the main harness plug each time. I can image this might be dangerous if the engine was running but would it be safe if the engine wasn't running or would it still be risky as the initial values wouldn't be reloaded? I'm mainly interested in the stepper motor saved value and the long lambda trims.
Cheers
Steve
Excellent and thanks again for the 1st class support.
Would it be possible to add a button to reset the ECU's battery Backed RAM so we don't have to pull the main harness plug each time. I can image this might be dangerous if the engine was running but would it be safe if the engine wasn't running or would it still be risky as the initial values wouldn't be reloaded? I'm mainly interested in the stepper motor saved value and the long lambda trims.
Cheers
Steve
stevesprint said:
Here's Jools answer from page 16
Steve, I'm glad you remembered Jools' excellent explanation of the map scalar earlier in this thread. I think he nailed it.stevesprint said:
Would it be possible to add a button to reset the ECU's battery Backed RAM so we don't have to pull the main harness plug each time.
This would not be a good idea. The ECU frequently writes to this area when values need to be updated. Some of the values are also written during the shutdown sequence. Even when this RAM area is not being written, the data is periodically being compared with a copy kept elsewhere in memory. Cutting power is a cleaner and more predictable way to reset the saved data. A battery cut-off switch makes it easy and saves wear and tear on the main ECU connector. Another way is to put a toggle switch in line with the wire (brown, I think) that goes to pin 15 on the main connector. This wire supplies the constant battery voltage to the ECU to maintain the saved data even when the ignition is off. Turning this switch off for a few seconds with the ignition off should do it. Check the pin first with a voltmeter to make sure I got the pin number correct. By the way, the Mot 6803 monitors this 12V input to tell the software when the data is deemed unreliable. The data in RAM doesn't need to be destroyed. If the reliabilty bit is negated, the software will do the data reset on the next power-up.One final thing. The latest version of RoverGauge takes command line argument "-d" to double the communication baud rate from 7812.5 to 15625 baud. I have been using this for some time with good results. The overall data flow rate is not doubled but is significantly improved. You need to make a minor change to the 14CUX code in two files (reset.asm and mainLoop.asm). To switch between the two baud rates, I use defines in the data file as follows:
;BAUDRATE_UART_ON = $050A ; 7812.5 (UART enabled)
;BAUDRATE_UART_OFF = $0500 ; 7812.5 (UART disabled)
BAUDRATE_UART_ON = $840A ; 15625 (UART enabled)
BAUDRATE_UART_OFF = $8400 ; 15625 (UART disabled)
One pair must be commented out as shown. The values are loaded into the sciModeControl register, so you can search for "sciModeControl" in these two files. You may think that this would lead to more communication errors, but my experience shows just the opposite. Two-byte values are transmitted closer together in time, minimizing data writes in between. Also, why is the UART ever disabled? The same MPU pins are used for a "bit-bang" interface to the OBDD which uses Philips IIC protocol.
https://en.wikipedia.org/wiki/Bit_banging
Dan, You've been doing some amazing things!!
I realise we add the four lines complete to our data file (data_R3652_430_6250.asm) and comment out two lines as required.
Please confirm I have the following changes correct
I realise we add the four lines complete to our data file (data_R3652_430_6250.asm) and comment out two lines as required.
Please confirm I have the following changes correct
reset.asm Line 269
from ldd #$050A
to ldd #BAUDRATE_UART_ON
mainLoop.asm line 564
from ldd #$050A
to ldd #BAUDRATE_UART_ON
i2c.asm line 64
ldd #$0500 ; disables SCI xmt and rcv
ldd #BAUDRATE_UART_OFF ; disables SCI xmt and rcv
davep said:
Dan, do we need to add the four line UART define block to all three files where sciModeControl is used? If so, where in the code sequence should the insert offsets appear?
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 couldn't test Dan's double comms speed mod quick enough and I'm pleased to report the log file has increased from 2 records a second to 5.
Very Impressive & 5 records a second is very useable.
time,roadSpeed,engineSpeed,waterTemp,fuelTemp,throttlePos,mafPercentage,idleBypassPos,mainVoltage,currentFuelMapIndex,currentFuelMapRow,currentFuelMapCol,targetIdle,lambdaTrimOdd,lambdaTrimEven,pulseWidthMs
19:27:12.113,0,968,-17,-17,0.0527859,0.0432042,0,0,2,0.9375,5.375,0,0,0,0
19:27:12.289,0,978,-17,-17,0.0527859,0.0423944,0,0,2,0.875,5.5,0,0,0,0
19:27:12.513,0,980,-17,-17,0.0537634,0.0411799,0,0,2,0.9375,5.375,0,0,0,0
19:27:12.689,0,982,-17,-17,0.0527859,0.0410642,0,0,2,1,5.3125,0,0,0,0
19:27:12.913,0,961,-17,-17,0.0537634,0.0434355,0,0,2,0.9375,5.375,0,0,0,0
19:27:13.137,0,964,-17,-17,0.0527859,0.0419896,0,0,2,0.9375,5.3125,0,0,0,0
19:27:13.408,0,947,-17,-17,0.0527859,0.0418739,0,0,2,0.9375,5.25,0,0,0,0
19:27:13.585,0,962,-17,-17,0.0527859,0.0425101,0,0,2,1,5.3125,0,0,0,0
19:27:13.809,0,967,-17,-17,0.0527859,0.0434355,0,0,2,0.9375,5.4375,0,0,0,0
19:27:13.985,0,988,-17,-17,0.0537634,0.0425101,0,0,2,0.9375,5.4375,0,0,0,0
Luckily Dan's double speed mod doesn't change the layout of the bin file and only three bytes at the following prom offset have changed from 05 to 84
PLEASE NOT THESE OFFSETS ARE FOR R3652 ONLY!!!
09B4/49B4
0C40/4C40
3260/7260
PLEASE NOT THESE OFFSETS ARE FOR R3652 ONLY!!!
If anyone needs a hand with another revision please let me know.
Colin,
I'm even more pleased to see at idle my currentFuelMapRow is now 0.9xx and not rounded down, thanks.
MPO,
Sounds like its time I give you a hand to get started with Dan's rebuild project.
Edited by stevesprint on Tuesday 25th August
After further logging I've since realised this RoverGauge logging speed increase was not only due to doubling the comms speed but also by reducing the number of sensors logged.
Very Impressive & 5 records a second is very useable.
time,roadSpeed,engineSpeed,waterTemp,fuelTemp,throttlePos,mafPercentage,idleBypassPos,mainVoltage,currentFuelMapIndex,currentFuelMapRow,currentFuelMapCol,targetIdle,lambdaTrimOdd,lambdaTrimEven,pulseWidthMs
19:27:12.113,0,968,-17,-17,0.0527859,0.0432042,0,0,2,0.9375,5.375,0,0,0,0
19:27:12.289,0,978,-17,-17,0.0527859,0.0423944,0,0,2,0.875,5.5,0,0,0,0
19:27:12.513,0,980,-17,-17,0.0537634,0.0411799,0,0,2,0.9375,5.375,0,0,0,0
19:27:12.689,0,982,-17,-17,0.0527859,0.0410642,0,0,2,1,5.3125,0,0,0,0
19:27:12.913,0,961,-17,-17,0.0537634,0.0434355,0,0,2,0.9375,5.375,0,0,0,0
19:27:13.137,0,964,-17,-17,0.0527859,0.0419896,0,0,2,0.9375,5.3125,0,0,0,0
19:27:13.408,0,947,-17,-17,0.0527859,0.0418739,0,0,2,0.9375,5.25,0,0,0,0
19:27:13.585,0,962,-17,-17,0.0527859,0.0425101,0,0,2,1,5.3125,0,0,0,0
19:27:13.809,0,967,-17,-17,0.0527859,0.0434355,0,0,2,0.9375,5.4375,0,0,0,0
19:27:13.985,0,988,-17,-17,0.0537634,0.0425101,0,0,2,0.9375,5.4375,0,0,0,0
Luckily Dan's double speed mod doesn't change the layout of the bin file and only three bytes at the following prom offset have changed from 05 to 84
PLEASE NOT THESE OFFSETS ARE FOR R3652 ONLY!!!
09B4/49B4
0C40/4C40
3260/7260
PLEASE NOT THESE OFFSETS ARE FOR R3652 ONLY!!!
If anyone needs a hand with another revision please let me know.
Colin,
I'm even more pleased to see at idle my currentFuelMapRow is now 0.9xx and not rounded down, thanks.
MPO,
Sounds like its time I give you a hand to get started with Dan's rebuild project.
Edited by stevesprint on Tuesday 25th August
After further logging I've since realised this RoverGauge logging speed increase was not only due to doubling the comms speed but also by reducing the number of sensors logged.
Edited by stevesprint on Tuesday 25th August 03:07
Thanks Dan and Steve :-)
I’m hoping this is not off topic… 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?
I’m hoping this is not off topic… 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?
Gassing Station | Griffith | Top of Page | What's New | My Stuff