Tuning the NSX 3.0L Using the OEM ECU

[greenberet]

Using Matt's old definition, I had new maps programmed for my engine after installing 410cc turbo RDX injectors. The idle from a cold start is fine AFTER the PGM-FI has learned fuel trims. If the battery has been disconnected, the engine dies at idle unless the gas pedal always depressed at least a bit. Not fun.

With the stock injectors, the idle was perfect from a cold start even after the battery had been disconnected and the fuel trims had been erased. Something still needs to be adjusted in my maps so that the car doesn't have to rely on fuel trims to idle properly.

After the turbo RDX, Acura came out with an n/a RDX. Maybe those injectors, whose flow rates are between those of an NA1 NSX and a turbo RDX, would be better.

 

[BBVNSX]

After the turbo RDX, Acura came out with an n/a RDX. Maybe those injectors, whose flow rates are between those of an NA1 NSX and a turbo RDX, would be better.

Or something like this with a bit more flow:

http://www.nsxprime.com/forum/showthread.php/208707-New-Injector-Innovation-for-NSX

 

[Honcho]

out of my league here hence the question, but if i wanted to run a complete stand alone ECU, could my tuner use the definition and bin files to put a base map into my ECU?

I'm just worried about getting it to cold start and run like OEM, if this information could be useful then i can pass it on

Yes, these maps would give you the information needed for a base map on a standalone. However, these maps are calibrated for the OEM ECU logic. I can already tell that there are several other scalars and lookup tables that modify the values in the base fuel and timing maps, depending on certain engine conditions. Thus, I doubt it is a 1 to 1 transfer of information between the OEM and standalone. Still, the maps give you a pretty good idea of VE across the powerband and, if you use a VE based tuning solution (like AEM Infinity), it might get you close.

Using Matt's old definition, I had new maps programmed for my engine after installing 410cc turbo RDX injectors. The idle from a cold start is fine AFTER the PGM-FI has learned fuel trims. If the battery has been disconnected, the engine dies at idle unless the gas pedal always depressed at least a bit. Not fun.

With the stock injectors, the idle was perfect from a cold start even after the battery had been disconnected and the fuel trims had been erased. Something still needs to be adjusted in my maps so that the car doesn't have to rely on fuel trims to idle properly.

After the turbo RDX, Acura came out with an n/a RDX. Maybe those injectors, whose flow rates are between those of an NA1 NSX and a turbo RDX, would be better.

The fact that you have a stable idle means that the minimum pulsewidth for stable fuel delivery of the 410cc is below the commanded minimums in the map. Based on my early travels through the definition, my guess is that either (1) the temperature correction factor for cold cranking pulsewidth is not quite rich enough for the bigger injectors or (2) the commanded pulsewidth in the cold cranking table is too lean. It might be a combo of the two. Basically, when you warm start, I bet that the ECU is in closed loop and is applying the latest BLM to the cranking pulsewidths and enriching the mixture.

Or something like this with a bit more flow:

http://www.nsxprime.com/forum/showthread.php/208707-New-Injector-Innovation-for-NSX

The problem with those injectors is that we don't know the spray pattern or the dead times. The RDX 410cc is fully documented with a perfect spray pattern for the NSX intake manifold/head port.

 

[Honcho]

I revisited the Legend and NSX definition this past winter and made some significant changes and updates to it. I made some additions and updates to the oxygen sensor and idle parameters, cleaned up a bunch of loose ends and clarified the language a bit. One major change I was working on was an update to all fuel multipliers to use a factor instead of percentage (1.0 vs. 0%). I kind of left things mid-sentence with the updates so i will try and update it soon and share.

In the last 5 years since I released the definition I have grown leaps and bounds in my career and abilities - to the point that I'm somewhat embarrassed by the state of the public definition. I am now working for Dynojet and im back home with Honda. My current project is the Honda Talon side-by-side DCT. It's very fascinating but also all encompassing with over 2000 tables and settings controlling those 6 little cogs.

The revisit this past winter just reinforced my initial feeling of the Legend and NSX ECU. There is nothing in a modern ECU that is not happening in this 30 year old ECU - at a slightly lower resolution of course. The sheer cleverness of the engineers that designed it and made it all fit into 48K of ROM and 2K of RAM is incredible.

