nitrousnrg wrote:I have a crank and idle algorithm, but that never conditioned me with table sizes (should it?).
Kind of, yes. If you didn't have such algorithms, you would need more width in the table to cover that region.
I think #2 is a mid term, between too turbo and too N/A (slightly in the N/A side). I prefer to have more flexibility in the RPM axis. Anyway, you have plenty of cells to fill, interpolations will be accurate enough. 17 load points sounds good to me.
My second choice was #4..
I'm erring on the side of number four at the moment. I drew some code up for that earlier, but it's easy to change anyway. With 4 you have 16kPa steps from 0 - 304kPa and 350rpm steps from 0 - 8050rpm.
I picked #4 i like to have plenty of load sites and if i fell this is too much i can just fill in the last few columns with the same values as the last used rows better to have too much than not enough.LOL
I use two tables right now 16x16 ( one TPS based and one MAP based) and it seems to work real good on the bike i use a slave for the secondary injectors with its own 12x12 fuel table so 3 fuel tables in all for a 1.3L motor with individual throttle bodies and a big honking turbo.LOL
For the basics right now it should be fine and still have plenty of resulution for the guys who need more for boosted apps.
Yeah sorry about that Fred im been super busy trying to sort out this bike stuff and i havent had time to come on and contribute much .
Everything is looking great so far though ( i still need to get my butt in gear and purchase the adapt board as im excited to do some testing) .
Yeah the fuel tables should be fine either way but for some motors they like bigger tables excpecially high boost high reving motors like these bikes have, tunning from 0-13,800 rpms then throwing some boost on top of that, it take some careful placing of bins to get them tunned with some resanable range ( considering the stock ECU has around 24 or more maps)
Tony wrote:Yeah sorry about that Fred im been super busy trying to sort out this bike stuff and i havent had time to come on and contribute much .
Not at all, don't worry about it, it's still all software for the moment anyway, though soon there might be tuning app to firmware serial comms to test :-)
Everything is looking great so far though ( i still need to get my butt in gear and purchase the adapt board as im excited to do some testing) . :twisted:
That would be sweet, you can be number 5 (remember that movie lol)
Yeah the fuel tables should be fine either way but for some motors they like bigger tables excpecially high boost high reving motors like these bikes have, tunning from 0-13,800 rpms then throwing some boost on top of that, it take some careful placing of bins to get them tunned with some resanable range ( considering the stock ECU has around 24 or more maps)
You are actually the IDEAL person to take advice from in this thread as the most extreme application I can think of is boosted cammed ITB turbo bike, and you have practical experience with exactly that. I'm glad my gut feeling matched your practical experience :-)
Hey no problem really it applys to all motors ( that i have tunned any way ) just some require more work than others.LOL
For my project's the fuel tables should be fine and i really cant see where in any engine that having a bigger fuel table could hurt anything at all minus having more bins to tune but EFI isnt suppose to be a 5 minute job then your done ( atleast not for me i cant leave nothing alone.LOL).
I just had a cunning thought inspired by some other gentlemen discussing resizability. My algorithm handles it just fine so Thats no issue. The idea is that instead of just sizing the table to one and using the spare space for something else, I size it to the largest reasonable pair and size the axis arrays to the largest from each set such that any subset is available :
#define MAINTABLE_RPM_LENGTH 24 /* How many cells on the X axis */
#define MAINTABLE_LOAD_LENGTH 19 /* How many cells on the Y axis */
#define MAINTABLE_MAX_RPM_LENGTH 27 /* How many cells on the X axis max */
#define MAINTABLE_MAX_LOAD_LENGTH 21 /* How many cells on the Y axis max */
#define MAINTABLE_MAX_MAIN_LENGTH 462 /* 924B 462 shorts maximum main table length */
/* Use this block to manage the main VE and Advance tables */
typedef struct {
unsigned char RPMLength; /* The length of the RPM axis table */
unsigned char RPMLengthMax; /* The max length of the RPM axis table */
unsigned char LoadLength; /* The length of the Load axis table */
unsigned char LoadLengthMax; /* The max length of the Load axis table */
unsigned short RPM[MAINTABLE_MAX_RPM_LENGTH]; /* The table of RPM (X) axis values */
unsigned short Load[MAINTABLE_MAX_LOAD_LENGTH]; /* The table of Load (Y) axis values */
unsigned short Table[MAINTABLE_MAX_MAIN_LENGTH]; /* The actual table of values */
} mainTable;
Which is even more flexible and still just the same size, but has no ID field (which was a waste of time anyway)
Its very simple you want as big a map as possible to cater for ever eventuality
if you are lazy and don,t want to spend the ten minutes it will take to fill in suitable mapping points ,then what are you doing even messing about with a DIY ecu .
the point of having as big and adjustable mapping points in both axis is the ability to set the exact points ,and maybe gouping some at closer rpm /load values you want without comprosing some other part of the map .
idle althouhg you are going to have idle on these maps is a perfect example ,but when you have picked the point at which you change from the idle map to the main map ,then there will still be a cross over area .
every engine I have ever worked with has a "black hole" somewhere inthe map wherethe timings /fuelling need to be significantly different to the points either side .
this is caused by the inevitable effect of induction length ,cam spec and ex manifold lengths .
yes you can do all the working out from books which will give you formulaes for correct lengths to maximise torque or top end bhpby altering the lengths of induction and ex primary lengths and primary sizes ,collector lengths ,etc,etc
a typical example is a car which if you only map every 500rpm you can miss the blackhole altogether as it may only last for 5-800rpm .
I have seen where a good engine giving exceptional power had a point where the power actually dropped 20bhp iat 5600rpm ,then by time it got to 6100 it had come back and actually continued up at rate you would expect,so the graph when plotted every 500rpm looked a nice climbing line .
It was even hard to feel when driving as the car accelerated so well that you were through the "hole " very quickly .however when the same car was dynoed using dif log points ,IE go to an rpm --hold then log bhp ,not an inertia run ,It was very obvious .
car was then remapped around "black hole" by closing up mapping points between 5+6k --
the result, whilst not seeing any bigger bhp at 5+6k , was another 1/2sec a lap -due to the way the car drove .
you couldn,t feel it when it was there ,but you could notice the dif when it was mapped out.
Now if you have fewer mapping points you could not have corrected this without loosing defination at other points.
whilst I am here a very handy function would be the ability to save all values form one map --then being able to rescale and being able to dump values from last map into any points that were available on previous map .
I have seen some ecu,s where you can do this if you change injector sizes which sort of work ,but never spot on ,but not one that you could do what i am proposing --and because of this alot of black holes won,t be fixed due to time to totally remap once you change the mapping points.
so yes bigger the better --needs to able to be fully free value insertion .
If you don,t need the defination then an interperulation function so you just state upper and lower map axis values--then it won,t take more than 10secs to do the configuration any way.
you cannot have too much data or configurability -the more you have the better the outcome will be and the less drastic the interpulatins from one point to another
I choose no.6 the reason is that once rpm is well up and into serious power then the dif in fuel and ign gets smaller the higher rpm /load you go and no one is going to do it properly anyway ,but load points at part throttle and low rpm make the drivability
Last edited by johnd on Sat Jul 05, 2008 6:23 pm, edited 1 time in total.
"Yeah the fuel tables should be fine either way but for some motors they like bigger tables excpecially high boost high reving motors like these bikes have, tunning from 0-13,800 rpms then throwing some boost on top of that, it take some careful placing of bins to get them tunned with some resanable range ( considering the stock ECU has around 24 or more maps)"
this is a slightly different problem as i doubt many people will have a dyno to run the engine at high boost long enough to stabalize the fuelling or advance ,say 4 seconds at each point,and even less will have a big enough intercooler /engine cooling to hold it there so it doesn,t fry.--
In the real world this is where a "proper w/b unit which can correct within 30millisecs is what you want (gems)--this is why i consider w/band to be even more essential for tuning the car on the road ,as you will not be at any single load point for very long .
especially a motor bike --standing 1/4 in how many secs? 7maybe?,so trying to load it up on a specific point is going to near impossible by the time its on boost ,the transient maps are what you will be using more than actual mapped ponts under load. and transient are supposed to be just that an addition to the base map same as water and air temp /baro corrections,so all you se in the main map is actual base numbers
It actually would make more sense for most to have maybe 6 or 8 points around expected idle for rpm/load and do the idle on the main map ,which of course would be very possible if the maps are larger enough ,then you only need a cold start /cranking map to be seperate.
the old weber alpha used this approach and it worked very well and if set up right was very consistant in real use .
I leave how you make this happen with your coding up to you--I know nothing of such things-don,t want or need to .
I only know what you need for a real engine and what functions of software make life easy
johnd wrote:transient are supposed to be just that an addition to the base map same as water and air temp /baro corrections,so all you se in the main map is actual base numbers
Have to step in and correct you there. air temperature is integral to the speed density system. Without it your calculations are not complete and have no meaning. It is not a correction any more than MAP or RPM are.
Secondly, the majority of transient fuel corrections are for change in airflow due to throttle movement, not RPM. Thus at WOT running from 1000 to 15000rpm you won't be using them much or at all. However going from trailing throttle to full throttle they will be used maximally. There is more to it than even that though. If the readings are taken accurately and JIT (Just In Time) then the need for transient corrections is GREATLY reduced. My aim for our system is to take readings JIT and therefore be about as accurate as possible with regards knowing what is going into the cylinders for that cycle. In this way the need for transient correction should be almost eliminated.
Which sensor element to GEMS claim is giving them 30ms response?
