DIYEFI.org Forum

They are all fundamentally linked. They all control the same engine over the same rpm range over the same load range.

Fred wrote:My take on AFR/Lambda, and it's not a target, it's integral, is that you pretty much want X AFR at X kPa. Thus it COULD be 2d instead of 3d.

Exceptions to that might be idle vs same conditions at higher revs? What else?

TONS of else.

Lambda can and should follow the torque curve at high loads. A 2D map for lambda is, excuse the expression, helmet-class retarded.

Example:



EDIT: Off-topic table naming discussion moved here

Fred wrote:Do you tune for 11:1 at 5k rpm and 15psi and 12:1 at 8k rpm and 15psi? if so you can achieve that with two points.

Sure. You could. If you want a linear change between those two points. Take a look at the 110 kPa row. You can't really compress that any. Only the 2,300 rpm entry is superfluous. And when you take into account the other rows, you can't get rid of that column.

Fred wrote:See where I'm going? I guess I'm assuming comparable VE across those levels too which isn't necessarily true.

Yah, you're way off base. If we were planning on only controlling one engine with known VE characteristics then yes, we could do all sorts of optimizing. But we aren't. And we shouldn't.

Fred wrote:I don't mind making it the same as ign timing,

Good. That should be done at the least.

Fred wrote:BUT, it will NEVER be the same exact size (for maximums) that the VE table is, because they are different formats.

What do you mean they are different formats? And why the hell are they different formats?

BenFenner wrote:They are all fundamentally linked. They all control the same engine over the same rpm range over the same load range.

That does NOT make them fundamentally linked, only linked in a meta way. By that logic the fan control tables are fundamentally linked to the VE tables too, and that is clearly not the case. Discontinue the off topic shit and get on with the show, please. I'm all out of patience for pointless arguing about inconsequential details of semantics. No more in this, very serious, thread, please.

BenFenner wrote:Lambda can and should follow the torque curve at high loads. A 2D map for lambda is, excuse the expression, helmet-class retarded.

Totally agreed, the point was, that it can be MUCH less granular and still achieve a very good and totally acceptable result.

http://www.supercars.net/gallery/132464/1497/698528.jpg

A map for lambda with a step in it between 110kPa and 130kPa is, excuse the expression, helmet-class retarded, too.

And when you take into account the other rows, you can't get rid of that column.

So you'd be happy with 12x12 tables then? :-p Yes, I understand the reasons behind it, see above point. Also, you can stop trying to educate me about something that I already understand. Cheers! :-)

Fred wrote:I guess I'm assuming comparable VE across those levels too which isn't necessarily true.

Yah, you're way off base.

I apologise for assuming that people won't run this system on inferior engines. It sometimes slips my mind that this is not true. PS, you're the king of dry humour, I do not expect a response to this comment :-p

If we were planning on only controlling one engine with known VE characteristics then yes, we could do all sorts of optimizing. But we aren't. And we shouldn't.

Absolutely agree. What we have here though, is the situation where we ordered a whole sheep and two cows for each person, instead of a good sized T-bone steak. It's not an optimisation. It was an intentional over-allocation of resources to a specific area of operation with the premeditated intent to revert what was not necessary at a later date, ie, now.

Fred wrote:I don't mind making it the same as ign timing,

Good. That should be done at the least.

I agree, but, it's at the most, and the least. It's just the right thing to do. Anything else would be, what did you say, helmet-class retarded, I believe.

Fred wrote:BUT, it will NEVER be the same exact size (for maximums) that the VE table is, because they are different formats.

What do you mean they are different formats? And why the hell are they different formats?

I mean this isn't a tower PC with 8 gig of RAM, it's an embedded micro with 32KB of RAM, and resources need to be used appropriately. more than 8 bit data for ignition timing and lambda is absolutely NOT required under any circumstance. Thus they WILL be 8 bit, and VE, which only really needs 10 or 12, which are both more than 8, will be 16, because 8 is no good and 16 is the next available size. The tables are variable sized such that someone with a screaming high revving engine that is naturally aspirated can stretch them in the RPM direction and compress them in the load direction. Also, such that someone with a 30psi big block chev can do the exact opposite. Thus there is flexibility to do whatever you want, be it 8x8 or 21x21 or some other odd shape/size. Because of their fundamentally different structure and shape, the maximal sizes at various aspect ratios are not the same, they are NEARLY the same, just not exactly, off by one cell in places, 0 cells in other places.