I let this project fall by the wayside because i just never saw any solid interest like I'm seeing in this thread. As my first love I'm always down to get the ball rolling again (if I can find the time).

P.S.
I have the entire fuel system worked out in a excel spreadsheet. You can plug in a desired pulsewidth and values for various fuel multipliers and see the final pulsewidth.

-Matt

Matt, can you send me that excel sheet? I'd really like to know the causation chain that the ECU goes through to arrive at a certain pulsewidth that we ultimately see at the injector. I was going to map the chain on a document to show how the ECU selects a pulsewidth in different circumstances. At the end of the day, we're really interested in tuning to adjust for maximum VE for different mods like headers, exhaust and more aggressive setups like mine (cams, ported heads, etc.) I'm sure that is only about 10% of the definition where we need to adjust, but still, I think the interest is there from a lot of us. The normally aspirated folks have kind of been left out in the cold since Prospeed left the community.

Also, any idea why the rev limiter is set to 7,000 for the manual trans? Is there another scalar that multiplies the value somehow to get to the 8,000 limit? Also, I can't find the fuel cut scalar. It should be set to 8,300 rpm.

 

[MotorMouth93]

Oh boy an OEM ECU tuning thread!


Creating a TunerPro ADX file presents a rather substantial challenge, it’s not really possible without patching the ECU firmware to spit out useful data. Assuming you can patch the ECU to output data in a useful way, you then need to know where the data you’re interested in resides in RAM. This is the real killer, to figure this out requires you to disassemble binary code in the CPU itself and infer from the code what RAM values do what.


Before I pulled my engine for a rebuild I had some rudimentary logging patches and ADX files working if you saw the YouTube link I posted in the FB group, but through a combination of lack of time and loss of interest I haven’t really developed it beyond that.

 

[(/O^O\)]

Well, hello there

I revisited the Legend and NSX definition this past winter and made some significant changes and updates to it.... In the last 5 years since I released the definition I have grown leaps and bounds in my career and abilities... -Matt

Hello
My '90 Legend on MDX injectors still purrrrz.
Passes emissions each two years.
Your personal report is very upbeat... good to hear, congrats.
I don't see a PM option on this site .. sry for public OT comment.

 

[Honcho]

I re-read the thread [MENTION=16606]sr5guy[/MENTION] initially made while he was developing the definition for the Legend and NSX. It looks like he had at least partial datalogging running in TunerPro RT with table X and Y axis linking over a serial connection directly into the ECU. He never mentioned doing it through a .adx definition file, so I assume he wrote custom code for this and ran it through the Ostrich interface? He did not indicate that he attached any additional header cable to the ECU for datalogging. He indicated that he had linked the memory addresses for the various parameters directly to the TunerPro definition file: "There is a list of memory addresses for the stream within the ROM chip and I have the memory addresses custom modified to suit my needs above. The Tunerpro definition file correlates directly to this list of memory addresses."

It also looks like he figured out a way to hijack a sensor input for the ECU to use with a wideband O2 sensor.

I've spent the last few days reading and re-reading the definition. I have a better idea about how the NSX handles fuel and timing. I think, based on Matt's prior work, all we need to tune the car is:

1. Moates Honda chipping kit
2. Moates Ostrich 2
3. Wideband O2 added to manifold via extra bung
4. Matt's custom program for datalogging in TunerPro RT (via the Ostrich interface?; needs to be adapted to NSX from Legend?)
5. Moates Burn 2
6. TunerPro RT

He also got the RDX injectors to work in his Legend, so it only makes it more appealing for the NSX, as he has the dead times and pulsewidths figured out.

Matt- were you using the Hulog cable and the 4-pin header for your datalogging on the Legend ECU, or were you using the ROM tracing feature in the Ostrich?

 

[MotorMouth93]

I re-read the thread @sr5guy initially made while he was developing the definition for the Legend and NSX. It looks like he had at least partial datalogging running in TunerPro RT with table X and Y axis linking over a serial connection directly into the ECU. He never mentioned doing it through a .adx definition file, so I assume he wrote custom code for this and ran it through the Ostrich interface? He did not indicate that he attached any additional header cable to the ECU for datalogging. He indicated that he had linked the memory addresses for the various parameters directly to the TunerPro definition file: "There is a list of memory addresses for the stream within the ROM chip and I have the memory addresses custom modified to suit my needs above. The Tunerpro definition file correlates directly to this list of memory addresses."

It also looks like he figured out a way to hijack a sensor input for the ECU to use with a wideband O2 sensor.

I've spent the last few days reading and re-reading the definition. I have a better idea about how the NSX handles fuel and timing. I think, based on Matt's prior work, all we need to tune the car is:

1. Moates Honda chipping kit
2. Moates Ostrich 2
3. Wideband O2 added to manifold via extra bung
4. Matt's custom program for datalogging in TunerPro RT (via the Ostrich interface?; needs to be adapted to NSX from Legend?)
5. Moates Burn 2
6. TunerPro RT

He also got the RDX injectors to work in his Legend, so it only makes it more appealing for the NSX, as he has the dead times and pulsewidths figured out.

Matt- were you using the Hulog cable and the 4-pin header for your datalogging on the Legend ECU, or were you using the ROM tracing feature in the Ostrich?

The way datalogging works on OBD1 Honda ECUs (including the NSX ECU) is through the onboard serial communication lines. Civic/Integra ECUs have these in an easily accessible header on the board but the NSX ECU pins are just routed to test points on the ECU board and headers must be installed manually. This process is detailed in sr5guys original thread. You can connect the ECU to TunerPro RT using a standard USB-to-UART cable like this: https://www.adafruit.com/product/954

By default, the NSX ECU just dumps a bunch of crap out the serial port constantly, IIRC it has a list of 60 something addresses that it spits out, some of it is useful data but most of it isn't. To actually get useful output for tuning, the list of data dump addresses must be updated to include useful data.

When he refers to memory addresses, he is referring to the addresses of various engine parameters within the ECU itself, for example the throttle position might be at address 0xDEAD and the calculated load might be at address 0xBEEF and so forth. Once these addresses are identified, the ECU can be programmed to output their values in a serial stream and a TunerPro ADX file can be created to read the stream through the serial cable I linked above.

The Ostrich has no datalogging interface, but it does have address tracing, meaning it will show you what addresses in the tables the ECU is accessing at any given time.

The Moates Demon does have datalogging capability and that is what I was using in my ECU. The Moates datalogging interface is poorly documented and doesn't work all that well though so you are much better off just using a 2nd USB cable like I linked above. The demon also has analog inputs that can be used for wideband O2 sensor inputs.

That said, just buying the USB cable won't get you very far. You still have to find the list of addresses in the ROM chip, disassemble the code to figure out how they are written out, extract the internal CPU ROM code from the main processor, and then disassemble that to try to figure out the RAM addresses. Sr5guy spent 5-10 years working on this, it is not an easy or quick process.

Last I talked to sr5guy, time permitting, he was planning on selling a rather fancy tuning solution for NSX and Legend ECUs at some point.

 

[nsxspdfreak]

Lots of great information here! I recently installed Bosch 18 hole 315cc injectors in my car which has headers, test pipes and allegedly a Dali chipped ECM. So far the car is performing flawlessly with a smooth idle and instant starts even after reconnecting the battery which is kept disconnected while it's parked in the garage, and just by the not so calibrated seat of my pants it feels like it's improved power. Hopefully after the NSXPO I'll have time to get it on a dyno to see how it's actually performing and how the ECU is handling it.

 

[SWFL_NSX]

I let this project fall by the wayside because i just never saw any solid interest like I'm seeing in this thread. As my first love I'm always down to get the ball rolling again (if I can find the time).
-Matt

Yes, there is definitely interest in the community as well as advantages for everybody if we can make the OE ECU tunable. These cars are becoming expensive to maintain and modify and I suspect that an OE ECU will take care of 99% of everyone's tuning needs at a much lower price than existing solutions.

So what is the next step in the project, and how can a group of well-intentioned owners help?

 

[cutsheal5]

I’m in for this I think this is long long over due. Stand alone ecus are nice but a factory ecu that’s tuned for the car is way way better unless it’s a full blown race car imo. I have a socketed and chipped ecu in my nsx right now, if there is any way I can help please let me know. I will ask around my group of friends to see if anyone still has the stuff to use Crome or Neptune software to read these ROM chips anymore and see if I can get the tune file off it. It might give us a good head start.

 

