Table resolution and size

Testing and development of Megasquirt 3

Moderators: daxtojeiro, muythaibxr, jsmcortina

Re: Table resolution and size

Postby coyoteboy » Wed Dec 22, 2010 10:47 am

WRT to code complexity - sure it adds a little, but not a lot, and while I've not read the MS3 code I do this sort of thing day to day so I understand the level of increased complexity.

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.


It does, if you don't have back to back tests there's pretty much no way you can claim its not necessary without glossing over some factors. As I said from the start, the difference may be minor, and most people may not want to map 32x32 or so on, but that doesn't mean they're not necessary, just that they dont fit the general usergroup of MS. If it was said that "we don't think anyone wants to tune more than 16x16 and that can handle most tuning eventualities to a reasonable degree" then I'd agree entirely and not have said anything, but to say it's not needed is a different matter. The reason the OEMs can use a 40+x40+ table is because they have a team of people with one engine for weeks on end trying to get the very best out of the engine and (to some extent) trying to meet regulations on emissions. My argument is simply that larger tables are useful, I already commented that it's probably not suitable for the MS usergroup on several grounds.

WRT the holley autotuning shifting many bins - of course, thats a simple tuning algorithm scaling the bins as it goes because it was designed to illustrate (listen to the commentary) that it can be done without a base map for the engine - it is demonstrating large-scale map autogen, not fine tuning of single bins.
coyoteboy
Super MS/Extra'er
 
Posts: 1023
Joined: Wed Feb 01, 2006 7:52 am
Location: UK

Re: Table resolution and size

Postby racingmini_mtl » Wed Dec 22, 2010 11:07 am

coyoteboy wrote:WRT to code complexity - sure it adds a little, but not a lot, and while I've not read the MS3 code I do this sort of thing day to day so I understand the level of increased complexity.

Then you should know about feature creep and the fact that something that seems small very often isn't and most of the time you realize it after the fact.

coyoteboy wrote:... As I said from the start, the difference may be minor, and most people may not want to map 32x32 or so on, but that doesn't mean they're not necessary...

Necessary for what? Extracting the last bit of power from the engine or meeting the emission rules? I would question the necessity and even the usefulness for a generic ECU (not only MS). With the number of parameters and the generic nature of the algorithms, I doubt many would be able to measure the difference between 2 tables of different sizes. And for those who would have the means to make the measurements, I doubt they'd be able to reproduce it under different conditions.

I think it would need time, money and resources to be able to spend a lot of time on a specific engine configuration to be able to use a larger table. Moreover, I think it would also require tweaking of the code to take advantage of it.

Again this is just my opinion based on a lot of speculation. But in any case, if you feel the need to have more cells there are options right now so this is a somewhat academic discussion.

Jean
jbperf.com Main site . . . . . . . . . . . . . . . . . . . . . . jbperf.com Forum
Image
racingmini_mtl
Super MS/Extra'er
 
Posts: 5175
Joined: Sun May 02, 2004 6:51 am
Location: Montreal, Canada

Re: Table resolution and size

Postby hassmaschine » Wed Dec 22, 2010 11:19 am

yeah, if you really want a larger table - do a 30x30 table with MS3. Have fun tuning 900 load sites though, yikes..
hassmaschine
Super MS/Extra'er
 
Posts: 1329
Joined: Mon May 21, 2007 8:36 am

Re: Table resolution and size

Postby coyoteboy » Wed Dec 22, 2010 11:40 am

Then you should know about feature creep and the fact that something that seems small very often isn't and most of the time you realize it after the fact.


I do, but I don't let that stop me doing something if I think it's worth doing.

I think it would need time, money and resources to be able to spend a lot of time on a specific engine configuration to be able to use a larger table.


I agree.

Necessary for what? Extracting the last bit of power from the engine or meeting the emission rules?


Both.

. But in any case, if you feel the need to have more cells there are options right now so this is a somewhat academic discussion.


I thought this was an academic discussion, as the table sizes are already set and I can't see them shifting, we are just discussing whether larger is better and the similar but not the same, whether larger is useful here.
coyoteboy
Super MS/Extra'er
 
Posts: 1023
Joined: Wed Feb 01, 2006 7:52 am
Location: UK

Re: Table resolution and size

Postby muythaibxr » Wed Dec 22, 2010 11:52 am

