Share your Math Channel List

[mapper]

I like to start a thread where everyone can add his Math channels, so a database is built. 

Please only post Math channels with short explanation in this thread. 

To keep it simple any discussion must be done in other threads. 

 

Boost error channel = Target Boost - MAP

Boost error parameter can then be used to control an electric Blowoff 

Brake bias = (rear+ front break press)/ rear break press

Front Wheelspeed Difference = LF wheel speed - RF wheel speed

Used to tune your LSD differential settings

 

Slip right = nondriven-wheelspeed - RR wheelspeed

Setup an Aux and turn on a driver warning light on the right side of the dash. So Driver knows right rear wheel is spinning faster ( eg. attention after a curb). Add the same function another for left. Then it looks like this :-)  from 3.00min

 

Boost error channel = Target Boost - MAP

Boost error parameter can then be used to control an electric Blowoff 

Brake bias = (rear+ front break press)/ rear break press

Front Wheelspeed Difference = LF wheel speed - RF wheel speed

Used to tune your LSD differential settings

 

Slip right = non-wheelspeed - RR wheelspeed

Setup an Aux and turn on a driver warning light on the right side of the dash. So Driver knows right rear wheel is spinning faster ( eg. Attention after a curb) to another function for left. Then it looks like this :-)  from 3.00min

 

Boost error channel = Target Boost - MAP

Boost error parameter can then be used to control an electric Blowoff 

Brake bias = (rear+ front break press)/ rear break press

Front Wheelspeed Difference = LF wheel speed - RF wheel speed

Used to tune your LSD differential settings

 

Slip right = non-wheelspeed - RR wheelspeed

Setup an Aux and turn on a driver warning light on the right side of the dash. So Driver knows right rear wheel is spinning faster ( eg. Attention after a curb) to another function for left. Then it looks like this :-)  from 3.00min

 

[TechDave]

So this afternoon I sat at the simulator and started mucking about with a few ideas.
I wanted to calculate my average speed based on some event, I used a digital input latching on.
In the UK we have average speed camera zones, you get snapped at the start and end and they do a distance over time calculation. Often you'll get slowed down by a Karen in an X5 not paying attention, I've always been curious how much I could safely speed up again to catch back up to 50 mph average over the trip.

You can do this in log analysis with the statistics view, but this is obviously operating at runtime.

So there's a few things here I've done that aren't documented yet, yes they will be.

The first is that maths channels can do reassignment, x = x + 1 etc

The next is that they're evaluated at 1000 Hz

Lastly I know of a few built in functions too.

I figured out two methods, of averaging, the first could be used not only for wheel speed, but for really any parameter, lambda, throttle position, you could use another maths function to find lambda, vvt, boost, etc error then feed that function into this one and have an average of error over some time period.

This one uses this algorithm:

newAverage = oldAverage + (newSample - oldAverage)/sampleNumber

the cnt function is a real good cnt function, it counts 1 per cycle (so 1 per millisecond) while c is greater than or equal to 1, so if you feed it a status which evaluates to 0 OFF and 1 ON, then you're away. If you want to use this for Anti-Lag active we might have to get a bit imaginative about an offset, iirc Anti-Lag OFF = 0, ON = 1, Active = 2...etc

I had to add a +1 to cnt because on the first cycle it's 0 and that's div by 0, plus the first cycle is the 1st sample too.

The 2nd method I came up with was to calculate distance, which of itself is a useful function, then calculate distance/time, again using that good cnt function:

Again using reassignment in the Distance function, multiply speed by 1/100th of a second, of a minute, of a hour to get distance travelled per millisecond (rate is 1kHz), I multipled by status to simply switch it on and off. This gives me km.

distance a over time, divide by the same multi as above gets us back to an average.

You don't need to use 8dp for this, I was just using it while getting my exponents sorted.

My functions agree with each other and track to my expectations, but if you spot an error in my maths then shout out

edit: unfortunately this is all in kph as I started running out of characters to add the mph multiplier, I've spoken with engineering and we'll see if we can get the length increased, 2.77e-7 helped a lot, but still lost a bit to parenthesis too.

 