[Scrapdog2grand]

What is odd is that the main RPMLimiter appears to be set at 7,000 rpm. This makes no sense, as the factory service manual is clear that, for the manual transmission, the RPM limiter is 8,000 rpm with a fuel cutoff at 8,300 rpm.

7000 rpm limiter is for limp mode.

 

[MotorMouth93]

I’m in for this I think this is long long over due. Stand alone ecus are nice but a factory ecu that’s tuned for the car is way way better unless it’s a full blown race car imo. I have a socketed and chipped ecu in my nsx right now, if there is any way I can help please let me know. I will ask around my group of friends to see if anyone still has the stuff to use Crome or Neptune software to read these ROM chips anymore and see if I can get the tune file off it. It might give us a good head start.

The current tuning solution for NSX ECUs uses TunerPro, Crome and Neptune do not support it. The EEPROMs are the same though so whatever ROM reading tool they might have should work for the NSX.

 

[B2FiNiTY]

if you build it, they will come.

me included.

 

[MaxGeek]

Would love to see this even though I'm OBD2.

 

[Honcho]

Oh boy an OEM ECU tuning thread!


Creating a TunerPro ADX file presents a rather substantial challenge, it’s not really possible without patching the ECU firmware to spit out useful data. Assuming you can patch the ECU to output data in a useful way, you then need to know where the data you’re interested in resides in RAM. This is the real killer, to figure this out requires you to disassemble binary code in the CPU itself and infer from the code what RAM values do what.


Before I pulled my engine for a rebuild I had some rudimentary logging patches and ADX files working if you saw the YouTube link I posted in the FB group, but through a combination of lack of time and loss of interest I haven’t really developed it beyond that.

The way datalogging works on OBD1 Honda ECUs (including the NSX ECU) is through the onboard serial communication lines. Civic/Integra ECUs have these in an easily accessible header on the board but the NSX ECU pins are just routed to test points on the ECU board and headers must be installed manually. This process is detailed in sr5guys original thread. You can connect the ECU to TunerPro RT using a standard USB-to-UART cable like this: https://www.adafruit.com/product/954

By default, the NSX ECU just dumps a bunch of crap out the serial port constantly, IIRC it has a list of 60 something addresses that it spits out, some of it is useful data but most of it isn't. To actually get useful output for tuning, the list of data dump addresses must be updated to include useful data.

When he refers to memory addresses, he is referring to the addresses of various engine parameters within the ECU itself, for example the throttle position might be at address 0xDEAD and the calculated load might be at address 0xBEEF and so forth. Once these addresses are identified, the ECU can be programmed to output their values in a serial stream and a TunerPro ADX file can be created to read the stream through the serial cable I linked above.

The Ostrich has no datalogging interface, but it does have address tracing, meaning it will show you what addresses in the tables the ECU is accessing at any given time.

The Moates Demon does have datalogging capability and that is what I was using in my ECU. The Moates datalogging interface is poorly documented and doesn't work all that well though so you are much better off just using a 2nd USB cable like I linked above. The demon also has analog inputs that can be used for wideband O2 sensor inputs.

That said, just buying the USB cable won't get you very far. You still have to find the list of addresses in the ROM chip, disassemble the code to figure out how they are written out, extract the internal CPU ROM code from the main processor, and then disassemble that to try to figure out the RAM addresses. Sr5guy spent 5-10 years working on this, it is not an easy or quick process.

Last I talked to sr5guy, time permitting, he was planning on selling a rather fancy tuning solution for NSX and Legend ECUs at some point.

