BoostControl Testing
While BoostControl has not too many configuration options (see GenBoard/Manual/Config/BoostControl) ...
Why ?
The PID parameters are hard to tune to a given setup. It is impossible and dangerous to tune by guessing.
Making a test system with compressor and air connections is beyond what most tuners are willing to spend.
Fortunately, a simple circuit can be soldered in 10 minutes that resembles the real system and is suitable to learn the PID controller tuning and experiment with how the boost-target works.
Note: MAP-target works in a very similar way, with minor differences:
- different configuration
- different input signal is considered for control
How ?
We have to make a "boost signal" that is a function of:
- "boostcontrol output" and
- a disturbance
So solder (TODO: drawing)
- The boostcontrol output can be delayed (to make a more realistic system) with a 33k and 220nF (appr. 7msec). The power output is actually inverted, so the gate of the IGBT (or FET) must be used. An I259 channel is recommended (make config.boost_channel match and don't forget to change it back for the real setup) since it is less likely to make big damage to the board that way.
- Alternative way is using an output inverter with an NPN and 2 resistors
- or a simple pullup resistor (1..10k) between 5V and the power output and inverting the output by adding (or substracting) 0x80 to config.boost_channel (don't forget to change it back in the real setup)
- 33k from boostcontrol output to boost signal
- 220nF from to boost signal to GND
- The disturbance can be any 0..5V (eg. TPS) signal through 100k resistor. Make a disturbance signal with a variable resistor, or resistors and switches (or making temporariy resistors manually):
- solder 100k resistor between disturbance signal and boost signal
- protection of the chips (for the case when you manage to provide 14V on the boost signal somehow).
- solder 10..22k between boost signal and actual boost input of the board
Basic tests
We send the boost signal into the controller, and measure with DVM if the boostcontrol output is what we like:
- OFF when boost < config.boost_minpressure
- otherwise boost tries to maintain the configured boost target (check TPS, RPM and configuration of b[] and t[] tables)
If boost signal is below what we think would be appropriate:
- the b[] value lookued up according to RPM signal is different than you think
- the t[] value lookued up according to TPS signal is different than you think
- the boostcontrol output is railed to maximum (the solenoid would be fully open, there is little more the controller can do in this case)* boost_pid_ki is too low
If boost signal is above what you think would be appropriate, that can be caused by the same reasons, with the obvious difference:
- the boostcontrol output is railed to minimum (the solenoid would be fully closed, there is little more the controller can do in this case)
No matter how you vary the disturbance, the above still holds. At some point you are likely to run into the "railed to minimum" or maximum case.
If the config.boost_channel is inverted, you will see that
- boostcontrol output is railed to minimum, although boost is lower than target or
- boostcontrol output is railed to maximum, although boost is higher than target
Mastering the PID
If you can record the boost signal with a soundcard, you can tune config.boost_pid_kp and config.boost_pid_kd for best (fast, but little overshoot) response.
Closing words
The table setup is useful since you can check without much risk of damage how the PID reacts.
If you follow this, when you are in the car you'll know what's happening and how to handle it, with less risk of damage.
In any case, start with low boost-target (just above the minimum boost that will show up with fully closed solenoid) and step off the throttle immediately if it seems that boost climbs higher than it should.
Test results
I table-tested the boostcontrol and fixed some bugs. The boostcontrol itself was OK, but the code to save and restore boostcontrol tables was partly missing.
- b[] and t[] tables couldn't be set from menu (missing action for them in menu.c)
- with mct r[] was dumped instead of b[] and t[] tables (missing break in comm.c)
- eating CPU that Emil experienced was not in the version recommended by GenBoard/UnderDevelopment/FirmwareChanges
After these it worked OK.