Page 1 of 3

Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 3:46 am
by Fred
OK, I'm saving my vote till later on this one. ALL votes must be accompanied by a post explaining why you went the way you did.

Tuning variables like most/all others on this system will be 16 bit variables. As I recently found out it is convenient to use 1024 bytes of space (1 sector) to store a table in flash and ram. As such, we want to cram the most tuning table size we can into one such sector.

We will likely have 2 tables visible to the code at any one time so 2k of ram used on this essential data. Jean may wish to add a third later and that should be fairly straight forward (he requires fully mappable fuel timing too).

The formula for memory used by a given table configuration is this :

*2 because shorts used @ 2 byte each
+2 for two chars to hold row and column count

size = (rows * cols * 2) + (rows * 2) + (cols *2) + 2

If you want the opposite of what is available in the poll (eg : 16rpm, 29 load instead of 16 load 29 rpm) please state your desires in your explanatory post.

Obviously you could go to a smaller number in any axis, but there is nothing at all to gain from it so it will be one of these 6 pairs that we use.

Cast your votes! and post your comments!

Fred.

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 3:52 am
by Fred
I should add, and this is critical, that there will be no "cranking mode" or "idling mode" as such. (idling will be coded for, but it will generally be tuned with cranking and the rest of the map as a whole surface rather than separate regions.)

SO, RPM should be larger than Load for 99% of applications, or possibly 100%. How much larger is up to you perhaps.

This table thing *should* be temporary, but it may not be, so treat it like it is permanent and put some thought into it.

Fred.

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 4:13 am
by sry_not4sale
Voted for #1. I like high revving rotaries!

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 5:38 am
by nitrousnrg
#2

i used 12x21, so 21/12 = 1.75 which is similar to 27/17. I think it is a logic ratio.
Mrk

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 9:04 am
by Fred
Marcos, Do you also use it as "tune from zero RPM up" with one algorithm from stop to redline? If not, why do you think it is a logical ratio? (I have my own thoughts on this, but...)

Aaron, What about 30psi rotaries? ;-)

Fred.

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 9:55 am
by Fred
Maybe I should clarify this a bit more.

There will be no cranking mode like MS.

The lowest RPM row is ALWAYS going to be zero RPM. It might be that you can get a good cranking, starting, idling setup with 1000rpm idle with just 0, 800, 1200, or you might want more below idle. My guess is that you will want 2 - 4 cells below idle for configuring this. So, after that it comes down to setup :

100kPa with WILD cams and 15k redline on a bike probably means you want 30+ by 10 or so if you are lazy. However, if you have 30psi/300kpa, you may want 30 steps from vacuum to full boost, and maybe it only revs to 6k and has mild oem cams. at this point you want the opposite. I'd say we should try to cater well to engines that rev to 10k and make 30psi of boost.

if you have a step at 500rpm increments roughly, then its 20 cells of rpm + those below idle. for the boost situation, you do need intermediate cells, but only during spool up, so it's less critical. one step each 15kpa is probably good too 300/15 = 20 steps up, however that is too fine, so perhaps a bit less?

Basically I think 6 is a poor choice, 5 a very marginal choice that you would only want on a low revving dinosaur engine with immense boost. Above that though, it's a tough call.

I personally currently have a 7500 cut, and the next few things I'll be doing will be similar. Certainly not over about 9k for me anyway. Even when I one day buy a 20b ;-)

30psi is high, but I am going to be going to 27psi on my turbo so I do want some resolution above 100kpa, but i'm not sure how much.

I think number 3, 18x25 is poor because of the space it wastes a lot of space.

I still can't pick 1, 2 or 4 though.

Looking forward to more discussion and votes coming in.

Fred.

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 10:21 am
by Fred
I should have also mentioned that the locations of the RPM and load sites will be configurable except for the low rpm row which will always be zero RPM.

Fred.

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 12:01 pm
by dandruczyk
who HONESTLY want's to fill in more than 144+24 entries?? (12x12). Pleople keep making the assumption that MORE IS BETTER because thats what a lot of the supposed "pro" ecu's have. What people keep conveniently ignoring is that the PRO ecu's tend to have FIXED rpm axis's, (i.e. bins every 500 rpms), or systems that don't interpolate, or do it so poorly that they have to use massive numbers of bins to make up for it to cover up poor internal firmware designs.

As the MS guys proved, more bins is NOT necessarily better, you ONLY NEED bins where there's a CHANGE IN SLOPE of the table. If your table is linear from 2000-6000 rpm's that can be taken care of with TWO columns in the table (at mininimum)
There were several years where people had excellent running vehicles on 8x8 8 bit tables.

Also screen real-estate and rendering speed becomes pretty awful and painful to use (not to mention time consuming as hell) for the tuning side.