Hi [MENTION=33247]MotorMouth93[/MENTION]! Welcome to the party lol. Honestly, I have so much mechanical work to do on the car at this point that I would just pay for the tuning solution. But, it is also really fun learning how to do this myself. I purchased this book and read it cover to cover: https://www.amazon.com/Engine-Management-Advanced-Greg-Banish/dp/1932494421. While I already knew come of the material, it really filled in the blanks on the fundamentals. I re-read the [MENTION=16606]sr5guy[/MENTION] thread again (so much great content in there!) and Matt has an ADX file for datalogging that he did not release with the definition. He also uses a NVRAM flash memory solution in place of the Ostrich that allows real-time emulation and parameter changes via direct connection to the MCU. It looks like he re-programmed the MCU itself (amazing) to handle both the datalogging and ROM write functions, so you don't even need the Ostrich or Demon. However, he never released that hardware and it's unclear if he ever will. So, I'm going to focus on creating an ADX file that will give us enough info for good tuning using an Ostrich or Demon hardware solution. If you want to collaborate, let me know! I firmly believe that a C30A with cams, injectors, headers and an enlarged intake tract is capable of a factory-reliable 120 hp/liter. My roadblock now is the tuning solution, so... here I am. It seems I am taking up the NSX tuning mantle from Prospeed LOL.

The following nodes on the ECU board will allow serial data collection from the MCU:

(JP21 MCU SI Transmit [TXD]) (L5 MCU SI Receive [RXD]) (G6 Ground)

MotorMouth93, you said you were getting limited datalogging off of the ECU- do you know if I need the ground lead for the USB ALDL cable you linked? Some Honda tuning forums have indicated just the TXD and RXD wires are required for datalogging in TunerPro RT. If I solder some header pins to these nodes, we can at least start seeing the data streams. Does the ECU board require any resistors or jumpers to enable datalogging, or is it always running in the background? I ask because most B-series ECUs require jumpers and capacitors to enable datalogging through the 4-pin header. Even if I can get the connection working, it's probably going to be a bunch of random numbers unless we can figure out where the PID addresses are. If you think the USB direct to laptop datalogging method is better than the demon, then I will go that way. It seems cleaner anyway. You would then have three USB inputs into, right? (1) Datalog ALDL cable from ECU (2) Ostrich from EPROM socket (3) Wideband O2. Matt mentioned "hijacking" an unneeded ECU pin (A/C Pressure, for example) to feed the wideband data, but isn't it easier to hook the wideband controller directly to the laptop via an ALDL USB cable and use TunerPro to display the output?

Matt identified 3 separate serial data streams coming from the ECU:
1. Bi-directional full duplex - send it a memory address and it responds with a value (extremely difficult to use/modify)
2. 14 byte one-way stream read from a list of (modifiable) memory addresses in the ROM.
3. 66 byte one-way stream read from a list of (modifiable) memory addresses in the ROM. (slow updates - about once per second)

Matt also figured out how to modify the streams to any number of bytes he wanted, and predicted that even a 30 byte stream would still have enough update resolution to be useful for tuning. That's way beyond my ability, so I will try to use the default 14 byte stream, as I think it can display enough information to permit adequate tuning of the car, especially if you break up the tuning session into "FUEL" and "TIMING" phases. Using the 14 byte stream, which updates about once per millisecond, we can monitor up to 14 different PIDs, assuming we can find the addresses for the data and the formulas needed to convert the raw numbers to real world values.

Of course, all I will get is the MCU vomiting numbers at me and without the adx file to tell TunerPro how to read the streams, it's gonna be tough to get a working dashboard. Still, Matt provided some clues for us:

Coolant Temp (CTS) --> 0xFCDF --> Formula for Deg F = (x - 40)
RPM (RPM) --> 0xFC52 --> Formula = (x*28)
Intake Temp (IAT) --> 0xFCCF
Calculated Load (LOAD) --> 0xFCB2

Here are the data items I think we would need to tune the car properly. Ideally, you would tune fuel first using a wideband and then tune timing. A lot of the fuel tuning could be done on the street driving around, but final adjustments and timing would require a dyno that can apply a static load and rpm to the car so you can tune each cell.

[[FUEL]]
RPM
Load
Coolant Temp
Intake Temp
STFT
LTFT
Open/Closed Loop Status
Final Inj Pulsewidth
Accel Enrich Inj Pulsewidth
Manifold Pressure
Inj Duty Cycle
Current Fuel Map

[[TIMING]]
RPM
Load
Coolant Temp
Intake Temp
Base Timing
Final Timing
Knock Correction
Current Timing Map

