Fixed point mathematics [now with POLL please vote]

[Fred]

Abe, the reasons that it can exceed 100 or indeed even get close are those of resonances and inertia etc. Overlapping cams at high revs with high compression leads to the charge being accelerated into the chamber artificially fast and thus building pressure in there that is then trapped by a closing inlet valve. etc. :-) If not for that sort of thing 100% would be an excellent cap.

Jean, with it artificially capped at 10 inside a 16 field, you can multiply 3 of them together and still fit inside a 32 field. (correct me if I'm wrong)

I think more than 8 are needed for fine control for sure. I haven't looked into it enough to know if it is fool hardy to allow 16 bits or to cap it to 10 artificially though.

If there are 16 available it should be trivial to change what can be done with them at the end of the day.

[AbeFM]

No no, what I was saying was I'm pretty convinced it's relative to ambiant. To "STP" (standard temperature and pressure), i.e. if you stopped the motor, took the air out, let it cool, and measured it, that would be the ratio. Another way to think about it, you're really counting the number of molecules that got in. Which is what you want to know, if you're delivering fuel (and all the best engine computers do that).

[Fred]

Which is what you want to know, if you're delivering fuel (and all the best engine computers do that).

LOL, yes, STP is included, and yes, you are counting the molecules per volume in the intake vs. the molecules (of fresh air) per volume in the cylinder after the valves all close.

[Mops]

i think that 0.1 resolution is all we need, and even that's i think should be optional... most people should be happy with 1% resolution.

up to 127% would be just fine, provided you use 'multiply map feature'

Multiply map feature is:
you take the ve bin value (say 50%) and you multiply it by map valaue (or fuel load, in percent).

so basically at low map's you need to use larger ve numbers (compared to without multiply map feature) and on high map areas you use lower ve numbers. that basically translates to flatter ve table, which in turn can be used to extend precision while maintain gin manageable numbers...

kinda ve table is 'transposed' or 'compressed' (if you will) by the map% factor.

[SleepyKeys]

I think our speed-density implementation will be too imperfect to utilize .1% lookup resolution. However I could be wrong and please don't hesitate to let me know.

I would like to see VE represent VE and not be masked by varying a AFR. The VE table could be multiplied against a AFR target value or Power Enrich value.

I did a dump of my stock gm tables. http://www.diyefi.org/forum/viewtopic.php?f=16&t=215

[Fred]

Being able to turn "multiply map" off is a dirty hack and flies in the face of well founded physics. Any such table is NOT a VE table or even close to one. James, Al, Bruce, etc are right on that one and Ken is wrong, though, he had me fooled for a while... There will be no option to turn off physics in any code I have something to do with writing I assure you of that :-)

VE will be VE or as close to it as we can get.

As for the math not being able to utilise the extra precision, I suspect you are wrong there as everything else will be much finer and that would leave VE as the worst component in the calculation. The master fuel trim can probably be coarse grained as it only has to get you close anyway...

Anyway, regardless of whether you have map multiplied or not, you would get the same precision despite of the level. If you reduce the ceiling, you make the grains finer as well. It is just a visual thing that defaults to where people are most likely to use it. My map looked strange and went from low numbers to 163 or so. I have a strong feeling that this is quite wrong, but I will just have to wait and see. Either way, my map is a premium example of just what we want to avoid. There I was with 255 max range and I'm miles from it limiting the accuracy of my adjustments artificially. If people set things up such that by default the ceiling is close to their max, everyone will be better off.

The poll is there to say "I want 1%, 0.5%, 0.25%, or 0.125% change" etc. I'm interested to see what those with some real experience fine tuning an engine have to say. Mops has this experience, and appears to be indicating that 0.125 change would be better for his needs than 1.0 change but that most people who don't bother to fine tune things won't give a damn. If this is the case I'd like to go with the higher accuracy version if possible as I do want this to be super accurate. That is one of the primary goals.

Fred.

[jbelanger]

Jean, with it artificially capped at 10 inside a 16 field, you can multiply 3 of them together and still fit inside a 32 field. (correct me if I'm wrong)

Yes but you better make sure this cap is enforced everywhere the value can change otherwise you screwed. It also has to be very clear in the code that this is needed because someone could be tempted to use the full 16 bits at some point without changing the math behind.

Jean

[SleepyKeys]

Without a specific gravity sensor for the fuel(unfortunately if varies quite a bit in the US, mainly due to ethanol content) or a way to measure humidity, wont the 02 loop always be correcting more than a % or two's worth in the VE table ??

[Fred]

Yes but you better make sure this cap is enforced everywhere the value can change otherwise you screwed. It also has to be very clear in the code that this is needed because someone could be tempted to use the full 16 bits at some point without changing the math behind.

You raise an excellent point. In the time it took my bogged down firefox to load this post page I realised that you expose all 16 bits to the world and right shift them to where you want them in the code. If we even want to do this of course. It definitely has to be enforced in some way, and the use 16 shift back to 10 (or whatever) method seems most infalible.

[hassmaschine]

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.

It's not a problem where you have large VE values, like 200+ where you have .5% accuracy - that's fine. it IS a problem when you have really small values, like 6 or 7. I've seen plenty of maps where the idle VE was a 7 or less - how do you suggest you tune an idle with 14% resolution at best? It can't be done. I'm betting most of these people either aren't daily driving their cars or they don't care.

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

I don't think interpolation is the problem. having higher precision in the interpolation stage doesn't help when the individual VEs are small and the resolution is poor. You're just accurately interpolating between two inaccurate numbers.

And it also doesn't help if there is a large change in VE between two points - one reason I was able to smooth out my engine was expanding the VE table, making it flatter. before it jumped in 300-400rpm steps, and sometimes (well, most of the time) the interpolated values were too high or too low. Setting your RPM/Load points is important of course but there is only so much you can do.

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

Doesn't MS1/e HiRes have higher resolution in the VE table? A friend of mine who uses it suggested that it did. in that case, I can see where poor interpolation could result in less accuracy. But in MS2/e's case, it's not going to make any difference when the resolution varies between ~14-0.5%.

I agree that it would make more sense to keep the calculations 8/16/32 bits instead of something odd like 11 or 20. But I don't really know why I agree, it just looks nicer.