Instructions to change fuel maps on 14CUX Griffith, Chimaera
Discussion
robertf03 said:
Much better. O2 is switching nicely.
It does look better. What did you do?On the other hand, I just can't rest until I find something odd in the data. The glitch du jour is in the coolant and fuel temperatures. Please take a look at Temperature_Glitch.png here:
https://drive.google.com/?tab=wo&authuser=0#fo...
Does anyone have a clue what's going on here. I sure don't.
I think I have some of it figured out. Here is the temperature look-up table in degrees C. Although it implies that you can read 130 at the hot end (ADC count zero) or -25 at the cold end (ADC count 253 or greater), this is not the case.
Of the 256 possible values, the software checks if you get too close to either end, which could indicate a shorted or opened connection. For early code, getting closer than 8 counts of either end triggered a fault. This was later desensitized to 4 counts which means that 251 (-24 C) is the maximum useable reading. This is equivalent to about 100K ohms. It is easy enough to test this just by unplugging the sensor, thereby exceeding the 100K ohms and getting a fault.
If you look at D90_Coolant_Temp.png (same place as before), you can see what happens when a bad temp sensor connection acts up. In this case we are looking at raw ADC counts which decrease with temperature rise. At the point where the connection opened, software replaced the bad reading with the value 112, which is $70 hex or 35 C according to the table. This translates to 95 degrees F and is close enough to the 94 degrees logged by RG. I think Colin uses a curve fitting technique instead of a LUT which could explain the minor error. In both cases (Robert's file and the D90), the connection was re-established, possibly due to vehicle vibration, and software resumed using the sensor output.
I know this does not explain the narrow negative spikes in the graph, but it's all I've got at the moment. Robert, did you get a fault code?
130,129,127,126,124,123,121,120,118,117,115,114,112,111,109,108,
106,105,104,103,102,101,100, 99, 98, 97, 96, 95, 94, 93, 92, 91,
90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75,
74, 73, 72, 71, 70, 70, 69, 68, 67, 66, 65, 64, 63, 63, 62, 61,
60, 59, 59, 58, 58, 57, 56, 56, 55, 55, 54, 54, 53, 52, 52, 51,
51, 50, 50, 49, 49, 48, 48, 47, 47, 46, 46, 45, 45, 44, 44, 43,
43, 42, 42, 41, 41, 40, 40, 39, 39, 38, 38, 37, 37, 36, 36, 35,
35, 35, 34, 34, 33, 33, 32, 32, 31, 31, 30, 30, 29, 29, 28, 28,
28, 28, 27, 27, 26, 26, 26, 25, 25, 24, 24, 23, 23, 23, 22, 22,
22, 21, 21, 20, 20, 19, 19, 18, 18, 17, 17, 16, 16, 15, 15, 14,
14, 14, 13, 13, 12, 12, 11, 11, 10, 10, 9, 9, 8, 8, 7, 7,
7, 7, 6, 6, 6, 5, 5, 5, 4, 4, 3, 3, 3, 2, 2, 2,
2, 1, 1, 0, 0, -1, -1, -2, -2, -3, -3, -4, -4, -5, -5, -6,
-6, -6, -7, -7, -8, -8, -8, -9, -9,-10,-10,-11,-11,-11,-12,-12,
-12,-13,-13,-14,-14,-15,-15,-16,-16,-17,-17,-18,-18,-19,-19,-20,
-20,-20,-21,-21,-22,-22,-22,-23,-23,-23,-24,-24,-24,-25,-25,-25
Of the 256 possible values, the software checks if you get too close to either end, which could indicate a shorted or opened connection. For early code, getting closer than 8 counts of either end triggered a fault. This was later desensitized to 4 counts which means that 251 (-24 C) is the maximum useable reading. This is equivalent to about 100K ohms. It is easy enough to test this just by unplugging the sensor, thereby exceeding the 100K ohms and getting a fault.
If you look at D90_Coolant_Temp.png (same place as before), you can see what happens when a bad temp sensor connection acts up. In this case we are looking at raw ADC counts which decrease with temperature rise. At the point where the connection opened, software replaced the bad reading with the value 112, which is $70 hex or 35 C according to the table. This translates to 95 degrees F and is close enough to the 94 degrees logged by RG. I think Colin uses a curve fitting technique instead of a LUT which could explain the minor error. In both cases (Robert's file and the D90), the connection was re-established, possibly due to vehicle vibration, and software resumed using the sensor output.
I know this does not explain the narrow negative spikes in the graph, but it's all I've got at the moment. Robert, did you get a fault code?
Dan, I think it's got be something common to both look-up temperature table routines as the two negative going glitches have the same, or very similar period, which is 3 seconds and similar amplitude. I can't see that happening as a result of an electrical issue since the two transducer circuits are independent of each other.
robertf03 said:
The vacuum gauge and the load row were surprisingly close.
Certainly proves Marks theory correct that the vacuum is the most accurate method to measure load and not the throttle pot position. Mark, not that I ever doubted you. This came up in conversation when choosing map-able ignition options.It seems that the communication glitches shown by Robert's data represent an exceptional case, but I could ultimately enhance the software to detect such glitches.
I need to think about how to architect this, because it will influence the mechanism that I use to maximize bandwidth (by reading the slowly-changing sensor values at a lower rate.)
I need to think about how to architect this, because it will influence the mechanism that I use to maximize bandwidth (by reading the slowly-changing sensor values at a lower rate.)
I'd like to add to this.
The 14CUX communication port is single wired, RS232 style and not noise immune like the dual wired (differential) RS422 style. In addition, it's being used in a hostile environment when you consider the ignition spark plus alternator and motors. There is not even a parity error checking bit available in this MPU, although we probably wouldn't use it anyway. It only catches odd numbers of bad bits in a byte and adds about 10% to the traffic which we can't afford.
Robert, I can't remember seeing a log file with this many errors so it probably is, as Colin mentioned, an unusual case. You could try positioning the cable away from other wires and components. You could also make sure all your condensers are in place and well grounded.
The 14CUX communication port is single wired, RS232 style and not noise immune like the dual wired (differential) RS422 style. In addition, it's being used in a hostile environment when you consider the ignition spark plus alternator and motors. There is not even a parity error checking bit available in this MPU, although we probably wouldn't use it anyway. It only catches odd numbers of bad bits in a byte and adds about 10% to the traffic which we can't afford.
Robert, I can't remember seeing a log file with this many errors so it probably is, as Colin mentioned, an unusual case. You could try positioning the cable away from other wires and components. You could also make sure all your condensers are in place and well grounded.
Lately I feel like I'm monopolizing this thread but I'm having so much fun analyzing Robert's data that I just feel the need to share the joy.
I just placed RobertsRoadSpeed.png in the usual place. This is a portion of the road speed in MPH from his RG log. If you remember that I mentioned "The Stig" saying that the road speed measuring technique is flawed because you can get "strobing effects", here is, I believe, an example of what he was talking about.
The software sampling rate is constantly varying with RPM and the waveform frequency from the Vehicle Speed Sensor (VSS) is also varying with road speed. There are combinations of these two speeds that create beating or strobing effects between the two frequencies. In the graph, you can see the result of this strobing which starts to happen around 50 to 55 MPH. The data makes it appear that Robert decelerated from 51 MPH to 29 MPH in only half a second. I wanted to calculated the G's for this to prove it's not possible but I didn't know where to begin. Anyway, you can clearly see the speed oscillation that starts to happen.
I just placed RobertsRoadSpeed.png in the usual place. This is a portion of the road speed in MPH from his RG log. If you remember that I mentioned "The Stig" saying that the road speed measuring technique is flawed because you can get "strobing effects", here is, I believe, an example of what he was talking about.
The software sampling rate is constantly varying with RPM and the waveform frequency from the Vehicle Speed Sensor (VSS) is also varying with road speed. There are combinations of these two speeds that create beating or strobing effects between the two frequencies. In the graph, you can see the result of this strobing which starts to happen around 50 to 55 MPH. The data makes it appear that Robert decelerated from 51 MPH to 29 MPH in only half a second. I wanted to calculated the G's for this to prove it's not possible but I didn't know where to begin. Anyway, you can clearly see the speed oscillation that starts to happen.
Edited by danbourassa on Sunday 9th March 21:40
Dan
yes, I did have a coolant temp sensor fault. The JPT connector is cracked and I have not replaced it yet.
I had a belt tensioning problem that I think showed up in that voltage spike. I sorted out a few problems with it this weekend and just logged a 40 mile highway drive. It drives better and the voltage looks better in the logs.
The speedometer in rovergauge is a little slower than my dash gauge, and it isn't always a linear relation between the two. Is this a sign of a failing speed sensor, or does it have something to do with the way the 14cux or rovergauge interprets the data?
New log is at www.flemcodesign.com/logs2.zip
Still the stock 3360 bin with the fuel constant modified as the only change. I'm not brave enough to try the tune resistor yet, maybe once I get a few thousand miles on the engine.
and speaking of noise, the suppressor on the ignition coil had a bad crimp. That was also fixed this weekend, maybe that has something to do with the CTS values?
Edit: Dan, I see your explanation of the VSS now. I didn't get that far before I replied. I thought maybe I was pulling a few Gs of acceleration with the new engine
yes, I did have a coolant temp sensor fault. The JPT connector is cracked and I have not replaced it yet.
I had a belt tensioning problem that I think showed up in that voltage spike. I sorted out a few problems with it this weekend and just logged a 40 mile highway drive. It drives better and the voltage looks better in the logs.
The speedometer in rovergauge is a little slower than my dash gauge, and it isn't always a linear relation between the two. Is this a sign of a failing speed sensor, or does it have something to do with the way the 14cux or rovergauge interprets the data?
New log is at www.flemcodesign.com/logs2.zip
Still the stock 3360 bin with the fuel constant modified as the only change. I'm not brave enough to try the tune resistor yet, maybe once I get a few thousand miles on the engine.
and speaking of noise, the suppressor on the ignition coil had a bad crimp. That was also fixed this weekend, maybe that has something to do with the CTS values?
Edit: Dan, I see your explanation of the VSS now. I didn't get that far before I replied. I thought maybe I was pulling a few Gs of acceleration with the new engine
Edited by robertf03 on Monday 10th March 04:18
danbourassa said:
I'd like to add to this.
The 14CUX communication port is single wired, RS232 style and not noise immune like the dual wired (differential) RS422 style. In addition, it's being used in a hostile environment when you consider the ignition spark plus alternator and motors. There is not even a parity error checking bit available in this MPU, although we probably wouldn't use it anyway. It only catches odd numbers of bad bits in a byte and adds about 10% to the traffic which we can't afford.
Robert, I can't remember seeing a log file with this many errors so it probably is, as Colin mentioned, an unusual case. You could try positioning the cable away from other wires and components. You could also make sure all your condensers are in place and well grounded.
Dan, the 'other' 3 second negative going glitch in the Fuel Temperature values occurred with the engine Off-Ignition On state, so no noise:The 14CUX communication port is single wired, RS232 style and not noise immune like the dual wired (differential) RS422 style. In addition, it's being used in a hostile environment when you consider the ignition spark plus alternator and motors. There is not even a parity error checking bit available in this MPU, although we probably wouldn't use it anyway. It only catches odd numbers of bad bits in a byte and adds about 10% to the traffic which we can't afford.
Robert, I can't remember seeing a log file with this many errors so it probably is, as Colin mentioned, an unusual case. You could try positioning the cable away from other wires and components. You could also make sure all your condensers are in place and well grounded.
What are the odds for the Fuel Temperature transducer to have the same connector fault as the Coolant Temp that also went O/C for exactly the same period?
Edited by davep on Monday 10th March 10:29
davep said:
Dan, the 'other' 3 second negative going glitch in the Fuel Temperature values occurred with the engine Off-Ignition On state, so no noise:
Dave, I did notice in the data that Robert's Land Rover appeared to stall and he didn't restart it immediately. If a glitch happened during this time, then I have to agree with you.davep said:
What are the odds for the Fuel Temperature transducer to have the same connector fault as the Coolant Temp that also went O/C for exactly the same period?
I forgot to explain that part. Like Colin mentioned about reading slowly changing data at a lower rate, temperature is only read at about 3 second intervals. Faster changing data is read several times per second. So if you get a corrupted temperature byte, it is output to the log until the next reading corrects it. This gives the bad reading more legitimacy than it deserves. This is easy enough to fix. Since the sensor has thermal mass, it can't change by 50 degrees in 3 seconds, so detecting this kind of error is not difficult. Expect another RG upgrade.Thanks Dan, the penny has dropped, clunk! All helps in my/our understanding of 14CUX and RoverGauge I think.
So at present in RG, any rapid voltage level glitch in the Coolant and Fuel temperature reading circuits of any period less than 3 seconds will result in a pulse shaped series of irregular logged values being shown for a duration of 3 seconds.
Now I can get back to implementing your fix for my road speed problem.
So at present in RG, any rapid voltage level glitch in the Coolant and Fuel temperature reading circuits of any period less than 3 seconds will result in a pulse shaped series of irregular logged values being shown for a duration of 3 seconds.
Now I can get back to implementing your fix for my road speed problem.
robertf03 said:
It wasn't a stall, I pulled over when the check engine light went on and inspected the connector. Reattached and went on. I never stopped the log.
I see that now. According to the time stamps, you must have quickly turned off the engine and then turned ignition back on to keep logging. The ECT sensor started working again during that time since you reconnected it. I can see where the main voltage dipped during restart. That part all makes sense. I also see that Dave's correct about a temperature glitch during this time.Robert, I don't know what you changed, if anything, but I quickly looked at your latest log file and it looks error free.
I want to mention that I looked at roadSpeed.asm recently to answer a question for Dave and realized that the file still has old, inaccurate comments. I'll be replacing it soon with a new version. While looking at it, I was reminded that, unlike most parameters in the 14CUX, road speed is updated slowly (approximately once per second). Since RG reads it more often than that, I concluded that the log must repeat every reading at least once. Looking at the log files, it seems that this is true.
I want to mention that I looked at roadSpeed.asm recently to answer a question for Dave and realized that the file still has old, inaccurate comments. I'll be replacing it soon with a new version. While looking at it, I was reminded that, unlike most parameters in the 14CUX, road speed is updated slowly (approximately once per second). Since RG reads it more often than that, I concluded that the log must repeat every reading at least once. Looking at the log files, it seems that this is true.
danbourassa said:
If you remember that I mentioned "The Stig" saying that the road speed measuring technique is flawed because you can get "strobing effects", here is, I believe, an example of what he was talking about.
Dan, I’ve previously noticed the road speed in RoverGauge can some times be random. At first I thought it was caused by my aftermarket road speed sensor but now I'm thinking it could be another example of the strobing effect, what do you think?08:42:39.507 60 1704 57 16 0.107404 0 0.372222 13.21 2
08:42:39.888 60 1699 57 16 0.117831 0 0.372222 13.21 2
08:42:40.468 60 1698 57 16 0.129301 0 0.372222 13.21 2
08:42:40.909 52 1707 57 16 0.154327 0 0.372222 13.21 2
08:42:41.460 32 1708 57 16 0.162669 0 0.372222 13.21 2
08:42:41.921 32 1727 57 16 0.159541 0 0.372222 13.21 2
08:42:42.451 39 1743 57 16 0.128259 0 0.372222 13.21 2
08:42:42.942 39 1746 57 16 0.117831 0 0.372222 13.21 2
08:42:43.493 58 1751 58 16 0.117831 0 0.372222 13.21 2
08:42:43.923 58 1754 58 16 0.12513 0 0.372222 13.21 2
08:42:44.444 58 1740 58 16 0.126173 0 0.372222 13.21 2
08:42:44.915 55 1734 58 16 0.106361 0 0.372222 13.21 2
08:42:45.456 55 1704 58 16 0.108446 0 0.372222 13.21 2
08:42:45.926 60 1693 59 16 0.11366 0 0.372222 13.21 2
08:42:46.537 60 1677 59 16 0.117831 0 0.372222 13.21 2
08:42:46.888 59 1683 59 16 0.117831 0 0.372222 13.21 2
08:42:47.449 59 1697 59 16 0.117831 0 0.372222 13.21 2
08:42:47.929 59 1691 59 16 0.173097 0 0.372222 13.21 2
Cheers, Steve
P.S. Dan, please don’t worry about monopolizing this thread I’m sure lots of people including myself are lurking and learning.
P.S.S. Robert, I’m pleased to hear you are making good progress.
blitzracing said:
A good read here as well:
http://www.g33.co.uk/images/PDFS/14cux%20faulot%20...
Mark, I notice on the bottom of the first column is sayshttp://www.g33.co.uk/images/PDFS/14cux%20faulot%20...
"The ECU in a modern catalyst equipped engine switches it between rich state and lean state at a rate of one to three times per second. They don’t ever run ‘in the middle'. They do this because catalytic converters function much better when switching in this way."
fascinating.
stevesprint said:
Dan, I’ve previously noticed the road speed in RoverGauge can some times be random. At first I thought it was caused by my aftermarket road speed sensor but now I'm thinking it could be another example of the strobing effect, what do you think?
Steve, yes, I agree. This looks like the same problem.The apparent temperature glitches in Robert's log file correlate strongly with deceleration. When the road speed drops quickly, the temperature appears to increase by several degrees before eventually re-stabilizing at the real value. This might be due to either something mechanical (physically shifting during deceleration) or perhaps an electrical gremlin. In any case, I don't believe it's a logging issue; those temperature spikes are most likely what the ECU is actually seeing.
stevesprint said:
P.S.S. Robert, I’m pleased to hear you are making good progress.
Thanks Steve. Can't wait to see what it does with that tune resistor. So the O2 ground and coil condensor are obviously critical, but those logs will at least show what happens when they aren't in good shape
I'm glad you all are getting something out of these logs. I've got one more annoying bug to fix before I can focus back on tuning the thing. The timing is jumping around and it has a wandering idle speed when warm. I popped the cap off the distributor to check the air gap and noticed the reluctor is loose around the shaft. I estimate it is out of control by 5 degrees. I've got a proline distributor I bought just for the vacuum advance that I'll probably swap in this weekend, but I'm thinking about putting a buick delco points distributor in there converted to electronic pick up. Good lucas caps are hard to get around here, but delco stuff is almost free.
Gassing Station | Griffith | Top of Page | What's New | My Stuff