Lots of great information here! I recently installed Bosch 18 hole 315cc injectors in my car which has headers, test pipes and allegedly a Dali chipped ECM. So far the car is performing flawlessly with a smooth idle and instant starts even after reconnecting the battery which is kept disconnected while it's parked in the garage, and just by the not so calibrated seat of my pants it feels like it's improved power. Hopefully after the NSXPO I'll have time to get it on a dyno to see how it's actually performing and how the ECU is handling it.

That's great! I'd be interested to see your LTFT and STFT data, as I bet the ECU is trimming pretty hard in closed loop- those injectors are about 25% larger than the stockers! Also, I would expect that your open loop AFRs are rich, which is safe. Though, we think that the ECU applies the last LTFT to the WOT map, so I wonder if that trims it back closer to the factory AFR for open loop? If you gather data on this, please share it!

 

[BBVNSX]

Since the car is now 30 YO would it be impossible to get this information directly from Honda?

You can call me crazy... But it came to my mind... :redface:

 

[MotorMouth93]

It is impossible to reprogram the MCU, the programming was burned in during fabrication and cannot be modified or updated. The only way to change the MCU programming would be to buy a new MCU and program it, but you can only program them once so every time you updated anything you'd need a new chip. Doable yes, but expensive to keep buying chips for each update and not really necessary for NA applications. Some of the MCU code is located on the external ROM though, and it is possible to inject custom code here which is where Matt added code for the NVRAM.


His NVRAM solution works like an EEPROM emulator, the code to make it work is placed in the empty regions of the external ROM. It essentially does the same thing as an Ostrich - allow real time changes to the external ROM - but at a much better price point.


Yes you need a ground wire in addition to the TX and RX lines, otherwise there is no stable voltage reference for the TX and RX lines. I soldered single pin headers to the TX, RX, and ground test points on my spare ECU so I could easily plug in the USB adapter. That's all you need to see the default data output, no capacitors or jumpers or anything. The Demon would be a cool all-in-one solution but until I have time to pester the Moates engineers more about how to get it working the way their documentation says it should the data rate you can get with it is just too slow, direct to laptop is better as of right now. This video is using the Demon for datalogging and you can see it's getting data packets at a rate of about 10/second which is okayish I guess but if it was working properly it would be double that.


https://www.youtube.com/watch?v=zjeEhdT3s0k


The default mode is the 66 byte stream, if you look in the external ROM you can find the list of memory addresses it uses, I played around with that and the other modes but ended up just doing sort of like Matt did and writing my own data output routines that could do any number of bytes I wanted.

 

[Honcho]

Yes, there is definitely interest in the community as well as advantages for everybody if we can make the OE ECU tunable. These cars are becoming expensive to maintain and modify and I suspect that an OE ECU will take care of 99% of everyone's tuning needs at a much lower price than existing solutions.

So what is the next step in the project, and how can a group of well-intentioned owners help?

Next step is getting reliable datalogging. I now know how to pull the data off of the ECU via hardware. I just need to figure out how to put together a ADX file for TunerPro that can translate that data into useful information for tuning.

I’m in for this I think this is long long over due. Stand alone ecus are nice but a factory ecu that’s tuned for the car is way way better unless it’s a full blown race car imo. I have a socketed and chipped ecu in my nsx right now, if there is any way I can help please let me know. I will ask around my group of friends to see if anyone still has the stuff to use Crome or Neptune software to read these ROM chips anymore and see if I can get the tune file off it. It might give us a good head start.

The ROM is already "read" in that Matt's TunerPro ECU definition contains a complete map of the NSX ECU. The big roadblock right now is datalogging.

7000 rpm limiter is for limp mode.

Weird that is says RPM Limiter - Normal. The limp mode limiters (A and B) are set at 4,000 rpm. I wonder if "normal" limiter is a function of a multiplier?

if you build it, they will come.

me included.

Me too! I've gotta get these Comptech heads working if I want to drive the car, so I'm motivated!

Would love to see this even though I'm OBD2.

Gonna be tough, as the EPROM information is burned into the MCU itself and is not on a separate chip. You're probably better off converting to a cable-throttle manifold and using a 91-94 ECU. With proper tuning, your engine will run fine.

Since the car is now 30 YO would it be impossible to get this information directly from Honda?

You can call me crazy... But it came to my mind... :redface:

