Originally Posted by nj1266

FWIW, Evoscan never had a problem logging my LM-1 and neither did Mitsulogger. But now that Logworks can combine Tactrix data, I have been using it to do all my logging in one application.

I can't wait for the Xede plug-ins so I can log my real timing. Innovate FTW

Originally Posted by 4 Wheel Slide

i have no problems using my lc1 with evoscan.. make sure you pick evoscan on the drop down menu and the correct communication port.... i installed it on 2 computers and it defaulted to com 5 both times.... if its not set up properly it wont work right... and i need to select it everytime i start evoscan.. for some reason i cant get it to save the same settings

did you calibrate it correctly? with the outside air?

Originally Posted by jfitzpat

I've never seen this first symptom, but it makes sense. Serial is on a 2.5mm jack (for a firewall hole). When you insert the jack, tx and rx briefly make contact with ground. So, you are briefly putting 8-12V on system ground. This probably triggers the overvoltage/brownout protection.

Since initialization (warmup and stablization) did not complete, the unit assumes that the other persistant values are suspect as well and rests.

Regarding the second case, the unit will actually report an error (heater circuit open) with no sensor attached. I'm not sure I would ever trust a controller that thinks it can send a value when there isn't even a sensor!

MJ:

Down and dirty, LC-1 only serial isn't that hard. Hookup a sensor, attach the serial connector, turn it on. After heater cal (occurs first time sensor is attached or when sensor is replaced), and warmup (always occurs), you can open a serial port at 19,200, 8, n, 1, no handshake and see the following over and over (in hex):

B2 82 47 13 01 51

B2 82 is the serial2 protocol header. 0xB2 means serial2, sensor data, no device in chain is recording, no device in chain has built in logging.

82 is the remaining packet length in WORDs (2 bytes) with the high bit set. FWIW, 'look for B2 then confirm next byte has high bit set', is a very reliable way to syncronize to the stream.

The remaining four bytes are the LC-1 data. It is easier to look at them as two big endian words:

4713
0151

The second word is a value, however, since the top bit is not allowed to be set in either byte, the first byte is the top 7 bits of our value and the second byte is the lower 7 bites of our value. So, 0151 actually means a value of D1 (209 dec). Or (01 << 7) + 51 (of course, you can multiply the first value * 128 instead of shifting it).

The first word tells us several things. Counting from Bit 15 down the breakdown of bits is:

0 1 0 F2 F1 F0 1 AF7 0 AF6 AF5 AF4 AF3 AF2 AF1 AF0

The zeros and ones are fixed, and can be tested for. In other words, if you AND the first byte (47) with E2 you should get 42, indicating that it is, indeed, an LC-1 data block. Similiarly, you can AND the second byte (31) with 80 and should get 00.

F2 F1 F0 (bits 12, 11, 10) indicate the meaning of the value word. Possible values are:

000 Lambda valid, normal operation.
001 Lambda value contains O2 level in 1/10%
010 Free air Calib in progress, Lambda data not valid
011 Need Free air Calibration Request, Lambda data not valid
100 Warming up, Lambda value is temp in 1/10% of operating temp.
101 Heater Calibration, Lambda value contains calibration countdown.
110 Error code in Lambda value
111 reserved

The one you care most about is 000 (lambda data). However, my sensor is sitting in free air (outside normal measurement range), so the mode is 001 (47 AND 1C = 04, Shifting down two bits (or divide by 4 - to put the function in the bottom of the byte) gives us 01).

Looking at our value, of 209, this makes sense. We are reporting O2 at 20.9%.

If you want a lambda value, you can use butane from a lighter. Once the mix gets to a measurable range, the mode will switch to 000. Then the value calculation changes. For O2 it was "value * .1". For lambda it is "(value * .001) + .5".

The result of this calculation will range from .5 to 1.523 and is the actual lambda measured. To turn lambda into AFR you would multiply by the proper multiplier for the fuel. For example, for gasoline "AFR = 14.7 * lambda". You could just use lambda values this way and your readings will be right. However, if you want to use it, the packet also carries the AFR multiplier programmed into the unit (gasoline, methanol, whatever). It is in the AF bits in the first word.

We mask them out:

4713 AND 017F = 0113.

Then combine the two bytes as we would a value (again, because the second byte is limited to 7 bits). 01 13 becomes (01 * 80) + 13, or 93 (147 decimal). Like O2, the multiplier is in 1/10ths, so 147 is actually 14.7 - meaning this LC-1 is programmed for gasonline.

The packets will occur every 81.92 mS (just over 12 Hz) by default. If you need faster rates, contact me - it can be done, but it is a bit more involved.

Last note, after you run LM Programmer, there will not be any data packets until you cycle power.

I hope the above helps.

-jjf