Tuning the NSX 3.0L Using the OEM ECU

[mskrotzki]

Here is a screen shot of my TunerPro -- exactly as you describe, except my setup defaulted to COM 3 for the USB to Serial port when I plugged in the Demon. The Demon II red and green LEDs perform as described for proper operation. When I press the double arrows for data acquisition, the annunciator turns orange and says DA Connecting -- and just sits there. As Winnie The Pooh says: "It is a puzzlement.

I hooked up my WBO2 with no problems -- short of being 6'4"and crawling around the firewall. I need to be a damned contortionist!" Once I get the working I'll add it to the Dashboard.

Thanks again.

 

[MotorMouth93]

The ADX file you are using is very old and not compatible with the more recent ECU logging patches.

I've created a new directory called Releases in the google drive, from here on out, I'll be uploaded sets of files that all work together so there is no question about what file are needed to work. The first release is 1.0 alpha, I would recommend you go download all of those files and see if that works, then if it does pull in the fuel values from whatever binary you are trying to use now.

The 1.0 alpha release is binaries that I've tweaked for use in my own car and put a decent number of miles but as always use at your own risk. EGR will be disabled by default in releases since I don't want to deal with tuning the EGR fuel tables.

 

[mskrotzki]

Great. I'll try them out tomorrow and see how it goes.

I've passed air inspection, so that is behind me. Any potential downside to running without EGR over a period of time?

Thanks again and I'll let you know how it goes.

Mark

 

[jvtec95]

In case others are thinking of chipping their ECU, I wanted to share my setup. Mark noted that the Demon interface is a little iffy and he had to brace it. I wasn't very happy with the USB connection directly to the board (you have to press on the board/socket interface and the connector is pretty far inboard of the opening since the board wasn't really designed for the NSX ECU), and using that connection means the cable exits below the ECU (a little tricky to connect/disconnect). I used the included remote USB connection and ran that out the side of the ECU close to the center console. This means I'm never putting pressure on the Demon board, and the connection can be reached with simply removing the rear upper bulkhead cover. It also is easy to route through the console if desired (this is where I have all my wideband wires/controller/gauge mounted). Note, when using the Demon II on it's intended ECU the datalogging connector provides some additional support which isn't present when using on the NSX (you must re-route the datalogging wires from the unit to the ECU locations).

This is the connector I'm using on the board, as it allows secure installation of either a EPROM or the demon unit:

https://www.hamotorsports.com/collections/ecu-parts-diy-kits/products/28pinsocket

Here's my ECU mounted with the Demon II unit installed, remote USB exiting to the right, my analog signals & ground from wideband coming from the center console and up through the first USB cable routing I had used (direct to the Demon board). I used a different later-model bracket to mount my main relay lower to move it out of the way for clearance. If you're careful it may be possible to put the remote USB connector lower and miss the main relay in it's standard position.



Then I keep this in my car "just in case", a burned EPROM chip with my current .bin file installed on a ZIF socket (you could use just the chip, but I've found it can be difficult to install/remove these chips without bending the pins). Note the pins on the ZIF socket are thicker than the ones on an EPROM chip (thin & flat).





Again, I've never heard of anyone having issues with the Demon II installed, but I will be swapping the unit out to my Integra for tuning so once I'm happy with the map and no longer datalogging I'll run with the burned chip installed.

Just wanted to share my setup for others to see! Here's my "no cutting"dual wideband sensor location, I've since re-ran the wires to go through the center console area and out near the interface to the carpet for a cleaner wire routing.

 

[jvtec95]

My $0.02 on running without EGR, if you drive a lot and are interested in MPG then I'd just keep it. It should only come into use during cruising at those loads/speeds and will not affect power in any way. The only real downside is that running EGR will have some contaminate forming in the intake manifold (if you've ever cleaned out your manifold you'll know what I'm talking about). Oil bypass and EGR contaminate will combine and form some sludge in the intake manifold. I'm not sure how much of each contributor is guilty, but it is likely a combination of the two.

If you don't care about MPG, then cap it off and disable it via ECU. In theory the intake manifold doesn't see exhaust gas contaminate and ECU tuning now takes 1 fuel table out of play to worry about! I will probably do this in the future, but for now I've scaled the fuel maps accordingly and haven't noticed any issues with it still used.

I think [MENTION=33247]MotorMouth93[/MENTION] is running with EGR disabled, he may have some additional input.

 

