Table resolution and size

[ChevytoyR1]

heres what Holley uses
http://www.youtube.com/watch?v=qwkqjotkDJQ

[gurov]

heres what Holley uses
http://www.youtube.com/watch?v=qwkqjotkDJQ

that's pretty d*** cool.

[jsmcortina]

Isn't it totally reliant on what AFR number the tuner picks though? Bruce was saying in his wideband presentation how everyone "needs that number" whether it be right or not.
32x32 yuk.

James

[elaw]

heres what Holley uses
http://www.youtube.com/watch?v=qwkqjotkDJQ

that's pretty d*** cool.

As far as coolness goes, you can have their software but I'll take the dyno!

[tpsretard2]

32x32 yuk.

James

you can say that again !!!

[muythaibxr]

Yeah, a table that big is completely unnecessary, auto tuning or not.

Ken

[prof315]

agreed

[Gokart]

I don't care how many cells the table have as long as I can make a podium finishes.

[coyoteboy]

Yeah, a table that big is completely unnecessary, auto tuning or not.

Ken

Multi-million pound OEM ECU development teams disagree though. While interpolation may work if the engine has a linear response between two cells, they don't when looked at in fine enough detail. Maybe if you want to gloss over the minor improvements that can be made, but then why not stick with MS1, and while you're at it stick to non floating point timing values - 0.1degrees is overkill anyway, whole degrees is fine, and it can interpolate... Hell, why not stick to 5 degree increments...

Another slant is that while it may have rows, or columns, of the same value bin after bin and appear to waste space, it's 2D - the gradients on the map change differntly with differing load/rpm trends. Sure you can cleverly pick your axes to place them as well as possible around the gradiented points, but why limit and require compromise when it's a piece of cake to implement bigger tables and accept some bins in some areas will be containing similar values. On my 12x12 maps I'm begging for more resolution in a couple of spots but can't get it as I need things like a timing ramp at low revs to catch idle due to light fly. Seems like missing a simple and easy to implement train to me.

[muythaibxr]

If you're on MS1, you're also fighting with a slow CPU with low VE resolution and a whole bunch of other factors.

Again, as I said on the first page of the thread, show me the proof that more than 16x16 is necessary. I have yet to see any proof in the 1.5 years this thread has been open. All I've seen is anecdotal evidence at best.

Ken

[richyvrlimited]

I'n not particularly fussed either way as to the size of tables, as long as it works I'm happy.

However why isn't 'what OEM's do' enough evidence for you?

You copy the way they control idle, so why not fuel & ignition tables?

[24c]

...
You copy the way they control idle...

I don't know if copy is the right word, because idle controls systems have different control strategies depending on their type. If you are making an ECU that has to work with these existing systems, then your controlling methods are predetermined and are bound to be similar to OEMs by circumstances out of your control.

The other thing that springs to mind is the marginal utility of doing something more, as if what you have works for most, why compromise that or complicate things unnecessarily catering for a smaller perceived need.

Besides all this table resolution debate reminds me of GHz/processor wars in computer adverts of the past, not enough about what are you going to use it for and is it suitable, but more about hitting high numbers.

[BenGTT]

I'n not particularly fussed either way as to the size of tables, as long as it works I'm happy.

However why isn't 'what OEM's do' enough evidence for you?

You copy the way they control idle, so why not fuel & ignition tables?

I don't think Ken is copying OEM's code, but he want to make the code so the behaviour will be similar to OEM's and for me that's the right way. For the tables resolution, I know many 90' european cars that were running with ecu that have 9*13 or some 13*13 ve AND spark table. They were and still are running great even turbocharged ! Some peaple are even tweaking those ecu's to make them work with GM 0-3 bar instead of oem 0-2 bar map sensor. So interpolation is even bigger.

Having 12*12 for spark (ms2) and 16*16 for VE is most all the time enough. In addition, I have worked with several other brands of EMS and tuning large tables on roads can be a really big pain for the driver, the tuner AND the car (the brake).

The most important for me, are the settings beside the maps (open time, correct dwell etc) all those characteritics are sometimes hard to find from oem's but when correctly filled, you have sometings working great and accurate.
Important improvement are also coming from the work we don't see like the new mapdot code or Rob's work to improve mainloop time.

I can hear here in France that MS is not capable to drive correctly low impedance injectors, I don't agree with them. Yes there are some tweaks to do on the v3 boards, but most of the time the problems are settings of bad assembly done in the back of the garage...

Ben

[richyvrlimited]

Yeah sorry I didn't mean to imply Ken had copied the code, just that he's cloned the way it works.

[coyoteboy]

Again, as I said on the first page of the thread, show me the proof that more than 16x16 is necessary. I have yet to see any proof in the 1.5 years this thread has been open. All I've seen is anecdotal evidence at best.

But there's no way I could present that (though I could spend an afternoon rifling through some papers to see what I can find) evidence as I'd need to have exactly the same car on exactly the same everything except differing table sizes otherwise there's too many factors involved to call it a fair trial. I'd have to modify the MS code and run two copies of the firmware, then spend the time dyno tuning the two - I dont know anyone who has that sort of free time and cash. It doesn't mean the point is incorrect though. If 16x16 were fine, why would OEMs go higher? There would be no point, the vehicle manufacturers would say "but you don't need >16x16, stop giving us this unwanted extra map space and do something more useful. I can't see that OEM EFI system manufacturers try to hype their product over other peoples by claiming bigger tables if the guys designing the engine already know bigger maps don't help.

