MS3 pre-1.4 alpha 1 released

Post by **jsmcortina** » Mon Mar 10, 2014 12:59 pm

To announce the release of "MS3 Pre 1.4 alpha 1" - this is a new stream of development codes derived from 1.3.0.
(A few testers have had an earlier test code called 1.3.1 BETA, that is now superceded. Those features will be in 1.4.x, not 1.3.x)
EDIT: ETA on this 1.4.x code becoming release is 6-12 months.

Who should use this code?
Experienced users wanting to test the new features.

Who should not use this code?
New or casual users - please use the current release code instead - see the Downloads page linked above.

Main changes since 1.3.0
Bug fixes:
Handle another impossible tooth count with config error.
Typo causing GPS to trigger single event fuel cut.
Only calc VVT angle if new data available per channel and only then run closed-loop. (untested)

New / enhanced features:
Tie boost control interval to boost valve frequency. Removes a setting.
Add new CAN realtime data broadcast system for dash compatability.
Add new CAN receiving system
CAN broadcast: add user defined test message
Support CAN RCV into VSS3,4 also.
Re-implement boost control as an Ideal PID loop with a bias table instead of initial duty table.

Minor / internal:
Separate boost control into its own source file.

The two large changes here are:
1. CAN broadcasting and receiving
See: http://www.msextra.com/forums/viewtopic ... 25&t=53115 and http://www.msextra.com/forums/viewtopic ... 25&t=53116

2. Boost control.
See: http://www.msextra.com/forums/viewtopic ... 34&t=53051

The firmware zip is available from:
http://www.msextra.com/doc/ms3/files/al ... alpha1.zip

James

shaodome · Post by **shaodome** » Tue Mar 11, 2014 12:36 pm

Already on to 1.4! You guys waste no time.

Is this the stream meaning 1.4X where we might see launch control and nitrous not being mutually exclusive?

Matt Cramer · Post by **Matt Cramer** » Tue Mar 11, 2014 1:21 pm

shaodome wrote:Already on to 1.4! You guys waste no time.

Is this the stream meaning 1.4X where we might see launch control and nitrous not being mutually exclusive?

I see another user has requested this feature, along with the ability to have nitrous on when the trans brake is active.

gjw · Post by **gjw** » Wed Mar 12, 2014 3:07 am

Is this the correct place to request features/functions to be added?? I would like to contribute to the functionality of the MS3 (I use the pro variant), I do not know how to code but have a good working knowledge of most of the ECU systems out there and how they achieve certain functionality. My background is mainly sprint, hillclimb and circuit racing not drag. Thanks

BR
Glen

shaodome · Post by **shaodome** » Wed Mar 12, 2014 10:27 am

It is not the place to request features. I only posted that because James had mentioned that changes to allow nitrous to be available on launch control/trans brake would be something the team would look at in the 1.4 code as they were moving to a stable release of 1.3 and that was priority.

AbatelliCristian · Post by **AbatelliCristian** » Wed Mar 12, 2014 2:38 pm

is possible insert 2 table for vvt (step for power)? or blanding vvt table with adc channell?

wes kiser · Post by **wes kiser** » Thu Mar 20, 2014 5:07 am

Where do we post feedback on this alpha? Do we start new threads for specific features, or general feedback here? I haven't loaded an Alpha in a LONG time, but the boost control changes basically "forced" me to. So far, runs the same with better boost control (I was on a early 1.3 beta).

Post by **jsmcortina** » Thu Mar 20, 2014 5:51 am

Feedback and discussion is fine here.

James

wes kiser · Post by **wes kiser** » Fri Mar 21, 2014 4:39 am

So far so good. With my setup (quite simplistic) basic operation feals the same.

The reason I switched was boost control, and that certainly works more like most people expect. I would post logs, but car developed a miss this morning under boost (likely a plug wire, that is what this has been the other times it feals like this).

