Proposed Changes To Some Core Vars/Tables

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Proposed Changes To Some Core Vars/Tables

Post by Fred »

Thinking about this change was motivated by moving the table axis to 8 bits from 16. This brings some benefits with it, such as being able to have a 31x15 or 30x16 table in either direction, good for high boost only or high rpm only engines. The current status quo is 27x17 which is still going to be an available option.

When 8 bit axis are used, you're stuck with 0-255 * 256 as your range of raw values. In RPM terms that mean that our raw values would suddenly be 128, 256, 384, 512 etc. Not exactly pleasing to the eye in a GUI. In kPa terms the situation was similar, 2.56 kPa steps. Not as bad, but still annoying.

The solution then is to reconcile these uglinesses with scaling changes to those two main vars.

kPa affects the fueling math calcs and mtx scalings and RPM affects scheduling calcs and mtx scalings.

For RPM we can reduce our overly heady 32767.5 max RPM back to a mere 25599.6094, still more than good enough for the craziest of bikes and now the steps in the GUI tables are suddenly 100 RPM, much better.

For kPa we can reduce our unreasonably high maximum boost level from 555 kPa/5.5 bar/80psi to a mere 412kPa/60psi/4bar of boost (512kPa total range).

To generate kPa we just scale from sensor config anyway, so there is no loss in performance as the internals of the code don't care about what scale it is on.

To generate RPM we do a calculation involving normal math anyway, so again, it's the same. The internal numbers are never visible anyway. In cutecom they come out as hex, and in OLV or MTX they come out as a pre-scaled number.

In other words, the only loss is a bit of range, which was excessive anyway, and a bit of time making the change and triple checking it. The gain is the prettiness of the GUI and using less memory and/or making more out of the memory available. There will be a slight loss of efficiency in the table lookups, however they aren't a critical code path, and it will be a very simple/quick left shift operation anyway.

Today I did the ground work on the tables and committed the spread sheet. The next 2 posts will contain my plans for timing tables and Lambda tables.

I will unlock this thread to allow comments with the final post in this series of proposed changes.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Proposed Changes To Some Core Vars/Tables

Post by Fred »

OK, maximal axis size pairs are listed below:

1k block, 16 bit vars, 8 bit axis, max axis length being 31, mainly for VE:

Code: Select all

15	31
16	30
17	28
18	26
19	25
20	24
21	22
512 byte block, 8 bit vars, 8 bit axis, max axis length being 30, mainly for timing (fuel and ign):

Code: Select all

15	30
16	28
17	26
18	25
19	23
20	22
21	21
256 byte block, 8 bit vars, 8 bit axis, max axis length being 25, mainly for lambda:

Code: Select all

8	25
9	22
10	20
11	18
12	17
13	15
14	14
Though lambda could be same as timing also, it doesn't need to be because it is naturally a coarser grained configuration.

Of course, for the above specced table varieties, you can also use any subset from 8x8 or smaller through to those maximums.

Other memory layout combos are possible, but those seem best.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Proposed Changes To Some Core Vars/Tables

Post by Fred »

For VE this results in no change in math as it stays 16 bit.

For ignition timing, the new values will be -10 to 53.75 in 0.25 degree steps down from 0 - 65.535 in 0.001 degree steps, which was just plain stupid.

In terms of injection timing, it could be 0.25, 0.5 or 1 degree steps, with matching ranges. Or perhaps we'll do another table for ignition timing of lower res and higher bit count (16) and scale it 0 to 720. I don't really think that is necessary, but it might satisfy some strange people. Yes you.

As for lambda, the range we handle is 0 - 2.0 with 0.5 - 1.5 being the normal range experienced. Thus a granularity of just under 0.01 (0.0078125) will get us the required 0 to 2.0 range.

This all seems VERY reasonable to me.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Dan
LQFP144 - On Top Of The Game
Posts: 1204
Joined: Tue Mar 02, 2010 2:33 pm
Location: Australia

Re: Proposed Changes To Some Core Vars/Tables

Post by Dan »

+1 to the above! more than satisfies requirements of 99.99% of people! :-)
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Proposed Changes To Some Core Vars/Tables

Post by BenFenner »

Stop me if I'm on the wrong track, but I highly disagree that the AFR-Target table needs are intrinsically less granular than the other main tables. That's especially true if FreeEMS is going to attempt to actually get VE/AFR Target tuning done properly.

Either way, IMO, those tables all need to have the same resolution capability.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Proposed Changes To Some Core Vars/Tables

Post by Fred »

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?

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.

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

I don't mind making it the same as ign timing, BUT, it will NEVER be the same exact size (for maximums) that the VE table is, because they are different formats. Same goes for ign timing. You could always make them match and waste a little in one, or waste a bit differently in each, I guess.

Further thoughts?
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Proposed Changes To Some Core Vars/Tables

Post by Fred »

Let me put this another way, Ben, the ign timing tables are not getting more than 512k each, as such if you want me to artificially limit the VE table to match, I could, but that seems stupid. Better to give people the option of maxing out both, or wasting a little for them to match, or whatever.

Injection timing tables are up for debate, maybe 512k and 16 bit and lower resolution is fine for that, that way it could be 0-720 degrees. Let me check the numbers now...

How about 512, 16 bit fields of 0-720, 8 bit axis 20 max axis

Code: Select all

11	20
12	19
13	18
14	16
15	15
That way it's simple and all in one table if you want wild injection timing.

or the same, but max axis of 31 and these combos:

Code: Select all

7	31
8	28
9	24
10	22
11	20
12	18
13	17
14	16
15	14
31	7
or upto 32

Code: Select all

6	32
7	31
8	27
9	24
10	22
11	20
12	18
13	17
14	15
Given that there is likely to be a much larger variation in injection timing with RPM than load (which is dangerous anyway, btw, especially with undersized injectors) perhaps this is better.

Thoughts?

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Proposed Changes To Some Core Vars/Tables

Post by BenFenner »

I feel like I could craft some technical argument for why the resolution (edit: table size!) should be at least as large as we'd initially decided on, but there is an easier argument.

At the end of the day, people (humans) have to work with this system and making it as easy for them as possible is wise. Having to move between 3 fundamentally linked tables that share the same x and y axis is much easier when all three tables share the same resolution (edit: table size!), regardless of the underlying data or need. Having to change your frame of mind between the tables is something I'd love to avoid. This would be reason enough for me to make them all the same size and potentially "waste" some available space.
Last edited by BenFenner on Thu Oct 06, 2011 7:37 pm, edited 1 time in total.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Proposed Changes To Some Core Vars/Tables

Post by Fred »

OK, well, currently they are all 16x16 by default. That may change, but if it does, I'll make sure they all match, sound good? The exception being the fuel timing, which is totally unrelated to the other stuff at all.

We could go to one of these:

Code: Select all

18   25
19   23
20   22
Or 21 square though I don't like that, I think more RPM than load is good.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Proposed Changes To Some Core Vars/Tables

Post by Fred »

PS, none of them are fundamentally linked :-p They're all similar, but don't be fooled by that.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply