pcmhacking.net

When using PCM Logger 014 to read PCM addresses from 0xFF8000 to 0xFFC000 it always returns 0s. Reading registers above this RAM space always returns 0s. I tried using the PCM Logger 014 Example 2 log file and all of the RAM addresses log as zero when using the 3358 PCM. Is there something else that needs to be enabled? I saw a thread on WB Logging where they were trying to read the A/D at address FFFF2C2 and also received 0s.

Please try: PcmHammer16D-Preview

Thank you for the link to the latest. When I run that version of PCM Logger 016D-Preview and the 3358.RamParameters.LogProfile none of the RAM variables are listed in the CSV Log file. With PCM Logger revision 014 the RAM variables are listed but are always set to 0.

I noticed the Pcm Logger 016-D Preview 2 byte calculations are not what I expected. I changed the bin to force a run time of 0xF080, and did the same for the MAF sensor PID so I could report RAM address location values. Something strange is going on with the MSbit assuming a sign position and how the remaining 7 bits are used. It is not a standard 2s complement.

I expected to see 0xF080 = 61,568 is Pcm Logger assumes unsigned which the XML assumes since does a MSB*256
or a -61,568
From the Parameters.Standard.file
<Parameter
id="11A1"
name="Engine Run Time"
description=""
byteCount="02"
bitMapped="False">
<Conversion units="Boolean" expression="((x_high*256)+x_low)" format="0.00" />
I think for now I will just report the RAM Address WORD sized data using two different byte sized PIDs which seem to not assumed 2s complement data.

Can you post your modified bin file?
That will make this easier to debug.
Thanks!

Hi,
I figured out what happened. Here is how it goes. I was reporting a value of 0xF080 in the Mass Airflow PID.

MSB = 0xF0
LSB = 0x80

The Pcm Logger assumes the MSB of the Airflow PID is SIGNED, and the LSB is UNSIGNED.

2s complement of 0xF0 is NOT(0xF0)+1 = 0x10 = -16 decimal

Pcm Logged computes this : -16 *256 + 128 = -3968

It does the same for the EngineRunTime so if the MSByte bit 7 is ever set it will start reporting negative. I am guessing it does this for all of the PIDS that report 2 bytes.

Yes, I think you've got it figured out.

I'm pretty sure that you can now use just "x" instead of combingin the x_high and x_low values in the expression, but the "x" value is going to have the same problem because it is computed the same way.

In the Subaru logger definitions from the RomRaider project, there's a storagetype attribute, so for example you can say storagetype="uint8" or storagetype="int16" or whatever. That tells the code how to avoid this kind of problem. I'll add the same thing here, and use that in place of the byteCount attribute that's in there now, since storagetype also indicates the number of bytes.

I posted a zip file here that should fix the issue, please give it a try and let me know how it goes:

viewtopic.php?f=42&t=6688&p=107406#p107406

The x_high and x_low stuff is gone, now there is just x and it should always be correct.

The byteCount attributes have all been replaced with storageType attributes.

Hi,
I ran the 16E pcmlogger.exe and Win10 reported an unhandled exception. I have attached the Win10 debug report. I clicked on the exception window "continue" button and then PcmLogger allowed me to select a param file. I selected the 3358 param file in the same directory. The log window then reported it could not evaluate the "Engine Speed" equation and displayed it. The equation did appear to be correct.

It occurred to me you mentioned only "x" exists now in 16E. The "standard" file in the Pcm Logger 16E directory contains both "x" and "y" in the 16 bit equations. This is likely the reason PcmLogger 16E is failing and reporting the unresolved equation for the Engine Speed since it is the first x and y equation it encounters. I will try modifying the equations later to just use x * K instead of (x*256 + y) * K.