Instructions to change fuel maps on 14CUX Griffith, Chimaera
Discussion
spitfire4v8 said:
blitzracing said:
The next challange now is to turn off the lambda feeback so the ECU does not correct the mixture on the fly and alter your gas readings as you make changes to the map. Mark Adams described it as trying to put up a level shelf on a moving boat..... If I get a spot at the weekend Ill try running the cat map without probes connected and see if it drops back to limp home map. If it does not, and simply runs with 0% fuel trim, Id say let the mapping commence. 
this is the stage we need to get to to map cat cars .. I can't believe at this moment that the lucas lambda control is so rubbish that it makes mapping in closed loop such a lottery, but of course I won't know until it's been tried.robertf03 said:
Is the spark interrupt routine stored on the chip and could we remove the call to the o2 update?
The only way to run open loop is by selecting an open loop map (1, 2 or 3). If it's a NAS vehicle, it will be a little more difficult (there may be a software lock value and a missing connection). If you have cats installed, I wouldn't even attempt to run open loop. Mark makes a good point about optimizing in a localized way, if it can be done. Also, even closed loop maps run open above a certain RPM, so you may have some freedom there. Other than than, as Mark also mentioned, the goal should just be to keep the trim centered.
danbourassa said:
The only way to run open loop is by selecting an open loop map (1, 2 or 3). If it's a NAS vehicle, it will be a little more difficult (there may be a software lock value and a missing connection). If you have cats installed, I wouldn't even attempt to run open loop. Mark makes a good point about optimizing in a localized way, if it can be done. Also, even closed loop maps run open above a certain RPM, so you may have some freedom there. Other than than, as Mark also mentioned, the goal should just be to keep the trim centered.
Dan/Colin/Robert/DaveP/Mark/anyoneMark and Joolz’s (spitfire4v8) discussion has thrown my mind into overdrive and as a result I thought it might be useful to bounce some ideas around to see what the options are: -
1. Would it be possible to add an option to RoverGauge to temporarily speed up the long-term lambda cycle?
2. Would it be possible to add a lambda long term trim reset button to RoverGauge.
3. What other parameters does the 14CUX learn, e.g. stepper position??
4. Could you add an option to RoverGauge to refresh the fuel map displayed (I had to disconnect and reconnect each time)
5. If I really wanted to turn off the lambdas, I realise the risks, is there any reason why I couldn’t copy the cat map 5 to a non-cat map 2 and change the map resister accordingly, does it run the same main code? I understand not for NAS vehicle?
6. Would it be possible to add an option to RoverGauge to switch maps, on second thoughts that could be very very risky in the wrong hands but anyway would it be possible?
7. How can Lambda sensors work on a TVR when they are down wind of the precats?
8. Do rolling roads normally map cars with the lambdas functioning?
Sorry I’m throwing a lot of questions into the air, I just want to get some options bouncing around to see what goes over the fence and what sticks.
Thank you in anticipation.
Cheers Steve
P.S. This reminds me why I bought a pre-cat Griff
stevesprint said:
Dan/Colin/Robert/DaveP/Mark/anyone
Mark and Joolz’s (spitfire4v8) discussion has thrown my mind into overdrive and as a result I thought it might be useful to bounce some ideas around to see what the options are: -
1. Would it be possible to add an option to RoverGauge to temporarily speed up the long-term lambda cycle?
2. Would it be possible to add a lambda long term trim reset button to RoverGauge.
3. What other parameters does the 14CUX learn, e.g. stepper position??
4. Could you add an option to RoverGauge to refresh the fuel map displayed (I had to disconnect and reconnect each time)
5. If I really wanted to turn off the lambdas, I realise the risks, is there any reason why I couldn’t copy the cat map 5 to a non-cat map 2 and change the map resister accordingly, does it run the same main code? I understand not for NAS vehicle?
6. Would it be possible to add an option to RoverGauge to switch maps, on second thoughts that could be very very risky in the wrong hands but anyway would it be possible?
7. How can Lambda sensors work on a TVR when they are down wind of the precats?
8. Do rolling roads normally map cars with the lambdas functioning?
Sorry I’m throwing a lot of questions into the air, I just want to get some options bouncing around to see what goes over the fence and what sticks.
Thank you in anticipation.
Cheers Steve
P.S. This reminds me why I bought a pre-cat Griff
I'll answer what I can:Mark and Joolz’s (spitfire4v8) discussion has thrown my mind into overdrive and as a result I thought it might be useful to bounce some ideas around to see what the options are: -
1. Would it be possible to add an option to RoverGauge to temporarily speed up the long-term lambda cycle?
2. Would it be possible to add a lambda long term trim reset button to RoverGauge.
3. What other parameters does the 14CUX learn, e.g. stepper position??
4. Could you add an option to RoverGauge to refresh the fuel map displayed (I had to disconnect and reconnect each time)
5. If I really wanted to turn off the lambdas, I realise the risks, is there any reason why I couldn’t copy the cat map 5 to a non-cat map 2 and change the map resister accordingly, does it run the same main code? I understand not for NAS vehicle?
6. Would it be possible to add an option to RoverGauge to switch maps, on second thoughts that could be very very risky in the wrong hands but anyway would it be possible?
7. How can Lambda sensors work on a TVR when they are down wind of the precats?
8. Do rolling roads normally map cars with the lambdas functioning?
Sorry I’m throwing a lot of questions into the air, I just want to get some options bouncing around to see what goes over the fence and what sticks.
Thank you in anticipation.
Cheers Steve
P.S. This reminds me why I bought a pre-cat Griff
1. I'm not intimately familiar with the long-term lambda code, but I think the answer is almost certainly no. The timing data is probably read directly from the ROM, and therefore wouldn't be adjustable by changing values in RAM.
2. This is definitely possible. It's probably just a matter of writing the midpoint value to the two 16-bit long-term trim locations. I'll look into it.
3. The 14CUX doesn't so much "learn" the idle motor position because it gets no feedback from it. (It only knows the position because of dead reckoning.) Offhand, I can say that the minimum throttle position is learned (i.e. measured over time and stored in RAM.)
4. Although this would be possible, I'm reluctant to do it because it would either mean clicking a button (which is already possible by 'Disconnect'->'Connect') or by constantly re-reading the current fuel map, which costs a great deal of bandwidth.
5. You can definitely copy a cat map to a non-cat map position, but the ECU will not run exactly the same code. There are many branches in the firmware for cat vs. non-cat map selection. There are also many pieces of data that are map-specific (e.g. RPM limit and various comparison thresholds).
6. Changing maps via a write to RAM is not possible. The tune resistor ADC routine is in the normal ADC mux table, so it will be continuously re-read and set the map back to the one selected by the tune resistor. You could, however, have a rotary switch (or a decade box) wired in, so that the appropriate impedance is selectable.
--Colin
I will also answer what I can
1. Would it be possible to add an option to RoverGauge to temporarily speed up the long-term lambda cycle?
I think you are looking for instant feedback to the accuracy of your fuel map. You should be using a wideband O2 sensor instead of relying on ECM trims. I use an Innovate LM-1
2. Would it be possible to add a lambda long term trim reset button to RoverGauge.
Pull the EFI fuse for 1 second, gone.
8. Do rolling roads normally map cars with the lambdas functioning?
No, not the ones I've been around at least. The operator ALWAYS disables the feedback and usually replaces the o2 sensor with a wideband. If the vehicle has no catalytic converters then a tailpipe mounted sensor is good enough
1. Would it be possible to add an option to RoverGauge to temporarily speed up the long-term lambda cycle?
I think you are looking for instant feedback to the accuracy of your fuel map. You should be using a wideband O2 sensor instead of relying on ECM trims. I use an Innovate LM-1
2. Would it be possible to add a lambda long term trim reset button to RoverGauge.
Pull the EFI fuse for 1 second, gone.
8. Do rolling roads normally map cars with the lambdas functioning?
No, not the ones I've been around at least. The operator ALWAYS disables the feedback and usually replaces the o2 sensor with a wideband. If the vehicle has no catalytic converters then a tailpipe mounted sensor is good enough
stevesprint said:
8. Do rolling roads normally map cars with the lambdas functioning?
I assume you mean functioning as closed loop - You really need to disable closed loop, so you are the only thing that is making adjustments.You should leave the lambdas powered up if they are in the exhaust though, as the heater inside them burns off deposits.
Going forwards, without the ability to disable closed loop on the ECU (did I read that correctly?), I wonder if you could make a circuit to simulate perfect lambda, so the feedback the ECU gets is always steady state?
On the lambda feedback bit : it would be unwise to try and map the lambda controlled part if you had no way of looking at the trims being applied by the ecu because you would never know where your fuel map is in relation to the trim being applied.
But in rovergauge we have access to both the long term and short term trim therefore I believe it is entirely right that you can map the fuel under lambda control until you see the trims reaching as close to zero as possible, that then gives your ecu the largest possible range of trimming left to make any changes it needs to itself.
This is how I map the lambda areas of the MBE ecus fitted to later TVRs .. I have the wideband up the exhaust as well but that's only a quick reference as I'm tapping the fuel keys on the laptop, the last bit I do off the lambda trim values through the ecu so that the amount of trimming is the least required. It is a very quick way of mapping the closed loop and I can't at the moment see any reason why I shouldn't be able to do the lucas in exactly the same way. I will have to wait to try it on my dyno of course but running through the mapping sequence in my head the actual events sequence should be the same as described above..
But in rovergauge we have access to both the long term and short term trim therefore I believe it is entirely right that you can map the fuel under lambda control until you see the trims reaching as close to zero as possible, that then gives your ecu the largest possible range of trimming left to make any changes it needs to itself.
This is how I map the lambda areas of the MBE ecus fitted to later TVRs .. I have the wideband up the exhaust as well but that's only a quick reference as I'm tapping the fuel keys on the laptop, the last bit I do off the lambda trim values through the ecu so that the amount of trimming is the least required. It is a very quick way of mapping the closed loop and I can't at the moment see any reason why I shouldn't be able to do the lucas in exactly the same way. I will have to wait to try it on my dyno of course but running through the mapping sequence in my head the actual events sequence should be the same as described above..
It takes 2.5 mins at idle to reset the long term trim, so you cant really alter a setting and wait- you would be there all day. On the bright side the long term trim is only set at idle (as least as far as I can tell, when conditions are stable), so reset the ECU and get the idle mixture right to start with to get minimum long term trim. Any changes in the map above idle wont affect this setting from that point upwards, so you can then concentrate on minimum short term trim up to 3400 RPM when it goes open loop anyway.
stevesprint, like you I’m so pleased that I have a pre-cat (open loop) car, life is so much easier. So I’m unable to offer any input on the closed loop stuff as I’ve not bothered to look at it. Basically, I’m a pre-cat Griffith owner/RoverGuage user who is interested in what goes on within, so this thread has been a real bonus.
So far I’ve not had a lot of time to look at the 14CUX Assembly code to gain a useful understanding, but I’m working on it. However, what immediately struck me was the inefficient ‘one size fits all’ approach that results in code redundancy and processor overhead; especially for a basic Griffith pre-cat application. For example:
- ADC routine 6, Air Conditioner loading
- “ “ D, O2 sense voltage
- “ “ 1, Heated Rear Screen
- Purge valve timer interrupt and loop
- O2 sensing
- Routines labelled as unused and maybeUnused.
Then there’s the Patch fixes and wasted processor power of the type Dan has described in his explanations. And how many times does the processor need to check the Tune Resistor value for map selection during a single session (from ignition On to ignition Off)? I’m not sure if the ADC table is multiplexed or round robin (cyclic) and how it is timed and values selected, but for ordinary use surely the resistor value only needs to be checked once/session?
So once real-time mapping and lambda control is fully solved what about looking at potential gains (if any) of firmware fixes that run on the existing architecture? Or is that pushing the envelope too far?
So far I’ve not had a lot of time to look at the 14CUX Assembly code to gain a useful understanding, but I’m working on it. However, what immediately struck me was the inefficient ‘one size fits all’ approach that results in code redundancy and processor overhead; especially for a basic Griffith pre-cat application. For example:
- ADC routine 6, Air Conditioner loading
- “ “ D, O2 sense voltage
- “ “ 1, Heated Rear Screen
- Purge valve timer interrupt and loop
- O2 sensing
- Routines labelled as unused and maybeUnused.
Then there’s the Patch fixes and wasted processor power of the type Dan has described in his explanations. And how many times does the processor need to check the Tune Resistor value for map selection during a single session (from ignition On to ignition Off)? I’m not sure if the ADC table is multiplexed or round robin (cyclic) and how it is timed and values selected, but for ordinary use surely the resistor value only needs to be checked once/session?
So once real-time mapping and lambda control is fully solved what about looking at potential gains (if any) of firmware fixes that run on the existing architecture? Or is that pushing the envelope too far?
davep said:
So once real-time mapping and lambda control is fully solved what about looking at potential gains (if any) of firmware fixes that run on the existing architecture? Or is that pushing the envelope too far?
Dave, the potential gains are huge. One of our future projects is to be able to build the PROM code from scratch. The idea is to have build control flags so you can turn features (like the heated screen) on or off. We talked about having the ability to re-create various tunes bit for bit, but that would make things a lot more complicated. The original code is so bad that a better idea is to understand it well enough to eliminate all the bad and unnecessary parts. The software tools would all be open source (of course). Changing the software the way we want opens up many possibilities like real-time software controlled fuel map switching and maybe doubling the baud rate to RoverGauge. This could be fun.stevesprint said:
Dan/Colin/Robert/DaveP/Mark/anyone
7. How can Lambda sensors work on a TVR when they are down wind of the precats?
P.S. This reminds me why I bought a pre-cat Griff
Lambda probes dont measure the exhaust gas based on CO or CO2 (like a gas analysers), but the amount of unused oxygen remaining after the burn. From memory exhaust going through the catalysts involves several chemical reactions where oxygen is ripped from some of the oxides present, and used to ignite any unburnt fuel, and the actual cycling of the mixture aids the process by shifting the chemical balance in the cat between oxygen rich and oxygen lean. This kills off lots of different pollutants in one process but I would not like to say if any of the unused oxygen from combustion gets used or added too, but the fact that the TVR cycles the mixture at all means any shifts in oxygen levels cant be huge through the catalyst process.7. How can Lambda sensors work on a TVR when they are down wind of the precats?
P.S. This reminds me why I bought a pre-cat Griff
Thanks everyone for answering my random questions. I've been busy testing my PreCat Griff with a white tune resistor and my non cat fuel map copied to map 5 and with the Lambda's disconnected. Within 25 seconds the short term trims shot to 100% on the right. After a further 2 minutes they reset to the centre/center but this time moved one at a time to 100% and produced lambda errors, first the right then the lefts. Although my car stayed on fuel map 5 with the lambdas errors it drove surprisingly well. I still think their are too many unknowns and risks with disconnecting the lambdas. For example does the code compensate for the missing lambda sensors? Are the throttle direction tables different? Mark it would be interesting to hear how well your car drives with the same test.
1. I love this forum; you ask one question and get three very different and very valid answers. Spitfire as you tune the later TVRs from the lambda trims and a wide band sensor it’s time you try the same technique on the 14CUX after a reset. Now I've seen the trims work I guess you could tune on the short term plus a wide band sensor before the long trim kicks in.
2. Yes please, it will make Spitfire's life easier.
3. That's interesting, so it learns lambda trims plus minimum idle motor position. Shame it doesn't learn max idle motor position for given engine temperatures.
4. Sorry Colin, I didn't mean constantly, I was thinking more of a refresh button near the map.
5. Thanks, that’s what I would expect. A long time ago someone told me TVR didn't bother copying the cat fuel maps and code to the Precat ECU’s but your comments and my test above proves that wrong. My Griffith's 4.3 cat fuel map looked like a standard 3.9 Land Rover cat map and certainly wasn't blank.
6. That makes sense especially when I've seen the map number change mid flight when changing the tune resistor. Maybe it's for the best as in the wrong hands could be risky and I'm sure most people in the 14CUX business would have a collection of tune resistors.
Keep up the good work chaps & Cheers
Steve
1. I love this forum; you ask one question and get three very different and very valid answers. Spitfire as you tune the later TVRs from the lambda trims and a wide band sensor it’s time you try the same technique on the 14CUX after a reset. Now I've seen the trims work I guess you could tune on the short term plus a wide band sensor before the long trim kicks in.
2. Yes please, it will make Spitfire's life easier.
3. That's interesting, so it learns lambda trims plus minimum idle motor position. Shame it doesn't learn max idle motor position for given engine temperatures.
4. Sorry Colin, I didn't mean constantly, I was thinking more of a refresh button near the map.
5. Thanks, that’s what I would expect. A long time ago someone told me TVR didn't bother copying the cat fuel maps and code to the Precat ECU’s but your comments and my test above proves that wrong. My Griffith's 4.3 cat fuel map looked like a standard 3.9 Land Rover cat map and certainly wasn't blank.
6. That makes sense especially when I've seen the map number change mid flight when changing the tune resistor. Maybe it's for the best as in the wrong hands could be risky and I'm sure most people in the 14CUX business would have a collection of tune resistors.
Keep up the good work chaps & Cheers
Steve
I too have been driving up the road on map 5 without lambda sensors, and got a similar result, in so much that the ECU started to apply more and more short term trim to try and get the probes switching again, so Id agree we simply cant unplug them. (BTW the car drives fine like this) Id think the easiest answer would be to fake the lambda input with a perfect 1 volt square wave of about 2 to 4 hz. The fact that the mark / space ratio of the waveform is balanced should fool the ECU into thinking the mixture is perfect. Ill knock something up and see what happens.
Thinking one step ahead of this, you could monitor the output of the stock probes whilst supplying the fake signal as they work quite happily with the outputs removed from the ECU, and simply alter the mapping until the probe switches state. The big advantage here is the RV8 Lambda one is slightly shifted at 14.35:1 AF ratio, not the more common 14.7:1, so you can get the mapping to match the probe design instead of using gas results.
Mark
Have you seen this little tool, it removes the pain from fixing the checksum. It's just what we need and it works a treat, Thanks Workshop15 Ltd.
http://www.pistonheads.com/gassing/topic.asp?h=0&a...
Enjoy, Steve
Have you seen this little tool, it removes the pain from fixing the checksum. It's just what we need and it works a treat, Thanks Workshop15 Ltd.
http://www.pistonheads.com/gassing/topic.asp?h=0&a...
Enjoy, Steve
I've been lagging.
Here is the tunerpro DLL as promised
www.flemcodesign.com/files/14CUX_CHECKSUM.ZIP
the xdf is still a mess, I'll update that in the future.
The DLL needs to be placed in the tunerpro folder in the program files directory.
There are 2 options in the checksum dll. The first is checksum only, the second (and more useful IMO) is checksum and bin stack. The XDF defaults to use the checksum and bin stack. You can toggle between the two by editing the xdf header info and going to the checksum tab.
For those unfamiliar with how this works in tunerpro, checksum is automatically updated when the file is saved, that means the bin will be stacked at that point.
When using tunerpro RT with an eprom emulator it will auto update the checksum and stack each time a change is made.
this means real time tuning with checksum updates is here, though I haven't tested it yet.
Here is the tunerpro DLL as promised
www.flemcodesign.com/files/14CUX_CHECKSUM.ZIP
the xdf is still a mess, I'll update that in the future.
The DLL needs to be placed in the tunerpro folder in the program files directory.
There are 2 options in the checksum dll. The first is checksum only, the second (and more useful IMO) is checksum and bin stack. The XDF defaults to use the checksum and bin stack. You can toggle between the two by editing the xdf header info and going to the checksum tab.
For those unfamiliar with how this works in tunerpro, checksum is automatically updated when the file is saved, that means the bin will be stacked at that point.
When using tunerpro RT with an eprom emulator it will auto update the checksum and stack each time a change is made.
this means real time tuning with checksum updates is here, though I haven't tested it yet.
Got it, try downloading again.
A few things about this. It is copying the upper half to the lower half at checksum calculation. After some thought I think we should be editing the lower table and it copying the lower to the upper at recalculation since the 14CUX seems to ignore the upper half as far as I can tell.
I was also wrong about auto checksum updates, Tunerpro RT does not recalc the checksum evertime there is an update, only when the BIN is saved. I don't think this will be a problem since it only evaluates it at startup.
I'll post up when I have an updated xdf for the lower table addresses and a new checksum dll to match.
A few things about this. It is copying the upper half to the lower half at checksum calculation. After some thought I think we should be editing the lower table and it copying the lower to the upper at recalculation since the 14CUX seems to ignore the upper half as far as I can tell.
I was also wrong about auto checksum updates, Tunerpro RT does not recalc the checksum evertime there is an update, only when the BIN is saved. I don't think this will be a problem since it only evaluates it at startup.
I'll post up when I have an updated xdf for the lower table addresses and a new checksum dll to match.
Gassing Station | Griffith | Top of Page | What's New | My Stuff