Table resolution and size

[muythaibxr]

OK so here's the plan for ms3:

VE tables are going to be 16x16 with no more option for 12x12. We are going to make the VE values 16-bit numbers. that means the ability to tune VE to 0.1%. This means no more need to reduce reqfuel to gain ve table resolution. We will also be increasing the main spark tables to 16x16.

We will not be going any larger with either table once we have done that. Anyone that thinks there is a need please provide data with real proof that a table larger than 16x16 would help.

Ken

[jsmcortina]

The table size question "my ECU has bigger tables than yours" has been a stated "problem" for years. As Ken says basically we don't believe it and think that the larger tables are mainly a function of the marketing machine or poor software that doesn't interpolate rather than a real need.

So now the gauntlet is laid down !

Feel free to post screenshots from other ECUs, you can erase their name if you wish as this is intended to be an objective discussion not some ECU war. We want to see well tuned fuel or spark tables, not some random number game.

James

[MS2mercury]

bosch motorsport
24 * 20
http://www.bosch-motorsport.com/content ... l/3589.htm
could maybe give some other ideas to

[tpsretard]

Well GeMs ecu's which are well known in the world of WRC with Subaru and mitsubishi are 14*19

If that is good enough for them, i do not see why 16* 16 is not good enough for us.


16* 16 make it so captain.

[racingmini_mtl]

Even though I don't think it's needed if you go to 16x16 with 16-bit values, you probably will have only one table per 1K page so you might as well go to the limit that this will allow. That would mean something like 24x19 would fit in the 1K page (998 bytes with the rpm and load data).

But the only reason for that would be to optimize the memory use and satisfy those few who do need the bragging rights (and it's more than what's currently available on MS2 so it must be better...).

Jean

[jsmcortina]

Just to be clear, I'm not interested in just a screenshot of a large VE table, I know what they look like.

I saw an ECU at the weeked that had a fuel table about 20x20 - the car ran like a dog and achieved 3mpg. Not very impressive.

What we want to hear is REAL EVIDENCE of a need for anything larger than 16x16. Datalogs showing rapidly changing VEs that cannot be accomodated by interpolation between values. (Can you believe that some ECUs do not interpolate?)

James

[muythaibxr]

Even though I don't think it's needed if you go to 16x16 with 16-bit values, you probably will have only one table per 1K page so you might as well go to the limit that this will allow. That would mean something like 24x19 would fit in the 1K page (998 bytes with the rpm and load data).

But the only reason for that would be to optimize the memory use and satisfy those few who do need the bragging rights (and it's more than what's currently available on MS2 so it must be better...).

Jean

On ms3 we do not have the same paging limitations as ms2 so there is no need to do things just to fill a page. Plus 16x16 is already a lot of tuning (which is why we want real proof that larger is necessary)

Ken

[racingmini_mtl]

On ms3 we do not have the same paging limitations as ms2 so there is no need to do things just to fill a page. Plus 16x16 is already a lot of tuning (which is why we want real proof that larger is necessary)

Ken

It's good to hear that there isn't the same paging limitations but there's still the 1K unit in the flash, isn't there? But that 's OT.

So I agree that 16x16 should be sufficient. It seems that higher numbers are necessary only due to software limitations or tuner limitations. I'd be interested to see a table proving otherwise that isn't the result of badly mismatched components.

Jean

[muythaibxr]

On ms3 we do not have the same paging limitations as ms2 so there is no need to do things just to fill a page. Plus 16x16 is already a lot of tuning (which is why we want real proof that larger is necessary)

Ken

It's good to hear that there isn't the same paging limitations but there's still the 1K unit in the flash, isn't there? But that 's OT.

There is also no 1k limitation because we have enough ram and d-flash to avoid things like that.

Ken

[jeremydde]

If you have the capacity to increase the table size now then why not? Is there a difficulty/compromise in programming that warrants this discussion?

I have tuned many honda engines running large amounts of boost (25+ psi). These engines have large turbos and injectors for their displacement. These engines also run as high as 12,000 rpm. If I was forced to try to tune these engines on a 16x16 table as opposed to the 24x20 that we have there would definately be some compromises in economy and emissions tuning as well. There would be considerable interpolation needed to make this work. The fuel differences between 10psi and 20psi can be extreme, and certainly not linear. In fact these fuel curves would more fit an exponential curve in this case rather than a linear curve. In this case a linear interpolation wouldn't work. The compromise would have to be running richer in higher bins. It is well known that a turbo's efficiency increases up to a certain point given their size. Engines running very large turbos don't flow enough air at low rpm to spool the turbo. These engines will have a linear increase in fueling requirement right up until the boost spikes up. Once this happens there would indeed be very large VE changes. These engines need larger table sizes. Also, how would you divide 0-12,000 or even 0-10,000 rpm across only 16 cells? Any wild cam may require a more focused set of bins surrounding any given rpm area which would take away from the obvious idle area concentration of bins as well.

Well GeMs ecu's which are well known in the world of WRC with Subaru and mitsubishi are 14*19

If that is good enough for them, i do not see why 16* 16 is not good enough for us.


16* 16 make it so captain.

If this is acceptable in a race situation where there are no emission testing or laws then 16x16 would be just fine too I suppose.