I hope that clarifies your thoughts on this matter.

Please, lay off the abuse, we're all here to do the same thing, me included.

Fred.

Fred wrote:By that logic the fan control tables are fundamentally linked to the VE tables too

Are the fan control tables 3D, with rpm and load as indices? Anything with those indices are fundamentally linked, and require the same resolution (edit: table size!) in my mind.

Fred wrote:Totally agreed, the point was, that it can be MUCH less granular and still achieve a very good and totally acceptable result.

The resultant engine behavior might be totally acceptable, but the tuning method is inexcusable.

Fred wrote:Also, you can stop trying to educate me about something that I already understand. Cheers!

Same.

Fred wrote:It was an intentional over-allocation of resources to a specific area of operation with the premeditated intent to revert what was not necessary at a later date, ie, now.

Fine. Scale them all back though. If you need the resolution (edit: table size!) for VE, surely you need it for the rest.

Fred wrote:Because of their fundamentally different structure and shape, the maximal sizes at various aspect ratios are not the same, they are NEARLY the same, just not exactly, off by one cell in places, 0 cells in other places.

I just don't see how you can treat VE differently from ignition time, or lambda as far as needs go. Ignition timing and lambda both change for the same reasons VE changes, and at the same times, and with the same frequency. Giving one some sort of precedence over the other as far as importance goes just makes no sense. If ignition and lambda can live with a max of 8 bits, then so can VE.

Fred wrote:Please, lay off the abuse

There's a Monty Python reply in here somewhere.

Seriously, this is not abuse. Not my abuse anyway. This is just how I communicate. You'll know when I'm abusing you. =D

BenFenner wrote:Are the fan control tables 3D, with rpm and load as indices? Anything with those indices are fundamentally linked, and require the same resolution in my mind.

And only in your mind. Get out your calculator and logic paper text books.

BenFenner wrote:The resultant engine behavior might be totally acceptable, but the tuning method is inexcusable.

Who said anything about actually doing it? Stop dodging the point.

Fred wrote:Also, you can stop trying to educate me about something that I already understand. Cheers! :-)

Same.

The trouble here is that you don't. So I will, until you do. But please, and excuse the implied arrogance, don't return the favour. I _actually_ understand this. I live and breath this. It's not even difficult to understand, you've just not thought about it in any depth at all. When you have it will be clear. Don't post about it in this thread, though, please. It's not relevant. Focus on the topic of the thread, whether the suggested tables are sufficient for a top class EMS, and I believe the answer is a clear yes, even from you.

Fine. Scale them all back though. If you need the resolution for VE, surely you need it for the rest.

What, the resolution or the size? Did you actually read this thread? It's not here to discuss the need for more than 8 bits in VE, that was done long ago. The other tables were not discussed then, only more recently, and with different results. More than eight bits ARE required for VE for GOOD reasons that this thread is NOT here to discuss. If you want to learn about it, go and read. Please don't waste more posts in a perfectly good thread and increase the noise:signal ratio even further.

I just don't see how you can treat VE differently from ignition time, or lambda as far as needs go.

That is clear, yes.

Ignition timing and lambda both change for the same reasons VE changes, and at the same times, and with the same frequency.

Also true.

Giving one some sort of precedence over the other as far as importance goes just makes no sense.

To you.

If ignition and lambda can live with a max of 8 bits, then so can VE.

False. I'll explain it to you on the phone. Leave this thread out of that picture, please.

The information, numbers, logic etc that you need are on this forum. Not in this thread, and they do not belong here.

Fred.

So, to sum up our phone conversation, I'm just going to pretend like the VE table can't get as large as it really can. I'll pretend the maximum table size for the VE table is the same as ignition and lambda tables and be blissfully ignorant.
Since one can change the tables sizes "at will" it really begins to become a moot point as long as they can be "big enough".

