mapper

if you tune in VE mode and have everything correct set, the VE curve represents more or less the torque curve, so you can adjust ignition timing accordingly. 

Hi,
Just an idea... It would be great if there was a way of searching for what a DI controls.
For example, you have a DI x set to activate Boost. You may want it to do other things and have it activating a less agressive traction control, alternative fuel map etc.
A simple "Search" for DI x shows all the things that DI x is assigned to?

Another thing which I would like is a 3D Accel Cold correction table so it can be spanned with Engine running time or charge temperatur or a modelled intake manifold temp. 
The reason is simple. Just after cold startup, it needs much more accel enrichment, than after 1-3min running time of the engine.  From a tuning perspective, you need to add a lot of accel enrichment just after the start of the engine so throttle response is good. But after 1-3min running ECT is still similar, but manifold ports have got some temp into it. Now the big Accel enrichment just flushes the cylinders and oil film down.  

Another thing which I would like is a 3D Accel Cold correction table so it can be spanned with Engine running time or charge temperatur or a modelled intake manifold temp. 
The reason is simple. Just after cold startup, it needs much more accel enrichment, than after 1-3min running time of the engine.  From a tuning perspective, you need to add a lot of accel enrichment just after the start of the engine so throttle response is good. But after 1-3min running ECT is still similar, but manifold ports have got some temp into it. Now the big Accel enrichment just flushes the cylinders and oil film down.  

I was wondering if it would be possible to add PWM table functionality to virtual auxiliary outputs? I would like to utilize them for pressure differential measurement so I can have basically a single output value that can be used on one axis of an ethrottle table or any other table for that matter. Alternatively 4D mapping on the ethrottle tables would also work equally as well. 
 
Blaine Carmena
Carmena Performance

Would this be at all possible?
Instead of having to save each individually?

We use the ESR 10 Series, we also found they are so fast that you can double them up if you need more amps and they shut down if over current so if one fails no issue, we have not had one fail yet.

They work fine wired in the normal manner if you connect to an ignition aux rather than a normal aux.

Yes you can do this a couple of different ways.
One option is; In the ECU you still assign the function you want to an auxiliary output - lets say as an example we set up engine cooling fan on Aux output 1.  You dont physically connect any wires to aux 1.  You then use the "A1 (status)" parameter to send to your PDM over CAN.  The Aux status parameters are sent as follows:  0 = OFF,  1 = OFF,  2 = ON,  3 = FAULT.  You can use the Multiplier/divider/offset to scale that into numbers that your PDM wants.  For instance if your PDM wants 0=off, 1=on, then you use an offset of -1 to get that.
Heres an example:

 
An alternative option is very similar to option 1 but use a Virtual auxiliary rather than a real auxiliary - this allows you to keep the real auxiliary output free for doing other stuff (you only have a max of 8 virtual auxiliaries however).  Set up the virtual auxiliary just like you would set up the normal auxiliary, then send parameter "VA1 (Status)" to the PDM.  
Here is an example for a Virtual aux set to fuel pump. (note the ECU will still handle the normal fuel pump prime logic etc):

Hi Hans,
I believe Mapper's question was referring to the comments he found in this post here: 
 
Although there are improvements planned for E-throttle ISC in the future, for most users the existing functionality works perfectly fine and there are no show-stopping issues.  We sell many plugin ECU's for E-throttle cars and have very few reports of poor idle control, when there have been it is usually just tuning related.  

Will the new Firmware come with a fix for idle control with DBW? I have to convert a few LINK equipped cars in the coming months and i dont like to install an external idle controll valve. I even have to less aux available on a car. 

Try this: Select the correct CAN Bus and Enable User Defined Mode and Transmit Generic Dash at 1Mbs on CAN ID 1000
 
 

I assume we are talking Evo 9 Mivec?  If so the mivec cam position is done by a separate sensor to the trigger “sync” so you are free to change the trigger.  Note you will need to remove one tooth from the exhaust cam if you are changing to a generic multi tooth or missing tooth crank.  
Benefits of a higher tooth count is more correct/stable ignition timing during fast transient conditions so if retuned you can often run more timing before the knock limit is reached.

