What is dynamic airflow

**SiriusC1024** · 08-19-2023

Originally Posted by Cringer

2) This entire method is predicated on the fact that DynAir and only DynAir controls IPW. If this can be disproved, then this method is seriously flawed. MAF and VVE only indirectly influence DynAir. It would be totally different if the ECM hopped between MAF, VVE, DynAir at any moment to control IPW. However, DynAir is always present, always updated and always maintained and ready to render an opinion on air flow and is the only controlling factor over the final IPW.

DynAir controls IPW as far as I can tell. This is confirmed at [0018] and the formula laid out at [0021] of the patent.

Check this out. At [0018] Patent 5,394,331 is referenced and it is "incorporated herein" as a foundation. First sentence of the summary explicitly calls this dynamic airflow.
"The present invention is a method of dynamically determining the airflow into an internal combustion engine using a mathematical model of the engine".

https://patentimages.storage.googlea.../US5394331.pdf

And here's more proof that dynamic airflow is the strategy employed:
proof.png

**hjtrbo** · 08-19-2023

Originally Posted by siriusc1024

P.s. Can someone post up a .csv log with map, maf, vve, dynair tracked? I want to demonstrate the filter graphically.

that file is not public. It is customary to exchange with something of a similar nature.

hth, note the red trace is when my filter is allowing data to pass. Love the transients on decel...
Screenshot 2023-08-20 141102.png

**SiriusC1024** · 08-19-2023

I'm starting to doubt that ECM 13432 is the predetermined gain limit. The method filter concept is valid, that MAF and MAP have to each be in steady state for dynair to be steady state, but I can't seem to find the exact constant in the tune.

**SiriusC1024** · 08-19-2023

Originally Posted by hjtrbo

that file is not public. It is customary to exchange with something of a similar nature.

hth, note the red trace is when my filter is allowing data to pass. Love the transients on decel...
Screenshot 2023-08-20 141102.png

Oh you mean the file that had all the hidden tables?

Thanks for the .csv.

**SiriusC1024** · 08-19-2023

hjturbo since we can't see what you are able to, any chance you can find info on the predetermined gain limit constant referenced in [0025] of the patent?

**hjtrbo** · 08-19-2023

Originally Posted by SiriusC1024

Oh you mean the file that had all the hidden tables?

Yeah.

Originally Posted by SiriusC1024

Thanks for the .csv.

No probs, here is a bigger chunk of it if you want to grab some other data out of it. Just cruising along the highway.

**SiriusC1024** · 08-20-2023

Sigh. This is either going to need a much bigger k or a much smaller gain value. When I said smaller k is better I wasn't approaching the problem correctly.

And I should clarifiy that in the filter formula it's for MAF and MAP calculated airflow, not the sensors themselves. I think anyway...I'll get back to this when I'm not so spent because at this point I'm just causing confusion.

I was hoping to use the csv data to show the curves as dotted lines but have dynair solid where the steady state MAP && MAF was met. Yeah this is all I got lol whole lotta nothing.
nothing.png

It'd be no problem if k and gain were explicitly defined, but I don't see them in the tune.

**SiriusC1024** · 08-20-2023

Figured out what I was doing wrong. Arithmetic error.

Got it. We can now collect accurate data during transients.

got it.png

So, the filter is corrected and follows:

Code:

Poll [DynAir] if {(abs([MAF(k)]-[MAF(k-1)])/[MAF(k-1)]))/(k-(k-1)) <= [ECM 13432]} && {(abs([MAP(k)]-[MAP(k-1)])/[MAP(k-1)])/(k-(k-1)) <= [ECM 13432]}

becomes the simplest calculus
... if d(MAF)/dt <= [ECM 13432] && d(MAP)/dt <= [ECM 13432]

where d/dt is evaluated over polling rate = 12ms and [ECM 13432] becomes 0.1, simplifies to 
... if delta(MAF)/.012 <= 0.1 && delta(MAP)/.012 <= 0.1

where MAF is Mass Air Flow and MAP is VVE.

The above graph was a snippet to capture a transient. Data collected from dataset (attached) posted by hjtrbo. Here's the filter in action for the entire log:
DynAir_ss_total.png

As you can see, it's trimming a lot of data. It may appear that the reduction will increase tuning time, but remember this log is only 30 seconds. Perhaps the increased accuracy will make the total tuning time decrease by decreasing the need for tune/log iterations. Logging process is simplified. While steady pedal movements will increase % polled data, there is no need for filtering TPS and RPM. They are implicitly filtered when both MAF and MAP airflow are steady state.

It's interesting to note how DynAir trends toward MAF as steady state data density increases. This hints at the mechanism of bias between the two airflow models that informs DynAir. I think DynAir calcs can be solved in order to correctly adjust VVE and MAF. It also helps to validate this filtering method.

**verlon** · 08-20-2023

Originally Posted by SiriusC1024

I think he means how was all that data obtained? I'm interested, too.

Exactly. It contains GM internal names which can only be found in CTS/SSTS documents. But those documents hasn't been leaked.

Originally Posted by hjtrbo

Up for swaps if you have E67 or T43

What is the tool name and how did you got it?

**hjtrbo** · 08-20-2023

Originally Posted by SiriusC1024

Figured out what I was doing wrong. Arithmetic error.

Got it. We can now collect accurate data during transients.

got it.png

So, the filter is corrected and follows:

Code:

Poll [DynAir] if {(abs([MAF(k)]-[MAF(k-1)])/[MAF(k-1)]))/(k-(k-1)) <= [ECM 13432]} && {(abs([MAP(k)]-[MAP(k-1)])/[MAP(k-1)])/(k-(k-1)) <= [ECM 13432]}

