Turns out in my case the jerking was caused by too much advance, like 0x33 suggested. I reduced significantly the timing/torque and the jerking is finally gone. Now my car is really starting to drive well, I just have to fix the long cranking / stall after startup issue and it's all dialed in
Thank you all for you help!
Confession time: the hose I thought was going to the wastegate was going to compressor and the other way around I switched them around and now target boost seems to come around 25 % wastegate and controllable.
I'm sorry to have wasted your time and to have driven the car in overboost dozens of times while trying to understand what's going on.... unfortunately I was just too sure of how those hoses were connected and I thought of any other complicated explanation but this.
So car pulls strong and it seems that soon the tuning will be done. Next priority is getting the cold start decent but I'll meet you in other topics about that
Thank you for your help and good luck!
I see, I wish that it would always ask if I wanted to load write the changes to the ecu, no matter how large. Because when it just loads the config out of the ecu and doesn't notify about anything, it's easy to think there were not any changes in the tune file. Then you carry on, tuning the config loaded from the ecu, until you realize there is no filename associated with the open tune file. Then you have to open the old file and see what's different, plus the changes you've recently made to the config file that was automatically loaded.... I've lost a good bit of time this way.
If it's not possible for PCLink to ask if you want to load a tune with large differences, there should at least be a dialog that notifies what's going on (tune uploaded from ECU is replacing the open tune).
Currently with mixture map you set a threshold so that samples within say 25% of the centre of a cell vertically and horizontally.
This pool of results are used to contribute towards an average value in the centre of the closest cell.
However this means that you've got 25% variation of rpm and load, contributing to a static value in the centre - and you need to throw away 75% (?) of recorded values.
I have another idea that can let you use all of the data instead, and improve the results.
For simplicity's sake imagine a 4x4 grid, and our current load and rpm point is 25% of the way towards the lower RPM value and 25% of the way towards the lower Load value.
If we interpolate these values, as per what the ECU does.
Note: I have just titled the columns and rows with percentages to show what percentage of the each cell we are interpolating from.
We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 40)
= 0.625 + 6.075 + 3.75 + 22.5
= 32.95 is the table value that interpolation produces.
Now lets say that you wanted to add 10% to this value.
If we just adjust the closest cell by 10%, as per current Mixture Map strategy. Then our bottom left cell changes to 44 so our table now looks like this:
If we do the interpolation again, but with the new value to represent running the car again after the update:
We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 44)
= 0.625 + 6.075 + 3.75 + 24.75
= 35.2 as the new overall value. Which is only makes 6.8% difference to the interpolated value, rather than the 10% we wanted.
On the other hand...
If PCLink De-interpolated the 10% that it wants to add.
Instead of adding 10% to the one cell, we split the 10% addition across the 4 cells based on the same percentage that the value was interpolated from initially.
So:
Top left cell: (10 * 1.1 * .25 * .25) = 0.6875
Bottom left cell: (30 * 1.1 * .25 * .75) = 6.1875
Top Right Cell: (20 * 1.1 * .25 * .75) = 4.125
Bottom Right Cell: (40 * 1.1 * .75 * .75) = 24.75
= 35.75 is the table value that de-interpolation produces.
We were trying to add 10% and this new value produced is 10.5%. So that's pretty good!
(The 0.5% error comes from rounding to 3 decimal places in my example)
So it's accurate to the provided data in every instance. Which is especially relevant when it's applied 1000s of times across all of the cells. You dont need to throw away any of your recorded data, it all contributes to the cell values.
Mixture map is pretty good for roughing out a map initially but because of the inaccuracies of the "nearest cell" method I don't really use it that much anymore when trying to dial in a fuel map. You always overshoot or undershoot unless you set your cell tolerances impossibly tight and have millions of samples.
And, since this is all only done in PCLINK rather than the ECU, there's not really any worry about the overheads of the extra maths involved. It's worth having it chug away for a few minutes longer if you can get an awesome result on first or second iteration of Mixture map logging.
So - that's my Friday night suggestion.
Thanks for reading if you got this far, haha.
Regarding your last answer Adam, maybe you could add the feature of switching map tables (or other inputs) from the user interface to the wish list? For those who have installed a tablet with PCLink inside the car it would make more sense to be able to "simulate" switch actions from the software, rather than wiring and installing mechanical switches to do the same thing. I guess a generic approach where all digital inputs might be assigned to a "software user interface panel" would be worth considering. Just a suggestion to improve an otherwise very good system / software.