If the table size can be increased further and thus eliminate the need for table switching for increased resolution, then by all means why not? Yes larger tables take longer to tune, but then again autotune doesn't care how many cells there are to tune either does it? Besides, of all the enhancements and upgrades that MS has seen in its menus, an increased table size wouldn't need any documentation or further explanation. Just my 2 cents.

Jeremy

[jsmcortina]

Please provide tables and logs supporting this assertion.

James

[jeremydde]

Please provide tables and logs supporting this assertion.

James

This engine hasn't seen more than 25psi yet. I don't keep logs for anything, so I have no logs to post. However, these engines are both consistently at 11.8 AFR in boost above 5psi.


This engine has been running daily at 25psi for 2 years on pump gas (94 octane).


The point I was making is that with less cell resolution, the iterpolation between points would be far too great.

I am looking for a map I did for a turbo subaru that was running on link ems that suffered horribly from too low of cell resolution.

[jeremydde]

Sorry, I rescaled the photos down some more, but they keep showing up on here at full size. You'll have to right-click and save as to view the entire table. I also couldn't find the link map yet.

Jeremy

[jsmcortina]

What are the units?
It _looks_ like that ECU is not factoring MAP into the fuelling equation hence the very large range of values.

(EDIT: added the following)
Looking at the lower table.
As shown up to column 15, the table has a range of 82 times (1816/22). If I recalc the highest and lowest as if MAP was factored in to the calculation, the highest becomes 1023 and the lowest 180. The range then becomes 5.6. This would make interpolation significantly easier.
Is this tune perfect? I notice what appears to be an inconsistency at 6032/6056rpm and 97.3kPa (if I got the units right) as the fuelling numbers seem swapped if I follow the trend of the surrounding ones.

James

[jeremydde]

What are the units?
It _looks_ like that ECU is not factoring MAP into the fuelling equation hence the very large range of values.

James

I'm not sure that I understand your question? The top scale is the map (x-axis) and the y-axis is rpm. This is a standard load vs rpm fuel map.
You can see that the fueling definately isn't linear once boost kicks in. If you were to lower the resolution of the map you would have to compromise in some area. I have seen this over an over, and I have worked with Motec, AEM, Link, Tec3, Wolf, Utec, Split Second, etc. etc.

Jeremy

[jsmcortina]

As I posted though, MAP isn't being included in the fuelling equation which is causing a very large spread of numbers in the table. I added some more info to my previous post.

James

[muythaibxr]

What are the units?
It _looks_ like that ECU is not factoring MAP into the fuelling equation hence the very large range of values.

James

I'm not sure that I understand your question? The top scale is the map (x-axis) and the y-axis is rpm. This is a standard load vs rpm fuel map.
You can see that the fueling definately isn't linear once boost kicks in. If you were to lower the resolution of the map you would have to compromise in some area. I have seen this over an over, and I have worked with Motec, AEM, Link, Tec3, Wolf, Utec, Split Second, etc. etc.

Jeremy

As far as I know none of those factor in MAP. Doing that dramatically reduces the range of values required. If you further divide tbe numbers by 4 It would easily fit in our standard 0-255 16x16 table. Any spots left with sharp increases could be handled with our movable bins.

Ken

[jeremydde]

The tunes are very close to where they should be. You are looking at high cam maps. Not alot of time is spent perfecting out of boost in high cam because the engine almost never sits in there. To hit these areas you would have to accellerate so slowly above 50% throttle above ~5500 rpm while not boosting to hit some of those areas.

So if what you are saying is that you could potentially with some math scalers and req fuel, reduce the difference between the highest and the lowest, thus minimising any abnormal areas with a 16x16 table then that's great. But thinking ahead into the future, this may become more of a problem with variable cam timing and variable lift. If you need to focus your bin values into too many areas (idle, peak torque, variable timing crossover, variable intake runners, etc) then you could still potentially need more bins. If you guys are at the crossroads whether to increase table size then you know where I would vote. I'm not trying to make your programming any harder, as I am far from a programmer, I'm just trying to give you some real world experience. I hope that others will chime in some more as well. There has been a number of occasions with various ems units that I have felt the need for increased resolution with more bins, especially when very large injectors come into play.

Jeremy

[muythaibxr]

Your input is noted. We were saying that everything you talked about (reqfuel, scaling) is true and in addition we will be doing VE to .1% units, which should yield more than enough resolution. I have heard the argument you present but I need to see datalogs and settings. Not because it is difficult to program (it isn't really) but because we need a very good reason to take up space that could potentially be used for other data.

Ken

[FSG_PB_Patrick]

Concerning high rpm engines, from my expierence within Formula Student, I think that 16x16 Tables are fine. Our 2008 FS car ran a MS1 with 8x8 and reved until 12000RPM with flawless stable lambda values and the higher you rev the more stable it becomes.
If there really are fast changing VE values at high rpm, it's nearly impossible to react on or finetune. We expierenced something like that on the engine test bench in march. The cams were customized by an external company and unfortunately trimmed for torque at mid RPM range. By chance we had a runner length installed which seems to be close the resonance frequency of the valvetrain, means under WOT there was a range of 500RPM at about 7000RPM where VE and torque fluctuated by up to 10% and it was not finetunable at all, although the sound was awesome, even for a 600cc engine.