Try the basic setup below.  Set "upshift digital input" to the DI that is connected to the  Clutch switch.  Leave downshift digital input set to off.
The gear detection/gear ratios will need to be set up and working first.
With these example settings below; when RPM is >3000 & <9000 & TP is <30%, you will get a 25%throttle blip for 100ms everytime the clutch is pressed.

 
Note, upshift gear cut will not work if you have brake switch in series, I would try using just clutch switch only initially and only add brake switch if needed.

Hi Marc
Good to hear back from you. How much does your AFR oscilate? Where is the wideband located? Depending on position, you need to adjust Lambda rate and Gain. 
You should do some testing. Tune your VE table with CLL off  as good to your Target AFR as possible. Adjust your target AFR table to the rich side with one task by the amounts listed in the gain table 0,33 0,66 etc. And log, with a high logging rate, how long the sensor needs to get to a stable reading. 
Lets say it needs 0.3 seconds. This means your frequency in the lambda rate table may be max. 1/0,3  = 3.333
This test should be done at different loads and rpms to work out best CLL settings. Best place to do that is a load bearing dyno. 

Hi Marc
Good to hear back from you. How much does your AFR oscilate? Where is the wideband located? Depending on position, you need to adjust Lambda rate and Gain. 
You should do some testing. Tune your VE table with CLL off  as good to your Target AFR as possible. Adjust your target AFR table to the rich side with one task by the amounts listed in the gain table 0,33 0,66 etc. And log, with a high logging rate, how long the sensor needs to get to a stable reading. 
Lets say it needs 0.3 seconds. This means your frequency in the lambda rate table may be max. 1/0,3  = 3.333
This test should be done at different loads and rpms to work out best CLL settings. Best place to do that is a load bearing dyno. 

That and a few other handy features are already on my list of "Things that would make PCLink much nicer to use as a tablet dash".

Thanks!

Regarding Lambda control error correction table. I spend alot of time to tune these. The base map is adjusted the wrong way around. Because the error correction tables is a % corretion of actual error, you want big corrections like 15%  on small errors (0.03 lambda error) and small correction (like 5%) at the biggest error on the table. This is because a fuel film built up first in the ports when big correction are applied. This means it needs several burn cycles to get the whole change applied and measured. This means lambda control applies big changes two or three times for big corrections which leads to Lambda oscillation.  On small changes fuel film built up is much less.  Lambda change is done and measured much faster and within same burn cycle. This means the Lambda correction can be set much higher, because the change in AFR is measured instant.
I have attached a tuned example.  

Regarding Lambda control error correction table. I spend alot of time to tune these. The base map is adjusted the wrong way around. Because the error correction tables is a % corretion of actual error, you want big corrections like 15%  on small errors (0.03 lambda error) and small correction (like 5%) at the biggest error on the table. This is because a fuel film built up first in the ports when big correction are applied. This means it needs several burn cycles to get the whole change applied and measured. This means lambda control applies big changes two or three times for big corrections which leads to Lambda oscillation.  On small changes fuel film built up is much less.  Lambda change is done and measured much faster and within same burn cycle. This means the Lambda correction can be set much higher, because the change in AFR is measured instant.
I have attached a tuned example.  

Hi 
To speed up wiring and diagnostic I would like to have a function that outputs a list, a schematic, and a picture of the connectors with all labels of all configured (assigned) in- and outputs. On top of that many smart things could be implemented like an auto updated complete wiring schematic in an easy understandable format(e.g MS Visio style). These things can speed up install time and wiring a lot, which sets barrier lower to switch to a standalone ECU.  
possible examples attached. 

At last, my graphics issues are fixed, despite having latest geforce drivers, it was the windows setting for text scaling, it needs to be 100%, not 125%.

Yeah that one's a known issue thanks.

As fare I remember the old Nissan knock Sensors make groudn through the block and one pin makes contact with the mounting surface. You can Check that with a ohm meter. 
Bosch knock sensor doesn't have contact between pin and mounting surface. 

Very true.
Cost me quite a bit of time this!

Would be good if you can pack a additional paper to the ECU package, to get sure customers are aware. Because such things means always diagnosis time for us tuners which nobody want pay for. Think is a much easier task from your side to pack a letter to the ECU, which descrips the situations that the pinout will be updated only on the next firmware release.