RomRaider

With many ways to achieve a similar end result, it'd be good to get more info out there on how to do things the proper way if there is such a thing. Code disassembly is not in my skillset at all but I can pick some hints about how things work using the Renault A2L and observing which maps are utilised by which functions.

I'm posting this mostly to seek confirmation for some of my understandings and I'll edit if necessary so that it can help others. I also have a bunch of questions.


Scenario 1 - Not adding any airflow but wanting to change injectors only or change to E85:

Firstly, if we want to make a fuel change only with no impact on the load axis of any other tables (both ones we know about and ones we don't know about), my understanding is that we should not touch K Constant (mKCONST) or QA Unif Coefficient (mQUNIT) without rescaling mTP100 because otherwise this would change your load position on many tables including ones unrelated to fuel. You'd also need to rescale mTCCLV and there are likely many other tables we don't know about that uses BFS (a.k.a. TP) directly (not via mTP100) which are now thrown off. What may be better could be to use this one instead:

mMKINJM - Injector magnification reciprocal number

It seems like if someone wants to ONLY change injectors or ONLY switch to E85 while having the smallest possible impact on the rest of the tune, mMKINJM could be the best one to change to correct the injector flow rate (Along with the latency at 14v, latency slope, pulse width minimum limitation value and cranking pulse width if needed). My understanding it that this multiplier only applies to the injector output and does not throw off anything else.

Long story short: mKCONST and mQUNIT do not just influence fuel. They influence the load lookup on many things. mKINJM influences fuel only.


Most maps defined in most Nissan tuning tools where a BFS load axis is used is actually a "Cylinder intake filling up efficiency" axis which depends on mTP100 and it's just defined with a BFS scaling, manually factoring in the stock mTP100 value, because BFS is more widely known and logged. I use a map editing tool that can use references in the axis scaling so soon I'll update my definitions to show BFS (because it's easily loggable on any ROM and more widely known) on the load axis while factoring in the mTP100 value so that if you change mTP100, all defined maps that use "Cylinder intake filling up efficiency" will automatically be rescaled with their new BFS values.

Does anybody know which other maps other than mTCCLV (100% Load BFS) that use actual BFS (not "cylinder intake filling up efficiency") as an axis that would be essential to change after rescaling MAF, MAF factor or K Constant?

Edit: Idle BFS limits would likely need to be changed too.


Scenario 2: Adding airflow (adding forced induction, upgrading turbos etc):

Do some logs before adding forced induction and see where your MAF voltage gets to. If you know you're getting to 80% of your MAF's capacity before adding forced induction and you'll be adding another 70-80% more air flow, I'd put the MAF sensor in a housing with around 70% more area so that you don't max out the MAF but you also still try and get the maximum resolution/accuracy as possible.

I think the general consensus is to keep mTP100 below 27 at the most (most vehicles stock value is much lower) and scale your mKCONST and/or mQUNIT so that BFS does not ever exceed around 26 so you have a bit of headroom. I get that most maps can be scaled out above 100% to go above the mTP100 value but this is messy IMO. I presume you'd use mMKINJM for any additional scaling needed to suit the injectors that you're running after mKCONST and/or mQUNIT have got you into the best BFS range.

Unfortunately there will always be many undefined maps that are impacted by these changes but they generally don't matter if the fuel scaling and compensation and ignition trim maps are dialed in. If only using the ignition trim maps to tune timing, there will be some pretty unconventional values in there without digging into may other maps but generally that's OK.

DBW throttle and torque stuff needs changing too but that's a discussion for another day.



Does anyone know any difference between what mKCONST (K Constant) has an impact on and that mQUNIT (MAF Factor) has an impact on? Like do some parts of the ECU use the result from mQUNIT before mKCONST is factored in?

All stock calibrations that I've seen, including the VR38DETT, have a K Constant that does not stray much at all from 27000 so I feel that this is intended to only be used for minor corrections.

Does the "Mass Airflow g/s" (vQAI) logging parameter pull its data after mQUNIT but before mKCONST or does mQUNIT not have any effect on this logging channel and instead ONLY mCSTQA (Mass airflow meter characteristic coefficient) is needed to correct this logging data instead? Another way of asking this is: At what point is vQM produced?

Edit: It looks like "MAF Offset" is needed too. I presumed all factory calibrations had 0 for this and it was almost never required but it looks like that's not the case.

These ones are self-explanitory but appear to only be used by diagnostic stuff:

mUSRVL - At the time of the idle, AFM voltage reference value lower limit
mUSRVU - At the time of the idle, AFM voltage reference value upper limit

What is this one and what is "reference air"? It sounds like something that should be rescaled when changing MAF. The same function that reads the MAF scaling reads this one unlike the idle BFS and MAF limits which look like are just diagnostics limits so this one could be important for something:

mUS14V - At the time of the amount of reference air, output voltage


I'd appreciate any input, additions and/or corrections from those that know. I'd really like to get to a point where I'm really confident that we have what we need to do a really good job of changing injectors only, changing MAF only or for adding forced induction.

This may also be possible in RomRaider. I'm not sure. Here is an example of a map with a "Cylinder intake filling up efficiency" axis that is scaled correctly to display BFS even when mTP100 changes.

Not really interested in sharing my own potential theories, as this just leads to misinformation when/if my theories are incorrect. So I'm going to try to limit it purely to either pure speculation or confirmed information. That way I won't negatively impact someone's tune by providing incorrect information under the idea that it's accurate lol


Not sure on complete functionality for mKINJM. It gets multiplied by vKVC to set vMKINJ, but that's about all I have on it right now. So the interesting thing about the MAF Factor is it's actually a scaled value. It's scaled in kg/hr. So 255 raw = 0.0255 kg/hr. Basically, the MAF g/s value gets multiplied by the MAF Factor before being multiplied by the K-Value (ms/kg) all in order to get an injector pulsewidth value in ms. That's not the real calculation for BFS btw, but just part of it. The whole load lookup thing is going to be influenced by literally everything that affects injector pulsewidth. Any fuel compensation that occurs will affect ITAC (Cylinder Filling Up Efficiency). So this goes for any and all fuel compensation maps, tables, values, etc. So I wouldn't stray from adjusting the multipliers just from a fear of altering ITAC.

So if you adjust a multiplier to alter the injector pulsewidth, it WILL alter ITAC. So it doesn't matter whether you use mMKINJM, mQUNIT, or mKCONST, they'll all affect ITAC. So just be sure to setup ITAC properly. For some of the maps, they actually just use the last column exclusively when the accelerator pedal is depressed past a certain point (70 degrees for CF48D). For FI ROMs, they utilize a 0-200% setup it appears. So while for NA ROM's, 100% represents maximum airflow, I'm not quite sure what it represents for FI ROMs. But altering BFS will be inevitable if you're making ANY changes to fueling. So just be sure to dial in mTP100. As for the BFS alone axes, I wouldn't worry about it at all at this point. There are only a handful of maps/tables that actually use BFS and not ITAC, yet people have been running FI with absolutely no trouble from said maps/tables. So I wouldn't fret about it at all. However, I am going to be looking into them more later on to understand why Nissan would go with BFS and not ITAC for the axis.




I wouldn't rescale it as BFS tbh. ITAC = Estimated Volumetric Efficiency in a sense. Rescaling it back to BFS just takes away from the whole purpose of it. Instead of it being represented as VE, you're now just representing it as arbitrary injector pulse widths that don't represent load in any way. (Visually, that is.) The whole idea of being 0-100% is so it can act as a load axis. Hence why Nissan has many maps utilize the 100% column (LAST column) when WOT rather than continuing to following the ITAC %, because WOT = 100% load.

As for other maps that exclusively use BFS, I still need to look into that. Current definitions have the AFR Correction Maps, Misfire Diagnosis Maps, and a few others using BFS rather than ITAC. Datalogging BFS + Map Value would show you whether it's truly based on BFS, but I'd assume they are actually BFS.


There's no way to force BFS to stay below a certain pulse width if you absolutely need said pulse width without running lean. I'm not sure how Nissan has their 0-200% ITAC axes setup for their FI ROMs, but I'm guessing you'd want to have it so that 200% (FI) = 100% (NA), so view 200% as being the 100% value maybe? Not too sure at this point, as I haven't looked at FI ROMs too deeply.


Well, CF48D seems to have just about every map and table defined for it so far, with some exceptions of course. So hopefully once I get around to analyzing some of them, I'll be better suited to helping others make proper changes lol As for ignition timing, no issues for me with just making adjustments with the main timing maps. Most of the compensations won't need to be adjusted either. The main concern still is the calculations for MBT. Once I figure out more about what we as tuners need to do, I'll be able to figure out whether the calculations will be accurate for FI or not. (probably not.)

ETC Logic is...... not fun. You should see how many calculations are required in order to convert the QH0 Map to a final Target TVO angle lol There's not going to be an easy way to explain it nor easy way to understand the calculations for anyone who doesn't spend time digging through the code, as different vehicles have different logic. Hell, different transmissions have different logic.


I do believe that both are used in separate functions entirely for various purposes. IIRC, mQUNIT is used to calculate a MAF-based parameter and then the K-Value is used for some weird calculation that isn't defined in the A2L. So not sure what that's about. But it's possible that since the MAF Factor is in kg/hr, it represents something to do with base airflow in some way? Since the K-Value is ms/kg, this could possibly represent some base injector pulse width to hit a 14.7 AFR for 1 kg of air. All speculation, mind you.

It has been quite some time since I've looked at the code, so it's very possible that some of the information is inaccurate, as I'm going purely off of memory haha So I apologize in advance if any of this isn't accurate.

Thanks for the reply Pytrex and I appreciate that you don't want to speculate too much on theories. My approach is that we may not know some things for sure for a long time so I just throw my theories out there just to start the conversation.



Isn't "Mass Airflow g/s" (vQAI)" only a logging/diagnostics value and not used by load/fuel calculations? My understanding is the grams per second is only a logging value that's had a conversion done to grams per second by mCSTQA but the actual fuelling and load calculation does not care about the grams per second value. Where does mCSTQA get its starting point for its calculation for the logging channel output? Before or after mQUNIT has been done? What I'd like to know is does changing the MAF Factor also change the MAF g/s (vQAI) logging output?



I agree but ITAC is not a loggable parameter by default on factory ROMs. We need to know the memory address for ITAC to be able to log it. Although ITAC makes more sense to use, having the live load parameter viewable and loggable is far more important, and for these Nissans, the parameter available to us to view and log is BFS.



Excellent. Thanks for the confirmation. I think that given that K Constant is in milliseconds per kg, I think this is "milliseconds" in the sense of BFS/TP and not necessarily remotely close to injector milliseconds per kg of MAF. Given that cars with 370cc injectors and cars with 570cc injectors both have almost identical factory K Constant values, this is why I think that BFS/TP "milliseconds" really can be very different to injector milliseconds and that mKINJM is the one to change for injector flow rate changes.

I'm currently reading the UpRev and ECUTek tuning guides. I'm still narrowing down which cranking fuelling maps do exactly what and it seems neither UpRev nor ECUTek know exactly how they work either but ECUTek have more complete info.

I'm still working out exactly which is which but some (not all) of the cranking fuelling maps are:

mTPPINT
mTTST_R1, mTTST_R2 and so on
mTKNST


ECUTek said that K Constant should rarely need to be touched and to use MAF factor for MAF changes or "Fuel Injector Scaling" for injector changes. Is it fair to say that they must be referring to mMKINJM?

What would really help would be to see what the stock mMKINJM values are for various vehicles with different injector sizes.

When I say MAF g/s, I'm not referring to any particular RAM parameter. I'm just mentioning MAF g/s in general. But the MAF g/s RAM parameter used for the basic BFS calculation (vTP0) is vQ4 according to my notes. But why would the fueling calculations not care about the g/s reading? If it completely disregards the MAF sensor's readings, how could it possibly know how much fuel it needs to inject in order to hit a target AFR? Remember, the MAF Table isn't some raw value, it's actually scaled in g/s. (Most defs use the raw value and NOT g/s scaling, will be easy to distinguish.)


From my firsthand experience with UpRev tuners, this is false. When you portray it as BFS, no one gets a proper understanding of how it all works nor do the BFS readings mean anything at that point. I'll take having to define the ITAC parameter over a tune getting screwed up because someone didn't understand that the "BFS" axis actually represents a 0-100% load axis. On top of this, you would have to alter the scaling for every since ITAC axis w/ BFS rescaling within the table template whenever you alter the scaler. It would make more sense to automatically scale the BFS CID as an estimated ITAC so that any changes you make with the scaler only require you to change ONE scaling (logger scaling.) This also ensures that the load axis is still being represented and interpreted as such rather than being arbitrary numbers like with the "BFS" axis scaling.


The issue is with the MAF Factor. You could have similar K-Values but drastically different MAF Factors. Also, according to ONE Nissan patent, vMKINJ (vMKINJ = mMKINJM * vKVC) is actually a fuel pressure correction coefficient for cranking fueling. So if we are to take this single patent as being accurate for our ROMs, then this value has no functionality for larger/smaller injectors. Now, we obviously would need to further verify this by analyzing the code. But just something to keep in mind.

I guess my main question is regarding the built-in MAF g/s logging parameter from a DDL2/K-Line logging perspective only. Where does mCSTQA (The scalar for the vQAI MAF g/s logging parameter purely for logging) source its lookup from? Does it scale when mQUNIT scales (Gets its data after mQUNIT's output) or does it get its data before mQUNIT (making mQUNIT have no impact on the vQAI MAF g/s logging parameter)?

Edit: I think I've got the hang of ghidra a lot more than I did 4 hours ago. I can see that MQUNIT and K Constant are in the same function but mCSTQA is in the same function as the MAF function where MAF volts gets looked up, MQTBL gets applied etc. I'm still going through the RAM addresses to see exactly which RAM write in the MAF function is the one that eventually finds its way in to the MAF to BFS function where both K Constant and MQUNIT reside. I've also discovered that my ROM does not appear to have a mQAOFST at all. I can see the MAF function on the ZB060 where the ZB060 has a mQAOFST but VC264 doesn't. I can see it there on CF48D at 0x89D8 for example.



Yep I agree that if your mTP100 is set up correctly AND you have access to logging ITAC, then ITAC makes the most sense. I see what you're saying about rescaling the conversion on the BFS logging parameter to get ITAC. Great idea.

RomRaider can't currently use extra arguments for axis scaling. With the tool I use, when I change mTP100, the BFS axis on all ITAC maps display with the updated BFS scaling as those tables factor in the mTP100 value. This is how UpRev do it too. I think this particular topic does come down to personal preference at the end of the day. There are many tuners out there that have become accustomed to using BFS so having both options can sometimes be good.



ECUTek have 3 separate scalars defined for MAF, K Constant and Injector scaling. Their advice is to change MAF Factor for MAF changes, Injector scalar for injector changes and don't change K constant unless outside of an acceptable BFS range. They criticise other tuner packages for not having access to this injector scalar. This injector scalar has no impact on any load values which is very handy if only wanting to change injectors only. This is the one I really really want to find. It could be mKINJM or yes it could be something else we don't know about.

Is the load lookup for the Fuel Compensation table vQH0?

Is it just based on throttle position, throttle area etc or does it have a MAF, BFS or ITAC influence as well? If it's just throttle-based, this would be annoying to dial in for boost which can vary a lot with same throttle angle.

Update:

The more things I look at, the more I realise that mTP100 should ideally be set to 100% cylinder fill at atmo pressure and as Pytrex mentioned, it's completely fine to go well over 100%.

The only table I've come across so far that has a fixed ITAC axis is mTDENS and it tops out at 175%. Going to 200% probably isn't an issue for that one as the timing can be counteracted with timing trim anyway.

I wonder what else is limited my fixed axes before the max value of 200 that may be a bad idea to exceed and also which other tables that we don't yet know about are essential to rescale.

The issue is that they're using an arbitrary axis rather than a 0-100% load/Volumetric Efficiency axis. You could scale it as "toolboxes per snap-on screwdriver" and it would have the exact same meaning as BFS. The reason being, what's 30 BFS with 300cc injectors and 30 BFS with 1000cc injectors? Quite a substantial amount. But if the axis is 100% for both, then you know it's 100% load/volumetric efficiency regardless of what the BFS value actually is. Hence why it's necessary to understand the ITAC concept rather than just simplify things down to BFS.

If you look at many professional tunes, they don't understand the concept whatsoever. They think it truly is just BFS, resulting in them not adjusting the scaler properly because they don't see the need for it. Hence why every UpRev tuned ROM I've seen always has the ITAC axes set to crazy values. One ROM even had 167%! Which is just absurd since it was NA. ITAC is too critical of a component within the ECU to simplify down to BFS. Anyone who understands the concept of ITAC would have absolutely no need to simplify it any further, as it's literally a 0-100/200% load/Volumetric Efficiency.



So wait, EcuTek claims that they're able to alter injector pulsewidth, without altering injector pulsewidth? Because ANY changes to injector pulsewidth's will result in the ITAC reading being tweaked. The ONE exception is if the adjustment took place sometime within the transition from BFS to actual injector pulsewidth. Now that I think about it, that might actually be what they're referring to. Because IIRC, ITAC is scaled by vTP, rather than vTE or one of the actual injector pulsewidth parameters. These use four ROM multipliers and a multitude of RAM multipliers not used in the vTP calculation. So I wonder if that's what they're referring to then. If that's the case, then yes, you could actually alter injector pulsewidth without affecting the ITAC axis. Since it wouldn't be affecting BFS, it would just be affecting actual injector pulsewidth.

Yes I was referring to a multiplier between BFS and actual injector pulse width.

Since starting this topic, I now suspect that mMKINJM might only apply to vehicles with a returnless fuel system as a multiplier for the compensation for having static rather than vacuum-referenced fuel pressure. I don't think my ROM has mMKINJM at all.

I've been studying some stock turbo ROMs and will re-write the first post in the next few days.

Yes mTP100 should ideally be set to 100% cylinder fill at atmospheric pressure as Pyrtrex mentioned. Thanks again for the input.

Stock turbo ROMs have fresh air rate, flame speed and probably at least a handful of others scaled up to 180 ITAC.

I always thought fresh air rate was somewhat of a measurement of exhaust dilution (naturally more dilution at lighter load so less "fresh air") but this would stop increasing once the throttle is fully open and possibly even decrease under high exhaust back pressure. It's safe to say that this is not the case. Fresh air rate continues to rise as ITAC rises to nearly double the atmospheric pressure value. Flame speed does too but I already presumed that.

It's a shame that the ZB060 A2L doesn't have boost control. It would be really interesting to learn what type of parameters influence the boost target. Torque request would be the main one. Maybe QH0 factors in current boost as well as the usual throttle parameters.

Agreed! Ive checked out EcuTek and UpRev’s little sections for the GTR, but I have no idea what’s going to be applicable for non-supercar ROM’s haha I have no doubt that boost control would be somewhat linked with the QH0 Map as well. Most likely an external calculation that then acts as a limiter for the QH0 Map value

Here's some juicy stuff. mTTPMAX, "Maximum Injector Pulsewidth Table", is used before vTP (BFS) gets set. (Within the same function) So this basically confirms that the injector compensation/scaling HAS to be within the same function. Which means any injector compensations that occur WILL affect ITAC, as this is calculated AFTER vTP is set.

On top of this, I think it's safe to say the K-Value is the primary injector scaler. vTP0 = Calculation including vQ4 (RAM), MAF Factor (ROM), K-Value (ROM), Engine Speed (RPM _ RAM), and mNREF (ROM). After vTP0 is calculated, basic compensations occur to go and set vTP, which is then used to calculate ITAC. HOWEVER, it is CRITICAL to realize that the K-Value alone can't be correlated to ANY injector size. So further analysis will be required to truly understand these calcs.

I never thought mMKINJM was an injector sizing scalar used by Nissan. I just thought it may be used as a hack to temporarily run bigger injectors without making any other changes to the tune. Since then, I realised that it's probably just a modifier for how much DC to add as manifold pressure increases in fixed fuel pressure returnless fuel systems. My ROM and probably many others, doesn't even have mMKINJM.

As you know, the A2L naming translation is terrible at the best of times. What you're describing is saying that mTTPMAX is a limit to TP/BFS and not necessarily a maximum final injector duty cycle after AFR enrichment etc is applied.



None of that excludes mQUNIT possibly being the primary injector scalar. I'm not saying I think it's one or the other but I'm just saying that those calculations taking place does not either confirm or discount that mQUNIT could be the primary MAF AND injector scalar.

I think Nissan just do a good job at matching the readable range of a given MAF sensor/tube combo to the engine and injector size so that they never need to stray far from the same mKCONST and mQUNIT values.