To this point, control is much better, even with complete SWAG at settings and initial duties. I still have a little overshoot at the beginning (234 kpa on a 222 target that settles into 218-224 immediatley following), but I think that may more be a function of the lower limit delta being too tight for that target (35 kpa). My turbo comes up very quickly (efr 6758) and has an internal gate. I think it just takes a few ticks to get the gate moving and in position.

franksidebike · Post by **franksidebike** » Fri Mar 21, 2014 6:02 am

Littel Bug in Over Run Fuel Cut!
Fuel comes not back when over the RPMdot threshold (RPM re-enagement).
Frank

No RPMdot Fuel Cut Stop.msl

wes kiser · Post by **wes kiser** » Fri Mar 21, 2014 7:13 am

Has the rational of the rpmdot stuff in over run been explained (mentioned in thread above)? I am relatively sure I know the intent, but not necessarily the behavior/function of the two settings?

Attached is a log of a 3rd gear roll until I ran out of road testing new boost control implementation. Except for the overshoot I would consider this as good as I expect it to reasonably be. In this log it is fairly clear the overshoot either needs some "d" to fix it, or perhaps my low throttle targets and duty are off enough the integral windup is adding to my bias (when it crosses target it is adding about 5% duty to my initial table). In terms of what "button" to push (P,I, or D) do I now treat this like a more conventional PID loop (the previoius implementation was quite different).

Post by **muythaibxr** » Fri Mar 21, 2014 8:14 am

wes kiser wrote:Has the rational of the rpmdot stuff in over run been explained (mentioned in thread above)? I am relatively sure I know the intent, but not necessarily the behavior/function of the two settings?

It has in other threads. The basic idea is to bring fuel back sooner when RPM is falling faster.

Attached is a log of a 3rd gear roll until I ran out of road testing new boost control implementation. Except for the overshoot I would consider this as good as I expect it to reasonably be. In this log it is fairly clear the overshoot either needs some "d" to fix it, or perhaps my low throttle targets and duty are off enough the integral windup is adding to my bias (when it crosses target it is adding about 5% duty to my initial table). In terms of what "button" to push (P,I, or D) do I now treat this like a more conventional PID loop (the previoius implementation was quite different).

PID should now be treated like a standard normal PID loop for boost. The previous implementation was using the derivative form of PID since we were adding the output of every PID iteration to the current duty.

This is adding it to a bias table, so it's back to normal PID.

Ken

krisr · Post by **krisr** » Sat Mar 22, 2014 7:13 pm

Some ideas for potential features that would be nice but not sure on feasibility of they'd make it into 1.4;