becomes the simplest calculus
... if d(MAF)/dt <= [ECM 13432] && d(MAP)/dt <= [ECM 13432]

where d/dt is evaluated over polling rate = 12ms and [ECM 13432] becomes 0.1, simplifies to 
... if delta(MAF)/.012 <= 0.1 && delta(MAP)/.012 <= 0.1

where MAF is Mass Air Flow and MAP is VVE.

The above graph was a snippet to capture a transient. Data collected from dataset (attached) posted by hjtrbo. Here's the filter in action for the entire log:
DynAir_ss_total.png

As you can see, it's trimming a lot of data. It may appear that the reduction will increase tuning time, but remember this log is only 30 seconds. Perhaps the increased accuracy will make the total tuning time decrease by decreasing the need for tune/log iterations. Logging process is simplified. While steady pedal movements will increase % polled data, there is no need for filtering TPS and RPM. They are implicitly filtered when both MAF and MAP airflow are steady state.

Unreal.

Here is my tune if you want to try the filter constants from it.

**SiriusC1024** · 08-20-2023

Originally Posted by hjtrbo

Unreal.

Here is my tune if you want to try the filter constants from it.

See my edit, too

I'm not to the point of finding the constants. That's the other half of the problem. The WHERE has been solved, but we also need the HOW.

**GHuggins** · 08-20-2023

Originally Posted by SiriusC1024

Figured out what I was doing wrong. Arithmetic error.

Got it. We can now collect accurate data during transients.

got it.png

So, the filter is corrected and follows:

Code:

Poll [DynAir] if {(abs([MAF(k)]-[MAF(k-1)])/[MAF(k-1)]))/(k-(k-1)) <= [ECM 13432]} && {(abs([MAP(k)]-[MAP(k-1)])/[MAP(k-1)])/(k-(k-1)) <= [ECM 13432]}

becomes the simplest calculus
... if d(MAF)/dt <= [ECM 13432] && d(MAP)/dt <= [ECM 13432]

where d/dt is evaluated over polling rate = 12ms and [ECM 13432] becomes 0.1, simplifies to 
... if delta(MAF)/.012 <= 0.1 && delta(MAP)/.012 <= 0.1

where MAF is Mass Air Flow and MAP is VVE.

The above graph was a snippet to capture a transient. Data collected from dataset (attached) posted by hjtrbo. Here's the filter in action for the entire log:
DynAir_ss_total.png

As you can see, it's trimming a lot of data. It may appear that the reduction will increase tuning time, but remember this log is only 30 seconds. Perhaps the increased accuracy will make the total tuning time decrease by decreasing the need for tune/log iterations. Logging process is simplified. While steady pedal movements will increase % polled data, there is no need for filtering TPS and RPM. They are implicitly filtered when both MAF and MAP airflow are steady state.

It's interesting to note how DynAir trends toward MAF as steady state data density increases. This hints at the mechanism of bias between the two airflow models that informs DynAir. I think DynAir calcs can be solved in order to correctly adjust VVE and MAF. It also helps to validate this filtering method.

OK, I'm going to play as stupid as I am here. How would this equate out to an actual math function to plug into the filter of the scanner to actually be used?

**ttz06vette** · 08-20-2023

I was thinking the same thing but didn't want to be the one to ask.

**SiriusC1024** · 08-20-2023

I don't know how to configure scanner to poll at different time intervals.

If someone could show me what how to do MAF-MAF(last data point) or even MAF-MAF(.125 seconds ago) I'd fill in the rest.

**Cringer** · 08-20-2023

Originally Posted by SiriusC1024

I don't know how to configure scanner to poll at different time intervals.

If someone could show me what how to do MAF-MAF(last data point) or even MAF-MAF(.125 seconds ago) I'd fill in the rest.

In the user math section, the average function. -125 is looking 125ms in the past.
[50040.71.avg(-125)]

+125 is in the future.
[50040.71.avg(125)]

Note that a + average will not work for live driving and logging. You would have to save the file and then open it once all the data is in.

**SiriusC1024** · 08-20-2023

Actually let me clarify something. With a set timestep, instead of tracked by a function, if just one is offset because of a delay in count then the entire dataset becomes useless.

Can we use the actual polling interval? This would cover cases of infinite (varies) or if there's some processing delay that can't maintain 125ms.

What I'm saying is that I need a function in scanner math called 'timestep' that works to do this.

**hjtrbo** · 08-20-2023

You can right click the channel(s) in the channel list and select the polling interval. Now, if it is actually obeyed I do not know.

**Cringer** · 08-20-2023

Originally Posted by SiriusC1024

Actually let me clarify something. With a set timestep, instead of tracked by a function, if just one is offset because of a delay in count then the entire dataset becomes useless.

Can we use the actual polling interval? This would cover cases of infinite (varies) or if there's some processing delay that can't maintain 125ms.

What I'm saying is that I need a function in scanner math called 'timestep' that works to do this.

As far as I know you cannot track to the last discreet data for a channel. You would have to export to CSV and dig using some code I think. The other option would be to see the average polling speed of that channel (again, export to CSV with the "do not interpolate missing data" option and examine the timestamps to find the average. For me I am about 20ms IIRC, so assuming that was case you would use [50040.71.avg(-20)] to approximate getting the previous data.

**hjtrbo** · 08-20-2023

Just my 2 cents, but perhaps post processing the log in your math software of choice might be yield better results. I'm sure cringer has lots of free time to include it in his software suite

🙃

**Cringer** · 08-20-2023

Originally Posted by hjtrbo

Just my 2 cents, but perhaps post processing the log in your math software of choice might be yield better results. I'm sure cringer has lots of free time to include it in his software suite



https://instantrimshot.com/

Thread: What is dynamic airflow

Thread Tools