High-Resolution VE Table (option for 10ths)

[gslender]

Hi,

Wondering what folks think of having the option of an increase to the VE Table to 10ths of a percent... ie 45.1 similar to what the MS3 does.

I'm still looking into what options exist to make this work in the code, but one obvious hurdle is the extra memory needed to hold this high-resolution data.

One thing I'm toying with is the exclusive option of having VE Table 2 being unavailable when the high-resolution VE table is in use (due to the same memory slots be repurposed for the extra VE Table1 resolution data). This solution would mean those who use the two VE tables would never be able to access the high-resolution VE table option.

Thoughts?

G

[muythaibxr]

This is one of those features that we aren't going to backport. For starters the page size is not large enough for this.

Also, if it can't support all the current features (i.e. the multi-table options) then we're not going to allow a half-implementation that disables other tables.

The current MS2 implementation already interpolates in .1 units as well.

Finally, that is not a "fix" for an existing feature you are backporting. VE table lookups already work great. You are backporting part of a feature made possible by the MS3's huge flash.

Ken

[ol boy]

Instead of messing with VE why not figure out if one could increase the spark table to 16x16.

[racingmini_mtl]

Instead of messing with VE why not figure out if one could increase the spark table to 16x16.

The exact same issue about memory limitation Ken mentioned applies for this. So it won't happen either.

Jean

[ol boy]

I was wondering, it's in the 1/10 scale which is why it's limited to 12x12 in size...?

[racingmini_mtl]

I was wondering, it's in the 1/10 scale which is why it's limited to 12x12 in size...?

Yes a spark table table takes twice the memory space of a VE table of the same dimension.

Jean

[dontz125]

... which suggests that a 12x12 VE (HR) table could fit in the space of 16x16 VE1 and VE2.

It's a trade-off, giving up options (dual-table, 16x16) for another. This isn't unheard of in the MS/Extra history; the MS1/Extra HR code gives up lo-Z injector PWM control in favour of 35 usec (vs 100 usec) fuel pulse resolution.

[mariob]

There was already a working implementation of a 1/100 interpolation for VE, but it was rejected for inclusion in the standard firmware...

For improved resolution of the table values, one can double the VE values so that 200% means 100%. This involves some thinking for the cranking and afterstart values but gives double resolution at no cost.

Best Regards, Mario

[ol boy]

What would it take to make a bare minimum code which offers only dual load, missing tooth or dizy mode(basic trigger), no bio fuel, no stage injection, no dual table, and no sequential. That should free up loads of data for 2 VE table in the 24x24 range and a spark table in the 16x16 range. I'm surprised there's not a stripped down code floating around that someone has done.

Just an idea. Later Ryan

[racingmini_mtl]

... which suggests that a 12x12 VE (HR) table could fit in the space of 16x16 VE1 and VE2.

Wrong. A 12x12x16bit is still larger than a 16x16x8bit. So it won't fit in the same memory.

At this point, there is a consensus amongst the developers that there won't be a change to the spark table size or the VE table precision. If you absolutely want them you'll have to go to an MS3.

Jean

[dontz125]

Jean - You didn't read my statement literally enough. A 12x12x(2btye) table would fit in the memory space of a 16x16x(1byte) VE1 *AND* VE2, both tables together. For that matter, unless I'm out to lunch, a 16x16x(2byte) HR table would fit in the space of 2x 16x16x(1byte) tables.

If the devs really don't want to do it - or forbid it from happening, for that matter - it won't happen. From what Jean and Ken have said, however, it really doesn't sound like a difficult exercise (to this admittedly clueless NON-coder).

[racingmini_mtl]

Don,

You're correct that one 16-bit table will fit in the space of two 8-bit tables but Ken already mentioned that reducing the feature set to gain VE precision was not going to happen.

Jean

[dontz125]

My last post on the topic if it doesn't go further - I don't want to come across as stamping and whining (especially for something I might never use!).

I can appreciate the desire to not reduce the feature set, but is that really what's being discussed? If I don't use a stepper IAC, I have 2 more programmable outputs. If I use a stepper IAC, I can't use those two programmable outputs. This is particularly significant when discussing the uS Module, when the choice is not between a stepper IAC and 2 outputs, but rather between a stepper IAC and 2 injector channels!

To bring the ranting back on topic - If my setup warrants HR VE tables, I can't use table switching. If I have to use table switching, I can't use HR tables.

Why not make the option available, and let the user decide what works best for him / her / it?

[racingmini_mtl]

Using different outputs is significantly (not to say completely) different from using memory differently. I won't go in details but that's not desirable in the least.

Jean

[gslender]

Using different outputs is significantly (not to say completely) different from using memory differently. I won't go in details but that's not desirable in the least.

Jean

Jean,