[Davidv]

My ideas:

Pump safety

Fit a speed sensor onto a dry sump pump.

Pump speed / engine speed

If the number goes out of bounds you pump has jammed or belt has broken. So you can see a fault before oil pressure needs to drop.

Coolant capacity %

Will experiment with this but essentially

( ECT - IAT) / (rad temp) x100

So will fiddle with this a bit and try get a number that represents your remaining cooling capacity even when ECT is stable. So you dont need to see ECT climb to know youre nearing saturation point. 

Could be handy for EWP logic.

 

L/100km & km/l 

Self explanatory. Need modelled fuel

 

BSFC

Need a dyno that outputs a hp figure connected with canbus. Also modelled fuel. But can tune an engine for best bang for buck. Which is otherwise difficult to see. But good for endurance cars etc.

 

Ignition time to 14 adtc

(Ign adv + 14) / rpm 

Shows time period to reach where peak combustion pressure should happen.

So could use as an axis on a table that trims your ign timing with afr variations, leaner mix needs more timing and vice versa.

But it would be nice if there was just an option to show timing as miliseconds anyway as this makes simple trim tables way more useful across a large rpm range 

 

 

[Laimis]

VE Corrected = ( Lambda / Lambda Target ) * Fuel Table

For open loop mode. 

VE Corrected = ( ( Lambda / Lambda Target ) * Fuel Table ) * ( (100 + CL Lambda Fuel Corr. ) / 100 ) 

Should be working for closed loop + open loop modes. I will confirm later.

[Adamw]

15 hours ago, Laimis said:

VE Corrected = ( Lambda / Lambda Target ) * Fuel Table

For open loop mode. 

Not to take anything away from you post, I love to see these ideas coming through - but Im just mentioning this in case you werent already aware of the "quick trim" function that has been around since the G4, it will do this same basic calculation and apply the result to the fuel table for you (you still need to manually type in the measured value though).  If you have a log open and the fuel map on the same page, click on the cell in the fuel map that you want to adjust, then hit the M key, it will grab the target lambda from the lambda target table, you enter the measured lambda from the log and it will apply the correction to that cell for you.

[Laimis]

17 hours ago, Adamw said:

Not to take anything away from you post, I love to see these ideas coming through - but Im just mentioning this in case you werent already aware of the "quick trim" function that has been around since the G4, it will do this same basic calculation and apply the result to the fuel table for you (you still need to manually type in the measured value though).  If you have a log open and the fuel map on the same page, click on the cell in the fuel map that you want to adjust, then hit the M key, it will grab the target lambda from the lambda target table, you enter the measured lambda from the log and it will apply the correction to that cell for you.

Yes sir, totally aware of this function and Mixture Map, etc. But i thought its still nice to see in the log how far off your fuel map is.

[Rozsko]

Unfortunately I can't share an actual equation, but I would like to calculate the time of each engine cycle.

More precisely, the time of each power stroke. The purpose is the detect/verify misfires based on change in engine speed.

I looked through the parameter list and was thinking about how I could use a timer or the edge count function, I couldn't figure out what should drive the activation of the timer or the reset of the edge function value. It seems that the trigger scope 1 and 2 can't be used in math blocks nor in the timer function.

Do you guys have any idea how this could be achieved?

Thanks,

Béla

[Adamw]

11 hours ago, Rozsko said:

Unfortunately I can't share an actual equation, but I would like to calculate the time of each engine cycle.

More precisely, the time of each power stroke. The purpose is the detect/verify misfires based on change in engine speed.

I looked through the parameter list and was thinking about how I could use a timer or the edge count function, I couldn't figure out what should drive the activation of the timer or the reset of the edge function value. It seems that the trigger scope 1 and 2 can't be used in math blocks nor in the timer function.

Do you guys have any idea how this could be achieved?

Thanks,

Béla

I dont think there is a way to do this at present.  I see there is a "wish list" item in the system to investigate if this is possible.  

My understanding from a friend that has designed a similar strategy in his "research level" ecu is you need a minimum of 60 teeth on the crank to get good enough resolution/detail of the crank acceleration, then a fairly complex cylinder pressure model to create an expected crank acceleration channel to compare against the measured crank acceleration. 

[Rozsko]

38 minutes ago, Adamw said:

I dont think there is a way to do this at present.  I see there is a "wish list" item in the system to investigate if this is possible.  

My understanding from a friend that has designed a similar strategy in his "research level" ecu is you need a minimum of 60 teeth on the crank to get good enough resolution/detail of the crank acceleration, then a fairly complex cylinder pressure model to create an expected crank acceleration channel to compare against the measured crank acceleration. 

Thanks Adam.

Based on some of the Subaru technical documents I read, I am not sure if that 60 teeth is really required.

It seems Subaru is using the crank sensor signal voltage to determine if the crank is slowing down which makes sense as the reluctor sensor is highly sensible to speed.

Anyhow, if it is not possible, then that's it. Thanks again.

[Adamw]

That second scope capture doesnot show a misfiring cylinder.  Those missing teeth gaps are 180 degrees apart.  So those red arrows would show 3 cylinders out of 4 not running by their explanation.  

The fact that the distance (time between teeth) doesnt change much, but the voltage changes greatly suggest that this is actually a sensor failing or a lose connection.  If the crank had slowed down so much that the voltage was less than 1/4 normal, then the missing tooth "gap" would be much longer too.

 

[Rozsko]

On 6/8/2020 at 12:44 AM, Adamw said:

That second scope capture doesnot show a misfiring cylinder.  Those missing teeth gaps are 180 degrees apart.  So those red arrows would show 3 cylinders out of 4 not running by their explanation.  

The fact that the distance (time between teeth) doesnt change much, but the voltage changes greatly suggest that this is actually a sensor failing or a lose connection.  If the crank had slowed down so much that the voltage was less than 1/4 normal, then the missing tooth "gap" would be much longer too.

 

Makes sense Adam, yet, don't you think this method could be used? It sounds logical to me, and they implemented misfire monitor in the OE ECU (thought I am not sure how reliable that is ).

[Rozsko]

Tried to calculate the needed correction based on AFR target and lambda1, but the result is constant 0.

What am I missing here? Any idea is appreciated.

Thanks,

Béla

[Vaughan]

same setup seems to be working for me here, do you want to attach a copy of your basemap?

Also just to clarify did you setup that math block before making that log? The math blocks only work in real time and can't be backdated through logs.

[Rozsko]

23 hours ago, Vaughan said:

Also just to clarify did you setup that math block before making that log? The math blocks only work in real time and can't be backdated through logs.

I thought I did, but it seems I did not, as today with some crispy fresh pulls it is working properly. Thanks

[Vaughan]

Something I've done recently is add a knock warning to my CE Light, I used a math block to calculate knock level - threshold and put it through a gp output to get an off delay (hold time) and fed it into the CE Light Aux.

So far I've only used it for playing around with setting up my thresholds (so I can see how often it happens and for a clearer picture of when it happens) but I imagine it will be very useful once I've finished setting u the knock too. It has also been very useful for reviewing Knock stuff in PCLink logs as often the knock stuff happens too fast to be caught by PCLink but the knock light status can be used to see when it occurs without needing to actually see the knock level above the threshold.

 

[SimonSTI]

Not super fancy, but I use a math block to filter my speed signal with the average function (av). Works really well.

[Bethanyc]

So stealing that one

[mapper]

On 6/17/2020 at 9:37 PM, Rozsko said:

Tried to calculate the needed correction based on AFR target and lambda1, but the result is constant 0.

What am I missing here? Any idea is appreciated.

Thanks,

Béla

You don't need to use a math channel to calculate lambda error. There is already an lambda error channel in the G4X

[SimonSTI]

Average knock level to help adjust gain between cylinder.

 

[koracing]

So far just AFR based on lambda for when in mulit-fuel (because I'm old and dumb and think in gasoline AFR a lot).  Lambda1 * 14.7

Other various unit converstions for kpa to psi so I can look at fuel pressure in psi but table axis in kpa (similar reasons as above). 

 

I also did a % lambda error  - I was aware of the lambda error value but it is a lambda difference or offset I believe, and not a %. 

[Oldmanz350]

Can anybody correct my Equation. It's not working

It's to convert estimated Torque to Hp.

Math Block 1- WHP

Perameter 1   estimated Torque

Perameter 2   Engine Speed

Perameter 2   Path Block 1 Output -WHP

Equation.   c(a*.7376)*b/5252

This is Nm's to Ft/lb's to Hp

Thank You,

Tim

[Vaughan]

why are you feeding the math block back into itself? The problem is that the math block starts with a value of 0 and our always multiplying the new value by the previous value and so it will always be 0.

Should it not just be "a*b/7127"?

[Morrisman1]

Nice and simple ones:

Smoothing of the fuel level sensor to prevent intermittant low fuel warnings and give am more stable reading:
Parameter A: GP Input Fuel Level
Equation: av(a,10)

 

Calculating centre diff speed differential on AWD
Parameter A: FL wheel speed
Parameter B: FR wheel speed
Parameter C: RL Wheel speed
Parameter D: RR Wheel speed
Equation: ((a+b)/2)-((c+d)/2)

The output of that will be km/h, positive values for front wheel spin, negative for rear wheel spin (relative to each other)

 

Calculating Error in GPS speed readout
Parameter A: Driving wheel speed
Parameter B: Driven wheel speed
Parameter C: Longitudinal acceleration
Parameter D:
Equation: (a-b)/c

The output of this hopefully should prove a theory that the error in GPS speed is directly proportional to the acceleration of the car. Just taking some data points from old logs makes this appear to be about 12.5km/h per G of longitudinal acceleration. If I can pin this down to be pretty consistent then I can trim my GPS speed input with the value and make a more accurate driven wheel speed value on my AWD. Basically acceleration supplemented GPS speed. Id like to see if there was a better way of doing this too.

 

Im also looking at doing one to calculate rate of change of coolant pressure to feed into some engine protection for my head gasket, but I haven't yet worked out what I would use as a threshold for that protection to activate as I have never had a head gasket fail yet to collect data from. 

 

[koracing]

Working on getting the idle to act as close to stock as possible on my 1995 MR2 Turbo.  In that effort - I've created a math block to give me one axis to use on the base idle position 3D table.  It seems as though I need one set of values for no load on, then a second set for if the AC is on and I also wanted the base position to go to zero if I was on boost.  In this particular vehicle the AC clutch is controlled by a separate AC amplifier circuit, but the idle up is controlled by the ECU.  This is the Logic:

Label: Idle Math 
Param a : AC Clutch
Param b: MAP
Param c: BAP

eq: a+3*(b>(c*1.02))

This outputs a 0 if the ac is not on and the boost is less than 2% above BAP.  If the AC is on, a value of 1 will result.  If the car is boosting, a minimum value of 3 will result - or 4 if the AC is also on.  I did the equation comparing BAP and MAP so it wouldn't be dependent on units if I was in kpa or psi for pressures.  I didn't want to just have it be MGP>0 because I felt like at startup it was possible to have a slight calibration issue that may make the IAC base position go to zero.  I also didn't want to accidentally have AC on and positive boost have the same value which is why the second part of the equation is multiplied by 3.  Then the Y axis of my idle base position table is 0, 1, 2, and 4 - and only rows 0 and 1 have non-zero values (versus coolant temp): rows 2 and 4 have all zeros.

The reason why I don't simply use the AC idle offset table is that while it works decently for initial AC on, it causes problems when the AC shuts off.  It subtracts whatever the offset value is from the current Idle duty cycle which can cause the idle to dip a bit.  Using the base table with different values seems to work much smoother and better.

[djhedges]

Gsum = x + y + z accelerometer channels

It can be used to get an idea of much of the available traction a driver is using.  Think traction circle.