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
 

Thats my post ;-) 

Yes we will have some DI's with adjustable thresholds in a future ECU, but all our current ECU's have the thresholds set by hardware.  

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
 

I totally agree, this would make sense. Also, a long term trim function for Wastegate duty cycle would be great. 

Wall wetting compensation only applies to acceleration where the fuel to be injected is higher than previous injection cycle.
There's no 'normal' value as it fairly depends on the engine intake manifold/valve/combustion chamber design.
You'd have to experiment on that, but according to articles I have read, X*Tau enrichment ([fuel pooling/puddling & wall wetting total] * Time) would be around 32% more fuel.

I think absolute values for the transient lockouts would be very helpful. Seperate minimum lockouts would be even better.

Would be cool to have a little more flexibility for sure. Anything which has the ability to be enriched in open loop should really have the ability to also adjust the target lambda so that closed loop doesn't just over-ride it. Overlay tables can get you part of the way there, but you quickly run out of axis' and need to carefully consider the compounding effect like Mapper mentioned.

We need many more target lambda tables, like for: 
post start  ECT based IAT based Exhaust Temp Throttle Position average load based knock fuel trims (apply target trim instead of enrich, which the CL pulls back)  NOS compensation two separate targets for Multi fuel mode Launch  One way I can think of to do it, is use 4,5,6D and better some more tables as a target lambda or target lambda trim instead of a fuel trim. However, the ECU should just use the richest target within the calibration, so it doesn't get too rich when several conditions are meet. Like high IAT, ECT and Exhaust Temp, which are usually hit at the same time. Using target modifier for each condition, would end up in extensively rich target lambda. 
 

We need many more target lambda tables, like for: 
post start  ECT based IAT based Exhaust Temp Throttle Position average load based knock fuel trims (apply target trim instead of enrich, which the CL pulls back)  NOS compensation two separate targets for Multi fuel mode Launch  One way I can think of to do it, is use 4,5,6D and better some more tables as a target lambda or target lambda trim instead of a fuel trim. However, the ECU should just use the richest target within the calibration, so it doesn't get too rich when several conditions are meet. Like high IAT, ECT and Exhaust Temp, which are usually hit at the same time. Using target modifier for each condition, would end up in extensively rich target lambda. 
 

We need many more target lambda tables, like for: 
post start  ECT based IAT based Exhaust Temp Throttle Position average load based knock fuel trims (apply target trim instead of enrich, which the CL pulls back)  NOS compensation two separate targets for Multi fuel mode Launch  One way I can think of to do it, is use 4,5,6D and better some more tables as a target lambda or target lambda trim instead of a fuel trim. However, the ECU should just use the richest target within the calibration, so it doesn't get too rich when several conditions are meet. Like high IAT, ECT and Exhaust Temp, which are usually hit at the same time. Using target modifier for each condition, would end up in extensively rich target lambda. 
 

When the Throttle is suddenly lifted, lambda values go much to rich, do to the small delay in MAP reading and the fuel film puddle in the ports are sucked into the cylinder. 
I like to see a deceleration enrichment which removes fuel in these situations. 
Wondering if other tuners are missing this too? 

I have done the stock ACD ECU and worked out a stragey on G4X to control Center differentials with 3 different maps for acceleration, and 3 maps for braking. Additionally, there is a slip and steering angle overlay. 
Works quite good! 

I have done the stock ACD ECU and worked out a stragey on G4X to control Center differentials with 3 different maps for acceleration, and 3 maps for braking. Additionally, there is a slip and steering angle overlay. 
Works quite good! 

We need many more target lambda tables, like for: 
post start  ECT based IAT based Exhaust Temp Throttle Position average load based knock fuel trims (apply target trim instead of enrich, which the CL pulls back)  NOS compensation two separate targets for Multi fuel mode Launch  One way I can think of to do it, is use 4,5,6D and better some more tables as a target lambda or target lambda trim instead of a fuel trim. However, the ECU should just use the richest target within the calibration, so it doesn't get too rich when several conditions are meet. Like high IAT, ECT and Exhaust Temp, which are usually hit at the same time. Using target modifier for each condition, would end up in extensively rich target lambda. 
 

When the Throttle is suddenly lifted, lambda values go much to rich, do to the small delay in MAP reading and the fuel film puddle in the ports are sucked into the cylinder. 
I like to see a deceleration enrichment which removes fuel in these situations. 
Wondering if other tuners are missing this too? 

