Criticisms of two programming decisions in TPFC.
It was a mistake to include Fahrenheit temperatures in TPFC the way Troubadix did it.
Interpreting settings over 80 as Fahrenheit was cute, but unnecessary. The American century is over and those folks really must learn how the rest of the world does things. More important, it is now a defect in TPFC to be unable to make Centigrade settings over 80.
TPFC should be able to emulate the Embedded Controller and then to let us customize it. The Embedded Controller on my T43 does not freak out when the CPU is just over 80 C. See the TPFC window pictured at this picturelink
. The snapshot was taken during a defrag. I think my EC shifts to fan speed 64 (full throttle) when the CPU temperature exceeds about 90 C.
Conceivably TPFC can be tricked into accepting Centigrade settings over 80 by using positive SensorOffset values. For example, if SensorOffset1=15 and Level=75 64 then maybe the CPU would need to reach 90 C before triggering fan speed 64. But we can't be sure how TPFC calculates once the temperature is over 80 C. Nor for that matter can we know how TPFC calculates in mixed situations when some settings are over 80 and some under or whether it interprets the offsets as Centigrade or Fahrenheit. These ridiculous guessing games should be put to rest with the elimination of Fahrenheit from TPFC.
Another smaller weakness entered TPFC with Shimodax. The sensible way to set the fan switches is sensor-by-sensor. If the user wants
for sensor A, and the user wants
for sensor B, then the user should be able to set this. Separate schedules for separate sensors. Tighter control for sensor B than for sensor A. Such settings are impossible in TPFC. The use of offsets for the separate sensors was a "dumbing down" of the original sensible way. It weakens TPFC and ironically makes more
trouble for the user who has to boggle over adding and subtracting positive and negative offsets.