Bez has a few cool new features I hope he publishes soon in addition to John's 2 byte load..

 

MJ, when I was looking through the FSM this morning, I found out that ID 01 is used to monitor the deterioration of the cat. Page 13A-11 of the FSM states, "ECM monitors the deterioration of catalyst by the output frequency ratio between heated oxygen sensor (front) and heated oxygen sensor (rear)." The output is, "Catalyst Frequency Ratio".

 

my 13A-11 from USEvo8 manual doesn't have that much detail, can you please email me that pdf.. thanks.

 

I went through the entire manual and didn't see the specific page that said which requestID's were which.. I'd really like to know what every single one does before we go about modifying them..

But its good that we have some additional information.

I did see the page with regard to the MDP sensor though..

 

He is referring to the mode 6 reference table. It is on the same page in my manual...13A-11 and 13A-12.


Eric

 

I recall seeing the mode 6 table, but the ID's for known requests didn't correlate to the MUT requests, only the OBD Mode 6 stuff..

 

You're right. I missed the ODB-II ref. So ID 01 for MUT is not going to be the catalyst frequency ratio.

 

I easily got the 2 byte loading to work, however it's not without problems.

I have the mitsulogger dated 10/22/06, build v1.0.2486.22967. when logging the requests for the request ID 00, 01, over time the logger will crash after 10 - 40 seconds with a conversion error converting a string to double. Due to the nature of the crash, I suspect you have a memory leak somewhere, or your are not properly referencing some chunk of memory that is used frequently.

with out the 2 byte load logging the app is solid and does not crash.

When it does work, the 2 byte load value works pretty well when outside the range of the 1C load value. I just have not been able to use it long enough to do any real tuning using these load values due to the crashing issue.

overall it looks pretty good. I used the logger flawlessly (without the 2-byte load) all afternoon while tuning the EVO today.

 

Its probably not a memory leak, I'm not using pointer references or callbacks, so its not actually going to leak memory.. If you have the "2 byte" check box ticked, untick it, if you also make sure the value your using for the request is 2 not 3.. you will eventually get an error since your not getting 2 byte responses.. There are a bunch of implicit conversions being used, which is what is probably throwing that error.

Another possibility is some conversion error.. if you want, PM me the requestid lines your using for the requestid.xml file

 

no the 2-byte check box was not checked. I would tend to agree that the problem is in the implicit conversions that you use. That is probably where the leak is (inside the API you are using for the conversions and totally outside your control)

I will send you a PM with the request ids

 

Okay, makes it easier to test.. I am using the VBScript component to do those conversions, so its likely thats where the conversion/leak is happening.

 

I replied to your PM.. if it works for you, share it in this thread as I'm sure others might be interested in this too.

Leveraging some undocumented/partially documented features in Mitsulogger is beginning to show you its true power eh?

 

Thanks Jack,

the problem I was having was with incorrect settings in the responseID.xml file. Once I got that fixed, everything is working correctly now.

 

Can someone please post these MUT and LOAD addresses for these common roms
01_LANCER_EVO7-RalliArt_EDM_90550001.hex
or 04_LANCER_EVO8_USDM_94170008.hex

Thanks.

 

you need to add 2 tables to the 94170008.xml definitions

once those tables are defined in your ROM, you can then use your evoscan logger to log the values using these definitions in the data.xml