Davidv

Hi, 

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.

 
 

Here is an example of mine. Source is EGR port, which may skew the number from actual, but I don't have a way to source off the manifold of turbine housing right now. The far side of the canister will go to a braided line. The braided line will go to a firewall mounted pressure transducer. I suppose the transducer could be screwed directly into the canister.

Your mixture map is whatever your fuel table is. If you have two fuel tables, you need to go into the options and switch to that instead.

Hi Adam and David. 
I scratched out my sheet of measurements previously taken when I stripped a vvt pulley to ascertain the possibilities of limiting the range of adjustment. My bad, sorry, You are quite correct Adam, the pulley range of movement is just more than 23deg, equivalent 47crank deg as per the target tables. 
Apologies for questioning the topic again and again and thank for your input. 

ISCV is too slow to really be useful for quick changes in closed loop, you really need to get your fuel dialled in nicely and then ignition trim is the best way to keep it stable in my opinion.
 

Hi, 

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.

 
 

Hi, 

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.

 
 

It is a $98 tablet so wouldn’t surprise me   It seems fine with the 12Hz so might leave it for the sake of some sympathy on the old V44 hardware. 
I think a hearty thanks is in order for your support through something that is essentially 3rd party. Really does not go unnoticed. 

Hi, 

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.

 
 

Hi, 

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.

 
 

Yup you can now trim your fuel back to 0.86 lambda now.
 
Yup David that cold ignition advance table also had a good effect
 
But mostly that injection timing, I couldn't get my car up that hill in that driveway at the old house until around 40c otherwise haha

I tried to adjust the injection timing as suggested but I made a table that has ECT as the Y-axis. When the engine is warm a timing of about 400 works best in the idle range. I have verified this by observing the AFR and transient response.
But things seem to be very different when cold. When I dropped the injection timing by 90 deg I noticed a drop of lambda value from 0.86 to 0.77 and the transient response was improved. The PW was constant.
I should try the ign cold advance as well. I pre viously had good results with my motorcycle (e85 too) wiith MS2.


Here's what I think:
When the engine is warm the fuel is injected on the hot intake valve (& port). This vaporizes the fuel just before the intake valve opens. But when the engine is cold, injecting to the closed valve does not help the vaporization, instead the fuel sticks to the valve & port walls. So the best way to get a biggest amount of fuel in to cylinder is to inject on the open intake valve. Smaller value means that fuel is injected later since its "BTDC", right ?

Hi, These are my first impressions too, this table here helped clear it up for me.
credit to David V for his testing and ideas.

You could try adding neutral status DI5 to the Y axis of the ignition idle table. Add some timing when in gear and drop the neutral step from 22% down to say 10% and see what that does. 

Hey people, 
Just thought I'd post up a quick note about something I did recently that worked out well.

I was wanting to optimise ignition timing for cruise, so using some switches on my dash to trigger a combination of datalogging, 4D ignition, 5D ignition and the 2nd ignition table set to overlay mode.

With the idea that I could add or remove timing from the main table in varying amounts without having to stop the car, and datalog the whole lot easily.

Like so: 



Since you can turn on more than one ignition trim table at once, using those three you can get a combination of timing settings which I then marked on the switches. 

So +1 degree, + 3 degrees, +5 degrees, etc. 
I completed a run on a particular stretch of motorway that has lots of ups and downs, with cruise control turned on at a speed that's at 3250rpm in 6th gear.
Then flicked the first switch, did it again.
Flicked second switch, did it again, and so on. 

When home looking through the data, bringing up a time plot with instant fuel consumption and throttle angle it was very easy to see which timing gave best economy. 


However a secondary method of checking fuel consumption overall is to create a "statistics" page and bring up wheel speed and instant fuel consumption, and look at the mean values:


Then from here I've made a quick excel sheet that converts it to Litres per 100km:



Then from here, collated the results from each run.


So based on this it's pretty clear that an additional 9 deg advance made the engine pretty happy on those particular cells, so updated my ignition table and readjusted some of the surrounding cells to more sensible values too.

It was a fairly time consuming exercise but it's amazing to see how much fuel I have been throwing down the toilet just based on under advanced ignition. 
It was also interesting to see that at 100kpa my car only has 14 deg ignition at that rpm, but then by 70kpa it's wanting 33. (The goal AFR changes though, to be fair... 15.2:1 goal AFR for cruising)

Since changing the timing the car is a lot quieter too! 
I am guessing because when you dont have enough timing, the flame front is still expanding when the exhaust valves open. So instead of having energy push the piston down, it's coming out the exhaust as noise and heat. 

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. 

The more common way to do it is as per your swindon picture, your primary injector would be after the throttle so there can be no "pooling", the secondary outboard injector would only activate at WOT.  
 
http://www.supertouringregister.com/register/vehicle/96/

The Silver xtreme does in fact have E-throttle built-in. 
Cruise control is not available in the G4, so we can scratch that one off the list.  Another function E-throttle is really nice for is anti-lag but that is not relevant in this case.
So that leaves two main benefits;
The multiple target tables like David mentions.  Wet/dry or husband/wife setting etc. The other one David touched on but may not be clear to those who dont know;  Many engines will perform better with a smaller max throttle openings at some RPM's.  For instance you may find at 3000RPM your engine makes more power with 85% throttle than it does with 100%.  With E-throttle you can command a different "WOT" value for different RPM's. On the flip side, compared to a cable throttle, E-throttle uses up 3 more analog inputs, wiring is a little more complicated, and requires a bit more tuning time.  

+4 
I'd like to change the default save folder to my Dropbox folder, so as soon as I get within range of wireless it'll automatically back it up, and I can then view it on another machine with a better display.

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?