My thought would be that it's known other people go for bigger tables and without the ability to prove against the point, and with it being easy to implement, it makes sense to do so rather than not. I recognise the bigger maps are scary and take longer to tune for minimal gains, but if you're trying to make a great ECU that's something you need to consider. IF you're trying to make a DIY home user ECU maybe 16x16 tables are fine but then the MS3 price tag is relatively large for the average joe.

[ChevytoyR1]

just like u guys want proof that a bigger ve table would be better or make more power or what not ... can u guys give us proof that bigger ve table wont be better? unless uve tried it and have proof that is useless than u cant say it isnt better or wont help.. the option should be there.. unless u can back it up that isnt needed with a comparison of a smaller ve table vs. bigger ve table with same car, engine, fuel, hp dyno, and track times, then u can show us results that the bigger ve table didnt make a diffrance then this topic wouldnt be here...

btw does anyone here have their ms2 12x12 fuel ve table turned on? lol

[racingmini_mtl]

Again, as I said on the first page of the thread, show me the proof that more than 16x16 is necessary. I have yet to see any proof in the 1.5 years this thread has been open. All I've seen is anecdotal evidence at best.

But there's no way I could present that (though I could spend an afternoon rifling through some papers to see what I can find) evidence as I'd need to have exactly the same car on exactly the same everything except differing table sizes otherwise there's too many factors involved to call it a fair trial. I'd have to modify the MS code and run two copies of the firmware, then spend the time dyno tuning the two - I dont know anyone who has that sort of free time and cash. It doesn't mean the point is incorrect though. If 16x16 were fine, why would OEMs go higher? There would be no point, the vehicle manufacturers would say "but you don't need >16x16, stop giving us this unwanted extra map space and do something more useful. I can't see that OEM EFI system manufacturers try to hype their product over other peoples by claiming bigger tables if the guys designing the engine already know bigger maps don't help.

My thought would be that it's known other people go for bigger tables and without the ability to prove against the point, and with it being easy to implement, it makes sense to do so rather than not. I recognise the bigger maps are scary and take longer to tune for minimal gains, but if you're trying to make a great ECU that's something you need to consider. IF you're trying to make a DIY home user ECU maybe 16x16 tables are fine but then the MS3 price tag is relatively large for the average joe.

That argument (easy to implement) always makes me laugh when it's coming from someone who hasn't seen the code. Sure it's easy to set an array bigger in the code but that has many hidden implications. And since a very high percentage of the people using MS3 will not have the tools, time, money to fill a 32x32 (or whatever size you mean) map or even have a setup that would benefit from this, that would annoy most of those people when it comes time to tune. And if you want to have variable size map to please everyone then the complexity of the code and maintainability increases a lot.

And the proof doesn't have to be from a back-to-back comparison but from a single actual map of a real engine to show how you couldn't fit it in a 16x16 table. Using the arguments of what the OEMs use is also not very useful in my view since they have constraints that no one else has and a lot of what is in their ECU is there to pass some government test. I'm sure that if they were simply tuning for best power and efficiency, their ECUs and maps would be much simpler.

Anyway, that's just my opinion and since I don't develop the MS3 code (or even use one) it won't have any impact on what happens. But please refrain from using the argument that it's easy unless you are the one having to deal with everything that comes with the "easy" change.

Jean

[Matt Cramer]

Why do the OEMs use huge tables? I suspect the biggest reason is emissions. I get the impression that California emissions rules mean what's coming out of the tailpipe has to be cleaner than the air that's coming in the intake on a smoggy LA afternoon, so the OEMs really have their work cut out for them there.

ECUs with 32 x 32 - and sometimes even larger - tables have been out long enough now that if there's an advantage to be had with one, I'd expect someone to post a map that actually can't be shrunk to a 16 x 16 (or 16 x 30 - this can be done with the current MS3 code using table switching). Ken and James are asking those who want larger tables to present proof that they have a valid reason for needing one, and I don't think that is an unreasonable request.

[muythaibxr]

Haha, I am sure I have plenty of users with datalogs that show that larger than even 12x12 is unnecessary.

Even if there really are OEMs that have larger tables, I have seen recent cars with tables from the OEM that have similarly sized tables to us (Mazda for example, I do not remember how many it was exactly but if it was more than us, it wasn't by much).

Even in the Holley video above their autotune software is changing more than just the 4 bins being used. It is changing a huge number of bins at once. That tells me that many bins are unnecessary. If they were necessary, why aren't they direcly tuning every bin, or at least the current 4 bins surrounding the spot they are tuning.

If you REALLY like tuning a lot of bins, try using table switching + blending... that could give you around 30x30.

So again, post msq's/datalogs that show 16x16 isn't enough. No need to change code, just send an msq and datalog showing that AFR around a nonlinear point (with bins close enough together) could not adequately be controlled on a dyno-tuned engine.

Everything I have seen thus far just shows me that huge tables are a marketing gimmick.
Ken

[hassmaschine]

just like u guys want proof that a bigger ve table would be better or make more power or what not ... can u guys give us proof that bigger ve table wont be better? unless uve tried it and have proof that is useless than u cant say it isnt better or wont help.. the option should be there.. unless u can back it up that isnt needed with a comparison of a smaller ve table vs. bigger ve table with same car, engine, fuel, hp dyno, and track times, then u can show us results that the bigger ve table didnt make a diffrance then this topic wouldnt be here...

btw does anyone here have their ms2 12x12 fuel ve table turned on? lol

I've used 16x30 and even 16x45 with MS2. It's definitely uneccesary - I ran with 16x30 for a long time, the 16x45 (blended + switching) was just to see if I could do it. with MS3 I went back to a 16x16 table, since large areas of my 16x30 map were flat, and the flatter areas were actually more jagged than they needed to be due to too much resolution.

and there is definitely no power increase from a large table, that's totally silly.