Need Datapoints from 87 LM for datalogging

[csxtra]

I am looking for two addresses and the scaling info so I can finish the display/logging application for the 87 LM in my CSX. I have all the other points working, but now I need the following to see the results of cal tweaks:
1. Timing Advance
2. Injector Pulsewidth

I know they are available, as the OTC scanner can display them, but before I attempt to trace through a disassembly, I'm hoping that someone has this documented.

Anybody know what these locations and conversion factors are?

Warren

[ShelGame]

OverallAdvance - 0x0072 (The range is -64 to +64 degrees, so the scaling is : degrees = counts/2 -64)

InjectorPW = 0x008d (I'm not sure of the scaling for the LM, it's different from the SMEC and SBEC...)

[csxtra]

Rob,

WOW...talk about a quick response. Thanks SO much for this...I'll try to get this put into my app and let you know what I find out about the injector pulsewidth scaling.

Thanks again:thumb:

Warren

[csxtra]

Ok, I added in the locations for advance (scaled as above) and Injector PW (unscaled). Now at idle, it is showing advance of -20 degrees.:confused:

Is the scale such that a value of 0 = 64 deg advance and 255=-64 deg? This would give me an idle advance of 20 degrees, which looks similar to my old logs from the OTC scanner. I haven't driven the car yet, so I don't have any other datapoints yet, so I'm just speculating.

Also, any idea what the maximum possible pulsewidth is? Looking at old OTC scanner logs, I can see injector pulsewidths up to 25.4 ms (under high boost). Could it be that the scaling is just a simple divide by 10 deal?

[ShelGame]

Ok, I added in the locations for advance (scaled as above) and Injector PW (unscaled). Now at idle, it is showing advance of -20 degrees.:confused:

Is the scale such that a value of 0 = 64 deg advance and 255=-64 deg? This would give me an idle advance of 20 degrees, which looks similar to my old logs from the OTC scanner. I haven't driven the car yet, so I don't have any other datapoints yet, so I'm just speculating.

Also, any idea what the maximum possible pulsewidth is? Looking at old OTC scanner logs, I can see injector pulsewidths up to 25.4 ms (under high boost). Could it be that the scaling is just a simple divide by 10 deal?

Doh! I forgot - the advance gets normalized back to 0-128 deg. So, delete the '-64' in my equation above.

[risen]

As Rob mentioned, the value for advance is signed, I'm not sure how the LM's cpu handles signed numbers, but if they're ones or twos complement, scaling directly like that may not to work (the value for 255 would actually be -1 or 0 , not -127).

I too have been trying to sort out the advance for my datalogger, the next thing I'm going to try is this sort of logic:

if return_advance < 128
#value is positive, divide by 2, subtract from 64
then
advance = (return_advance / 2) - 64
else
#negative value, convert
#haven't found an easy way other than bit twiddling.....

I'm not sure how it's going to turn out, but

As to the injector pulsewidth, I believe it's actually 2 bytes with $8d as the upper byte. In the code there's many "load d from $8d" lines, so it's loading 2 bytes from there. So either take the $8d and $8e locations, multiply $8d by 255 and add the $8e value. Alternatively, you could take the $8d and just multiply it by 255 and use it like that, with a min granularity of 255 usecs. I haven't had a scope to confirm this with by checking the injectors, but it seems to be close, my logger shows ~1-2 milliseconds @ idle. I think max pulsewidth is probably on an even binary boundary, like 32768.

[risen]

Rather than edit my post, my guess is obviously wrong if the values are normalized. But I can tell you that taking the return and dividing it by 2, gives me like 50 degress of advance @ idle in my car. Maybe it's right, again, it's something I haven't had time to test.

Also, the max pulsewidth is more than I previously though. I just remembered that looking through the BB60 code I saw what was below:

; MAX INJECTOR PULSEWIDTH
ldd #$bfff ; load d (a&b) with value -10111111 11111111-

Anything greater than this value is clamped to it. The code checks the upper byte, and if it's larger than 10111111, it clamps the value.

Now the real value is: 49,151 unless I typed it wrong in my calculator.

[ShelGame]

It's a signed value right up to the point it gets stored. Just before it gets stored, it's converted to unsigned. If it's a negative number, it gets set to 0. So, the final advance is never negative.

As far as signed numbers go, yes, 255 is a negative number. Basically, signed numbers use bit seven as the 'sign'. If bit 7 is set, then the number is negative. In effect, numbers from 0-127 are positive, and numbers from 128-255 are negative - in two compliment form. In other words, 128 is actually -1. That's not a very thorough explanation...

[risen]

I

As far as signed numbers go, yes, 255 is a negative number. Basically, signed numbers use bit seven as the 'sign'. If bit 7 is set, then the number is negative. In effect, numbers from 0-127 are positive, and numbers from 128-255 are negative - in two compliment form. In other words, 128 is actually -1. That's not a very thorough explanation...

So the LM actually uses twos compliment to represent negative numbers? I've been looking for a while to see if I could find out what system it used.

I always have to look at wikipedia to figure out how to convert the binary format back to a human readable format. If anyone wants a real thorough explanation:

http://en.wikipedia.org/wiki/Twos_complement

Thankfully, compsci stuff isn't political in nature, so I'd trust wikipedia in this arena :) .