[cgrey8]

Since I didn't know which was right, I just datalogged both on the drive home from visiting. The drive was roughly 2.5 hours.

The value at 0x158 doesn't look like DESMAF at all. It seems to go up and down with engine load. And it seemed like it was paralleling the MAF value, but not exactly. While at part throttle, it might have. But at closed throttle, it seemed to become completely "disconnected" from what the MAF was doing. I'm not sure if maybe FAM only updates during PT or something (I haven't researched expected FAM behavior yet).

The value at 0x15e seemed much more stable early on, and I thought this was DESMAF. If it was, it was telling me I had some work to do to get it closer to actual since it was showing ~29kg/hr and actual MAF was ~22kg/hr. However as time went on, the value seemed to get smaller and smaller...but it did this over the span of most of the drive. An hour or so into the drive, the value was down to ~18. Another 30 min or so later, it went right to 0 and never changed value again until I power-cycled the ignition. Then it went back to 29. This doesn't seem like correct DESMAF behavior. I don't know what this was. If anybody would like to see the datalog, I can zip it up and post it.

Anybody interested?

I'm still looking for anybody that has installed that program just to verify that the math there is working and I don't have some dumb off-by-one issue or something. Knowing whether that program is calculating correctly will tell me if my understanding of the concepts is correct or not.

[cgrey8]

Updated the version and named the project better so it wasn't using the generic Visual Studio name.

[jsa]

Chris,

The most recent didn't work for me.
See attached log.

[cgrey8]

Ahh, I guess it does need all the other files VS put in the folder with the setup.exe. Some of those files were big...way bigger than necessary just to install this TINY little program. So I didn't include them.

I'm at work now, so I can't do anything about it here. But when I get back home, I'll try just posting up just the *.exe file (zipped) and see if that works. Since there won't be an installation program to check to see if you have the correct .NET version, you'll need to ensure that's already installed on your own.

Trying to get this to work on my WinXP VM, I found that 4.5.2 isn't supported on XP, so I fumbled around in the VS and found a way to compile the program for .NET 4 which is supported on WinXP. Just moving the *.exe to it did seem to work...after .NET 4 was installed of course.

Thanks for trying.

[cgrey8]

I can't remember if this EXE was one built for .NET 4 or 4.5.2. But I was able to execute it on my Ubuntu 14.04 machine at work using Wine and it had no trouble launching. So I assume if Wine can launch it, a native Windows machine won't have much trouble (again assuming the right version of .NET is already installed).

[jsa]

Hello Chris,

That runs.

Here's a challenge for you, expand on it so a section of code can be pasted and the right answer pops out.

Copy some code starting with an opcode. App determines address mode, truncates excess or requests try again if too short, once enough code supplied it spits out answer.

[cgrey8]

In the case of a register-reference, it wouldn't know the value of the register. So in the case of a

Code: Select all

stw R20, [R72+de]

It wouldn't know the value of R72 to know how to do that math.

The update though is I still cannot explain the behavior of what I'm seeing for either of the 2 addresses mentioned. So I don't think it is useful to include them in the def file. If I do publish an update, it probably will not have DESMAF in it...just the other updates. However I'm reluctant to even release those updates until I get some clarification on the MAF curve formula.

[Paulie]

I'm sure its difficult to figure out but I would really like to be able to datalog DESMAF.

[cgrey8]

If you want to play around with what I have right now, I'll post it as s Pre-Release here in this thread.

[Paulie]

If you want to play around with what I have right now, I'll post it as s Pre-Release here in this thread.

Thanks but my car is put away till spring.

[cgrey8]

I've run with the new def for long enough to be happy with the non-DESMAF changes. So I'm probably going to release these updates soon.

But since I never got any clarification on the behavior I'm witnessing of the two addresses I think are DESMAF, I won't be releasing the defs with them in it. If I do, they'll be marked as EXPERIMENTAL and thus subject to change.

Before I release these defs, is there any other suggestions for offsets I should try or explanation as to why what I'm seeing is reasonable for DESMAF that I can document the behavior?

[Paulie]

I've run with the new def for long enough to be happy with the non-DESMAF changes. So I'm probably going to release these updates soon.

But since I never got any clarification on the behavior I'm witnessing of the two addresses I think are DESMAF, I won't be releasing the defs with them in it. If I do, they'll be marked as EXPERIMENTAL and thus subject to change.

Before I release these defs, is there any other suggestions for offsets I should try or explanation as to why what I'm seeing is reasonable for DESMAF that I can document the behavior?

Did you ever make anymore progress with DESMAF?

[cgrey8]

I never got DESMAF giving me lucid values. The math looks good. But the results just don't seem lucid. So something still isn't right.