Fixed point mathematics [now with POLL please vote]

[Fred]

Yeah, I think divide by a fixed X to bring the values to a sensible level where max is maybe 110 - 150 and no more. Real VE isn't above that sort of figure anyway. I agree that you don't want the table defining the resolution as it does now. The worst things should be the ADC inputs and the injector output. ADC inputs will by far and away be worst (10 bit accuracy vs. 0.8us). We just have to figure out the scale of each component in the equations required and make sure nothing over flows and nothing is restricted and everything is high res and calcs aren't toooooo slow.

Fred.

[hassmaschine]

yeah, i think that's my main issue - the individual VE entries in the table shouldn't be defining the resolution. it makes for a pretty big tuning mess unless you have a flatter VE table (which multiply map does help somewhat).

I do like the flexibility of 3 VE tables, multiply, and additive - i was able to make my engine run smoother by taking my 16x16 ve map and simply expanding it over two 16x16 maps, no retuning required.

[Fred]

I'm impressed with the cunning displayed in your ideas, but I really think that you shouldn't have to be cunning :-) I also think that if you had 16bit cells you wouldnt have ever gone looking for cunning ideas :-)

It should come down to memory really, and we have plenty, it is just a matter of using it in a good way such that we can access most stuff most of the time :-)

[gearhead]

We have discussed this at some length previously... I understand Hass's comments. It makes sense that a flat VE will not be hurt by taking multiply map out of the fuel equation and maybe even help. What I still do not get is the thought that a VE limit is a problem. It really depends, as I see it, on the intermediate calcs.

If VE is 1-255, but is interpolated between values at .1 or .01 accuracy, this becomes less of a problem... If it is a really problematic part of the map, you can move the rpm or map value of that row or column, I would think. The inputs are limited to 10 bit accuracy, and if the VE map (and spark map) are limited to whole numbers, that is less of a problem and could be 'trimmed' my multiplying by another map, though I find it hard to believe that we can be/need to be *that* accurate with this stuff. I guess I have just not been that precise...

Now, for the fuel calcs, if we have 16 bit inputs, as you know, we will have 32 bit results when we multiply them together. I would think that we carry that all the way to the end of the fuel calcs then convert it to a 16 bit variable at the end for the timer. Also interpolation between VEs would not be limited to whole numbers, but could also be 16 bit...

Am I crazy, here? As it is, I am going to try to do this with MS1/E HiRes and see what happens. There is some stair stepping of the calcs which does not look all that great and I want to see if it can be improved. I am pretty sure that Ken carried 32 bit fuel calcs through on MS2/E which is why it is so smooth and has 0.001 fuel precision. MS1/E HiRes is a mixed bag. It has some 16 bit variables and some other routines which make it a bit less precise more so than just being 8 bit accurate on inputs to the fuel calcs.

Gearhead

[Fred]

Good post Gearhead.

Pulling map out of the calcs makes zero sense to me. If the table is flat and maximal, then res is optimal. By doing anything that makes the range from min to max larger you are hurting resolution. As agreed right at the start months ago we will use physics to guide this effort. Pulling map out disagrees with Physics. There is a reason why James says leave it in.

Yes, you could move the rpm or map value to fine tune the values, but that is far from optimal and not at all intuitive. If you go ahead and multiply with a second table, you may as well have all the bits in the first table and less stuffing around in code etc. You must agree though that if we have the memory we should use it for the primary functions first. If worst comes to worst and we have to downgrade later, so be it. If the memory management is done right that should not be necessary though.

Yes, I believe Ken did use 32 bit intermediates, but I haven't (tried (LOL) to) read the code to confirm. As agreed, we will ensure there is no loss of accuracy one way or another.

Thanks again, and yes "2 posts in one day" was an excellent effort ;-)

Fred.

[AbeFM]

Uhg! Insanity! Without a whole lot more explaining, I won't go for 127.5, it's silly. What's the reason for it? Everything should have a front end that makes sense from a physical, engine point of view.

This suggests two (and a half) scales:

1) 1-100%. You define 100% as the most effecient your engine will ever, EVER, be. And you obviously scale it in software. I don't care how many bits you use.

1b) 1% control? Fine, use 10 bits for the table, toss the 2% extra, and use 0-100% by 0.1%

2) You let VE represent, well, VE. So the scale upper limit would depend on the motor. I.E. An engine running 100% VE would have 100 in the table. Something running 2.5 bars of boost and 90% efficient there would have 315 in the table. Then, the VE table would be a measure of the Volumetric Efficiency of the engine at that point. To coin a term. Again, use however many bits you want.

Lastly, I don't see having arbitrary efficiency, you're not going to tune that well anyway. Give someone 10 bits, and you can interpolate as much as you want to whatever space you're using. I forget who suggested it, but it was a fine suggestion.

Personally, my physicist preference is option 2. A close second is option 1b. If I absolutely couldn't have that, then 1-1024 scale would work. At least everyone knows how to divide by 1000. 16 bit is ridiculous, I'm not putting 7F3C into any cells in my tables.

[Fred]

Uhg! Insanity! Without a whole lot more explaining, I won't go for 127.5, it's silly. What's the reason for it? Everything should have a front end that makes sense from a physical, engine point of view.

You said it yourself :-) engine VE never exceeds 100 by more than a little :

http://www.epi-eng.com/piston_engine_te ... ciency.htm

You are right that 10 bits are probably enough though. With 10 bits we can have max = 127.875 as a max value with steps of 0.125 which should be plenty fine enough. To achieve that though we would need to use 16 bit fields, but having the upper bits free could ease calculation complexity to ensure no overflow occurs.

I'll add a poll to this thread to see what everyone thinks about VE tuning resolution.

Fred.

[AbeFM]

Ok, from our offline discussion, I learned one thing at least: VE is as a function not* of ambient air, but of manifold pressure. I.E. An ideal motor would have an utterly flat table.

I'm pretty confused, then, how so many low RPM cells are down at half the value of the upper cells in the MS set up I have.

Now, all that said...

I'm definitely for the 1024 or so scale, assuming no one will ever use the EMS for more than 125% efficient engine is.... I dunno. I'm torn between it being realistic and being limiting.


*Hmmm, as best I can tell, the VE is defined as the volume of air in the motor (if you let that air out and returned it to STP) relative to the volume of air in the swept volume of the piston. So it's already a bit low, since your motor displaces less volume than it contains (dead volume when piston is at the top)....

Heh, I dunno. But the point is, running a couple bars of boost, from what I've read so far, it sounds like the VE would be in the 200% range. Sure, it's a matter of definitions, but it's important since one would be really flat and the other would be very far from it. I would think VE would be trivial to compute from an air flow meter and temp sensor (for a fixed displacement motor).

So, maybe we don't want to use VE as I defined, but some other term (intake efficiency?) which would be variations from 100%. Anyway, the more I think about it the more lost I am. One thing: With a barely open throttle, one might expect to have a mixture that's largely unejected exhaust.

[AbeFM]

Right now I'm a fan of 11 bits and a 204.8% range. There's no way anything will top that, and it still gives you 10 bit coverage for the part of the field you'll use. A close second would be 153.6 over 12 bits, but that's getting silly.

[jbelanger]

I think that if you go with more than 8 bits then you should go with the full 16 bits because if you multiply two 16-bit numbers your result will be a 32-bit number unless you're ready to make special libraries to work with 20-bit or 24-bit numbers. I think it will make things much simpler to keep everything either 8, 16, or 32 bits.

Jean