last question, should I make it either ADC0F OR AutoICS enablement of the altmaps?

Ie you can use both methods to enable/disable? you must choose one when your setting up your ROM?

Just makes the code a bit easier

edit - yeah I think I will do this, then I can use the "Enable AltMaps flag" as follows:

0 = no altmaps
1 = altmaps by autoics button
2 = altmaps by adc0f

of course for evo's that don't have ICS they will only be able to choose 0 or 2.

ok?

 

I think it would be fine to have to choose one or the other. I have the switch installed and I NEVER use the ICS switch now.

 

Here's what I was thinking with the 2d map for interpolation. While doing the 2d map you be able to implement your switch points as well as have the option manipulate the curve entirely with both voltage and percentage simply by changing the values. On ADC Curve 2 the vertical cut between the 0% and 100% is realisticly not at the same voltage but only .1 volts difference between full off and full on, or whatever tephra makes the increment value.

 

I see what you mean. Currently, its adjustable from 1 to 255 which is roughly .02v per increment. It all depends on what Tephra can accomplish at this point. If he does do this, as a default, you'd want it set to be less aggressive as it interpolates from map-to-map. That way people can push the limits slowly before the onset of knock, rather than having to adjusting to remove knock.

 

leave it for later guys

Just want to get V5 out and then we can work on the future!

 

sounds good. sorry for jumping the gun.. just wanted to add in while I was thinking about it.

 

The selection between a blend of 1/2 or 2/3 definitely depends on what the MIVEC system is doing. The selection criterion is very odd though. The selection depends on whether the actual MIVEC is above or below the target MIVEC. There is also a "blending" variable that is used to take the timing from a combination of 1/2 or 2/3. The blending variable scales with the actual MIVEC.

The amount of MIVEC overshoot or undershoot is very minimal for a properly working MIVEC system. That is reason enough for me to say that I can't see the value in adjusting the timing based on MIVEC.

 

damn - i just spent 4 hours debugging a non-starting car..

finally worked out I screwed up the injector scaling overwrite

 

"background checking on octane value and all"

I don't know if you mean this, but there are checks on the octane number that do other funky stuff depending on its value. I've not looked in detail, but it might alter the boost or something else?

It does make sense to trim the ignition timing when MIVEC changes, especially if it is way out due to a fault, although it seems underused given the similarities between the maps.

 

someone is going to have to write one mother of a manual for when you finish patching.

All these potential features seem to be running away a bit.

 

As far as I know, the altmap (digital) has already down.

We are just see how far this ADC 0F channel can be used to it full potential. altmap (anaolgue) has more potential, as it seems. People on this forum is very creative.

 

The straight line slope/curves can be implemented on either:

- ECU/ROM - User definable: but it will require a bit of computer skills.
- External device: a bit more user friendly, just a matter of trimming a few potentiometers. As long as the interpolation is defined linearily.

The idea needs further refinement for real work is carried out.

 

Exactly, if octanenumber is used in other places then we can't really use it as a E95/Meth interpolation thingymagig

 

If you have any source for your work so far on the map switching I'd be interested to see it as between us we need a unifed system of pointers for 1d, 2d, 3d maps that are then switchable by manipulating a global variable. My existing system works for 2d and 3d maps, but not for 1d without code changes as you've also noted.

There is a routine that initialises the octane value after the ECU has been reset/powered down. If you are not doing so already, that is a nice one to hook into to make sure your status/map switching variables are always clean. It would also be a good place to copy any ROM maps to RAM so that they are always populated.

 

the 1d maps were actually easier than the 2d, injector scaling for instance is referenced as a pointer to injector scaling, so overwriting this with a memory address was easy.

The BCS 2d maps were harder, I had to overwrite the pointer with my memory address and then overwrite the call to 2D-table_lookup with the same call that is used in the fuel/ign routines (inappropriatly named 3d-table-lookup).

I will send you a disasm if you like John?