Looking at the code (in a quick review) it not only looks possible but I'm also unsure why you'd suggest that the concept of options within the MS2 code to enable functionality only when the user requires it (like the outputs, or 12x12 vs 16x16 VE tables) aren't something similar. The code complexity might be different, but the concept from a user perspective is similar - I have no need for 2x VE tables and if I had the chance to vote, I'd ask for HR VE tables over the 2x VE tables.

I also don't see how it diminishes the MS2 feature set - it might even create a demand for MS3 as people realise that HR VE is what they wish to keep and then desire 2x VE Tables - then the only option is to go to MS3 (there is absolutely no way to accomdoate that with the remaining space on the chip).

If I were to build a protype HR VE mod, would that be frowned upon or OK to at least experiment?

G

[racingmini_mtl]

From a code stability, maintenance and support point of view, I don't think this is a good idea. Having a variable that can be either an 8-bit or 16-bit value depending on settings is asking for trouble. And this will have an impact on support due to user confusion among other things.

I'll let Ken and James chime in but as mentioned I don't think this is desirable even as a side project.

Jean

[racingmini_mtl]

To be on a more positive note, I should add that I could see having an option to have VE2 be a global trim table similar to what exists for the sequential injection trim tables. This allows a 0.1 accuracy on a multiplication factor applied to the main VE table. So you can go from 87.6% to 112.4% while still using the 8-bit value.

I understand that it's not the same and would require using 2 tables but that seems to minimize the changes from the current code and everything around it while still allowing more precision on individual cells.

But I'll wait for comments from Ken and James on this matter.

Jean

[gslender]

From a code stability, maintenance and support point of view, I don't think this is a good idea. Having a variable that can be either an 8-bit or 16-bit value depending on settings is asking for trouble. And this will have an impact on support due to user confusion among other things.

I'll let Ken and James chime in but as mentioned I don't think this is desirable even as a side project.

Jean

Jean - appreciate the fact you are taking the time to discuss this. Can you elaborate on those points above?

I can't see at all how it causes a configuration problem or a code issue with a byte either being used for 2-byte integer or 1-byte char... sure, if you switch between them (back and forth) the values will be garbage, but nothing too critical that isn't beyond what most people have to contend with when dealing with EFI and ensuring values are valid that don't harm the engine etc. It would also even be possible for TS and MS2 to coordinate the transfer of values safely by enabling a two-step config change whereby the ECU first prepares, and then copies the values between the tables to ensure nothing goes pear shaped. It would copy VE Table1 to HR Table in such a way that it copies-and-transfers the existing data as needed (and also on the way back from HR VE to 2x Table VE). If I do this correctly, I should be able to copy bytes in such a way that it preserves the low resolution VE values into the HR VE table, and back again (loosing resolution but maintaining non-10th values).

As for user confusion - I guess this would be all up to the provided TS instructions, the notes around the config screens, and warning notes to ensure all is understood. With the level of complexity MS2 is already at, I find it hard to believe this option would stump folks… or cause any more confusion than the mass of options that already exist?

Again, I'm just keen to understand the real technical barriers to proceeding - from all aspects as I understand the code, this is a relatively straight forward task to add 10th resolution to the main primary VE table (clobbering over the 2nd VE Table to do so).

I think everyone appreciates the desire to move all to MS3 for better features and reduce the development focus to a single architecture - but like everyone else, I'm just not prepared to ditch my recently purchased MS2 unit when there is plenty of capability left in the device.

Obviously if releasing a mod is going to have me banished, then I'll refrain, because as I understand the changed licensing, MS/Extra must approve any mod. So technically unless Ken, James or you Jean say it is OK to experiment, I'm not able to proceed - that would be dissappointing, but it is your right to do so.

G

[gslender]

To be on a more positive note, I should add that I could see having an option to have VE2 be a global trim table similar to what exists for the sequential injection trim tables. This allows a 0.1 accuracy on a multiplication factor applied to the main VE table. So you can go from 87.6% to 112.4% while still using the 8-bit value.

I understand that it's not the same and would require using 2 tables but that seems to minimize the changes from the current code and everything around it while still allowing more precision on individual cells.

But I'll wait for comments from Ken and James on this matter.

Jean

Yup, thought of that too, which is really not that different to allowing a single HR VE table... it is just made complex by a lack of TS ability to combine the table into a single view for ease of editing... but thanks Jean for the postive thinking ;-)

G

[dontz125]

I don't know how the tables are stored relative to each other, whether VE1 and VE2 are contiguous or well separated. The thought occurs to wonder how hard it would be - rather than have cell 08-11 of VE-HR consist of 2 consecutive bytes - to have the data byte stored at what would be 08-11 of VE1 be the 0-255 value, and what would be cell 08-11 of VE2 contains the tenths value. This means that whether you are using HR or standard tables, the values and handling of VE1 remains the same. VE2 will either be the swap table or the tenths table. Did that make any sense? Would there be any benefit to this scheme, or would it make it harder?