It is increasingly looking like it is vehicle or ECU specific. In re-reading his post I realized that l2r99gst already is using LogWorks. I'll proceed with trying to track this down on NJ1266's setup and let you know what I find.

Thanks again.
-jjf

 

Thats really weird, as I've seen logs from both the 8 and 9 with mitsulogger and ECU+ running side by side..

I'm really interested in the outcome of this, as its the first time I've ever heard that the MUT output could vary depending on the Car.

It would be somewhat awkward to have different scaling settings for different model ECU/Rom's if this was actually true. As I am not completely certain, but the mut protocol might stream the ROM's ECUID as the first 4 bytes after it connects, I noticed a bit of data spit out just after the 5 baud init, but I never analyzed it to see what it was other than to look for a response.

 

Well so far I have run three numbers in the fromula and the results were off from the xede rpm and the LMA-2 rpm.

I ran x*31.25 and the number came out way too low. Then I ran x*40 based on Joe's calculations and the numbers came out so high that they were clipped by Logworks. The Open port numbers basically maxxed out @ 8000 rpm.

On the way back from work I ran another number, x*37.894 based on Joe's original findings on an Evo 7. The rpm was also higher but less so than before.

I am going to try x*33.674 next based on some very crude calculations that I did and will report back. The logs are posted on the innovate forums if anyone cares to see them.

 

Is there any possiblity that the data from the XEDE is what is off and not the MUT?

 

I really doubt it for two reasons. First, I tried to log open port rpm on another Evo 8 and got similar results. Second, the rpm data from the LMA-2 and the Xede and the tach needle are very similar.

 

Just so you know, the tach on most of the Evo's is off, it reads high by about 300-400rpm..

 

FWIW, here is where my thinking currently is.

* I think that 31.25 may not be perfect, but is probably close.

* I think that my plug-in is working correctly (reading the right MUT byte and properly multiplying). I'd love to say this is my bug, but all the other ECU logged params look fine and running test values through shows nothing (I even wrote a little MUT ECU simulator)

* I think that XEDE and LM-1 are correct. It is possible for them to be wrong, but in this case, they are virtually identical and use two different measurement mechanisms. XEDE is using the CAS and the LM-1 is using an ignition spark.

I have three theorems at the moment:

1. There are variants of the protocol and ECU. Frankly, I think the probability on this is no looking low (since a seemingly identical setup is not having the problem).

2. Something about the way the piggyback is altering CAS is confusing the RPM calculation in the ECU.

3. Something in an ECU Flash change has altered the RPM reading.

If anyone else has a theory, throw it up, I'm just going to start testing them one at a time!

-jjf

 

jjf,

All of my latest logging is done with your LogWorks app, so I can verify that RPM is indeed working correctly, meaning matching my tach, in my LogWorks logs.

To verify, I can do what you are asking though. I will try to do that on the way home from work today.


Eric

 

I wonder if he's running any ECU Hacks, such as the baud rate hack.. Not that it makes much sense, but anything is possible at this point.

 

Yeah, thats the sort of things I'm thinking w/2 and 3. Unintended side effect from the piggyback or from a ROM change.

l2r99gst: No need to do the gauge test, you essentially already have. I didn't realize you were logging with LogWorks when you first posted. Thanks though!

-jjf

 

The ECU is a little timing sensitive when it comes to signals from sensors, I suppose its possible that the way the sensor data is reproduced could be throwing things. Though if his tach is reading right (more or less) then I'd suspect something in the Rom, as remote as that seems, but we don't know what side effects some of this stuff has anyway.

 

Also you can ask NJ if he has any of his ECU wires tapped for sensor, etc. Tapping some of the wires have been known to alter readings.


Eric

 

The fact that he has an XEDE means not only are the wires tapped, but some of them are recieving a reproduced signal and not the original signal from the sensor. If I recall, the earlier firmware in the xede had some issues with CEL errors being thrown due to discrepancies in the (CAS?) signal, see if you can search on some of this stuff, as I don't want give out any misinformation if this isn't actually true, its possible that some of the sensor outputs were altered to keep the ECU happy, and have the side effect of causing RPM to read differently.

 

I'm a little swamped at work this afternoon, but this evening I'm going to take a look at some of the ROM disassembly that has been done so far. If the RPM routine has a rejection filter and there is a little noise, or if the edge is a little sloped, I could see RPM getting scewed.

If I can get a little better idea of how the ECU is measuring, it should be easy to hunt down things that might confuse it.

-jjf

 

This is weird. I _don't_ see a signifcant difference between Xede RPM and MUT RPM. I have code that logs both at the same time. I can sample them within 50ms of each other.

d