Also:

Fred wrote:What, the resolution or the size?

I didn't realize we were having this communication problem until we talked on the phone. I edited every reference previously from "resolution" to "table size". Never was I referring to the table value resolution. Only the table size.

Also, I never read closely enough to realize you brought up injector timing tables. I read "ignition" timing tables. Stupid me.

Would you like to continue this thread in that direction? I don't have any input on the matter, but you said you were working on that now and you brought it up.


Oh, and your tin can on a string needs polishing. I could barely make out 1/3 of our conversation.

Hooray! :-)

The injection stuff, isn't being used at all right now, so I will likely just leave it alone for the time being. I'll put a note somewhere to dig into the details of what it means to various people. Yes you. No not you, Ben :-)

Just to be perfectly clear, years ago, I setup the code to have VE, Lambda, ign timing, inj timing all the same size just for convenience and not coding more than I needed to. One of those was carefully planned and it was more than enough for the others. The others are now shrinking to make way for other awesome features that we simply can't do while we're burning dollar bills on accuracy that we do not need in other areas.

Onwards and upwards! :-)

As for the computer, it's the software, if I use skype on the same machine, it's crystal clear. I might try to fix it.

Fred.

A few things occurred to me recently.

1) We can make the tables fully flexible and prevent the waste of unused axis space. This improves all table dimension combos somewhat and should be just as fast/clean. Even MTX can continue to work with fixed build-default sizes :-)

2) 255 / 3 = exactly 85 degrees range. Perhaps this is a better choice. 20 degrees ATDC to 65 degrees BTDC giving people who need more advance the opportunity to use a false master offset and have 0 to 85 degrees BTDC

Thinking about this more, if the interpolation methods return 16 bit results, and the natural resolution of the rest of the system is at 0.02 degrees then...

0 raw = -20 degrees -20 in 0.0.2 is -1000
60 raw = 0 degrees which is 0 in all scales :-)
255 raw = 65 degrees which is 3250

so it's 4250 range with offset of -1000

Inside a 16 bit var: ((255 * 167) / 10) - 1 000 = 3 258.5
Inside a 32 bit var: ((255 * 16 666 667) / 1 000 000) - 1 000 = 3 250.00008

An error of 9 units is 9 * 0.02 degrees of real timing = 0.18 degrees, which is a bit yucky, but not too bad considering it'd only be at that level at full 65 degrees advance. At 22.5 advance it's 0.09 degrees which is pretty damn small really. Certainly this is all very manageable and will keep people from complaining about insufficient range for high compression engines at high loads and low rpm and shit engines at low loads and high rpms.

Fred.

With respect to the last post, that error could be shifted by moving the offset by half or all of the error to make the error zero where we choose and negative in other places etc.

For the 0.25 degree -10 to 53.75 scheme the numbers are:

0 raw = -10 degrees = -500
40 raw = 0 degrees = 0
255 raw = 53.75 degrees = 2687.5

So the scaling is 12.5 and the offset is 500, or an offset of 375 for -7.5 to 55 degree range.

That can be done inside 16 bits with a multiply of 250 and a divide of 20.

Specifically multiply the looked up values by 250, interpolate them, then divide by 20 afterward.

Another thing occurred to me last night/this morning: Multiple timing table resolution options. Why have it fixed? This could present some issues, but maybe some memory can effectively be unioned at a location id level and used/interpretted in different ways depending upon what is enabled/configured elsewhere in settings.

In fact, we could take it a step further and provide the same memory area and just let them choose 8 or 16 bit, and if 16, have half as many cells to tune, 70% axis sizes.

16 bit timing tables would likely end up limited to 128 range with a significant part in the negative and perhaps 80 or 90 btdc max.

Fred.

8 bit lambda will be straight forward, but here is the math for the record:

look up corners, multiply by 256, interpolate, (divide by 1) return.

If the table look up is generic, which it likely should be, then passing in a multiplyBeforeInterpolate and a divideAfterInterpolate could be a good approach. How that would fit into a generic source model with different resolutions available, I don't know.