Variable sized tables that are user changeable are also frankly a pain in the ass to code for.

I think by going for "excessive" (IMHO) table sizes is only going to irritate users. (what!? I have to type in 512 entries by hand!!!!????) with possibl benefit to perhaps less than 0.05 potential users (who if they need this many bins, have an atrociously mismatched, intake, cam,exhaust esetup anyways) , and irritating the other 99.95% of us.

i stay, stick with 12x12, 16x16 is pretty damn big, and that's 256+32 values to type in, vs 144+24. if people need more bins, allow them to do staging and if they configure the bins well, they can have one table for low rpm,m and another to transition to for high rpm, thus giving them and effecting 24x12, or 32x16 setup.

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 12:35 pm
by Fred
mtx_man wrote:who HONESTLY want's to fill in more than 144+24 entries?? (12x12).
Surely you could code to be able to select a 6x6 area and fill it with a single value? or increment an area by x% or x?
Pleople keep making the assumption that MORE IS BETTER because thats what a lot of the supposed "pro" ecu's have. What people keep conveniently ignoring is that the PRO ecu's tend to have FIXED rpm axis's, (i.e. bins every 500 rpms), or systems that don't interpolate, or do it so poorly that they have to use massive numbers of bins to make up for it to cover up poor internal firmware designs.
I'm aware of this. Another reason they like it is because it saves time for them with automated tuning tools because you don't have to intelligently choose the bin locations to get a fairly accurate tune. They are by default close together everywhere. However, this project isn't about running an engine at all. It is about running it brilliantly. Some minority of MS users might need more, but i hope it is more than a minority here as the target audience is different. Much like buying Bowers and Wilkins speakers or Panasonic speakers, some people care about the 1%. I'm one of them.
As the MS guys proved, more bins is NOT necessarily better, you ONLY NEED bins where there's a CHANGE IN SLOPE of the table. If your table is linear from 2000-6000 rpm's that can be taken care of with TWO columns in the table (at mininimum)
There were several years where people had excellent running vehicles on 8x8 8 bit tables.
Agreed, but what happens when you have a significant slope in both directions at once? you need to compress both axis and end up with sparse boxs elsewhere. You also will never tune the top left corner of any boosted table. So you are sitting on about 3/4 to fill out. Possibly closer to 1/2 if you never lift off and stay in gear at redline like I do :-)
Also screen real-estate and rendering speed becomes pretty awful and painful to use (not to mention time consuming as hell) for the tuning side.
This is a good point.
Variable sized tables that are user changeable are also frankly a pain in the ass to code for.
In terms of the ms2e 12x12vs16x16 either or situation, sure, but what about a more generic general approach where first you fetch the number of columns and rows from the two 8 bit chars and then display and function based on that. It's fixed for any given tune once set and readjusting it should cause the user to lose his tune really. On each boot you read the config (from ecu or file) and configure and build the UI based on that. I can't see why a system like that needs to be any more tricky than swapping from ms1 to ms2e for example. Read config, display data with configured size right? Or am I missing something? I can think of a way to implement that in the firmware efficiently and cleanly. If that was done, you could have 8x8 and I could have 23x20 and we could both be happy.
I think by going for "excessive" (IMHO) table sizes is only going to irritate users. (what!? I have to type in 512 entries by hand!!!!????) with possibl benefit to perhaps less than 0.05 potential users (who if they need this many bins, have an atrociously mismatched, intake, cam,exhaust esetup anyways) , and irritating the other 99.95% of us
There is the solution I mentioned above, and also, if a user only wants to type in 8x8, they can just define their range inside the lower part of the table and ignore the rest/set it to zero. Then they only have to fill in 8x8.
i stay, stick with 12x12, 16x16 is pretty damn big, and that's 256+32 values to type in, vs 144+24. if people need more bins, allow them to do staging and if they configure the bins well, they can have one table for low rpm,m and another to transition to for high rpm, thus giving them and effecting 24x12, or 32x16 setup.
That's a convoluted way to support something. There are lots of hacks in MS land firmware for such things. I'd like there to be no hacks required on this. Clean code, clean simple interface, clean algorithms, simple and effective.

Thanks for your input, I'm sorry there was no suitable poll option for you, but your opinion is noted and respected as always.

Fred.

Re: Tuning Table Size VE and Advance POLL inside

Posted: Fri Jun 27, 2008 9:52 pm
by nitrousnrg
Fred wrote:Marcos, Do you also use it as "tune from zero RPM up" with one algorithm from stop to redline? If not, why do you think it is a logical ratio? (I have my own thoughts on this, but...)
I have a crank and idle algorithm, but that never conditioned me with table sizes (should it?).

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..

Also, i don't care if it gets too big. Software (PC or firmware) can make tuning much easier, but if tables are too small.. well we have a problem.

Marcos