The purpose of this thread was "Show me something other than marketing that proves with datalogs and msq that a larger table is necessary." So a datalog that shows an engine is non-linear at a particular point in its operation to the point that you can't tune it.

I know for sure that there are OEMs that use table sizes similar ours.

So again, show me proof that you need those huge tables.

Ken
muythaibxr
Site Admin
 
Posts: 6982
Joined: Thu Oct 14, 2004 12:48 pm

Re: Table resolution and size

Postby y8s » Wed Dec 22, 2010 12:18 pm

wouldn't this hypothetical nonlinear motor need to be very nonlinear at about a dozen different places in the rev range? You've got a parametric set of load and RPM points. if there's a hard to tune spot, add resolution and then remove it somewhere you dont need it.
y8s
Master MS/Extra'er
 
Posts: 478
Joined: Wed Jan 07, 2009 3:21 pm

Re: Table resolution and size

Postby coyoteboy » Wed Dec 22, 2010 12:31 pm

So again, show me proof that you need those huge tables.


As has been said, I can't, but it doesn't mean it doesn't exist. If the purpose of this thread was to say "unless you have MSQs/datalogs to prove this point, leave me alone" then you've succeeded in having no evidence against your thought. My point was simply that the need is there, OEMs (and I mean good ones) use larger ones for a reason, but most people on here will not have the kit to prove it (or sense it), which makes it pointless for the MS but not for everyone. Most small 2 stroke engines still use carbs, most 2 stroke users will tell you they work fine and there's no need for more, but it is being developed for them and it makes a measurable difference to economy and power. Point being, jsut because you cant see the need doesnt mean there is no need, just that what you have is good enough for you.
coyoteboy
Super MS/Extra'er
 
Posts: 1023
Joined: Wed Feb 01, 2006 7:52 am
Location: UK

Re: Table resolution and size

Postby muythaibxr » Wed Dec 22, 2010 12:51 pm

y8s wrote:wouldn't this hypothetical nonlinear motor need to be very nonlinear at about a dozen different places in the rev range? You've got a parametric set of load and RPM points. if there's a hard to tune spot, add resolution and then remove it somewhere you dont need it.


That's more or less the point I'm trying to make :D

Ken
muythaibxr
Site Admin
 
Posts: 6982
Joined: Thu Oct 14, 2004 12:48 pm

Re: Table resolution and size

Postby muythaibxr » Wed Dec 22, 2010 12:55 pm

coyoteboy wrote:
So again, show me proof that you need those huge tables.


As has been said, I can't, but it doesn't mean it doesn't exist. If the purpose of this thread was to say "unless you have MSQs/datalogs to prove this point, leave me alone" then you've succeeded in having no evidence against your thought. My point was simply that the need is there, OEMs (and I mean good ones) use larger ones for a reason, but most people on here will not have the kit to prove it (or sense it), which makes it pointless for the MS but not for everyone. Most small 2 stroke engines still use carbs, most 2 stroke users will tell you they work fine and there's no need for more, but it is being developed for them and it makes a measurable difference to economy and power. Point being, jsut because you cant see the need doesnt mean there is no need, just that what you have is good enough for you.


Who would you consider a "good" OEM?

I would consider the ones I've looked at to be "good" in that their engines run smooth and have good drivability and fuel economy that is as good as can be expected given the mechanical and physical limitations of the engine.

I am really not asking a user to provide anything complicated. Just a log or logs that show that there are multiple non-linear points and not enough bins to properly tune them.

That said, as I and others in this thread have said, it's possible to combine the 4 VE tables we have into one huge megatable. That is more than enough I'm sure.

Ken
muythaibxr
Site Admin
 
Posts: 6982
Joined: Thu Oct 14, 2004 12:48 pm

Re: Table resolution and size

Postby BenGTT » Wed Dec 22, 2010 4:08 pm

muythaibxr wrote:
y8s wrote:wouldn't this hypothetical nonlinear motor need to be very nonlinear at about a dozen different places in the rev range? You've got a parametric set of load and RPM points. if there's a hard to tune spot, add resolution and then remove it somewhere you dont need it.


That's more or less the point I'm trying to make :D

Ken


totally agree !!!!!!!!!!!!!
BenGTT
Master MS/Extra'er
 
Posts: 385
Joined: Sun Nov 23, 2008 4:46 am
Location: France

Re: Table resolution and size

Postby slow67 » Wed Dec 22, 2010 4:35 pm