good suggestions
I would also add a time delay to each filter setting. So for example when transient rpm was detected, mixture map sampling is delayed by X secs or better engine cycles until Lambda reading has stabilized
 

When the Throttle is suddenly lifted, lambda values go much to rich, do to the small delay in MAP reading and the fuel film puddle in the ports are sucked into the cylinder. 
I like to see a deceleration enrichment which removes fuel in these situations. 
Wondering if other tuners are missing this too? 

A couple of notes I made while using the mixture map that I thought would be worth looking at. Feel free to discuss, there's likely reasons why some aspects are the way they are, but I thought I'd share anyway.

- CLL corrected lambda channel would be handy to have, without having to use a math block. I feel like mixture map is something people use while sifting through large logs from a period of driving that wasn't an active tuning session, so for most people I assume CLL would be active.

- Percentage of change towards target. With ECUmaster a friend says he can choose the percentage of change, so if mixture map calculates it needs another 2% in that cell, if you select "50%" it will adjust it by only 1%.

- Lambda delay. Transport delay to the sensor is obviously going to effect mixture map readings. I'm not sure what the best way is to tackle this, but it's something that needs to be considered while using mixture map at current.

- Additional filter slots would be a really big help. I flick through a couple different conditions/filters to see which is playing the largest role for that log, but it would be nice to have them all included.

- This could be an alternative to the above, but would be awesome to have both. The ability to use multiple "<" or ">" signs for a condition parameter on a single filter. Eg., "70C < ECT < 95C" or "-5% < TPS Delta < 5%", etc.

- The highlight range doesn't seem to save, it always goes back to 0.27La.

- Ability to apply all changes with a single click. If there was a greater level of filtering this may be handy.

- Ability to ctrl+z mixture map changes. Maybe I'm missing something, but I can't seem to undo a change after applying a mixture map correction.

- Lockout for engine cuts? Can use CLL < 9.5 I think, but already limited on condition slots.

- Transient filters are units/s, but TPS and MAP delta channels are units/100ms? I think units/s makes sense for most other channels, and ideally I'd use a conditional filter for TPS and MAP delta seeming they are already logged, but can't really do this if restricted to 3 conditional filters. Which means I then use TPS and MAP as a transient filter, but it's a different unit scale.

- Ability to use either a zoomed in section of the log only and/or the ability to trim log files.

 

I'm going to assume there's a reason for why math blocks have a 20 character limit, but thought I'd ask anyway. I have to use 2 math blocks to calculate some channels due to needing just a couple more characters. You eat into the characters pretty quickly with just basic equations. Would it be possible to increase this limit?

PDMLink was initially intended to support Windows 7 but due to incompatibilities and the outdated nature of Windows 7, PDMLink doesn't support Windows 7.
You can find an online version of the PDMLink help manual at: User Manual | LinkECU Documentation Centre (link-user-wiki.herokuapp.com)
When using an output in H-Bridge mode, the current is running in series through each pin so the current capacity is the same as a single high power output.
 
A way to ensure the current limit isn't exceeded is to limit the range of duty cycle in the H-Bridge. This shouldn't limit the range of motion of the motor but would reduce the torque slightly at the end stops.

I would also use idle ign control. Helps alot to stabilise idle.

Here is what the manual says. From my expierence the full 33 amps are reached only for a very short time, so the Razor PDM might handle it fine. On top you can define Inrush current and safety trip time.  The hardware is very capable, so I guess it will handle it just fine. 

Outputs
High Power
There are 4x high power outputs with a maximum safe inrush current of 80A and a continuous current limit of 25A at 12V.
While the maximum safe inrush current is 80A, the maximum measurable current is 60A.
The high power outputs each share two pins of the 26-pin super seal connector.
They can be used as high-side or low-side drivers, have a max frequency of 10kHz, and can be configured as 4 x half bridges or 2 x full bridges allowing control of devices such as e-wastegates. 
When in full bridge mode, Output 1 is paired with Output 2 and Output 3 is paired with Output 4.  
Outputs can be joined together to allow the use of higher current devices.

You can use several outputs in parallel to get more current. 

I would like to have a function clear fault codes which can be activated over an ECU Input or over CAN. 
We set up customer Dashes that every fault code is shown as plain text message. It will be good that the customer can clear the fault code with a press on the Dash or an external switch.