Interest in Tuning for Boost with the Stock ECU

[RYU]

Thanks for the updates Matt. I never know if this project is still on so it's nice to hear the progress. I must admit though, following this project is starting to become a novelty/curiosity for me instead of a necessity. Is there a way, in the interim, you can provide a solution to read he ECUs STFT/LTFT and timing? This way, until you complete the project, I can use something like an AEM F/IC for my boosted application.

 

[bngl3rt]

It has to be flashed while the car is *running*? Is the ECU not awake under accessory power? What about "on" without starting the engine?

 

[sr5guy]

Thanks for the updates Matt. I never know if this project is still on so it's nice to hear the progress. I must admit though, following this project is starting to become a novelty/curiosity for me instead of a necessity. Is there a way, in the interim, you can provide a solution to read he ECUs STFT/LTFT and timing? This way, until you complete the project, I can use something like an AEM F/IC for my boosted application.

This is a hobby for me! I have been pressed for time over the last 6-8 months with my shop closing, it's not exactly easy to sort through 10,000sq/ft of nearly filled space on your own while dealing with other issues! Send over a PM and we can discuss the details.

It has to be flashed while the car is *running*? Is the ECU not awake under accessory power? What about "on" without starting the engine?

The entire flash process must be done with the key on, engine off. Single or multiple byte DATA updates can be done with the engine running.

-Matt

 

[RYU]

This is a hobby for me! I have been pressed for time over the last 6-8 months with my shop closing, it's not exactly easy to sort through 10,000sq/ft of nearly filled space on your own while dealing with other issues! Send over a PM and we can discuss the details.


-Matt

Certainly understandable Matt! Didn't mean to impose any pressure of the sort. Regardless of what I end up doing this is an awesome project and i'll be following it.

PM coming thru now

 

[bngl3rt]

The entire flash process must be done with the key on, engine off. Single or multiple byte DATA updates can be done with the engine running.

Cool! I hope you post the source code of your flasher tool someplace (github?) - I assume it's written for Windows and I'd love to port it to Mac (and any number of other platforms).

Windows is dying but the auto industry is notoriously slow to catch up to these things so I assume AEM's tuning software will be stuck there for a while yet... it would be great to turn a new leaf and build open source, cross platform tuning software.

 

[RYU]

Cool! I hope you post the source code of your flasher tool someplace (github?) - I assume it's written for Windows and I'd love to port it to Mac (and any number of other platforms).

Windows is dying but the auto industry is notoriously slow to catch up to these things so I assume AEM's tuning software will be stuck there for a while yet... it would be great to turn a new leaf and build open source, cross platform tuning software.

On that note I would LOVE to run an Android tablet with an AEM or Zietronix (my data logger) "App". I think we've talked about this before.

My search to run a Windows Emulator on the Android OS was a bit of a fail.

 

[bngl3rt]

The thing to do would really be to implement the core functionality in C# and then share it between Windows, Mac, iOS, and Android using something like Xamarin Mono (http://xamarin.com)

Core functionality for both tuning/flashing (data going into the ECU) and logging (data coming out).

 

[latzke]

The thing to do would really be to implement the core functionality in C# and then share it between Windows, Mac, iOS, and Android using something like Xamarin Mono (http://xamarin.com)

Core functionality for both tuning/flashing (data going into the ECU) and logging (data coming out).

Not to take this thread too off-topic, but here are "Brian’s 10 Rules for how to write cross-platform code":
http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-write-cross-platform-code/

Back on-topic: This tuning via OEM ECU is an AWESOME project. I'm somewhat holding out on getting more-sophisticated tuning so I can have this as an option. Matt has also been helpful answering a few unrelated questions. Quite a nice/knowledgeable/helpful guy!

 

[foundry3]

Not to thread jack but=> since when is Windows or .net dying?

Please show me one published metric supporting such a claim.

___

sr5guy,

Out if curiosity: have you spoken with HRTuning at all regarding what you are doing as they may have interest in your efforts?

I do understand that the C engine ISR protocols may differ from the B/H/F OBD1, however it occurred to me while reading this thread that Neptune(HRTuning) may have strong interest in what you are doing as it fills a gap in their platform if they are able to support C series.

This could abstract you from hardware concerns as well.

___

Do the C series 16 Bit addresses differ from standard Honda 4 cyl obd1?

I would also like to speak with you regarding something I'm doing with AEM, PM me when you can.

//f0obot.exe

 

[latzke]

I have been pressed for time over the last 6-8 months with my shop closing, it's not exactly easy to sort through 10,000sq/ft of nearly filled space on your own while dealing with other issues!

Hope all is well, sounds like you had/have a lot on your plate.

 

[whrdnsx]

Any Updates?

 

[sr5guy]

Working on describing the fuel system and all it's entanglements in a document with flow charts and graphics, look out for a major update within the month.

Here is a little teaser: The NSX's fuel injection timing isn't calculated based on the start or end time of of the injection. The ECU times the injectors (in 30* increments) so that the middle of the pulsewidth (minus deadtime and the time for fuel to flow from the tip of the injector to the valve) occurs as close as possible to maximum valve lift at operating temperature. At cold coolant temps, it injects fuel onto a closed intake valve to improve atomization. All of these variables will be adjustable within the definition.