[mskrotzki]

Thanks for the write-up on your setup. I really think we should gather all this information into one thread. Now that the code is mostly available more people may want to play around and this would be a good repository. Perhaps one of the moderators can pull this off. I'll do it if I can figure out the method.

From my tagline you can see that I am very interested in fuel mileage, so therefore to want to run EGR. I've just finished looking at the difference between Partial Throttle tables and EGR tables and they are very different. In fact most of the pulse widths are wider for EGR, but there are a number of other PW modifiers before the injector fires. I'll look in them tomorrow.

There is a flag in the code to Set EGR System & Valve Lift Sensor Switch -- I think it is switched on. I have (I think) added a data collection point to see when the EGR is open and also put it on the dashboard. I'll try that out tomorrow too.

 

[MotorMouth93]

The NSX EGR system is crude at best and only monitors valve lift and not gas flow. If the passages become clogged, flow is reduced but the ECU can't tell which can result in lean conditions and knock. To me, the marginal emissions benefits do not outweigh the value of removing a potential failure point and cleaning up the engine bay a bit. It also adds another fuel table to tune.

Adding a dash field to display EGR status should be pretty simple as the byte containing that flag is already in the data stream.

@jvtec95 that looks like a good way to deal with the USB connection, I wonder if something similar could be done with the analog wires for the O2 sensors.

 

[mskrotzki]

I want on a logging drive to Paul's house to see how his type S is coming along. Here is a playback of the (~25 mile) drive through diffenent driving conditions. Surprised to see just how fast I did go (part on a 75 MPH speed limit I-25)

https://www.facebook.com/nancy.r.crow/videos/10221383780918925

Aside from the rather wide AFR swings on cruse control, pretty much all seems to be fine. I have not gotten the EGR lift to respond -- I can't find the place to put the actual EGR address into TunerPro. I can found most anything but not quite everything. I've never done assembler, so this is quite a learning experience, which I am enjoying immensly.

What occurs to me to do, is find out how to determine which fuel map it is using at any precise time. Then from knowing exactly what the final pulse width is at that time, do a data analysis on all the things that alter the map value. Maybe I can find something, perhaps not, but why not give it a try. I used to be able to make SQLServer dance and was able to find things unimagined. But that was simply data, not real world empirical happenings.

Stay safe everybody

 

[MotorMouth93]

Aside from the rather wide AFR swings on cruse control, pretty much all seems to be fine. I have not gotten the EGR lift to respond -- I can't find the place to put the actual EGR address into TunerPro. I can found most anything but not quite everything. I've never done assembler, so this is quite a learning experience, which I am enjoying immensly.

If you look in some of the reverse engineering spreadsheets I've created you'll see that the EGR status bit is in the same data byte as the power enrichment status bit, so to get EGR status all you need to do is add an entry to the ADX that looks at this bit, using the power enrichment status entry as an example. I'll probably just include an EGR flag by default in the "beta" release.

Actually adding new data addresses to the logging stream from the ECU is a rather in depth exercise and is not required here. You have to change the parameter for number of log bytes, add another address to the log list, add values in the adx file to interpret the new data, then modify the Demon initialization sequence to make it look for the new data. It's worth noting that the Demon is very finicky, it doesn't seem to like packet sizes of greater than 16 bytes.

What occurs to me to do, is find out how to determine which fuel map it is using at any precise time. Then from knowing exactly what the final pulse width is at that time, do a data analysis on all the things that alter the map value. Maybe I can find something, perhaps not, but why not give it a try. I used to be able to make SQLServer dance and was able to find things unimagined. But that was simply data, not real world empirical happenings.

That is a very painful way to go about it. Using a combination of the VTEC and PE status indicators you already can tell exactly which fuel map is being used (if you have EGR disabled) and if you enable data tracing in tunerpro it will show you exactly which cells in the fuel table are being used at any given time. If you have EGR enabled you'll need to use the EGR status bit to tell when the EGR table is being used.

 

[mskrotzki]

I know the packet is STAT0 from the reverse engineering sheets posted. What I don’t know is how to get that packet into the ADX editor.Here is the entry for PE





The offset seems to be base 0, and I just took a wild guess at the equation

I also made a Bitmask entry for EGR, trying to get a Status (Flag) gauge type.


