Logging

[Gampy]

Mr. Jim,

I understand the frustration and I personally appreciate your candor ... A good product takes open honest comments and them being listened to!

Here's the deal from me ...

We are all volunteers, though I have no life, the others do.

PcmLogger is still very raw in it's development, PcmHammer is a bit further along.
I have no way to test PcmLogger, so I do no development, I do look it over, that's about it.

I do agree that we need to move the User Settings saving to the proper users location (%APPDATA%\PcmHammer).
I assure you I will do everything I can to get that done ... I want it done!
It just hasn't got there yet, when I finger out how to get it done without looking like a sore thumb in NSFW's work I'll hit the send button, until then it's up to somebody else.
I don't don't have a 10th of NSFW's C# design skills ...

None of the PcmHammer Suite needs installation.
Installation packages make so many useless and unnecessary changes for such little gain, a couple of shortcuts!
Why add all the registry and folder bloat (including save points) caused by an installation process.

Being version folder zipped is a pain ...

Thus, I recommend setting yourself up for success,
1. As administrator (if required) create a "PcmHammer" folder someplace. (off 'Program files' if you desire)
. Example: C:\PcmHammer
2. (if required) As administrator give your username full control (full permissions) to that folder.
3. Unzip PcmHammer to that folder.
. So you get: C:\PcmHammer\PcmHammer<version>
4. Add short cuts on (pin to) your launch bar (start menu, or where ever you like) that point to PcmHammer.exe (and or PcmLogger.exe).
. Example: C:\PcmHammer\PcmHammer14\PcmHammer.exe

Then you only need to do the following on each release.

1. Unzip PcmHammer into that same folder.
. So you get: C:\PcmHammer\PcmHammer<version>
2. Edit the shortcuts to the new versioned folder.
3. Delete old version when you are ready to do so ...

-Enjoy

[NSFW]

PcmLogger is still primitive, but it basically works...

You have to edit the XML files by hand to get it to log different parameters. The profile contains a list of parameter groups, and each parameter group can fetch 6 bytes from the PCM. It's up to you to make sure that each parameter group has at most 6 bytes (each parameter can be 1 or 2 bytes). I've tested up to 3 groups. Eventually I want to give it a list of parameter that you can just pick from.

The other thing is that you can pick parameters based on OBD2 PIDs pretty easily but for a lot of useful stuff there is no PID, and we'll need to find the RAM addresses of the important stuff through reverse engineering.

And it only produces CSV files, so you'd need Excel or something like it to create a histogram.

[B52Bombardier1]

Rick, is there one of those phone apps that will work with the OBDLinkLX and record EGT (for my wideband), along with STFT/LTFT, MAP, TPS, ECT, RPM and advance? That's really about all I need I think.

Jim

Hello Jim,

With the exception of EGT, most of these apps support the things you desire. These apps do read the O2 sensor voltages but not as Exhaust Gas Temperature. For a free app and only needing an inexpensive $15 OBD2 Bluetooth adapter, its hard to go badly wrong here.

Rick

[bubba2533]

EGT? Do you mean EGR?

[NSFW]

Exhaust Gas Temperature.

[B52Bombardier1]

Exhaust Gas Temperature is a turbine jet engine performance parameter but I suppose it could be construed as having some relevance here to oxygen sensor performance.

Rick

[In-Tech]

EGT is worth having a gander at but truly has little to do with tuning. Having done lot's of 10 wideband stuff, the AFR/Lambda can be perfect and EGT's will be all over. All that means is different cylinders are doing different amounts of work(mass flow).

[Jim Blackwood]

I really do appreciate the work you guys have done, and you don't get anywhere near enough praise for it. Fortunately for me I've cleared yet another hurdle and can now concentrate on the Log Profile, another new area where I have much to learn. My single biggest challenge at the moment is to include the EGR System Enable (B1301) in the PID's because this is connected to my wideband sensor via pin C1-55 with the flag enabled. I gather that is a somewhat common way to datalog the WB-O2 and I'm following Scott C's lead on it. I think once I'm past that I will be ready to datalog a full runup to operating temp, look at the datalog and fuel trims and be a big step closer to driveability.

On the topic of EGT, I do find that useful. One particularly helpful trip included a climb up Jellico Mtn which is long but not too particularly steep. By watching the WB, the EGT, and the ECT I was able to make considerable progress in tuning not just the VE table but also the advance table. It's been a long time now so I don't really trust myself to get all the details exactly right but even though ECT tended to lag EGT they did not indicate the same thing and the important thing that I learned from that was that I could use one to tune the advance and the other for fuel, in conjunction with the WB and each other of course. It was a sort of dance they did depending on how the engine was being fed. If you learn to follow that dance you can do a pretty good job of fine tuning. I documented this on the BritishV8 forum so it should be possible to go back and find it for the details. Probably when I get a little farther along I'll look for it.

Jim

[ColPaul]

PcmLogger is still primitive, but it basically works...

You have to edit the XML files by hand to get it to log different parameters. The profile contains a list of parameter groups, and each parameter group can fetch 6 bytes from the PCM. It's up to you to make sure that each parameter group has at most 6 bytes (each parameter can be 1 or 2 bytes). I've tested up to 3 groups. Eventually I want to give it a list of parameter that you can just pick from.

The other thing is that you can pick parameters based on OBD2 PIDs pretty easily but for a lot of useful stuff there is no PID, and we'll need to find the RAM addresses of the important stuff through reverse engineering.

And it only produces CSV files, so you'd need Excel or something like it to create a histogram.

Can we put the 6 byte response restriction in a README or somewhere more obvious? Maybe even an XLM comment in each of the provided XML files (my preference). I tried using PCMLogger with some success, but some of the data wasn't making sense. I did NOT limit each parameter group to 6 byte response. Maybe I missed that warning, but it was not until I searched this thread that I found the constraint.

I don't want to sound negative here. I really appreciate the opensource software. Thanks for all your work on this!