jfitzpat

I know, provacotive title, but here is the deal. I got a message and a log from a user who is bringing RPM into logworks 3 ways: His LM-1 (attached to his ignition system), his XEDE (also deriving RPM from ignition), and his OpenPort cable (from the ECU via MUT. He reported that my plug-in is logging RPM incorrectly from MUT, since the value does not match the other two.

However, in looking at his log I found something interesting. First, look at just the XEDE and LM-1 traces:



The traces do not overlap, because one channel has a scale of 0 to 8000 and the other is scaled from 0 to 10230, but when you drop in measurements the traces are virtually identical (well within the margin of error for the measurement principles involved). The LM-1 trace is sampled a little faster, so some spikes have some extra detail, but literally every detail seems to match up.

Next, look at the XEDE RPM and the MUT RPM:



These two channels are the same scale (0 to 8000) so they should overlap. But they do not and, the disparity shows up in measurements. Clearly, the raw ECU data is correct. Although the lower sample rate of the ECU rpm makes the trace steppy, they are clearly in agreement.

At first glance I would say that the multiplier I am using for the raw MUT value is wrong. But the user sent me a formula from Mitsulogger and it appears we are the same - multiplying by 31.25.

The second thought is that maybe there is something wrong with either my plug in scaling or math parsing. However, when I run test data through it appears to be multiplied by 31.25 and the scaling is not only correct, it is the same mechanism used by the XEDE plug in, which appears to match both the LM-1 and the user's tach.

Now look at all three traces:



Notice that the ECU trace, on a scale of 0 to 8000, lays on top of the LM-1, on a scale of 0 to 10230. This struck me as an odd coincidence, so I hit my original notes and started thinking about it. We use 0 to 10230 for the LM-1 because it is very convenient for 10 bit samples (which the LM-1 uses). One bit = 10 RPM.

This sent me back to my notes about the 31.25. In my original test on an Evo, I simply noted the tach and the raw MUT response. The relationship appeared to be value multiplied by 37 and change. However, the value seemed odd and I knew that my test was course. So I did a google search. 31.25 popped up a number of times in multiple forums and I plugged it in.

However, now that I am looking at this discrepency, I am really wondering about the 31.25 multiplier. It is easy to see how it could be derived. The MUT response is 8 bits (0-255). 8000 divided by 256 equals 31.25. However, now that I think about it, the value does not make a whole lot of sense.

First, using 31.25, most RPM values returned by the ECU are fractional. Second, the max value actually ends up less than 8000 RPM, which already seems pretty close to practical read line. Third, an integer implementation is a little unclean. Finally, it doesn't really overlap with the OBD-II implementation as well as it might seem at first glance.

A multiplier of 40 actually seems more logical. Every bit has an integer RPM meaning, the max value moves up to 10200, the integer math is trival, and it lines up well with the required OBD-II output format. Last, if I take the samples in the log above, divide by 31.25, then multiply by 40 (I exported to a DIF file, used Excel to alter the MUT RPM column, then reopened the DIF file) the three channels fall into sync:



MUT RPM now overlaps XEDE RPM (since they are the same scale of 0 to 8000), LM-1 RPM sits lower, since the top of the screen represents a higher value of 10230, and measurements are in sync (the 14 RPM difference between MUT and the other two is well within rounding error for 8 bit samples).

I'd love to say that this is my bug, but it really seems to me that the multiplier in common use (31.25) is incorrect!

I'm bringing this up because it would result in shifted tunes for air/fuel maps. It would have a smaller impact in dyno type calculations since it is the rate of change, or slope of RPM, which has the largest impact on the calculation, but there would still potentially be an error because of what is fed into SAE.

So! Old hand MUT types, please prove me wrong!

-jjf

MalibuJack

iTrader: (5)

I don't know that the multiplier is incorrect, as the stock ECU's redline is about 7600rpm (I think 7620 or something along those lines) but its actually higher than the stock redline for the engine.

This is a pretty "Common" issue, as the scalings were always somewhat off, and had been "derived" from raw data, and the ECU itself has only recently been disassembled enough to see what its conversion actually is.

Its not actually a bug on anyones part, I think the value is what has been used by OBD-II and is therefore a "Standard" calculation that had been carried over.

Of course, because of how loggers worked in the past, it would have been difficult to overlay data as you have in logworks to see this anomoly. In fact, I only noticed something similar recently when I was finishing up the UTEC portion of my logging tools..

I do think the multiplier is off, as are a few of them, but this value is what DSM Logging tools were using and pre-dates OBD-II.

MalibuJack

iTrader: (5)

What I do notice is that the discrepency is within 200rpm, which appears to be the error/rounding step anyway.

I have no problem updating the definitions in my app if this proves to be the case, but this is also the reason WHY I chose to make all of the calculations for the logging and conversion flexible.

I recently had a similar discussion about the range of the fuel trims, and how to scale them, ultimately the documentation said one thing, but the correct answer was a little different, and even better was the DSM logger guys also used a different scale.

Its good that fresh eyes have noticed this though.

jfitzpat

Thanks for the feedback. Actually, the error is proportional to RPM. At 3600 above it was 800 RPM off (2nd image). The higher the raw value, the larger the error in absolute terms. I think you might be adding a zero to the difference in the first image between the two ignition system based measurements.

I wasn't accusing anyone, I just thought a 28% error in RPM was worth noting! On a third gear pull, the shift in a fuel map seems like it would reach a couple columns.

FWIW, ODB-II uses a 16 bit value and 1/4 RPM increments. I just did a DSM plug-in (1G), so it will be interesting to see how those results line up.

Thanks again,
-jjf

Edit: Fortunately, I put all the calculations in an XML file as well!

C6C6CH3vo

iTrader: (9)

As long as it's accurate and consistantly off then a 28% error in precision doesn't worry me

jfitzpat

Seriously, I'd really like to hear why you are OK with this. Remember, we are talking about a proportional error. The measurement is off by about 600 RPM at an actual RPM of 2000 and off by 2000 RPM at an actual RPM of 7000. Contrary to by brain fart last night (where I was thinking of the raw 8 bit value) the slope of RPM does change, so torque and power calculations from RPM will be wrong, also by a changing proportional amount.

Normally, RPM is considered a 'core' metric, since it touches so many things. There wasn't a lot of data in the log (it appears that the car was mostly just sitting in neutral and the engine rev'ed a few times). But there is a logged channel from the ECU called load. Look what happens when I open a fuel map using this param, true RPM (from the LM-1) and AFR:



Now look what happens when I open the same chart using the incorrectly scaled RPM from the ECU:



The table is now both vertically compressed and shifted. I don't really know what the ECU parameter called Load does, but it clearly clips at 100%. Look what happens when I do a simple load calculation using RPM and Airflow (AirFlow/RPM*852). Because RPM is proportionally under reported, the calculated load is proportionally over reported with airflow:



So if we redo our chart again, first with the valid RPM:



And then with the proportionally incorrect RPM:



We can see that our 'actual' fuel map is now shifted and skewed in two directions. To me, comparing actual to desired would be difficult with any table (2D or 3D) that involves RPM (remember, the ECU is not internally scale impaired, this is a proportional logging error). But, again, I'm coming from a point of view where RPM is a core metric.

-jjf

P.S. MJ: Credit for the initial catch goes to nj1266.

l2r99gst

iTrader: (2)

jjf,

In my experience the RPM data with the current 31.25 multiplier seems correct to me, although I haven't looked into it with as much detail as you have.

I can guarantee you that it is not off by 2000 RPM at 7000 RPM, though. For example, when I am doing third gear pulls, I usually just go up to 7k (based on my tach) and when I look at my logs afterwards they show up to 7K. So, whether the 31.25 multiplier is correct or not, I don't know, but I don't think it is off by as much as you are proposing.

Maybe I'll watch a realtime log as I cruise to the gym today to see how much, if any, difference I notice. I'll try to hold a steady 3k on my tach and glance at my log, then 4k, etc.


Eric

PVD04

iTrader: (23)

I checked my 2 logs from this morning, one from Mitsulogger and one from my Translator Pro and the peak RPM in Mitsulogger was 3781 and the peak RPM on the Translator Pro was 3783, so I'm not seeing any difference. In the past while tuning WOT pulls I noticed that both the Mitsulogger and Tuner Pro logs would peak at the same RPM. I'm not sure why your data is showing something different, but it is not possible that the calculation is off by 2000 RPM at 7000 RPM. I've logged hitting the rev limiter and my RPMs were within 50 RPM of the set point of the rev limiter setting when checked in the MUT log.

-Paul

jfitzpat

Are you sure you are getting RPM from the ECU? RPM from an LM-1, LMA-3, SSI-4, etc. would not have the problem. If one of those was available, I would generally log from it, since you would get a smoother, more complete, RPM trace.