It seems the Bitwise AND for bit 7 should be 0x40, but I could be wrong; It wasn’t for VTEC, which is bit 7 of STAT1.

It has been really interesting looking at the history files, and being able to see the running sample count. With this knowledge it is easy to determine any spurious entries and discount them. All in all, TunerPro is an amazing application, especially since it is the work of one individual over a period of many years.

 

[MotorMouth93]

The packet offset is the index of the byte within a data packet received from the ECU, so it needs to be the same as the PE field, so 0x6.

The reason for having both flags and values for PE and VTEC is that flags can show up as on/off in dashboards and values can be displayed in the graphs. When PE or VTEC engage you'll see a horizontal line appear at the bottom of the graph (green for PE, purple for VTEC) so it's very easy to tell what fuel map is being used at any given time in the graph view.

The function of the data conversion is to take the bit value and turn that into an output value that will appear near the bottom of the graph. In the case of the PE value, it's ((X&0x20)/32)*0.4. The innermost parenthesis containing the logical AND operation removes all bits but the PE bit, so the result is either 0 or 32 (in binary that is 0b00100000, hex 0x20), dividing that by 32 results in possibly outputs 0 or 1, then multiplying by 0.4 means that the horizontal line that appears in the graph will be at y=0.4 when PE is active or y=0 when PE is inactive.

For EGR you'd need to modify the conversion to look at bit 6 instead of bit 5 and change the division and multiplication to place it at the desired y value when EGR is active, probably 0.3 or 0.6 as to not overlap with the VTEC and PE indicators.

For the bitfield, you just need to make the packet offset 6 instead of 7, the operand and result to test are correct in that photo.

 

[mskrotzki]

Thanks for the information. I have the EGR working now. I've changed the appearance of the dashboard to be able to read it easier on the passenger seat.

Now I would like to add a status field for open/closed loop. I believe I need to access B1O2STAT, 0xFD6C bitfield 7: False (0) is open loop, True (1) is closed loop The packet offset is 0x07 and the conversion is ((X&0x80)/32)*0.7. When I make a status monitor and add it to the dashboard I just get a blank spot in the lower left of the dashboard (which is where the monitor is supposed to be).

Do you have time to guide me to the fix?

 

[MotorMouth93]

Power enrichment = open loop. When PE is on, the car is in open loop, when off, closed loop fueling is used and fuel trims are applied.

0xFD6C/B1O2STAT is not included in the logging stream so there is no way to access it without modifying the logging addresses and demon settings.

 

[mskrotzki]

Power enrichment = open loop. When PE is on, the car is in open loop, when off, closed loop fueling is used and fuel trims are applied.

0xFD6C/B1O2STAT is not included in the logging stream so there is no way to access it without modifying the logging addresses and demon settings.

Power enrichment = open loop. When PE is on, the car is in open loop, when off, closed loop fueling is used and fuel trims are applied.

0xFD6C/B1O2STAT is not included in the logging stream so there is no way to access it without modifying the logging addresses and demon settings.

OK, Thanks for the explanation -- it make sense. Is there somewhere the logging stream is documented. I've not been able to find any of the packets listed in the reverse engineering documents in the bin, fdx or adx files. I have yet to discover where these files get their information.

Do you have a feeling how much the AFR should swing during steady state, cruise control driving? Mine seem to swing a lot - 1 - 2 or more points, which seems high. Average values seem just fine in the history tables, right around 14.7. It occurs to me that it may be a function of the cruise control quickly adjusting the throttle in increments too small to be measured by the Demon -- or it could be instrumention fluke (WBO2).

I'd love to hear your thoughts.

 

[docjohn]

I'm impressed with your abilities....

 

[MotorMouth93]

Swinging from 14-16 or so in closed loop is normal.

I played around with TunerPro's ability to compile AFR tables like that but the data they produce is kind of crappy as it lumps all 4 (or 5 including EGR) fuel maps worth of AFRs into one table. That's why the python script I wrote spits out 4 AFR tables instead of 1, it sorts the AFRs based on which fuel table was in use at the time.

The folder in the XDF titled Moates Demon II Datalogging contains the patch containing my datalogging binary patches as well as parameters to control the data stream from the ECU including packet size, address list, and the header byte definition. Anything changed there will require the ADX file to be updated to match.

 

[mskrotzki]

