Instructions to change fuel maps on 14CUX Griffith, Chimaera
Discussion
Discoveryunlimited said:
Amazing to see how busy this topic still is.
One of the things that has always got me is the AFM, I have been using the Bosch 0 280 218 010 meter with the remap but as we know the MAF curve is a fair bit different than the 5AM. (I am running a range rover classic not a grif...... and pushing 3 tonnes with everything on it)
This is the chart comparing the two meters: (I also have ADC counts if anyone is interested)
I have spent a lot of time in the rebuild code looking at the MAF related code and the interactions with it in the system as a whole. I am slowing working through how it uses the readings from the airflow meter. In the mean time I have created a little airflow converter that takes in the signal from the bosch and maps that to the equivalent signal of the 5AM. My setup is running the fuel rail at 3.5bar with EV6 injectors (4 hole spray), using a GEMS system plenum top with a 200 count air idle control stepper motor (code modified from the 180 count).
I just ran some test today with it (of course with new base maps) and I do think the car runs better. I use to find at the top end the car would get flat and I believe that this is because the bosch curve flattens out at the top end, how the 14CUX linearises the curve and uses it for load indexing it appears the load is reducing. When comparing the linearised MAF load with and without the airflow converter, the MAF load is higher at idle and in lower throttle positions. Once corrected the MAF loading is reduced for lower loads and increased for higher loads.
Overall I find the car much more responsive with a smoother idle when hot (I have kept throttle maps, coolant table etc the same and only changed the relevant fuel maps and scalars). Based on what I understand (which is limited) from the code and what I have seen today I do believe that while the 14CUX can be made to work with the bosch directly it is not particularly ideal and actually makes the system run sub-optimal.
My ultimate goal would be to modify the rebuild project to natively use the bosch meter, that is the linearisation of the MAF and its load indexing is correct for the airflow, so I am slowly chipping away at this.
Has anyone else looked at this? I am also be interested in the thoughts from the people that have spent a lot of time in the rebuild code and have spent many hours tuning the 14CUX.
Also as a side note using chatGPT for working through code sections is really a big help.
Cheers,
Josh
I went down the route of producing a small box that interfaced either the 20 AM or Bosch AFM to mimic the exact airflow characteristics of the 5AM. I tried this with both analogue electronics to modify the wave forms and a commercial system using a digital lookup table. I made the naively made mistake of thinking that I could use the increased airflow without remapping (This was way before the days of reverse engineering the fuel maps of the 14CUX). Now I realise that without increasing the fuel in the map, no power gains can be made, and subsequent rolling road tests of my unit proved this to be true.One of the things that has always got me is the AFM, I have been using the Bosch 0 280 218 010 meter with the remap but as we know the MAF curve is a fair bit different than the 5AM. (I am running a range rover classic not a grif...... and pushing 3 tonnes with everything on it)
This is the chart comparing the two meters: (I also have ADC counts if anyone is interested)
I have spent a lot of time in the rebuild code looking at the MAF related code and the interactions with it in the system as a whole. I am slowing working through how it uses the readings from the airflow meter. In the mean time I have created a little airflow converter that takes in the signal from the bosch and maps that to the equivalent signal of the 5AM. My setup is running the fuel rail at 3.5bar with EV6 injectors (4 hole spray), using a GEMS system plenum top with a 200 count air idle control stepper motor (code modified from the 180 count).
I just ran some test today with it (of course with new base maps) and I do think the car runs better. I use to find at the top end the car would get flat and I believe that this is because the bosch curve flattens out at the top end, how the 14CUX linearises the curve and uses it for load indexing it appears the load is reducing. When comparing the linearised MAF load with and without the airflow converter, the MAF load is higher at idle and in lower throttle positions. Once corrected the MAF loading is reduced for lower loads and increased for higher loads.
Overall I find the car much more responsive with a smoother idle when hot (I have kept throttle maps, coolant table etc the same and only changed the relevant fuel maps and scalars). Based on what I understand (which is limited) from the code and what I have seen today I do believe that while the 14CUX can be made to work with the bosch directly it is not particularly ideal and actually makes the system run sub-optimal.
My ultimate goal would be to modify the rebuild project to natively use the bosch meter, that is the linearisation of the MAF and its load indexing is correct for the airflow, so I am slowly chipping away at this.
Has anyone else looked at this? I am also be interested in the thoughts from the people that have spent a lot of time in the rebuild code and have spent many hours tuning the 14CUX.
Also as a side note using chatGPT for working through code sections is really a big help.
Cheers,
Josh
Hardware wise I was presented with various problems during long term testing. Using an analogue box the voltages tended not to be stable in the extreme temperature shifts of the engine bay, that would lead to mixture shifts and unstable idle. I probibibly could have over come this by putting the conversion unit inside the car but it stopped it being an easy plug and play solution. Once switched to digital conversion the extra internal electronics could not cope with the lightning storm HT system that spikes with both RF interference and corrupting the 12v supply line, especially in an unshielded glass fibre body. This constantly wiped the look up table in the NV ram.
As the new dawn of RoverGauge and Tuner pro made remapping a possibility the project sat in the back of the workshop and progressed no further as Id already wasted enough of my life on such follies.
This is analogue conversion unit
This is the two response curves for the 5AM vs the Bosch
The response curve having been analogue recalibrated.
Digital recalibration output.
Calibrating airflow does present various issues as you need to outflow the AFM to reach peak saturation, and the only way I could do this was with a petrol powered leaf blower. At one point I ended up with the whole assembly blowing apart across the workshop as the back pressure had built up so much with the smaller 5AM. Makes you realise how much air a 5ltr TVR pumps under full load and RPM !
Edited by blitzracing on Tuesday 14th May 08:55
Josh (Discoveryunlimited)
Thanks for your Bosch & 5AM comparison graph, excellent work & certainly confirms everyone’s thoughts and findings.
I'm sure your little Bosch airflow converter would be very popular if its plug & play and you overcome the issues Mark experienced as it won’t require a remap. We all know 5AMs are now all very old and failing and therefore could be the death of the 14CUX. Bosch 4.6L MAFs are still available new and its replaceable hot film cartridge is also used on some BMWs so hopefully will remain available new for a long time.
Furthermore, we currently can’t properly remap a 3.5, 3.9 & 4L to use the Bosch 4.6L MAF as the AFM scalar can’t be increased enough. This means a 4L with the Bosch 4.6L MAF don't flow enough air to use the bottom few rows of the main fuel table. As a result I really hope you can get your head around the AFM linearization code and workout what the linearization parameters do at prom offsets $1C3 $1C5. Dan once said its very impressive code for a 1980s processor without a maths co-processor. I personally think Motorola wrote the linearization code to help sell their processors to the motor trade, sadly I didn't pay attention enough in my physics lessons to King's law of hot wire & 4th order linearization polynomial equations because I never thought I’d use pure maths & differential equations again.
I’ve personally got excellent results remapping my home made 4.5BV with a Bosch 4.6 MAF by increasing both the AFM scalar (prom offset $483) and the AFM offset (prom offset $1C9). The scalar effectively amplifies the whole of the AFM output curve to hit the bottom row of the fuel table on full load and increasing the offset pulls the active row back up to the top of the fuel table on overrun. Works really well & my Bosch MAF has been 100% reliable but won’t work on a 4L.
Josh, do you know what vehicle uses your EV6 injectors? I’m hoping they are available in the UK.
Good luck with your airflow converter, I don’t mind testing its reliability on my Griff.
Steve
P.S, Good to hear you're using Dan’s assembler code and a GEMS 200 step stepper motor.
Thanks for your Bosch & 5AM comparison graph, excellent work & certainly confirms everyone’s thoughts and findings.
I'm sure your little Bosch airflow converter would be very popular if its plug & play and you overcome the issues Mark experienced as it won’t require a remap. We all know 5AMs are now all very old and failing and therefore could be the death of the 14CUX. Bosch 4.6L MAFs are still available new and its replaceable hot film cartridge is also used on some BMWs so hopefully will remain available new for a long time.
Furthermore, we currently can’t properly remap a 3.5, 3.9 & 4L to use the Bosch 4.6L MAF as the AFM scalar can’t be increased enough. This means a 4L with the Bosch 4.6L MAF don't flow enough air to use the bottom few rows of the main fuel table. As a result I really hope you can get your head around the AFM linearization code and workout what the linearization parameters do at prom offsets $1C3 $1C5. Dan once said its very impressive code for a 1980s processor without a maths co-processor. I personally think Motorola wrote the linearization code to help sell their processors to the motor trade, sadly I didn't pay attention enough in my physics lessons to King's law of hot wire & 4th order linearization polynomial equations because I never thought I’d use pure maths & differential equations again.
I’ve personally got excellent results remapping my home made 4.5BV with a Bosch 4.6 MAF by increasing both the AFM scalar (prom offset $483) and the AFM offset (prom offset $1C9). The scalar effectively amplifies the whole of the AFM output curve to hit the bottom row of the fuel table on full load and increasing the offset pulls the active row back up to the top of the fuel table on overrun. Works really well & my Bosch MAF has been 100% reliable but won’t work on a 4L.
Josh, do you know what vehicle uses your EV6 injectors? I’m hoping they are available in the UK.
Good luck with your airflow converter, I don’t mind testing its reliability on my Griff.
Steve
P.S, Good to hear you're using Dan’s assembler code and a GEMS 200 step stepper motor.
Paul (TRIUMPHBULLET)
Sorry for the delayed reply, I've been busy in the garage but you're always welcome send me a message to get my attention.
Yes you're right.
The code uses the throttle pot input to detect sudden throttle increases & decreases, the throttle table is used to calculate the amount and duration of the extra burst of fuel required for about a second when suddenly flooring it.
There are 5 throttle tables in TunerPro, 12&3 for non-cat maps and 4&5 for cat maps, here's an example how the throttle table works with your R2832 map2.
To increase your sudden throttle opening fuelling you need to increase the hex values in the throttle table on the 4th row at the required temperatures, you could also increase the duration by increasing the hex values on the 5th row. The column on the left comes into play when the temperature is between the columns and unfortunately its trial and error, good luck.
I also have a copy of the UK 3.5L version if you want to try it
www.remap-14cux.uk/bins/LR_R2667_3.5_UK_Disc.bin
Which fuel map do you run, non-cats or cat and are you in Australia?
Please let us know if Sardonicus suggestion worked, advancing the ignition timing, would be good to know. If not and your running a non-cat map its worth checking your CO TRIM in RoverGauge is over 1.25volts as you could be running generally too lean below 3,400rpm. If you don’t have RoverGauge you could try increasing you’re CO TRIM by turning the AFM screw clockwise half a turn at a time.
Good luck, its all good fun & let me know if you have any further questions
Steve
Sorry for the delayed reply, I've been busy in the garage but you're always welcome send me a message to get my attention.
Yes you're right.
The code uses the throttle pot input to detect sudden throttle increases & decreases, the throttle table is used to calculate the amount and duration of the extra burst of fuel required for about a second when suddenly flooring it.
There are 5 throttle tables in TunerPro, 12&3 for non-cat maps and 4&5 for cat maps, here's an example how the throttle table works with your R2832 map2.
98°89°73°46°29°17°6°-4°–11–17 - Top row is temperature in hex but here’s Degs C.
18 21 31 5A 7C 99 B3 CC DD EA - coolant temperature (low hex is hot)
06 08 0C 10 14 1C 26 30 33 33 - Detect Throttle opening sensitivity (Accel clamp)
07 07 07 07 07 00 00 00 00 00 - Detect Throttle Closing Sensitivity (Decel clamp)
3C 3C 3C 64 96 FF FF FF FF FF – Accel Fuel Multiplier for throttle opening
50 3C 32 1E 19 1E 1E 1E 19 19 - Accel time multiplier for throttle opening
55 55 55 55 55 1E 1E 1E 1E 1E - Decel time Multiplier for throttle closing
Decel Fuel multiplier is the same at all temperatures & found in each fuel map1-5.
Dan created this table so we can convert hex temperatures to degrees C.
first Hex digit down then second Hex digit across, then see Degs C in the table
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 130,129,127,126,124,123,121,120,118,117,115,114,112,111,109,108, 0
1 106,105,104,103,102,101,100, 99, 98, 97, 96, 95, 94, 93, 92, 91, 1
2 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 2
3 74, 73, 72, 71, 70, 70, 69, 68, 67, 66, 65, 64, 63, 63, 62, 61, 3
4 60, 59, 59, 58, 58, 57, 56, 56, 55, 55, 54, 54, 53, 52, 52, 51, 4
5 51, 50, 50, 49, 49, 48, 48, 47, 47, 46, 46, 45, 45, 44, 44, 43, 5
6 43, 42, 42, 41, 41, 40, 40, 39, 39, 38, 38, 37, 37, 36, 36, 35, 6
7 35, 35, 34, 34, 33, 33, 32, 32, 31, 31, 30, 30, 29, 29, 28, 28, 7
8 28, 28, 27, 27, 26, 26, 26, 25, 25, 24, 24, 23, 23, 23, 22, 22, 8
9 22, 21, 21, 20, 20, 19, 19, 18, 18, 17, 17, 16, 16, 15, 15, 14, 9
A 14, 14, 13, 13, 12, 12, 11, 11, 10, 10, 9, 9, 8, 8, 7, 7, A
B 7, 7, 6, 6, 6, 5, 5, 5, 4, 4, 3, 3, 3, 2, 2, 2, B
C 2, 1, 1, 0, 0, -1, -1, -2, -2, -3, -3, -4, -4, -5, -5, -6, C
D -6, -6, -7, -7, -8, -8, -8, -9, -9,-10,-10,-11,-11,-11,-12,-12, D
E -12,-13,-13,-14,-14,-15,-15,-16,-16,-17,-17,-18,-18,-19,-19,-20, E
F -20,-20,-21,-21,-22,-22,-22,-23,-23,-23,-24,-24,-24,-25,-25,-25 F
0 1 2 3 4 5 6 7 8 9 A B C D E F
To increase your sudden throttle opening fuelling you need to increase the hex values in the throttle table on the 4th row at the required temperatures, you could also increase the duration by increasing the hex values on the 5th row. The column on the left comes into play when the temperature is between the columns and unfortunately its trial and error, good luck.
I also have a copy of the UK 3.5L version if you want to try it
www.remap-14cux.uk/bins/LR_R2667_3.5_UK_Disc.bin
Which fuel map do you run, non-cats or cat and are you in Australia?
Please let us know if Sardonicus suggestion worked, advancing the ignition timing, would be good to know. If not and your running a non-cat map its worth checking your CO TRIM in RoverGauge is over 1.25volts as you could be running generally too lean below 3,400rpm. If you don’t have RoverGauge you could try increasing you’re CO TRIM by turning the AFM screw clockwise half a turn at a time.
Good luck, its all good fun & let me know if you have any further questions
Steve
blitzracing said:
I went down the route of producing a small box that interfaced either the 20 AM or Bosch AFM to mimic the exact airflow characteristics of the 5AM. I tried this with both analogue electronics to modify the wave forms and a commercial system using a digital lookup table. I made the naively made mistake of thinking that I could use the increased airflow without remapping (This was way before the days of reverse engineering the fuel maps of the 14CUX). Now I realise that without increasing the fuel in the map, no power gains can be made, and subsequent rolling road tests of my unit proved this to be true.
Hardware wise I was presented with various problems during long term testing. Using an analogue box the voltages tended not to be stable in the extreme temperature shifts of the engine bay, that would lead to mixture shifts and unstable idle. I probibibly could have over come this by putting the conversion unit inside the car but it stopped it being an easy plug and play solution. Once switched to digital conversion the extra internal electronics could not cope with the lightning storm HT system that spikes with both RF interference and corrupting the 12v supply line, especially in an unshielded glass fibre body. This constantly wiped the look up table in the NV ram.
As the new dawn of RoverGauge and Tuner pro made remapping a possibility the project sat in the back of the workshop and progressed no further as Id already wasted enough of my life on such follies.
This is analogue conversion unit
This is the two response curves for the 5AM vs the Bosch
The response curve having been analogue recalibrated.
Digital recalibration output.
Calibrating airflow does present various issues as you need to outflow the AFM to reach peak saturation, and the only way I could do this was with a petrol powered leaf blower. At one point I ended up with the whole assembly blowing apart across the workshop as the back pressure had built up so much with the smaller 5AM. Makes you realise how much air a 5ltr TVR pumps under full load and RPM !
Hi Mark,Hardware wise I was presented with various problems during long term testing. Using an analogue box the voltages tended not to be stable in the extreme temperature shifts of the engine bay, that would lead to mixture shifts and unstable idle. I probibibly could have over come this by putting the conversion unit inside the car but it stopped it being an easy plug and play solution. Once switched to digital conversion the extra internal electronics could not cope with the lightning storm HT system that spikes with both RF interference and corrupting the 12v supply line, especially in an unshielded glass fibre body. This constantly wiped the look up table in the NV ram.
As the new dawn of RoverGauge and Tuner pro made remapping a possibility the project sat in the back of the workshop and progressed no further as Id already wasted enough of my life on such follies.
This is analogue conversion unit
This is the two response curves for the 5AM vs the Bosch
The response curve having been analogue recalibrated.
Digital recalibration output.
Calibrating airflow does present various issues as you need to outflow the AFM to reach peak saturation, and the only way I could do this was with a petrol powered leaf blower. At one point I ended up with the whole assembly blowing apart across the workshop as the back pressure had built up so much with the smaller 5AM. Makes you realise how much air a 5ltr TVR pumps under full load and RPM !
Edited by blitzracing on Tuesday 14th May 08:55
I thought that I wouldn’t have been the first person to tackle the AFM. Interesting to hear your experience and it certainly highlights many of the aspects that were concerning me as I have embarked on this project.
I am very impressed with the converter that you have there and I can imagine the time you would have spent on getting it working especially calibrating an analogue device.
I have tackled the problem in a similar manner to what you did later, using off the shelf products. I have used an AVR board to take in the signal from the Bosch AFM. I then use a look up table to output the corrected signal corresponding to 5AM airflow, this is a PWM signal which feeds into a 10 bit DAC for analogue feed to the 14CUX.
I was able to make the table from the 5AM AFM data from Colin and Dan’s testing and then the data from the bosch HFM 5 AFM data sheet. I matched the mass airflow of the two which gives each corresponding voltage and from that I calculated the ADC counts which is what is in my table.
I, like you wanted to try and test this across the full range so first tried with a leaf blower. I also have a 200CFM extraction fan. When testing with both I found the blower is not suitable as the pressure buildup VS the pressure drop from sucking changes the signal, my conclusion was the sucking better matches what happens in the engine bay.
I bench tested from no flow up to the max flow for the exhaust fan and the curves were spot on to what I expected and matched the 5AM that I was comparing to. Knowing this I then used a potentiometer to simulate the Bosch AFM input from 0V to 5V and check the corresponding output of the DAC to what was expected. The plot from the potentiometer is below showing the full range. Like you said when you start trying to test you realise just how much air these engines flow and how much 500CFM actually is.
I currently have my first converter protype running in the car (along with a full remap etc. as required for my setup using the Moates ostrich). The converter is mounted away from the AFM, spark plug leads and heat in the engine bay (I’ll have to get a picture of it and update as I’m away at the moment with work). I also have it running off a dedicated 12V to 5V DC-DC converter (which also powers the AFM), essential for the correct output as both the AFM and converter need the same 5V reference.
I have driven about 10 hours total with the converter with the longest single trip being 200kms, so far I haven’t had any hiccups with it. Obviously, it needs much longer-term testing which I am doing to see what issues I encounter. The biggest upsides that I have noticed compared to my tune with the bosch AFM is more pull in the higher load region and the air idle is more open, this results in a much smoother and more controlled idle. The setup I am running is a 4.8L stroked motor with EV6 four spray injectors running a fuel rail pressure of 3.8bar using the 4.6L gems top and the 200 count stepper motor (code adjusted from the 180 steps).
Ultimately with what Dan and Colin have done with the reverse engineering of the 14CUX I am trying to adjust the linearisation aspect of the AFM in the rebuild project as this would be the most ideal solution. I’m slowly working on it but for the time being I’ll continue to test the converter and see if I encounter the issues you did. If you want to chat more feel free to contact me directly or I'll be checking back here regularly.
Hi all again.
I've been away for a while (not away as in prison, honest, just away on other 'projects') but I'm now back onto the car and playing with 14CUX and Rovergauge and as always I have a few questions.
Issue 1
Firstly, on starting to play again I downloaded the latest RG, 11.1 at that point, and one thing I find is that it doesn't seem possible to run the fuel pump (continuous) now, I switched back to v10.7 and it works OK. Has anybody else seen this or is it just my setup?
I also tried v11.2 with same result. Not a show stopper, just a 'nice to have' for setting fuel pressure, saves unplugging the vac' line.
Issue 2
I've recently added an AFR gauge to the car to make sure the mixture is as it should be. When the car is under power the mixture seems a little rich running between about 11:1 -> 13.5:1 but leans out when it comes to rest, I've seen values between 14->18:1 (Most typically between 14.5->15.5:1). Perhaps this is to be expected, no point in running rich at idle however this state seems to remain in effect for a short time even when I pull away again, sometimes accompanied by some stumbling or lack of power, I'd expect this to return instantly back to the richer side as soon as I start to pull away but it seems to take a while for this to take effect.
Has anyone seen simlar behaviour?
This is a screenshot of my map data (decimal values)
I'm assuming when at idle I'd be in the top or next to top row (unfortunately I can't run RG in the car at the moment so can't see this) and although the numerical delta between rows seems quite high it is no more than many other rows, of course I don't know if the load increments for each row are equal.
Why is this a problem?
In itself it's not too bad although, as mentioned, the car does sometimes seem a bit lacklustre when pulling away but mainly I was hoping to lean out the mixture as I think it's too rich when running (best figure I'm seeing is around 13.5 when cruising) but this will lean the idle even more, possibly giving other issues such as the pickup from idle. I could change the map values in individual areas but I was hoping to get reasonable behaviour by simply tweaking the fuel pressure down a little (I'm currently running at 38PSI which is a little higher than standard) or by altering the map muliplier value.
I've been away for a while (not away as in prison, honest, just away on other 'projects') but I'm now back onto the car and playing with 14CUX and Rovergauge and as always I have a few questions.
Issue 1
Firstly, on starting to play again I downloaded the latest RG, 11.1 at that point, and one thing I find is that it doesn't seem possible to run the fuel pump (continuous) now, I switched back to v10.7 and it works OK. Has anybody else seen this or is it just my setup?
I also tried v11.2 with same result. Not a show stopper, just a 'nice to have' for setting fuel pressure, saves unplugging the vac' line.
Issue 2
I've recently added an AFR gauge to the car to make sure the mixture is as it should be. When the car is under power the mixture seems a little rich running between about 11:1 -> 13.5:1 but leans out when it comes to rest, I've seen values between 14->18:1 (Most typically between 14.5->15.5:1). Perhaps this is to be expected, no point in running rich at idle however this state seems to remain in effect for a short time even when I pull away again, sometimes accompanied by some stumbling or lack of power, I'd expect this to return instantly back to the richer side as soon as I start to pull away but it seems to take a while for this to take effect.
Has anyone seen simlar behaviour?
This is a screenshot of my map data (decimal values)
I'm assuming when at idle I'd be in the top or next to top row (unfortunately I can't run RG in the car at the moment so can't see this) and although the numerical delta between rows seems quite high it is no more than many other rows, of course I don't know if the load increments for each row are equal.
Why is this a problem?
In itself it's not too bad although, as mentioned, the car does sometimes seem a bit lacklustre when pulling away but mainly I was hoping to lean out the mixture as I think it's too rich when running (best figure I'm seeing is around 13.5 when cruising) but this will lean the idle even more, possibly giving other issues such as the pickup from idle. I could change the map values in individual areas but I was hoping to get reasonable behaviour by simply tweaking the fuel pressure down a little (I'm currently running at 38PSI which is a little higher than standard) or by altering the map muliplier value.
I'm currently investigating a lean running issue with my car in the higher RPM/load area and after looking at the RG logs there's something I'm a little confused about so hoping someone can help.
The way I'm looking at things the most important thing with the management system is the output, that is what is feeding into the engine to make it run. Looking at the log file I have see the values for pulse width and these range from 1.882-10.268 on the test run I did obviously this is the time that the injector is open for but how often does that pulse occur?
From the reading I've done and the examination of the 14CUX code (thanks to Colin and Dan for that) I'm assuming this should once per engine revolution (4 ignition events per rev' every other one seems to bypass the guts of the ignitionInt processing and, of the ones which do process, every other one works on each bank of the engine alternately).
Did I understand that correctly?
The reason for my confusion is that it seems there would be a problem if the injector pulse width period approaches the period of a revolution.
The data for the RPM in my test run is limited due to the lean running issues so only gets up to 4621 maximum at which point there is just short of 13ms between revolutions and in fact the maximum PW was at lower RPM than this but given the figures in the map it would seem that it is possible to achieve a longer PW then revolution period at maximum RPM.
Fair enough it it unlikely that my lightweight car could do this, I've have to be attempting to accelerate hard up a very steep hill while already at maximum RPM but this is what made me think my understanding of the pulse width is flawed.
It would also seem to suggest that I'm at risk of being on the limit of fuel flow with my current injectors which doesn't seem correct as these are the standard (green) Lucas injectors being run on a mildly modified 3.9L engine. My understanding is that these same injectors are used on the 4.6L which I'd expect to make higher demands.
The engine is 3.9L running the pre-cat, green resistor map (2) hence open loop, PW is calculated from the input parameters excluding lambda sensors which are not present.
Any guidance on this would be greatly appreciated as it may assist with my lean running issue.
The way I'm looking at things the most important thing with the management system is the output, that is what is feeding into the engine to make it run. Looking at the log file I have see the values for pulse width and these range from 1.882-10.268 on the test run I did obviously this is the time that the injector is open for but how often does that pulse occur?
From the reading I've done and the examination of the 14CUX code (thanks to Colin and Dan for that) I'm assuming this should once per engine revolution (4 ignition events per rev' every other one seems to bypass the guts of the ignitionInt processing and, of the ones which do process, every other one works on each bank of the engine alternately).
Did I understand that correctly?
The reason for my confusion is that it seems there would be a problem if the injector pulse width period approaches the period of a revolution.
The data for the RPM in my test run is limited due to the lean running issues so only gets up to 4621 maximum at which point there is just short of 13ms between revolutions and in fact the maximum PW was at lower RPM than this but given the figures in the map it would seem that it is possible to achieve a longer PW then revolution period at maximum RPM.
Fair enough it it unlikely that my lightweight car could do this, I've have to be attempting to accelerate hard up a very steep hill while already at maximum RPM but this is what made me think my understanding of the pulse width is flawed.
It would also seem to suggest that I'm at risk of being on the limit of fuel flow with my current injectors which doesn't seem correct as these are the standard (green) Lucas injectors being run on a mildly modified 3.9L engine. My understanding is that these same injectors are used on the 4.6L which I'd expect to make higher demands.
The engine is 3.9L running the pre-cat, green resistor map (2) hence open loop, PW is calculated from the input parameters excluding lambda sensors which are not present.
Any guidance on this would be greatly appreciated as it may assist with my lean running issue.
Edited by CGCobra on Saturday 26th October 17:50
Road speed correction.
I don't know if this has been addressed in recent times as I've not kept myself intimately involved with what's happening since about page 65 but I know it has been asked before and it's something I've never been too happy about.
I know there is now a multiplier in the Rover Gauge and thank you very much Colin and Dan for putting that in there however it just really needles my OCD gene when things are not correct, plus I wanted to have a play.
I've always known my road speed was incorrect, initially due to using a third party pulse generating device and then more recently due to changes in the gearbox (with a different speedo drive gear) and differential.
I recently decided to measure this and it turns out it was not as bad as I thought. RG was indicating around 8MPH when my GPS speedo app was showing 10 and this multiplication factor was consistent at 20, 30, 40 & 50 MPH the 14CUX thinks I'm going at 80% or true speed or 25% down.
I think it was previous closer to 50% down as I had already introduced a x2 multiplication in the code so now all I need to do is change this to a x1.25, problem is how to multiply a binary number by a fraction.
After investigating different methods of multiplying fractional numbers in binary I realised it's quite simple, at least for 1.25. Shifting the original speed reading 2 (logically) places to the right will give 1/4 of the original, add the original back in and the value is now x1.25 original.
Any other binary fraction (1/2, 1/8, 1/16 and so on) could also be added in if required to dial in the accuracy.
The first command stores the road speed from B into $2003 as before then a couple of logical left shifts leaves 1/4 the original value in B which is then added with carry (to perform rounding) to $2003, the result appearing in B which is then transferred back to $2003.
I've tested this today against my GPS speedo app, I can only check the readings briefly as I''m driving but it is definitely closer than previous.
I'd like to get an app which can log my speed and timestamp it so I could then compare with RG log so if anyone knows of an IOS app (ideally free) which can do this I'd very much appreciate it.
Also if anyone believes my code could cause a problem I'd also be (very) interested, in my brief test all seemed OK but there could always be some circumstances where it could cause a problem, I'm thinking possibly due to the additional time taken to process the commands. If I've done my sums right this should take 16 clock cycles against the 4 taken by the original STAB command.
Edit 3-Nov-2024
Seems like code works OK, there were no problems running the car and the RG speed reading has increased by more or less the correct amount.
RG/ECU values are in Red, GPS values in Blue.
ECU values are typically a little high and response seems a little slow with readings being 'held' and giving a stepped/quantised appearance which is probably a function of how speed is processed in 14CUX.
I could probably dial down my multiplication to x0.125 but this would probably be slightly too low, I could add in smaller fractions with additional right shifts but this woudl add more processing and, given the appearance of the RG output would still only be correct for steady or slowly changing speed. Bottom line is does it really matter?
At the end of the day this was really just an excercise to see if I could do this and how the 14CUX would respond so job done for now.
I don't know if this has been addressed in recent times as I've not kept myself intimately involved with what's happening since about page 65 but I know it has been asked before and it's something I've never been too happy about.
I know there is now a multiplier in the Rover Gauge and thank you very much Colin and Dan for putting that in there however it just really needles my OCD gene when things are not correct, plus I wanted to have a play.
I've always known my road speed was incorrect, initially due to using a third party pulse generating device and then more recently due to changes in the gearbox (with a different speedo drive gear) and differential.
I recently decided to measure this and it turns out it was not as bad as I thought. RG was indicating around 8MPH when my GPS speedo app was showing 10 and this multiplication factor was consistent at 20, 30, 40 & 50 MPH the 14CUX thinks I'm going at 80% or true speed or 25% down.
I think it was previous closer to 50% down as I had already introduced a x2 multiplication in the code so now all I need to do is change this to a x1.25, problem is how to multiply a binary number by a fraction.
After investigating different methods of multiplying fractional numbers in binary I realised it's quite simple, at least for 1.25. Shifting the original speed reading 2 (logically) places to the right will give 1/4 of the original, add the original back in and the value is now x1.25 original.
Any other binary fraction (1/2, 1/8, 1/16 and so on) could also be added in if required to dial in the accuracy.
The first command stores the road speed from B into $2003 as before then a couple of logical left shifts leaves 1/4 the original value in B which is then added with carry (to perform rounding) to $2003, the result appearing in B which is then transferred back to $2003.
I've tested this today against my GPS speedo app, I can only check the readings briefly as I''m driving but it is definitely closer than previous.
I'd like to get an app which can log my speed and timestamp it so I could then compare with RG log so if anyone knows of an IOS app (ideally free) which can do this I'd very much appreciate it.
Also if anyone believes my code could cause a problem I'd also be (very) interested, in my brief test all seemed OK but there could always be some circumstances where it could cause a problem, I'm thinking possibly due to the additional time taken to process the commands. If I've done my sums right this should take 16 clock cycles against the 4 taken by the original STAB command.
Edit 3-Nov-2024
Seems like code works OK, there were no problems running the car and the RG speed reading has increased by more or less the correct amount.
RG/ECU values are in Red, GPS values in Blue.
ECU values are typically a little high and response seems a little slow with readings being 'held' and giving a stepped/quantised appearance which is probably a function of how speed is processed in 14CUX.
I could probably dial down my multiplication to x0.125 but this would probably be slightly too low, I could add in smaller fractions with additional right shifts but this woudl add more processing and, given the appearance of the RG output would still only be correct for steady or slowly changing speed. Bottom line is does it really matter?
At the end of the day this was really just an excercise to see if I could do this and how the 14CUX would respond so job done for now.
Edited by CGCobra on Sunday 3rd November 14:41
Hi all, don't know if there's anyone still around on this topic but if so your help would be appreciated.
Just working through the ignitionInt.asm program and I'm confused by some branching/logic commands..
In the graphic below the section marked in blue is setting the system up to close the IACV hence controlling idle but is not reached if the code related to TPS causes a branch.
It seems logical that the idle control will only be attempted if the TPS indicates closed throttle which I believe is when the reading is low.
But the note in the ASM indicates the branch will occur when TPS is low (closed throttle?) so IDLE reduction will only occur if throttle is open which doesn't seem correct unless the idea is to close the IACV when throttle is open (which may make some sense I suppose)
Overall this hinges on the action of the BCS-Branch Carry set command.
For the SUBD command the manual indicates "C: Set if absolute value of the memory contents ($70) is larger than the absolute value of the accumulator (D); cleared otherwise"
Looking at that the otherway around I get "Set if the TPS value is less than or equal to $70" which would set C where the TPS value is smaller (or equal) than the test value and the note in the program is correct.
I put the question to ChatGPT and it indicates that C would not be set hence branch would not take place but I've caught this system out several times now on Motorola logic and beaten it into a submission so I put more trust in the manual and Dan/Colin's expertise.
Has anyone else come across this type of logic construct? If so how did you resolve?
Just working through the ignitionInt.asm program and I'm confused by some branching/logic commands..
In the graphic below the section marked in blue is setting the system up to close the IACV hence controlling idle but is not reached if the code related to TPS causes a branch.
It seems logical that the idle control will only be attempted if the TPS indicates closed throttle which I believe is when the reading is low.
But the note in the ASM indicates the branch will occur when TPS is low (closed throttle?) so IDLE reduction will only occur if throttle is open which doesn't seem correct unless the idea is to close the IACV when throttle is open (which may make some sense I suppose)
Overall this hinges on the action of the BCS-Branch Carry set command.
For the SUBD command the manual indicates "C: Set if absolute value of the memory contents ($70) is larger than the absolute value of the accumulator (D); cleared otherwise"
Looking at that the otherway around I get "Set if the TPS value is less than or equal to $70" which would set C where the TPS value is smaller (or equal) than the test value and the note in the program is correct.
I put the question to ChatGPT and it indicates that C would not be set hence branch would not take place but I've caught this system out several times now on Motorola logic and beaten it into a submission so I put more trust in the manual and Dan/Colin's expertise.
Has anyone else come across this type of logic construct? If so how did you resolve?
Gassing Station | Griffith | Top of Page | What's New | My Stuff