Does this really work?Originally Posted by macca_779
http://www.hptuners.com/help/index.h...editor_rtt.htm
VE tuning with just the +- keys?
Does this really work?Originally Posted by macca_779
http://www.hptuners.com/help/index.h...editor_rtt.htm
VE tuning with just the +- keys?
Funny that this was just brought up again as I just had an idea on how to implement a system like HPTuners RTT without the need of a custom OS that uses supposed unused memory.Originally Posted by Chunx
My idea is that currently we have the Bi-di controls which are great and I tend to use delta timing quite a bit. But how about a customisable table built into the scan tool that works as a look up table for the Bi-Di's. I'll use timing as the example as this is what I use the bi-di's mainly for. Now ignoring all the modifiers that are applied to B5913, most of the time the data in this table is what we are working for. The way I see it is if the software is logging dynamic cyl air and RPM we have the axis's of a spark table and live lookup is possible as it always has been when cross referencing to the tune tool. Now if you were to fill this said table with a copy of B5913 or whatever you want, couldn't the software have the ability to apply this data to the bi-di's directly and control the forced timing option. The beauty part would of course be that the numbers in this table are only a look up table external of the PCM and thus changes to it can be applied in real time with the engine running. You could perform multiple pulls tweaking it and when your done copy it over to the tune file and apply the cal.
I think it would be a very useful addition and would require no revisions to an operating system for it to work. What do you guys rekon.
[edit] I just had another thought about this and naturally a forced timing MAP does have some negative implications for areas like idle and DFCO.. So on top of my previous idea how about a feature where on the lookup table you have areas selected where the software could disable bi-directional control automatically. Then only when in the segments which you want live look up of a forced value would the bi-di's be invoked and the subsequent lookup values applied.
Last edited by macca_779; February 19th, 2008 at 05:18 AM.
It is something that is was available in EFILvie V5. When we brought out RR support, we dropped support for the bidi controlled spark and fuel maps because RR was so much better.
Maybe we can re-instate it in version 8, but it would not be a high priority in the version 8 roadmap.
Regards
Paul
Before asking for help, please read this.
I know many people I have discussed this with would really appreciate the addition. Especially from a marketing perspective it would really put the competition back another notch
Has any more progress been made on the accel enrichment tables. Even if it was limited to the COS it would help the FI guys out.
This is something that is practically a must for us SD FI guys.Originally Posted by 5.7ute
To re-iterate the need... I went back to MAF today because I was tired of the lean stumble in SD.Originally Posted by dc_justin
A real quick stab was yielding a full 1/2 second delay before the engine would respond. My wife's not been allowed to drive my truck as a result cause she has a tendency to rapidly stab the throttle and the last thing I need is for her to damage something.
how about being able to open LS1edit and HPtuner files?
or would that be way too much to ask.
They have their own proprietary encryption.
There's also a mutual understanding between all parties... "you don't crack ours, we won't crack yours".