Yes, I highly suggest you use the Link for this test as I suspect our injector driver circuits are probably different than a MS2 and this can have quite an effect on dead times.  
See this post here for a bit of an idea how another user tested deadtime and short pulse width adder  (Roman is user @Davidv on the Link forum):  https://oldschool.co.nz/index.php?/topic/21624-romans-beams-3sge-toyota-carina/&do=findComment&comment=1688039  Im sure he had a similar post on this forum but I cant find it.

My arduino based canbus box thingy has escalated into a digidash haha. 

So 3d printing a housing that will mount up to standard points and accept the standard loom plugs for power supply and so on. 

Lots of work left to do, but will be cool.


 

Hi guys,
In the next update, I want the MAF table to be able to use cal 7 - 10.
If possible, please increase the number of grids in the table from 16 to 32.
regards,

Oh hey! 
Havent been up to much with the car lately... I moved to the South Island to take a job in the motorsports industry, so funnily enough I actually ended up moving right near that track shown on the post above. 
It was awesome down there, but some life complications meant I needed to come back.
Some interesting stuff has happened between now and the last time I posted though I guess...

Firstly I had the windscreen smash which was fun! 



Then I competed through the time atttack series which was good fun, cut a little bit short by me moving away. But I was determined to make my "Street class" car as streetable as possible... Drove it to-from events and even used the car for camping near the events.



At one of the events I had one of the outer injectors in my staged injection setup fail - due to a rusty fuel tank and blocked up fuel filter which obviously let some debris through. 
So I had to roadside retune the car back to primary injectors only, then set a new fastest lap once the engine was running right. 
Since then I switched to a Seimens 850cc "shorty" injector, this gives me more clearance to the bonnet which was needed.
I made up some MSpaint style stickers for the numbers that I needed for the race series, also at the event furthest from home (about 6-7 hours drive) I ended up having the front universal joint in my driveshaft explode which sucked! 



Ended up getting towed all of the way home by some friends who unloaded their car off the trailer so I could get home. Which was much appreciated.

On the ECU side of things, I've got a few changes to plan coming up. 
I have just been working through populating the table to run my tacho as a combined tacho and fuel economy meter, using virtual aux conditions to switch between them automatically depending on what the car is doing. 
So currently I am thinking that when RPM is between 2000 and 4000, rate of acceleration below (something) and speed is above say 60kph the tacho switches over to the fuel economy meter. 
I dont see a way to achieve this apart from wiring two auxiliary outputs to the same tacho input, and switching between them using virtual aux. But I've got some left over so that's fine. 
I also want to setup something using CAN, I have been meaning to double check the accuracy of my analog wideband input so I might kill two birds with one stone and buy the link Can wideband module some time soon.
I've got a lot of DIs left over so will be looking at setting up wheel speed sensors as well, it will be interesting to see how much my LSD is slipping or locking under different circumstances.
It will be interesting to have a play with the traction control system when this is setup, not that a car with this power level particularly needs it. Might come in handy on wet trackdays though! 

I saw a cool idea where someone was using a K type thermocouple dragging against a brake disc to measure brake temperatures. I've been meaning to get some temperature paint or similar to find out how hot the front gets, as I wear out brake pads quite quickly. 
So for sake of interest I might do something similar while I'm setting up wheel speed sensors. Or maybe even a K type just sitting against the brake pad, I guess that's really what you're trying to measure and prevent from overheating.

It might also be fun to setup 4x EGT or 4x wideband, one for each runner but would look at doing this with a CAN based solution.

Apart from that not much else going on, just driving the car and enjoying it.
I like having the car NA and fairly simple but realistically for the time attack stuff I've been doing this means my car is mid pack at best. 
It's heeaapppss of fun though, with some great people and I still wince at the extra engine bay complication of forced induction. As the whole point of this car is to keep things simple. 

I have been having some thoughts lately about starting a new build using maybe a Suzuki cappucino or a Honda Beat. 
Just because they are awesome, and I like the gimmick of tiny cars. Both options will most likely be slower than my existing car haha.
Maybe a Toyota MR-S or similar would be a more sensible starting point.
(Or just go on holidays to Fiji etc instead and enjoy the car I've got!) 

I've had a bit of a side project going on, I've wanted to learn about canbus so I bought an arduino and a canbus shield. 
Using some of the examples of code found on the net, managed to get frames both sending and recieving. I've never coded anything before so I had a few blunders like using = where I needed == and so on haha.

I'm using another shield on top of the canbus one that runs a screen, and have put together a box for it all.

The goal is to have the 4 pots control trim tables for goal AFR, ign timing, cam timing, and injector timing. So when I have cruise control turned on, I can quickly go through a lot of variations and have a graph showing fuel economy on the screen. 

I can also write a fuel economy value back to the ECU as well, and then have that log into the ECU's logs so that's cool.

Currently my car gets around the mid 7 litres per 100km mark, and I'd like to see if I can drop it into the sixes.

I'm most of the way there to finishing this thing so hopefully not too long till I can have a play around. 

I am thinking that for version 2.0 instead of pots I will have rotary encoders and then build an array which will act like a load vs rpm based trim table for each of the different areas. 
So it will hold the values in that area without affecting the others. It's a bit more complicated though so I'll just get this running as is for now.

Since I run 98 octane and MBT is quite far away from knocking I have also been thinking about using a feedback loop where the arduino adds a few degrees timing, see if this positively or negatively impacts economy, and then either reverts or keeps change. Then repeats, and maybe hones in by a smaller change each time. But I think that might work best once I've got some arrays setup, rather than just blanket applying a trim table to everything.