Honda will never release this information, for a variety of reasons- all of which are good reasons from Honda's perspective. By the way, you were right in your earlier post here- after a considerable amount of research, it looks like the MDX/RDX/RL 310cc injector is ideal for the N/A application. It has an identical spray pattern to the RDX 410cc, but a lower flow rate which should help the low pulsewidth mapping and operation, e.g., idle. I'm going to go with this solution. The part number is 16450-R70-A01. I may send one to RC Engineering so they can map the latency (aka dead times). That way, we can scale it accurately in TunerPro, as the NSX ECU uses a latency table for the injectors. Also, the B/D top hats and RDX harness plugs should fit perfectly. I need to confirm with [MENTION=13737]OLDMNSX[/MENTION] whether his sealing rings will work with these, though I think they will as the injector body appears identical to the RDX. 310cc should support any conceivable 3.0L N/A application other than a full race engine.

 

[Scrapdog2grand]

Weird that is says RPM Limiter - Normal. The limp mode limiters (A and B) are set at 4,000 rpm. I wonder if "normal" limiter is a function of a multiplier?

Perhaps it base map for operation prior to vtec engagement. When you have an existing trouble code for the vtec system, normal engine operation without vtec system engagement has 7k rpm limiter.

 

[Old Guy]

As a thought, does this car need to be emission compliant? If not, why not force it to run (or effectively run) in open loop all the time? This eliminates your problem with the long term fuel trim values adjusting the parameters in the high load portion of the fuel map. Remember that O2 closed loop control was introduced as a means to insure emission compliance. It was not introduced as an engine performance enhancement function. Its sole purpose is to insure that during the extended emission warranty period the engine runs at 14.7 AFR. This accommodates manufacturing variations between engines and gradual drift in such items as fuel pressure, plugged air filters, dirty air temp sensors ....... If you are confident in the values in the fuel map then you should be confident enough to run open loop.

 

[Honcho]

As a thought, does this car need to be emission compliant? If not, why not force it to run (or effectively run) in open loop all the time? This eliminates your problem with the long term fuel trim values adjusting the parameters in the high load portion of the fuel map. Remember that O2 closed loop control was introduced as a means to insure emission compliance. It was not introduced as an engine performance enhancement function. Its sole purpose is to insure that during the extended emission warranty period the engine runs at 14.7 AFR. This accommodates manufacturing variations between engines and gradual drift in such items as fuel pressure, plugged air filters, dirty air temp sensors ....... If you are confident in the values in the fuel map then you should be confident enough to run open loop.

I actually had a super long post on this typed up. I went to add a tab to Chrome to check something and hit the X by accident! I'm still so mad about it but the short version is that you want to have some closed loop on the car. It's good for keeping your cats clean and also for cleaning the combustion chamber. The trick is to shrink the closed loop region of the maps to only what is needed for light throttle or steady state cruising. Honda made more of the maps fall under closed loop for emissions purposes as you noted. Running those cells in open loop with ideal AFR and timing will yield considerable improvement in power. Lots of area under the torque curve at almost every cell. More to follow but I'm still torqued about losing that post. I had charts!!

 

[MotorMouth93]

Though, we think that the ECU applies the last LTFT to the WOT map, so I wonder if that trims it back closer to the factory AFR for open loop? If you gather data on this, please share it!

http://www.nsxprime.com/forum/showthread.php/183112-Fuel-trim-in-open-loop-operation

According to sr5guys post in this thread, fuel trims are not applied in open loop "power enrichment" operation. If fuel trims were applied in open loop the mixture would stay around 14.7:1 which defeats the whole purpose of switching to open loop under load. I don't remember if the XDF has parameters for defining the conditions for when the car changes from open to closed loop or not though, it's been a while since I've looked at it.

Also I have one of OLDMNSXs RDX kits so if anyone has a spare injector floating around I'd be happy to test it to see if it fits properly.

 

[Old Guy]

It's good for keeping your cats clean and also for cleaning the combustion chamber. The trick is to shrink the closed loop region of the maps to only what is needed for light throttle or steady state cruising. Honda made more of the maps fall under closed loop for emissions purposes as you noted.