Thanks for the reply. Glad to hear the swings in AFR are typical. I've seen some comments on other EFI systems where thay are talking about 3 - 5% swings, but they are clearly different systems.

I am unable to find a file called Moates Demon II Datalogging. I do have a file called NSX OBD1 ECU Runtime Parameter RAM Addrsses which seems to have that type information in it.

I did download your python script and also an app to run it. I started along a pythod tutorial -- seems like a nice language. I attempted to attach oe of my log files to it, even changed the name of it to match your parameter, but got an incomprehensible error messange. Then I got my car back and the weather turned nice soooooo, I need to get back to it.

I still have another 500 miles or so to drive before getting into the upper rev range with VTEC, so this is a good time to learn a lot more about EFI.

 

[MotorMouth93]

At the end of the day the NSX ECU is mid to late 80s tech so it won't be as precise as something more modern, but it's a lot cheaper than going to a full standalone so we make do. :smile:

It's not a file it's a category in the XDF, it's where the logging patches are located along with all the configuration parameters for the ECU logging output.

Logging using the Demon is fairly convoluted and it took a long time to make it work properly since Moates support doesn't understand their own product and their documentation is partially correct at best. But basically the ADX file has an initialization sequence that it sends to the Demon to tell it how to interface with the ECU and what analog inputs (the ones on the Demon) to use, this includes expected packet size and the data that the Demon will send to the ECU to request a packet. When the Demon receives a data request from the ADX, it turns around and makes a request to the ECU, which then sends the data to the Demon, which then attaches the analog values and a checksum and sends it back to the ADX for parsing.

The current version of the python script requires that logs be exported as CSV files to use it. At some point I'll add support for the binary log files but I haven't had the time.

 

[Honcho]

Thanks for the write-up on your setup. I really think we should gather all this information into one thread. Now that the code is mostly available more people may want to play around and this would be a good repository. Perhaps one of the moderators can pull this off. I'll do it if I can figure out the method.

From my tagline you can see that I am very interested in fuel mileage, so therefore to want to run EGR. I've just finished looking at the difference between Partial Throttle tables and EGR tables and they are very different. In fact most of the pulse widths are wider for EGR, but there are a number of other PW modifiers before the injector fires. I'll look in them tomorrow.

There is a flag in the code to Set EGR System & Valve Lift Sensor Switch -- I think it is switched on. I have (I think) added a data collection point to see when the EGR is open and also put it on the dashboard. I'll try that out tomorrow too.

The NSX EGR system is crude at best and only monitors valve lift and not gas flow. If the passages become clogged, flow is reduced but the ECU can't tell which can result in lean conditions and knock. To me, the marginal emissions benefits do not outweigh the value of removing a potential failure point and cleaning up the engine bay a bit. It also adds another fuel table to tune.

Adding a dash field to display EGR status should be pretty simple as the byte containing that flag is already in the data stream.

@jvtec95 that looks like a good way to deal with the USB connection, I wonder if something similar could be done with the analog wires for the O2 sensors.

Just a quick note on the EGR- when cleaning my 137,000 mile intake manifold, ALL of the EGR ports in the manifold were 100% clogged with exhaust debris/carbon. This meant the car was not getting any exhaust gas in the combustion chamber, but still was changing injector PW based on valve lift because it thought the EGR was working. Depending on usage, it could create a dangerous lean condition. After talking it over with John, I capped off the EGR and won't be using it. With good tuning, I think my mileage and emissions will still be ok.

 

[mskrotzki]

I'll have to ask Paul Z if he cleaned my intake manifold and what the condition of the EGR ports were. I had driven that engine for over 220,000 miles (and had planned to drive it a lot more except for the **** radiator) with no issues whatsoever. The EGR didn't do any harm. It seems like it didn't do any good either.

Onward. I just got Gigabit fiber optics in my 113 year old house which made my 20+ year old ethernet Cat5 obsolete. I've been replacing it with Cat6, which is a challenge to say the least. I haven't been thinking NSX for a week now. Before that I started working up the ECU operation as I understand it (only partially) to gain a better insite. I've added it here for any correction required and for a potential aid for others who might want to wander down this path. I hope it communicates:

 

[MotorMouth93]

I have some thoughts after looking at your PDF.

Power Enrichment

