Adding load columns and RPM rows to maps
Adding load columns and RPM rows to maps
This topic comes up every so often and was just mentioned in one of MrFred's threads so I decided to start a thread for this topic so we don't clutter up MrFred's thread 
With so many people running such high HP Evo's these days that are nearing the 500 load and 10,000 RPM region, increasing the fuel/timing map resolution is becoming more of a topic. This thread is for the ECU guru's to have a haven to discuss this and see how feasible this may be.
With so many people running such high HP Evo's these days that are nearing the 500 load and 10,000 RPM region, increasing the fuel/timing map resolution is becoming more of a topic. This thread is for the ECU guru's to have a haven to discuss this and see how feasible this may be.
Not to junk up another thread but another idea a buddy of mine had and we proposed to Tephra was configuring outputs.
Here is what we said:
Since the progression of "economical" standalones people were brought the ability to configure outputs. This is a really great tool if properly used especially on hard to control torque curves of a turbocharged engine.
I think it would be super cool if we could implement configurable outputs on the more highly modified evos. The more highly modified evo's don't run an EGR valve and don't use the FPR output. For this reason I suggest using these factory outputs as configurable outputs in code.
How I envision it working:
In "tephra mods" section simply enable "Configurable EGR output" or "Configurable FPR output". At this point the user will have to enter some data for these outpouts to turn on. It should be set up in the "window switch" mentality. IE: it is off unless all of these are true. The variables should be Engine RPM, Vehicle Speed, and Engine Load. If all three of these are true the output should be on. The user would have to enter a low limit and a high limit for each variable. Thus if the user wants the output to be on for all vehicle speeds simply enter 0-300mph or whatever limit would not realistically be exceeded. Then the code would work for engine RPM and engine load only.
Examples:
1. Use it to control methanol.
2. Use it to control nitrous.
3. Use it to control launch vehicle RPM via CDI box.
4. Use it to control timing pull at launch via CDI box.
5. many others...
Here is what we said:
Since the progression of "economical" standalones people were brought the ability to configure outputs. This is a really great tool if properly used especially on hard to control torque curves of a turbocharged engine.
I think it would be super cool if we could implement configurable outputs on the more highly modified evos. The more highly modified evo's don't run an EGR valve and don't use the FPR output. For this reason I suggest using these factory outputs as configurable outputs in code.
How I envision it working:
In "tephra mods" section simply enable "Configurable EGR output" or "Configurable FPR output". At this point the user will have to enter some data for these outpouts to turn on. It should be set up in the "window switch" mentality. IE: it is off unless all of these are true. The variables should be Engine RPM, Vehicle Speed, and Engine Load. If all three of these are true the output should be on. The user would have to enter a low limit and a high limit for each variable. Thus if the user wants the output to be on for all vehicle speeds simply enter 0-300mph or whatever limit would not realistically be exceeded. Then the code would work for engine RPM and engine load only.
Examples:
1. Use it to control methanol.
2. Use it to control nitrous.
3. Use it to control launch vehicle RPM via CDI box.
4. Use it to control timing pull at launch via CDI box.
5. many others...
Not to junk up another thread but another idea a buddy of mine had and we proposed to Tephra was configuring outputs.
Here is what we said:
Since the progression of "economical" standalones people were brought the ability to configure outputs. This is a really great tool if properly used especially on hard to control torque curves of a turbocharged engine.
I think it would be super cool if we could implement configurable outputs on the more highly modified evos. The more highly modified evo's don't run an EGR valve and don't use the FPR output. For this reason I suggest using these factory outputs as configurable outputs in code.
How I envision it working:
In "tephra mods" section simply enable "Configurable EGR output" or "Configurable FPR output". At this point the user will have to enter some data for these outpouts to turn on. It should be set up in the "window switch" mentality. IE: it is off unless all of these are true. The variables should be Engine RPM, Vehicle Speed, and Engine Load. If all three of these are true the output should be on. The user would have to enter a low limit and a high limit for each variable. Thus if the user wants the output to be on for all vehicle speeds simply enter 0-300mph or whatever limit would not realistically be exceeded. Then the code would work for engine RPM and engine load only.
Examples:
1. Use it to control methanol.
2. Use it to control nitrous.
3. Use it to control launch vehicle RPM via CDI box.
4. Use it to control timing pull at launch via CDI box.
5. many others...
Here is what we said:
Since the progression of "economical" standalones people were brought the ability to configure outputs. This is a really great tool if properly used especially on hard to control torque curves of a turbocharged engine.
I think it would be super cool if we could implement configurable outputs on the more highly modified evos. The more highly modified evo's don't run an EGR valve and don't use the FPR output. For this reason I suggest using these factory outputs as configurable outputs in code.
How I envision it working:
In "tephra mods" section simply enable "Configurable EGR output" or "Configurable FPR output". At this point the user will have to enter some data for these outpouts to turn on. It should be set up in the "window switch" mentality. IE: it is off unless all of these are true. The variables should be Engine RPM, Vehicle Speed, and Engine Load. If all three of these are true the output should be on. The user would have to enter a low limit and a high limit for each variable. Thus if the user wants the output to be on for all vehicle speeds simply enter 0-300mph or whatever limit would not realistically be exceeded. Then the code would work for engine RPM and engine load only.
Examples:
1. Use it to control methanol.
2. Use it to control nitrous.
3. Use it to control launch vehicle RPM via CDI box.
4. Use it to control timing pull at launch via CDI box.
5. many others...
As I stated in the previous thread any additional resolution would be great for both load and RPM. RPM i find most important in the fuel maps. If we had 5 more rows if possible and 5 more load columns for both fuel and timing that would satisfy most of my needs 
I vote for more load sites. I still haven't recaled any of my maps. I just run the maps and use the last column. Makes it simple to tune when running 30 psi on E85, but not ideal. I just never wanted to give up the resolution down low, where the car is 99% of the time, not to mention messing with any other maps that may be using the same load axis data.
I vote for more load sites. I still haven't recaled any of my maps. I just run the maps and use the last column. Makes it simple to tune when running 30 psi on E85, but not ideal. I just never wanted to give up the resolution down low, where the car is 99% of the time, not to mention messing with any other maps that may be using the same load axis data.
Trending Topics
True, but there are many other maps that use the same header data. And probably many more that we don't know about. So, I didn't want to mess around with that.
I agree it's good to have resolution up top as well, but not as necessary, especially if you are just running one boost level consistently. The last load column will be used above 260 load (for a stock VIII ROM).
I agree it's good to have resolution up top as well, but not as necessary, especially if you are just running one boost level consistently. The last load column will be used above 260 load (for a stock VIII ROM).
Until EVERY square inch of the roms are disassembled, I suggest keeping the 0-60 load columns (0-100 if you can) and the 0-3500 RPM rows alone for driveability concerns.
As for the output thing, I used tephra's 'spray on knock' feature to activate my alky kit by setting the 'minimum knock required to spray' to 0 and I set the 'minimum load to activate' to whatever load I wanted my alky kit to turn on at. I then added a relay to the ICS relay output to trigger my kit once my desired load was exceeded. The only thing is, you HAVE to make sure the Auto ICS is ON at all times.
Since it was my own car, I didn't mind. Because of the worry of ever NOT having the AUTO ICS activated, I never would have used that configuration on a customers car. Worked like a charm though
As for the output thing, I used tephra's 'spray on knock' feature to activate my alky kit by setting the 'minimum knock required to spray' to 0 and I set the 'minimum load to activate' to whatever load I wanted my alky kit to turn on at. I then added a relay to the ICS relay output to trigger my kit once my desired load was exceeded. The only thing is, you HAVE to make sure the Auto ICS is ON at all times.
Since it was my own car, I didn't mind. Because of the worry of ever NOT having the AUTO ICS activated, I never would have used that configuration on a customers car. Worked like a charm though
I would also like the additional columns for load even though I have a ~400 ceiling on a 4-bar at 1:1. Additional RPMS rows would be a nice to have. I think I remember it being said by Tephra or JCS that it wouldn't be terribly difficult to add additional rows/columns.
i dont even recall how long i have been running with my tables rescaled without any ill effects. I guess i could eat my words but at least 10k miles of autox, drag and 25-26psi daily with nothing in the logs to show issues. I feel pretty safe at this point - but my motor could assplode tomorrow
Extended RPM is something that would be pretty useful. For me, the timing needs of the motor start changing a lot when going past the stock rev limit. I can understand extending the load but for the most part the motor hits the max load and pretty much holds it and then tapers off. The timing is nearly the same every single pull, so rescaling for the higher load up top tends to solve this problem easily. Rescaling the RPM isn't quite realistic, as you need all the resolution you can get in the stock maps then you run out of cells. I've extended the columns and rows in my DSM ecu and it is really nice, especially since the stock DSM maps are so limited.
The configurable outputs would be nice as well and once again I did this on my DSM ecu as well. You can use it to trigger the CDI box for a soft spark cut launch control. Use it for nitrous activation. Use it for traction control aides in first gear. I simply hijacked the FPS and EGR outputs of the stock ecu and used the one for CDI spark cut at the line and the other to run wastegate boost in first gear. Also with the introduction of the "launching aide" by 9sec9.com you can use the output to control clutch engagement in first gear.
The configurable outputs would be nice as well and once again I did this on my DSM ecu as well. You can use it to trigger the CDI box for a soft spark cut launch control. Use it for nitrous activation. Use it for traction control aides in first gear. I simply hijacked the FPS and EGR outputs of the stock ecu and used the one for CDI spark cut at the line and the other to run wastegate boost in first gear. Also with the introduction of the "launching aide" by 9sec9.com you can use the output to control clutch engagement in first gear.
Steps required to make maps bigger:
a) identify map you want to make bigger
b) identify axis's of said maps
c) see if these axis's are used for any other maps
d) relocate axis's to new block of ROM
e) relocate said map(s) to new block(s) of ROM
It's not particularly hard, just time consuming, and a lot of checking required.
If anyone had a specific requirement/request I could do it fora small fee...
With regards to hijacking a +12v output, I reckon the BEST bet would be to use the second BCS. Anyone that has this requirement will be running a 3port (or after market) so the second BCS shouldn't be used at all.
a) identify map you want to make bigger
b) identify axis's of said maps
c) see if these axis's are used for any other maps
d) relocate axis's to new block of ROM
e) relocate said map(s) to new block(s) of ROM
It's not particularly hard, just time consuming, and a lot of checking required.
If anyone had a specific requirement/request I could do it fora small fee...
With regards to hijacking a +12v output, I reckon the BEST bet would be to use the second BCS. Anyone that has this requirement will be running a 3port (or after market) so the second BCS shouldn't be used at all.
I like the idea of increasing the cells, but what would be the drawbacks? Besides, of course, what was said above?
In reality, these highly tuned cars should be running stand alones anyhow. The factory ecu was never designed for small mods, let alone extreme applications.
Yeah, we like to push the envelope, but we have to draw a line somewhere.
In reality, these highly tuned cars should be running stand alones anyhow. The factory ecu was never designed for small mods, let alone extreme applications.
Yeah, we like to push the envelope, but we have to draw a line somewhere.