[*]IAT MAT Retard feature as a table - perhaps 8x8, this way people can tune hot air temp retard when WOT and areas susceptible to pinging and leave idle timing alone. Not sure how this would integrate with the idle timing feature. I personally don't use the idle timing feature as i setup table switching to have Ign Table 1 for when the car is in gear and Ign table 3 for when it's in Park/Neutral (setup the Inhibitor Switch to switch GND to the starter relay).
[*]CL Idle Initial Values - Rather than the table, perhaps a better way to control the valve could be to have an 8x2 point curve (or the same # of temperature points as CLT/ASE/etc..) could probably work better here and perhaps call it min idle steps/duty and have it based on CLT (or IAT?)/Steps rather than RPM as it'll follow RPM anyway as CLIdle target table will dictate the target RPM/CLT nicely. This way we could use the initial value table X axis for VSS and Y axis for actual engine RPM as an extension to the min value curve, so as you come off the throttle (when not in CL PID mode for eg) the table is active and you can open/close the valve depending on rpm/vss - i.e. don't just set the stepper or duty once, keep following the table so you can ramp the steps out when vss nears 0 and rpm nears target - this way you can allow more (or less) engine braking when coming off throttle @ cruise, control airflow between shifts. In LS1 tuning it's called the Throttle Cracker table.
[*]Cranking Pulse & Cranking Taper could be simplified by going to a single table - CLT/Tach Events
[*]When Include AFR = on, then have correction tables (ASE, WUE) multiply the commanded AFR rather than multiply the final PW. Most cars run widebands these days and we could realistically have CL fuelling once the WB is warmed up. I think a few users (including myself) raised this idea last year some time.
[*]Second cooling fan logic

franksidebike · Post by **franksidebike** » Sun Mar 23, 2014 6:42 am

Hi Ken

muythaibxr wrote:
wes kiser wrote:Has the rational of the rpmdot stuff in over run been explained (mentioned in thread above)? I am relatively sure I know the intent, but not necessarily the behavior/function of the two settings?
It has in other threads. The basic idea is to bring fuel back sooner when RPM is falling faster.

In wich threads?
Frank

richyvrlimited · Post by **richyvrlimited** » Mon Mar 24, 2014 6:09 am

More inputs for Idle up would be nice. i.e. Power steering.

AbatelliCristian · Post by **AbatelliCristian** » Mon Mar 24, 2014 6:15 am

More inputs for Idle up would be nice. i.e. Power steering.

it' s good.. subaru use this strategy...
lancia delta with iaw system use idle up during ABS on...

richyvrlimited · Post by **richyvrlimited** » Mon Mar 24, 2014 7:19 am

AbatelliCristian wrote:
More inputs for Idle up would be nice. i.e. Power steering.
it' s good.. subaru use this strategy...
lancia delta with iaw system use idle up during ABS on...

I can see a need for it with just application of the brakes, the extra load causes PID idle to have to compensate on my car.

Post by **muythaibxr** » Mon Mar 24, 2014 8:52 am

PID is there specifically because you can't account for all the things that can affect idle speed.

If PID had to engage to help with the extra load from applying the brakes, then good! It did what it was supposed to do.

I think there is a point of diminishing returns when it comes to accounting for every little thing that can affect idle speed.

My main focus for idle speed control is to do something to make it easier to tune and more simple. Adding more settings and more factors that can apply does the opposite of that. I'm working on a design for a method that will incorporate fan and AC control along with all the other factors today, can control the speed with both idle valve and timing, and should be able to react quickly to changes in load that aren't fed forward into the loop ahead of the load increase.

Ken

richyvrlimited · Post by **richyvrlimited** » Tue Mar 25, 2014 2:32 am

muythaibxr wrote:PID is there specifically because you can't account for all the things that can affect idle speed.

If PID had to engage to help with the extra load from applying the brakes, then good! It did what it was supposed to do.

I think there is a point of diminishing returns when it comes to accounting for every little thing that can affect idle speed.

My main focus for idle speed control is to do something to make it easier to tune and more simple. Adding more settings and more factors that can apply does the opposite of that. I'm working on a design for a method that will incorporate fan and AC control along with all the other factors today, can control the speed with both idle valve and timing, and should be able to react quickly to changes in load that aren't fed forward into the loop ahead of the load increase.

Ken

The inputs for idle adders would actually be more useful outside of the PID loop IMO, As you say PID can take care of it's self, but when outside of the loop, the idle control is dumb and needs to be told what to do. It's not just the times when you're in the PID loop that need to be accounted for.

Trying to make things simple is admirable, but to get good control/behaviour for the multitude of vehicles that MS3 is able to run you need options surely?

More options doesn't necessiarially mean more complexity either, especially when those options are backed up by documentation explaining what they're for and how you'd utilise them.

Making things simpler can make things more complex IMO. Case in point, the dashpot adder isn't added on small throttle blips, but this isn't documented anywhere, and there's no way for me to adjust this behaviour, so if it's not right for my car, then tough! I only found out about this behaviour by chance after you'd explained it on this forum.

Sure it's simpler as I've not had to set anything, but I respectfully disagree that this means it's better.

Post by **muythaibxr** » Tue Mar 25, 2014 5:21 am

You are allowed to disagree

In any case I have been supporting the code mostly as it stands now and the same problems come up on a regular basis, so I am going to fix those before I add anything else feature wise.

The main problem I am seeing is that there are too many settings that can affect idle and even though the current code is documented, people do not read docs often. So I need to do what I can to make it easier to tune without reading the docs.

Ken

Megasquirt Support Forum (MSEXTRA)