GenBoard/UnderDevelopment/FirmWare/CoolantTemperatureRange (2006-03-16 04:43:08)

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

Checklist to achieve this

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/SteenAndersen

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

Proposal: a constant curve-shape, positioned and scaled with 3 parameters:

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:

egt_enrichment.png

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.

For more (implementation) details, see /svn/manual/bin/egt_enrichment.pl


found some megasquirt stuff for this:

http://megasquirt.sourceforge.net/extra/cltiat.html