MembersPage/GunnarReynisson/FirmwareRequest (2012-10-08 17:54:54)

MAT / TPS ignition retard should be MAP based, or configurable ( MAP or TPS )

Agreed, working on it (more work in VemsTune than in firmware).

TPS makes sense for engines that might not have MAP sensor at all. (ITB normally aspirated).

MAP is usually better and easier to tune.

So choosable is best.

I´d like to check how this is going on? - I meant the MAT/MAP ignition retard

Input for Coolant temp and air temp can be selected from non pullup analog inputs - How?

This allows parallel installations to be done more easily.

ECU is setup for Cam sync but still runs if camsync fails.

This is easily handled by allowing configuration of outputs (ignition) in the dual config if camsync fails.

Engine operations are not affected by the loss of camsync therefore.


Right now fuelcut makes idle catch tuning tricky on some engines. How about a 'primepulse on fuel resume if TPS below IAC threshold, RPM falling, and fuelcut active'? Or something similar that allows for reloading the wall film when leaving fuelcut and descending quickly (out of gear) toward idle. In absence of proper X-tau some form of wall wetting would help with fuelcut recovery. Right now the only obvious solution is to richen the bottom row of the VE table and let EGOC take care of fixing those cells when cruising in those ranges. Even just a generic percentage of pulse width to add on fuelcut resume would work for most situations that I can think of, bonus points for having it scale against RPM or RPM drop/sec in some way.


camsync right at the missing tooth

sometimes before, sometimes after tooth0. (this is currently not allowed).

Especially important if cam angle is getting measured between 355-366 with a missing tooth wheel. Some BMW engines have the cam signal right in the missing tooth, this is a installation of the cam problem so some might trigger on one phase and some other ones on the other phase as well as some hopping between phases (which I have gotten, had to run dual out to solve).

Possible solution


Idle fuel/ignition map.

Something like a 6x6 map that only is activated during idle condition (below rpm, below tps)

Y axis can be MAP or Idle control duty cycle, selectable between each no matter if main strategy is alpha-n or speed density

There is a VE(MAP,RPM) table. Splitting out a corner would add complications and worse, transients.

- Sometimes ignition idle requirement is nowhere near what is needed at the same manifold pressure and engine speed.

This is done to get an even steadier idle without fluctations as well as low engine speed low throttle conditions which may require different ignition and fuel.

VE value resolution increase

At least a half a point or more

Mass fuel option fuel table.

Ideally 0-Xms opening time curve that represents volume

multiplied by a factor for fuel density. Allow addition of fuel temperature compensation from analog input.

-This is clearly not what I meant. But I understand that mass based fuelling is maybe not what VEMS is ready for.

Especially important for low resolution pulsewidth when flow is non linear to have the curve and massive injectors.

Ecu then chooses the appropriate pulsewidth based on the curve from the mass wanted from the fuel table.

Anytrim by TPS

Can this be implemented as an option for Anytrim 1 and 3

Anytrim 3d

Allows 2 axis to be choosen from any analog channel at least and it´s axis based on that channel , preferably any reported channel. Would allow custom function tables whose effect can be any of the current functions or new ones added.

.. Yes this would be nice / Erikk

Improved boost control

Include the option for Secondary PWM Table Absolute as the base duty cycle table for the main boost control function.

So boost control would work so

DC table (kpa, rpm) + anytrim function + gearDCtable + PID = BoostDC

Then target can be altered by anytrim and TPS and gear table.

I believe this would give far improved targetting with high variances possible without having crazy PID values.

The tuning would be done without PID to reach the correct boost (kpa in the DCTable) in all rpms and alterations for various gears if needed.

.. New boost control strategy is under development / Erikk

New idea for boost control (I have brought it up on the IRC already before) for highly improved targetting and converting the whole system into targetting, would of course work in simple style still.

New tables:

DCref table,

Y axis : boost target

X axis : rpm

P_table :

Y axis : kpa error , target - map

X axis : rpm

dcref.jpg

ptermtable.jpg

Currently we have targetting based on

Gear, TPS and various other things. Irrespective of where the target comes from improved accuracy in getting to the target is needed when the boost target can vary from 150kpa to 300kpa or when wastegates have leaks or simply don´t behave smoothly or linearly.

My suggestion is that the user completes a 3d table which acts as the base DC for each scenario, i.e boost target and current engine speed, the way they fill it in is by adjusting the target and then adjust the DC "curve" throughout the engine speed range to get there or at least as very close as possible.

This by itself would yield probably 95% success rate in targetting later down the road for the user.

The PID then needs to act to finalize the DC%.

The best way I can think of it is rpm and error based 3d table which would allow the user to get the best possible control over correction at both the amount of error (unlinear P term at X rpm) as well as unlinear at Y error amount. So that absolute dc control is available and this should raise targetting succes to near 100% if done right.

I and D same as before, the variable P term and varying DCref table cover almost absolutely every scenario possible in terms of hitting the target.

Antilag by Idle control valve

Would it be possible to add the function to run a specific idle control duty cycle while under antilag, thus acting as ALS valve.

.. Already implented, 'ALS Iac position' in the ALS menu / Erikk

Thanks for the heads up, - Gunni

A - B config

The current implementation I feel is wasting space by having absolutely EVERYTHING in each config.

My suggestion would be to follow the Pectel way.

Config swabbable things are things like

VE table, Ign table, Lambda table, boost targetting(gears, speed or whatever), variable cam target tables, Als configurables like rpm, duty cycles and such , not output pins or input pins.

Everything that is a fixed constant like ignition trigger settings, inputs and outputs wouldn´t change,

I believe this should free up some map space and might allow 3 configs to be swappable instead of 2.