rusefi
/
rusefi
mirror of https://github.com/rusefi/rusefi.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs

This commit is contained in:
rusefillc 2023-01-26 02:02:26 -05:00
parent e9bdcdd6ba
commit d1eb6d897f
2 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
firmware/controllers/actuators/alternator_controller.cpp
View File

@ -69,7 +69,7 @@ void AlternatorController::onFastCallback() {
alternatorControl.setSimplePwmDutyCycle(0);
} else {
currentAltDuty = alternatorPid.getOutput(targetVoltage, vBatt.Value, FAST_CALLBACK_PERIOD_MS / 1000.0f);
// huh, why do we bump based on button not based on actual A/C relay state?
// see "idle air Bump for AC" comment
int acDutyBump = engine->module<AcController>().unmock().acButtonState ? engineConfiguration->acRelayAlternatorDutyAdder : 0;
currentAltDuty += acDutyBump;
if (engineConfiguration->isVerboseAlternator) {

6
firmware/controllers/actuators/idle_thread.cpp
View File

@ -26,8 +26,10 @@
int IdleController::getTargetRpm(float clt) {
targetRpmByClt = interpolate2d(clt, config->cltIdleRpmBins, config->cltIdleRpm);
// Bump for AC
// huh, why do we bump based on button not based on actual A/C relay state?
// idle air Bump for AC
// Why do we bump based on button not based on actual A/C relay state?
// Because AC output has a delay to allow idle bump to happen first, so that the airflow increase gets a head start on the load increase
// alternator duty cycle has a similar logic
targetRpmAcBump = engine->module<AcController>().unmock().acButtonState ? engineConfiguration->acIdleRpmBump : 0;
return targetRpmByClt + targetRpmAcBump;