Subpage of GenBoard/UnderDevelopment/FirmWare related to coolant temp
The temperature range was traditionally -40 .. 215F (internally and in config 0..255) inherited from the procariotic ECM (megasquirt); This is a problem, because it rails when you are most interested in the temp (101..110C remember the coolant is usually pressurizable to 60..200kPa above athmosphere). Also, aircooled engines like higher head-temp.
We should aim for ait least +150C, that is the max temp for common sensors.
Proposed range: celsius based, starting at -50C
- internal values 1..210 for -49 .. 160C (0 and engine.clt >210 values reserved for error conditions and future whatever)
Checklist to achieve this
- thermfactor.c (thermfactor.inc): remap. This is very simple, apply linear transformation and 255 (215F = 101C) will become 151 => not rail !
- with the above simple change, we have the extended range for coolant. To match the new range, all coolant related variables must be updated (with simple conversion) in any config to match the new range. Maybe a name change is appropriate, so make mtt warns about the fact that using old-scale values:
- warmup_clt_range[] ... this might go to flash, since noone ever tweakes them. Maybe the highest bin should be 80C or 75C instead of 71C ?
- fan_temp / fan_hyst
- ego_coolant
- ve_learn_coolant
- water_pump_temp / water_pump_hyst
- iac_cold_idle_temp / iac_warm_idle_temp
- some compile time constants
- ... ?
- fix LCD functions that display temp
- fix MegaTune formulas for temp display. For the realtime values it should be very quick:
- current formula in MT is ((5/9) * (cltADC)) - ((5/9) * (40+32))
- for fahrenheit cltADC - 40
- fix MegaTune formulas for the relevant config variables
- currently (config.fan_temp - 72) * 0.555 = temp in celsius
- the proposed is: (config.fan_temp - 50) * 1.000 = temp in celsius
Remember the MegaTune part might be significant work (and testing !!!) too.In the best case, we only have to change at 4..5 places only. The config parameters are a bit problematic (they all have their own range and linear conversion). But we already use some helper to generate them, right ?
by: MembersPage/GintsK 2007-09-11
How about progress regarding this? I have real problems with temperature readings in Megatune and LCD:
With scare I find that coolant temperature readings in Megatune and LCD sticks at 102C although in real teperature goes higher!!! At tuning this is vital information!
Even make bench tests with two different firmwares: 1.0.3x (sorry do not record - was loaded from purchase) using Megatune from VemsMT1.0.53 package and 1.1.22 using MT from VemsMT1.1.12-pre. I have try it using standard firmware with default NTCs.
In both cases temperature readings sticks at 102C in Megatune and 101C on LCD. LCD rounds down (often indicate ~1deg lower than Megatune). IAT act similarly.
CLT input=5V - very high sensor resistance at -40C or disconnected sensor
We used cltsensor-disconnected limp-home earlier, which assumed 70C coolant temp with disconnected sensor. It can be applied simply by changing 1 entry in the cltfactor hex-file. However, it is NOT recommended. An engine in northern Sweden in -40C almost got damaged because of switching to "limp-home".
trying to drive home with twice of fuel can damage engine too. My suggestion is use somewhat in 0 to 20degC range for limp-home not 70degC. I do not knew what entry to change: hex file is not understandable for me.
If NTC circuit becomes open due to some damage, calculated temperature is -40degC. It adds LOT off fuel. To drive home, you need to
- reconfigure to warmup_clt[0]=64 (Man mttg12mmttc64 mcs)
- this suggestion deform warmup curve up to -28degC. sometimes here is -32degC.
- or insert a 0..5k resistor (a short wire will pretend 102C, 5k is actually quite cold) instead of the coolant sensor
- my customers have not resistor packs on road. sorry.
I used easytherm.exe to generate the ADC values to temperature correlation, for the 2.45Kohm bias resistor and values for a BOSCH standart temp sensor. The ADC values in the high range af temperatures is making some drastic jumps, so 1 bit change in ADC raw value represent a 10°C jump at 150°C because the value off the NTC becomes very low (below the 100ohm range) making readings somewhat unprecise.
But OK the jumps just above 100°C is 2-3 degree per bit, thats good enough for monitoring if your cooleant is overheated, or as in my case with air cooled, to se if the oil is reaching craking point temperature at 130-135°C.
I think the suggested range -49 .. 160C is OK. I was about to experiment myself with -100 .. 155C by just adding 100 to actually value.
Enrichment based on ExhaustGasTemp
Note that the EGT based enrichment has to affect the target mixture instead of being applied on the pulsewidth! -Jörgen
Proposal: a constant curve-shape, positioned and scaled with 3 parameters:
- minegt: EGT temp (Celsius), above which to apply enrichment
- maxenrich (max enrichment in 1/256: 0 to disable; 100 for max +40%)
- xcompress: peak enrichment reached when (egt - minegt) * xcompress > 4000
- 10 results in appr 400C span
- 20 results in appr 200C span
The simple solution would be a linear equation, that rails (plateau-s) at the set "max enrichment". The constant curve-shape is very similar, just smooths the upper break point a bit:
With this, any sane EGT-enrichment config can be approximated very closely. A more complex set of parameters would just increase chance of configuration error without added benefit.
The same type of function (with different scale) can be applied to retard(MATPR). The n[] ignadv table would be set up for max advance (cool winter MAT, when highest advance and power is possible) and retard(MATPR) would retard according to this function (estimated 6..9 crankdegree / 40C ). We don't want retard(MATPR) happen at low load (20..50kPa) or low RPM (<2000 RPM), while it is desirable at high load and middle-high RPM. Kindof complex because in naive implementation it's a retard(MAT, RPM, MAP) which is bloated. Maybe a slope and startingpoint in function of (RPM, MAP) would be best to experience with, before settling on a more fool-proof function.
- MATPR is a function of MAT (main contibutor), MAP (note that this contributes to the change in function of MAP, the base point is still the n[] table) and RPM (would be applied above 2000 RPM) so blending happens in every direction
- TODO: think about interaction with knock_retard
For more (implementation) details, see /svn/manual/bin/egt_enrichment.pl
A simpler (still better than nothing) implementation, similar to
http://megasquirt.sourceforge.net/extra/cltiat.html
Coolant based advance:
- when coolant below ...
- add ignadv, dIGNADV/dCLT slope: ...
- but limit ignadv to max: ...
MAT based retard:
- when MAP above: matretard_map
- note that this should not be a strict threshold (or a hysteresis), but appr 40kPa band for smooth changes. When MAP >= matretard_map, the calculated retard is applied. When MAP < (matretard_map - 40kPa), no retard is applied at all
- and MAT above: ...
- pull retard, dIGNRETARD/dMAT slope: ...
See also: