MegaSquirtSanta - Custom Modifications / Firmware
11-12-2011, 09:39 PM
#82
Junior Member
Join Date: Jun 2007
Posts: 411
Total Cats: 0
OK so let's get on with it then! Move along 
Next candidates for inclusion:
1. rob's tpsdot/mapdot smoothing patch. Eliminates noisy signal so that our accel enrichments are not accidentally triggered bu signal noise
2. idle valve duty smoothing via a moving hysteretic window, as suggested by Jason. A better way of smoothing out the idle valve movements at/near target without it being a dead zone with a nonreactive PID code.
3. Added an RPM based status 4 cancel option (if RPM < user defined RPM, status 4= 0). This will help save you from a stall if AC is on, by turning it off. Should have some sort of timer before allowing status 4 counter to start again, to allow engine to stabilize. Should not be noticeable in ordinary operation, but a good failsafe, just in case.
Next candidates for inclusion:
1. rob's tpsdot/mapdot smoothing patch. Eliminates noisy signal so that our accel enrichments are not accidentally triggered bu signal noise
2. idle valve duty smoothing via a moving hysteretic window, as suggested by Jason. A better way of smoothing out the idle valve movements at/near target without it being a dead zone with a nonreactive PID code.
3. Added an RPM based status 4 cancel option (if RPM < user defined RPM, status 4= 0). This will help save you from a stall if AC is on, by turning it off. Should have some sort of timer before allowing status 4 counter to start again, to allow engine to stabilize. Should not be noticeable in ordinary operation, but a good failsafe, just in case.
Last edited by Greg G; 11-12-2011 at 09:49 PM.
Reply
0
0
11-12-2011, 10:48 PM
#83
Newb
Join Date: Nov 2011
Posts: 11
Total Cats: 0
OK so let's get on with it then! Move along
Next candidates for inclusion:
1. rob's tpsdot/mapdot smoothing patch. Eliminates noisy signal so that our accel enrichments are not accidentally triggered bu signal noise
2. idle valve duty smoothing via a moving hysteretic window, as suggested by Jason. A better way of smoothing out the idle valve movements at/near target without it being a dead zone with a nonreactive PID code.
3. Added an RPM based status 4 cancel option (if RPM < user defined RPM, status 4= 0). This will help save you from a stall if AC is on, by turning it off. Should have some sort of timer before allowing status 4 counter to start again, to allow engine to stabilize. Should not be noticeable in ordinary operation, but a good failsafe, just in case.
Next candidates for inclusion:
1. rob's tpsdot/mapdot smoothing patch. Eliminates noisy signal so that our accel enrichments are not accidentally triggered bu signal noise
2. idle valve duty smoothing via a moving hysteretic window, as suggested by Jason. A better way of smoothing out the idle valve movements at/near target without it being a dead zone with a nonreactive PID code.
3. Added an RPM based status 4 cancel option (if RPM < user defined RPM, status 4= 0). This will help save you from a stall if AC is on, by turning it off. Should have some sort of timer before allowing status 4 counter to start again, to allow engine to stabilize. Should not be noticeable in ordinary operation, but a good failsafe, just in case.
Reply
0
0
11-13-2011, 09:21 AM
#85
Junior Member
Join Date: May 2007
Location: Columbia, MD
Posts: 248
Total Cats: 0
Santa,
If I may suggest ... the whole idle strategy needs to be re-architected.
The main changes I suggest are these:
- the idle_duty% is: lookup table values + feedforward values + PID
- PID always turned off if the wheels are connected to engine, but all lookup tables and feedforward *always* active in determining duty%
- TPS > 0 exits PID
- Whenever PID (closed loop) exits, I is *always* reset to zero
- the output of I has to have a + and a - limit. That is, e.g. it can never add mroe than say, 15%, or remove more than 10% from the output.
- Whenever closed loop is re-entered, I *always* has to be reset to zero
- Whenever closed loop is re-entered there should be a "closed loop re-entry target RPM adder". This stays for like 1 sec, and then the target ramps down to the normal target over say, 3 sec. For example, target will initially be 1200 RPM upon re-entry. This target will stay for 1 sec, then ramp down to 850 over 3 seconds. This will solve the stopping-at-a-stop-sign idle dip, and it will also work well for stepping on the clutch when lugging the engine at 600 RPM.
- having a good set of feedforward setups is critical: a/c, voltage, IAT, etc.
If I may suggest ... the whole idle strategy needs to be re-architected.
The main changes I suggest are these:
- the idle_duty% is: lookup table values + feedforward values + PID
- PID always turned off if the wheels are connected to engine, but all lookup tables and feedforward *always* active in determining duty%
- TPS > 0 exits PID
- Whenever PID (closed loop) exits, I is *always* reset to zero
- the output of I has to have a + and a - limit. That is, e.g. it can never add mroe than say, 15%, or remove more than 10% from the output.
- Whenever closed loop is re-entered, I *always* has to be reset to zero
- Whenever closed loop is re-entered there should be a "closed loop re-entry target RPM adder". This stays for like 1 sec, and then the target ramps down to the normal target over say, 3 sec. For example, target will initially be 1200 RPM upon re-entry. This target will stay for 1 sec, then ramp down to 850 over 3 seconds. This will solve the stopping-at-a-stop-sign idle dip, and it will also work well for stepping on the clutch when lugging the engine at 600 RPM.
- having a good set of feedforward setups is critical: a/c, voltage, IAT, etc.
In MS3 I have AC idleup already there as well. I have a 3d table of mat vs requested target with a z axis of duty to replace the "last good" value as well on the way for 1.1.x. I had no plans of limiting the I term action as in my use of the algorithm it is not necessary, and in some cases until I get rid of the "last good" value will actually keep you from reaching the target.
I am also planning a rewrite that doesn't use PID at all.
Frankly, I would really like you to start looking at how things work before making suggestions. It is obvious you want to contribute and that would save us covering ground that has already been covered. A lot of your suggestions are good, but a lot of the time you not looking how it works then saying "it should work x way" when it already mostly does can be confusing for others who don't know how things work yet.
Ken
Last edited by muythaibxr; 11-13-2011 at 09:42 AM.
Reply
0
0
11-13-2011, 04:13 PM
#88
Junior Member
Thread Starter
iTrader: (1)
Join Date: Jun 2011
Location: Australia
Posts: 178
Total Cats: 3
Folks - I'm going to put this whole MegaSquirtSanta thing on ice pending an outcome being discussed in the MSExtra forum on 3.2.0 and the recent licensing changes.
http://www.msextra.com/forums/viewforum.php?f=91
My preference would be that Ken/James and co allow me to continue to create test mods within the MSExtra forum and continue to take ideas and mods forward for people to try and test. If that works, then all this will need to cease and move on to the MSExtra forum.
Cool?
G
http://www.msextra.com/forums/viewforum.php?f=91
My preference would be that Ken/James and co allow me to continue to create test mods within the MSExtra forum and continue to take ideas and mods forward for people to try and test. If that works, then all this will need to cease and move on to the MSExtra forum.
Cool?
G
Reply
0
0
11-13-2011, 06:44 PM
#90
2 Props,3 Dildos,& 1 Cat
iTrader: (8)
Join Date: Jun 2005
Location: Fake Virginia
Posts: 19,338
Total Cats: 573
oh hi. TPSdot test code works very nicely. it's a 3 point median filter and keeps noise below a very low threshold even when the voltage is on the threshold of two bits. at 100 lag factor (ie raw tps).
tomorrow is hopefully the MAPdot version test.
tomorrow is hopefully the MAPdot version test.
Reply
0
0
11-14-2011, 11:28 AM
#93
2 Props,3 Dildos,& 1 Cat
iTrader: (8)
Join Date: Jun 2005
Location: Fake Virginia
Posts: 19,338
Total Cats: 573
I don't even know who Rob is. I think it's actually James working on it.
here's a snapshot of the new filter. tpsdot is the NEW filtered value. sensor16 is the "old style" tpsdot. I'm not sure what's causing it to be super flat like it is. Note the additional noise in the filtered value. note more how it's all below any threshold that might trigger enrichments. the old value spikes crazy high without much throttle input but the new value is way more subdued and only moves when it's supposed to.
here's a snapshot of the new filter. tpsdot is the NEW filtered value. sensor16 is the "old style" tpsdot. I'm not sure what's causing it to be super flat like it is. Note the additional noise in the filtered value. note more how it's all below any threshold that might trigger enrichments. the old value spikes crazy high without much throttle input but the new value is way more subdued and only moves when it's supposed to.
Reply
0
0
Thread
Thread Starter
Forum
Replies
Last Post
FAB
Prefabbed Turbo Kits
216
03-22-2017 04:00 PM
