Matt wrote:This is an update from my original 'diagnostic' document
http://www.nistune.com/docs/NIStune_Mapping_Guide.pdf
I've gone over HCR32 for a quite a number of hours tonight with the hardware maptracer and documented the tables which need a bit more explanation. HCR32 has more tables added and these will be available shortly. Next ECU targeted is the BNR32 and boost tables to go under the scope
I'll gradually add more ECU specific tables as I go but this is definately a good start on top of general table descriptions in the users manual
Any comments appreciated!
Good manual. I adore reading manuals.
I think every Nistune user should have one on tap (when it reaches its release state). It is always nice to have documentation. This is where maturity of the developer can be clearly seen. This is the sign of a real business and of a good (in fact, incredibly great) product. Something extremely rarely seen among enthusiast-developed products i might add. Keep it up, Matt.
I now had only a brief reading and have a couple of comments and questions:
1)At the very beginning - if one block represents 5ms then injector pulse width in the first case seems to be closer to 6-7ms than 5.3ms. Second seems to be in order.
2)
In manual Matt wrote:The grey cells are the consult reported TP values. We highlight grey cells to indicate accessed cells and a darker
grey cell (not pictured above) to indicate closest accessed cell
To make it clear - if i dont use emulator - what TP value do I get in Nistune? Is it a TP that is recieved directly from ECU through consult (calculated by ECU itself) or is it a TP based on some formula using MAF voltage/VQ map value, calculated by Nistune on a laptop?
In manual Matt wrote:In this example ... the TP = 27. This sits between 24 - 28 on the load scaling.
Highlighted value is in the "24" column although 27 is definitely closer to 28 than to 24. Is this a feature of a tracing algorithm or is it ECU derived? AFAIK the real output is averaged somehow between two (actually four, but horizontally two) values from map, does it use weights for real calculation? e.g.
[
(27/24)*{map value at column 24} +
(27/28)*{map value at column 28}]/2
or more likely
[
1-(28-27)/(28-24)]*{map value at column 28} + [1-(27-24)/(28-24)]*{map value at column 24}.
Italicized are weighting coefficients. Just interested in the mathematical formula.
3)
In manual Matt wrote:The basic works of the fuelling side of the ECU are:
Theoretical Pulse width (TP) = MAF Lookup * Injector multiplier + Injector Latency + Various enrichment
Injection Pulse width = Fuel table [ RPM , TP/256 ] * TP
In my humble opinion, "understanding TPW's" is a better place for this stuff than "PW limiting". Also AFAIK /256 (binary) means shifting 8 bits right. This actually means that MSB is the upper byte of the whole TP value, isn't it?
I also read somewhere that TP is somehow RPM dependent, is this true or 100% false?
4)
In manual Matt wrote:Larger injectors need a smaller pulse width to maintain the same amount of fuel at idle, but need a longer pulse
width at full throttle than the ECU would typically provide with stock injectors.
Hmm... that is really strange and counter intuitive to be honest. I don't get it. I admit that some people have experienced sudden lean condition at high load near rev limit, but it is unlikely to be traced back to larger injectors. The statement is true if airflow through engine has been increased significantly and map load scale has not been expanded accordingly, or load lattice has been expanded without map value recalculation, or VBOT aka latency has been set incorrectly, but it is not true if injectros is the ONLY thing that has been changed. This is a conditional statement and IMHO it should include conditions in which such an unusual state of affairs occurs.
5)
In manual Matt wrote:Theoretical Pulse width (TP) = MAF Lookup * Injector multiplier + Injector Latency + Various enrichment.
Is the 750 (example from the manual) value added to current theoretical TP as a numeric value right away, is it converted to some other value later (are msecs converted to some constant) or is 750ms interval added to output (total) injector pulsewidth? What dimensionality does latency have in the above formula? It is quite logical that latency is taken into account in final, real world pulsewidth calculation, but is it added to the theoretical pulsewidth? IMO latency is a final correction factor, that converts theoretical (ideal) PWs to real world, injector PWs, so I dont see why it should be added to theoretical PWs. I always thought of injector latency as a "time offset" so to speak. If injector X has less latency than injector Y, but their flowrate is the same, then it takes Y longer to open, but it also takes more time to close, so ECU just has to issue an opening command a {Y latency - X latency} msecs earlier, but pulsewidth is the same. On the other hand TTP is the index for accessing some specific point in the fuel map, in the above formula it represents engine load and i dont think that load has [msec] dimension at this stage. It becomes msec later, after total TP multiplication.
6)
In manual Matt wrote:The following graph shows the relationship
Blue = MAF (volts)
Green = TP (ECU raw value)
Purple = Injector Pulsewidth (ms)
As the amount of airflow increases, so does TP increase and resulting in a larger injector pulse width.
The relationship is clearly seen throughout the most part of the graph.. except the rightmost part, where MAF voltage keeps rising, but TP remains constant and injector PW jumps back and forth. I guess some lean condition is happening
That's it for now, I keep reading.
Cheers, Petros