Well GM has completely gone away from VE tables all together (for those who didn't know). They now use a formula and a series of constants to create a "virtual" ve table.
2000 Camaro, 5.3L 4L80E, 9 inch.
slow67
MS/Extra Newbie
 
Posts: 25
Joined: Sun Aug 19, 2007 1:11 pm

Re: Table resolution and size

Postby gurov » Thu Dec 23, 2010 7:51 pm

maybe this will sound like a bit of trolling, but here goes.

regardless of whether ken/person x/person y buys into someone's need to have a 64x64 table(aiming high here), once the code is released (which it will be, yes ?) would it not be somewhat trivial to actually make the change for this ? (assuming the thing actually fits into memory, which it will, yes ? we did not go through this hassle of upgrading to a new and cool processor to keep dealing with things like this, right ?)

this could potentially bring the proof for needing something like this from the other end, we have VEAL, so size of the table doesn't really matter. the amount of work that would be required to prove this is needed needs a hell of a lot more dedication and dilligence and indepth knowledge of how this particular engine runs. what if the proof came from testimonials of people who used this giant 64x64 table and got better response, behavior from the engine. what if with a large enough resolution the nonlinearity of an engine shows up from veal passing multiple times over the same spot.

so far the best reason i've heard for NOT having a gigantic table is that it's a bitch to tune. i don't buy this. we have software that does this for us. i've stopped changing fuel cells by hand a while back.

besides having my cars run how i want them, i'm in this because i want control over this stuff, size of the table doesn't matter to me because of VEAL.

why not put the burden of proof that this is not needed on the people NOT wanting to make the change ? i.e. "here's a version with gigantic table, knock yourself out silly trying to tune this, come back with whether it helped you in any way"

regardless of whether people buy into the huge table, i know i'll be trying to make a huge fuel table and let VEAL go nuts on it just to see how it responds.

and yes, i understand i can use the whole table blending/tableswitching thing to accomplish the larger table.

as said before, take the above with a fairly decent sized grain of salt, but i'd rather be proven wrong by trying something (i.e. giant table, let VEAL loose on it) and failing that way on my own vehicle or gaining nothing, than be restricted because there's not enough proof that it will make any difference at all.
2004 BMW 325xi Turbo A/T MegaShift MS3/X M54B25 j&s slc_oem
1994 Toyota Supra Twin Turbo - AEM EMS v2 - 2JZ-GTE slc_oem
2004 Nissan SE-R SpecV Turbo - MS3/X QR25DE j&s slc_oem (SOLD !)
2012 BMW X3 35i MSport - single turbo N55 - stock!
gurov
Super MS/Extra'er
 
Posts: 1007
Joined: Sun Jun 01, 2008 11:54 pm

Re: Table resolution and size

Postby ChevytoyR1 » Fri Dec 24, 2010 3:47 am

well said..

i think there should be a vote from everyone if there should be a bigger ve table on ms3 or not.. i dont think most of us are asking for a 64x64 table maybe something like a (20x20 - 24x24) table or so i think would be pretty good..
ChevytoyR1
Experienced MS/Extra'er
 
Posts: 360
Joined: Mon Oct 27, 2008 12:15 am
Location: Los Angeles, CA

Re: Table resolution and size

Postby Gokart » Fri Dec 24, 2010 4:44 am

through my experience, 16x16 table have a good smooth tune for NA engine but
that same great feeling is not there with turbo tuning. I just can't squeeze the proper
bin when it comes to a 300kPa - 400kPa boost.

Maybe I'm a numb skull but I don't face that same problem with other branded ecu
with bigger table.
(4G63T - MSIIextra) (4G13 - MS3-beta testing)
Gokart
Master MS/Extra'er
 
Posts: 647
Joined: Thu Aug 03, 2006 2:38 am

Re: Table resolution and size

Postby prof315 » Fri Dec 24, 2010 5:09 am

I'm using 1 table for N/A operation and 1 for boost on my car both fuel and spark. The kpa table switch is seamless and since my peak is only 200kpa I honestly don't think I really even need it. I just find it easier to deal with that way. I will agree with gurov in saying that VEAL makes the big fuel tables very easy to deal with.
The Professor
92 Corrado 2.0L ABA on MS3Pro. Support the developers! Sandy Linfert 11/4/91- 5/13/13
prof315
Super MS/Extra'er
 
Posts: 1536
Joined: Sun Jan 18, 2009 3:13 am
Location: Melbourne, FL

Re: Table resolution and size

Postby Peter Florance » Fri Dec 24, 2010 5:49 am

I don't tune car with the HP/liter #s that you guys do, but I would have expected to need more resolution (if needed) in the RPM axis, not the load axis. Are these fuel maps hitting non-linear regions as load increases, or is the VE table more curved in that direction than straight? Maybe some curve fitting interpolation needed as an option?
I'm speaking theoretically as I'm tuning turbo cars at about 125hp per liter, which is pretty mild.
Peter Florance
PF Tuning
81 BMW Euro 528i ESP Car
60-2 Wheel LS2 Coils, Low Z Inj
Check your grounds: http://www.msextra.com/doc/general/grounding.html
User avatar
Peter Florance
Super MS/Extra'er
 
Posts: 3206
Joined: Fri Apr 02, 2004 8:40 pm
Location: Virginia Beach, VA

Re: Table resolution and size

Postby jsmcortina » Fri Dec 24, 2010 6:12 am

I have no plans to increase the VE table size. For DIY coder in the future though, here's some technical notes.

The current serial transfer size is 1024 bytes, that's enough for a 22x22 table of 16bit values. (With the indicies in a different page.)

Tuning data is stored permanently in data-flash, but runs from RAM. The RAM is divided into 4k blocks (that's the same as the total RAM on MS2) and if you modified the serial to give you access to all of one 4k block in a go you could go up to 45x45, again with indicies in a different page. But don't forget the other three VE tables need a home too.

To do this would require re-arranging other ram pages, changing the serial/CAN to allow that size, re-writing the ini, etc. It is not a trivial task.

The XEP100 chip has 64k RAM, 32k data flash and 1024k program flash.
Presently we've allocated ~32k ram, but all is used during SDlog serial readback, ~24k data flash (this is where tuning data is stored) and ~150k program flash.

James
I can supply, repair or upgrade Megasquirts in UK.

My Success story: viewtopic.php?f=104&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
jsmcortina
Site Admin
 
Posts: 22821
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK

Re: Table resolution and size

Postby muythaibxr » Fri Dec 24, 2010 7:55 am

I have said all I really intend to say. Unless I see a datalog showing nonlinear behavior at multiple points such that you can't tune the AFR consistently, I am not going to make the tables bigger. People keep saying "I need bigger tables I need bigger tables." Well I am not saying no, I am saying "show me why."

You can give me all the reasons in the world why you want it, or you can vote, but without proof, I won't do it. As James says, we are using around 24k of our data flash. We still have a lot to add that uses tables (4 vvt, another boost table, idle speed model, table-based WUE, etc). The remaining 8k of data flash is going to fill up quickly IMO. We have tons of P flash left, but if you want to use that, say hello to the burn stumble again.

Bottom line is that without proof of real need, we are not going to waste space on bigger fuel tables when that space is needed for planned features. Especially when you can effectively combine the existing tables for 30x30.

Ken
muythaibxr
Site Admin
 
Posts: 6982
Joined: Thu Oct 14, 2004 12:48 pm

Re: Table resolution and size

Postby Gokart » Fri Dec 24, 2010 8:28 am

As of now, it doesn't matter of how big the tables are. Just make use of whatever been coded and try to manipulate it. I just hope that future MS development will take into consideration of having a bigger table.
(4G63T - MSIIextra) (4G13 - MS3-beta testing)
Gokart
Master MS/Extra'er
 
Posts: 647
Joined: Thu Aug 03, 2006 2:38 am

Re: Table resolution and size

Postby prof315 » Fri Dec 24, 2010 8:31 am

I'm gonna give leaving things alone a big thumbs up. If you can't get your car running smoothly on 16x 30 or 30x 30 you've got other issues anyhow. I know I had no probs with just 16x16 fuel and spark when I was running the 8V N/A setup on my car and I'm sure I could do the same thing now that I have added 12 valves and 12psi boost.
The Professor
92 Corrado 2.0L ABA on MS3Pro. Support the developers! Sandy Linfert 11/4/91- 5/13/13
prof315
Super MS/Extra'er
 
Posts: 1536
Joined: Sun Jan 18, 2009 3:13 am
Location: Melbourne, FL

PreviousNext

Return to MS3 Development

Who is online

Users browsing this forum: No registered users and 0 guests