Very early attempt at adding realtime buttons to a very early release of Mitsubishilogger. This is already far and away better than typing hex command lines. Behind each button is a series of request IDs using the new protocol which is ready to support realtime mapping once the front end is done...

I can select between the completely standard map set 0, or set 1 with my fuel map in RAM. Except it won't let me select set 1 unless it has first been copied as a safety feature. Also I can change the octane value with the buttons.

 

Congrats on the work !!! Simple and effective .

 

Even better...

I added his code snippets, and started refining it...

 

It will take some time to gather axis information, map location, and conversions from hex to data to make the information more usable, but I added to his existing functionality a universal read to get the ECUID which will be the basis for matching all of the proper data locations to the ECU.

 

I do still think we need dedicated requests for 2 byte load and others, perhaps one of the unused E0-EF calls, the reason I say this is to make the loggers themselves more robust.. Although you can do it with a direct memory request, you end up sending 5-6 bytes of data every time you do it, and you throw off the existing address your working in.

 

Excellent stuff! Nice to see the 94170008 code is working too That is such a relief now that you have that in your ECU, running on your bench harness and that you can now code for it. This is a huge leap forward!

Couple of options for load logging, I could make a 1 byte version for ease of logging that is shifted to fit 0-319 in a byte, resolution would be fine - it would be like the existing loadmax159 just divided by 2.

Or a multibyte response to a special single request ID that logs bytes or words from our own requestID table that we can write to RAM through the E0 command.

 

Wow so close to real time tuning, Let me ask you guys since this is for a 94170008 rom does this mean in order for live tuning to work with other roms it must be patched in?

 

I think your second suggestion (loadmax159/2) is a good idea, its a fast 1 byte response, and its actually not really possible to scale the ECU's load over 319 as many of the internal functions seem to have a max value of 319 (look at the load based tables such as Boost Load and others, where FF = 319, fuel cut table is a good example) FWIW this is another aspect that has to be addressed eventually as the stock ECU starts becoming more capable of handling very high horsepower combos.

 

Yes, in order for live tuning to work the rom must be patched..

The simple fact that my "Get ECU Internal ID" button works, is a good way to test if a rom has been patched, as it will not respond with anything if it has not been and the features can be disabled as not to confuse people.

The Diagnostic Tools window (you don't see in that screen shot) uses flags and diagnostic requestID's to determine test modes, sucess/failure, faults, and what is enabled/disabled.. This will work with any stock mitsubishi rom. I'm still gathering data on it, and working on borrowing or buying a MUT-II/III to sniff data from..

 

This stuff obviously has more value than tons of bells and whistles.. so forgive the ugly GUI for the time being.

 

I'm especially pleased the previously untested 94170008 patch I posted on Aktivematrix does actually work. With this you can read/write byte data from any address (obviously can't write to ROM), read word, read word with autoincrement, and copy whatever we define to be copied from ROM to RAM (presently the high octane fuel map), but on the 94170008 patch I haven't enabled it to be actually run from RAM yet like I have on my 88570008. But it will help Jack to get the map read in from his RAM to his table.

The working 94170008 patch means that migration to lots of different ECUs might be smoother than I thought as long as I keep organised, but I want to finalise the basics on the 88570008 and 94170008 before migrating a decent working version in conjunction with the logger developments.

Hamish is also working hard on incorporating this kind of stuff in Evoscan, up to now his custom request ID box has been the only way I've been able to test.

 

Yep, I was toggling the Octane number back and forth now that I have the memory address for 94170008..

The ram portion to maptrace table is a little more complex, so I'm working on that when I have more time to focus, probably tonight or tomorrow.

 

what exactly do you mean by patching the ecu? i have read the posts on aktivematrix about the 94170008 patch, but never fully understood what it does.

 

patching is modifying/adding new functionality to the ECU.

 

and this has only been done to the 94170008 ecu's?