Remember, I am not presenting this as fact, merely a hypothesis. NJ1266 sent me a log and noted that LM-1, XEDE, and tach all agreed, MUT did not. I originally assumed it was a bug on my part, but I can't find any evidence of that.

Everything above is extracted from that log - including my attempt at a math shift (replacing 31.25 with 40) which reconciled all three RPM sources.

If I'm wrong, I'm wrong. But if I'm right, the error is large. 7000 / 40 = 175. 175 * 31.25 = 5468 (OK, 1500+, not 2000 (I mentally rounded to 30%), but still large).

-jjf

l2r99gst

iTrader: (2)

Yes, I am getting RPM from the ECU. The only other devices that I log besides the ECU is my LC-1 and my GM 3.3 bar, hooked into your SSi4.

But, I have never seen a discrepancy between my logged RPM and my tach...at least nothing that noticeable.


Eric

jfitzpat

I think that the Maft unit uses a CAS sensor for RPM, like the XEDE, then RPM would be based on ignition timing. So the test is virutally identical. In that case, I would start to suspect MUT flavor differences between ECUs and version.s

However, if you are referring to the DSM piggy back thing, the multiplier used would be the same. I'm not sure what unit you have but a 2 RPM difference is awfully close. Remember, if you are reading MUT values, the smallest step is 31.25 (or 40 ). Ignition based measurement has no such contraint. So I would normally expect 10-15 RPM of fluctation. Though 3781 definately sounds like a 31.25 multiplier (3750, 3781.25, 3812.5...)

Again, I only have two ways to definitely test this - examine raw output, tach, and LM-1/XEDE on NJ1266's vehicle, or disassemble his ROM.

-jjf

Edit: I notice that both of you reporting no discrepency have Evo VIII in your tags. I'll have to check NJ1266's tag to see what he is specifically driving.

MalibuJack

iTrader: (5)

Mut logging has been virtually unchanged since around 1996, prior to that I think the baud rate was slower, and there were fewer available requestID's, so I don't know that it would be any different, but I certainly am interested in hearing more about all of this.

I didn't catch your later post about it being off exponentially, your earlier post indicated it was only a few hundred RPM at worst (and generally under 200rpm) Like I said, the biggest difference I had seen between UTEC rpm and MUT, was about 200rpm.

Any possibility that there is some "lag" in the MUT plugin on logworks? If there is, then the faster the engine accelerates, the greater the difference it might appear to indicate. All of my plugins use a thread to constantly update a collection of the values, so their always current when queried no matter how fast or slowly their polled. If I tried to poll MUT quickly by calling it as a subroutine, it would fall behind as its reply requests were filtering in, so I used a shared collection object that always had current values based on the maximum poll rate of the specific device associated with the plugin.

jcsbanks

AVC-R, OBD II, MUT, tacho are all close enough for me, errors so far only seem to be time sequence and the 8 bit MUT RPM feed is a grainy at 31.25 increment.

I've also logged 16 bit RPM from the ECU using a different scaling - again derived from ECUflash and it agrees.

jfitzpat

It definately seems like the discreprency is not universal. I'm going to try to get NJ1266 to run a lower level test and send me the results.

I can't see any evidence of latency (the traces in my original post aren't mocked up or manually integrated, they are just a saved log). The traces from all three RPM sources line up perfectly in terms of peaks and valleys, even though they represent three different data rates.

If this is a diagnostic protocol variant specific issue, I'll bet it can be detected by the ECU's initial response.

I'd still be willing to chalk this up to my bug, but I'll be darned if I can figure out what it might be. The XEDE channel runs through literally the same code and matches perfectly. Similiarly, speed, RPM, etc. all seem to be correct when I log OBD-II from my wife's Lexus (not exactly the same code, but the same math parser, XML parser, etc.)

Since both you and l2r99gst have LC-1's, there is a very simple test I'd love one of you to try. Just run the LogWorks plug-in, pick Engine Speed, and add a dial to the LogWorks dashboard. Then just see how it matches up to your tach.

If there is a problem, hooray - It's something I need to find here. But if RPM matches on your ECUs, I'll need to try to dig into NJ1266's specific ECU.

Thanks (to all) for the feedback!
-jjf

MalibuJack

iTrader: (5)

I'll see what I can do about getting data for you. Unfortunately the LC1 I have is on my bench getting set up so I can write code for it.

FWIW the Evo tach is off by a few hundred RPM depending on conditions. When I would compare MUT logs to ECU+ logs, they were within the 200rpm range (as it was real easy to find the portions of the logs by time offset) This was the only historical data I could find that would be of use to you.