PE reduction is essentially just factors that reduce the power enrichment/open loop pulsewidth based on various conditions. In the ECU binary code it doesn't seem to have any affect on the transition from open back to closed loop, it is purely a "feature" of PE/open loop. I'm not sure what the intended purpose of PE reduction is but that's what it does and I assume Honda has their reasons. For the most part, changes to these values will essentially amount to scaling pulsewidths to match larger injectors.

In regard to your comments on "Max Pulsewidth for ClosedLoop Operation ClosedLoopMaxPw", I refer you to this post I made in the other thread: http://www.nsxprime.com/forum/showt...rating-month?p=2026727&viewfull=1#post2026727

That table naming is somewhat misleading, out of the 3 main parameters controlling entry into open loop/PE, it is the least meaningful.

EGR

EGR is fairly straightforward, it has parameters dictating when it is activated and it just switches fuel and timing maps like you've pointed out. The reason the maps are much larger than "necessary" (going beyond 5k rpm for example) is so they will work with the same ROM code functions used to read the standard fuel and timing maps. Those functions expect 16x20 tables so the EGR tables must be 16x20 to be compatible.

I suspect the only thing that will need to be touched for EGR is the fuel map and that will amount to scaling and then adjusting as needed based on resulting AFRs. The solenoid pulsewidth map and timing tables should be left alone as Honda carefully tuned these values from the factory.

Load Calculation

The various alpha N parameters are used in limp mode when a MAP fault is detected but never any other time during normal operation. Fortunately, the code handling Alpha N has been written in a way that makes it easy to enable and disable it at will, so theoretically can be used to run ITBs with some code patches.

The 0-100% "load" value is derived directly from manifold pressure under normal conditions, the 10 bit raw reading from the MAP sensor analog to digital conversion is converted into a 0-255 value representing roughly full vacuum up to 0.25 psi then displayed in tunerpro as 0-100%, future releases will have the load percentages replaced with actual manifold pressure readings in tunerpro so we have a better idea of what's really going on in the engine.

 

[nsx_nordic]

I apologize in advance if I ask about something it already says about in the forum, but has not managed to find.

I must say I am very impressed with your knowledge of this, and at the same time I must admit that I do not understand what you are talking about (in a good way ..) :wink:

I am doing a major service on my C30, and had planned to cut out the EGR valve.
The intake was dirty and not very nice to look at, some muddy sand combined with oil.
After reading a bit about the topic on the forum (here) and elsewhere on the internet, isn't it just a matter of "cutting out" EGR like that without further ado? And then I think first and foremost about using a physical EGR blocker.
Am I completely lost in this and really should just forget it all?

If I seal the EGR itself, what more do I really have to do with everything else without doing damage or creating chaos for the engine and ecu. Cutting or blocking other things too?
Sorry if I ask stupid questions about this, but I'm a little stuck here.

 

[MotorMouth93]

Once the EGR hardware is removed and blocked (or the valve simply unplugged) the check engine light will come on but the car will still run just fine as if EGR were never there. To turn off the check engine light the ECU needs to be chipped.

 

[BBVNSX]

RFY seems to sell a device to prevent the check engine light to go on:

https://www.rf-yamamoto.com/NSXengine/36.html

But I'm not sure it is a good idea to simply just remove the EGR... I think it is good idea to adjust your fuel maps if you decide to remove EGR,...

 

[MotorMouth93]

Using that device sounds like a terrible idea. It looks like it tricks the ECU into thinking the EGR is present and functional, but if it's not actually there you'll be running EGR fuel and timing maps without exhaust gases being cycled through the intake which could present a potentially dangerous situation.

The ECU has separate timing and fuel maps for EGR, flipping the EGR system switch in ECU binary disables these maps so engine runs as if it were never there, no additional changes needed, Honda did all the work for us.

Just removing the EGR with no ECU changes disables the system and reverts to the standard fuel and timing maps as well, but also sets a CEL. Perfectly safe to run that way, but then the CEL will be on and you won't be able to tell if/when another CEL-worthy issue pops up later. The only danger here is not being able to tell that the CEL is on for some other issue, so I wouldn't recommend doing this.

Plenty of other Honda engines such as the B-series engines in various Civics and Integras don't run EGR at all and do just fine, the downsides to removing it amount to slightly worse emissions.

Like I said before, the correct way to delete EGR is to chip the ECU and flash a modified ROM with EGR disabled. I've done a few NSX ECUs already so maybe I should start offering this as a service in the future if there's interest.