Its not running in closed loop that keeps the combustion chamber clean, its running at an AFR of 14.7 that keeps the combustion chamber clean. I am not advocating that you deviate from 14.7 in the closed loop portion of the fuel map (unless you want to). Its just that if that section of the map is set up correctly and everything else is working correctly, the engine will run at 14.7 in those map cells with no need for O2 correction (perhaps a bit of an exaggeration depending on whether the control algorithm extrapolates between fuel cell values). However, if you are running cats with an expectation that the vehicle will be subject to emission tests my suggestion is dead on the doorstep. The AFR of the pre cat exhaust gas on a closed loop emission controlled engine dithers (it continuously fluctuates above and below 14.7). When the AFR goes above 14.7 it supplies a small amount of O2 to the cat surface which facilitates the conversion process on 3 way cats. Without that surplus O2 the conversion process efficiency goes in the toilet and some vendors suggest that the cat will suffer permanent impairment if the condition is sustained. That dithering may be built into the fuel control algorithm; but, I am a little suspicious that it is a useful natural bi-product of the highly non linear output of narrow band O2 sensors. Whatever the source of the dithering, if you force the ECU into continuous open loop operation I expect that you lose the dithering which means that the cats will be impaired. So, perhaps not an option.

However, in line with this thought if the concern is that the ECU treats the long term fuel trim as a global variable applied to all fuel cells, have you considered the possibility of continuously writing 128 (no correction) into the memory locations for the long term fuel trims? You would still have active short term fuel trim for the closed loop portion of the fuel map and you wouldn't have to worry about some long term fuel trim corrupting other portions of the fuel map. I run an ECU (not an NSX) with no long term trim (because it gives me that option) and it operates just fine. I will admit I haven't quite thought through on the continuously writing over thing.

 

[MotorMouth93]

Its not running in closed loop that keeps the combustion chamber clean, its running at an AFR of 14.7 that keeps the combustion chamber clean. I am not advocating that you deviate from 14.7 in the closed loop portion of the fuel map (unless you want to). Its just that if that section of the map is set up correctly and everything else is working correctly, the engine will run at 14.7 in those map cells with no need for O2 correction (perhaps a bit of an exaggeration depending on whether the control algorithm extrapolates between fuel cell values). However, if you are running cats with an expectation that the vehicle will be subject to emission tests my suggestion is dead on the doorstep. The AFR of the pre cat exhaust gas on a closed loop emission controlled engine dithers (it continuously fluctuates above and below 14.7). When the AFR goes above 14.7 it supplies a small amount of O2 to the cat surface which facilitates the conversion process on 3 way cats. Without that surplus O2 the conversion process efficiency goes in the toilet and some vendors suggest that the cat will suffer permanent impairment if the condition is sustained. That dithering may be built into the fuel control algorithm; but, I am a little suspicious that it is a useful natural bi-product of the highly non linear output of narrow band O2 sensors. Whatever the source of the dithering, if you force the ECU into continuous open loop operation I expect that you lose the dithering which means that the cats will be impaired. So, perhaps not an option.

However, in line with this thought if the concern is that the ECU treats the long term fuel trim as a global variable applied to all fuel cells, have you considered the possibility of continuously writing 128 (no correction) into the memory locations for the long term fuel trims? You would still have active short term fuel trim for the closed loop portion of the fuel map and you wouldn't have to worry about some long term fuel trim corrupting other portions of the fuel map. I run an ECU (not an NSX) with no long term trim (because it gives me that option) and it operates just fine. I will admit I haven't quite thought through on the continuously writing over thing.

I can confirm that there is an interpolation routine that runs on the fuel and ignition tables when they are accessed by the MCU.

There is a bit in the ROM that disables both long term and short term fuel trims in the XDF, so for tuning the cells you'd just do this and use a wideband to dial everything in.

Maybe I'm missing something obvious, but I don't see why you'd want to try to disable only the long term fuel trims. The ECU doesn't apply any fuel trims during open loop operation as shown in the thread I linked above and disabling fuel trims removes the ECU's ability to detect issues such as vacuum leaks or clogged injectors that could potentially cause a dangerous lean condition. I could see an argument for shrinking the region the ECU operates in closed loop for better part throttle power, but getting rid of it altogether seems pointless at best and dangerous at worst since it's pointless to run richer under low load cruising most cars spend most of their time.