-Matt

 

[bngl3rt]

How does it detect valve lift? i.e. is the stock camshaft essentially "hard coded"? could replacing the cams screw up that algorithm? or is it dynamic i.e. some kind of sensor monitoring the valve position?

 

[Honcho]

How does it detect valve lift? i.e. is the stock camshaft essentially "hard coded"? could replacing the cams screw up that algorithm? or is it dynamic i.e. some kind of sensor monitoring the valve position?

I would imagine it is hard programmed, since there is no sensor other than the crank angle that tells the ECU where the engine rotation is. Since Honda knows the cam specs, they know exactly where each valve is at any point in the rotation. Any update, Matt?

 

[sr5guy]

HUGE progress. ENTIRE fuel system has been defined!!!! Every single variable that effects fueling in any way is adjustable, configurable and tunable.

Now to start work on defining the ignition system!

-Matt

 

[DDozier]

View attachment 113692View attachment 113693View attachment 113694View attachment 113695

HUGE progress. ENTIRE fuel system has been defined!!!! Every single variable that effects fueling in any way is adjustable, configurable and tunable.

Now to start work on defining the ignition system!

-Matt

Stunning, what is a guy going to have to do to get his hands on this data? You are opening up a huge window for the NSX and I for one thank you for your efforts.

Dave

 

[sr5guy]

Stunning, what is a guy going to have to do to get his hands on this data? You are opening up a huge window for the NSX and I for one thank you for your efforts.

Dave

I'm trying to come up with something that would be in the best interest of everyone. My current idea is making the definition public, free and open for *personal* use with the hope that good carma (pun intended) will come my way. Yeah right , I can see the dyno tuners bootlegging it as I speak. My custom code, datalogging protocols and modifications to the ECU (NVRAM flash updating, boost support, etc) will be for commercial sale. I'm open to suggestions.

-Matt

 

[RYU]

View attachment 113692View attachment 113693View attachment 113694View attachment 113695

HUGE progress. ENTIRE fuel system has been defined!!!! Every single variable that effects fueling in any way is adjustable, configurable and tunable.

Now to start work on defining the ignition system!

-Matt

holy sh*t............................

this is groundbreaking! I personally thank you for doing this whether you make it open source or not

I think being able to view/know/analyze the fuel system parameters is huge. i'd be interested in that now actually. this way i can better tune my HKS piggyback.

Ultimaltely i'd love to see what you come up in terms of part 2; the interface!

 

[rj45]

holy sh*t............................

this is groundbreaking! I personally thank you for doing this whether you make it open source or not

I think being able to view/know/analyze the fuel system parameters is huge. i'd be interested in that now actually. this way i can better tune my HKS piggyback.

Ultimaltely i'd love to see what you come up in terms of part 2; the interface!

I would have paid some rather than use FIC.

 

[RYU]

I would have paid some rather than use FIC.

what are you talking about...?

 

[bngl3rt]

And to clarify again - you are working on the OBD1 NSX ECU only? Do you have any understanding of how the OBD2 ECU differs?

Given the low production volume (and engineering effort) Honda put into the car after it was launched, I would imagine they tried to change as little as possible, adding DBW and the OBD2 protocol implementation while leaving everything else (as close to possible as) alone...

 

[RYU]

And to clarify again - you are working on the OBD1 NSX ECU only? Do you have any understanding of how the OBD2 ECU differs?

Given the low production volume (and engineering effort) Honda put into the car after it was launched, I would imagine they tried to change as little as possible, adding DBW and the OBD2 protocol implementation while leaving everything else (as close to possible as) alone...

just obd1

if i wasnt injured id type more to help

 

[sr5guy]

If you want OBD2 and have some money to gamble, let me know, otherwise stop asking (not you in specific, I must have had a half dozen people ask me about it, but no one wants to gamble)!!!

It involves getting and very possibly destroying an OBD2 ECU, removing the processor and sending it to China for a delamination and photograph of the die. From there they will provide a binary file of the contents. I was quoted $300-600 for this rather shady service. Then it has to be reverse engineered, if it's the same/similar as the obd1 stuff it will be easy. If not it could very well take years of work. Once a definition is made, a programmable processor (~$100) has to be purchased, programmed with possibly a custom flashing program and with any luck it works. Once it's reverse engineered, there would be a steep chipping fee considering the processor is a 112pin QFP format.

-Matt

 

[bngl3rt]

So you destroyed an OBD1 ECU to get to where you are now? Or you destroyed a Legend ECU which happens to be physically similar...

 

[sr5guy]

So you destroyed an OBD1 ECU to get to where you are now? Or you destroyed a Legend ECU which happens to be physically similar...

OBD1 ECU's have their coding on an easily removable 28pin DIP chip, no destroying needed.

OBD2 ECU's have their coding INSIDE of the microprocessor, and DO NOT come with the flash version of that processor installed. It would only be "destroyed" if the chinese company had issues or if there were issues with the first time chipping.

-Matt