Evoscan and LC-1 - Weird readings
 

Hi Guys
New to using evoscan and the lc-1, managed to start logging data from my 8MR, but the wideband is not logging correctly. Im getting values like thos in the attached log file, what could be wrong, double checked my installation and everything seems correct. Is there anything i need to setup in the LC1?

Thanks for any help
Evosingh

If you already have the LC-1, you could simply use the newest LogWorks to log everything you are logging with EvoScan and you LC-1 and any other Innovate MTS devices.

Unless, of course, you are set on using EvoScan. If that is the case, I'm sure Evo4Mad could help you out or someone else that is using the LC-1 with EvoScan.


Eric

Have you made sure that the wideband sensor selection is set to LC-1? The menu item is "Wideband", fifth from the left.

I use the ZT-2, and since the default in EvoScan is the Innovate LM-1 (the first selection), if I don't remember to change the setting after I start up EvoScan, I get garbage in my logs.

How would i go about setting up Logworks to log data instead of evoscan, like i said im new to self tuning. Why am i getting the readings that i got in the attached file? the wideband value hover between 4 and 5 but jump to 10 and 13 in places.

That was one of the first things i checked, set to LC1 and correct com port selected

Just make sure that you download the latest version of LogWorks. Install that and you will have another option under 'Extra Devices' called OpenPort 1.3. You run that first before you start LogWorks. It connects to your Tactrix cable and asks what parameters you want to log. Choose the Mut-III option. When you are done picking them from the list, just start LogWorks and when you start a new realtime log, everything will be there in one Log.

Do a quick search in this forums. I have posted a few of these logs as well as others. Just search for LogWorks and I'm sure you'll find them.


Eric

You might also want to substitute the protocols.xml file in Logworks with this one that I have been using. I have been using it and I know that the following are accurate:

Speed
AirFlow (added)
TPS
TimingAdv
KnockSum (added)
OctaneFlag (added)
InjPulseWidth
CoolantTemp (fixed to display accurate *F)

I also organized them as shown. This makes it easier to load them everytime you want to log.

logworks is a really good app, I will also be adding support for the MTS Data channels (Innovate Widebands and other data aquisition products) to Mitsulogger in its next full release, I'll hopefully get basic LC-1 support into the 1.5 release. I have to talk to the folks over at Innovate, but I want to try to support the protocol natively and not have to rely on external apps or component installs for it to work. I had too many headaches with dependencies with other tools I've written. I'm hoping they use an I2C type addressing for their serial interface.

Hit me up offline. If you are only interested in Lambda devices, I can show you how to pick the lambda channels out of the data packet stream and ignore the rest. You could figure it out yourself from the serial2 doc, but I just helped another vendor do the same thing.

If you want to do LC-1 only, it is simpler still.

-jjf

Yeah, for the time being, the LC-1 is what I want to get into Mitsulogger for this maintainance release..

I'll e-mail you tomorrow when I get a chance, out of curiousity, will the LC1 function on the bench without the sensor connected but powered with a 12v power supply? I want to fully support all the stuff eventually as natively as possible in a plugin.

The lc-1 can and will change data settings if you plug in the serial cable during power off or boot/warm up modes. Use lm config and check the setting on your lc 1 and make sure it is set to gasoline on the first screen that pops up. I had the same problem until Innovate told me about the data corruption on plug in problem. I hope that helps.


Malibu, the lc-1 will go into heater circuit calibration mode if you attempt to run it without the sensor attached.


edited to clarify lc-1 conditions that can cause data change when attempting to connect the lc-1

Its funny, I have a test pipe with an o2 bung in it.. I have it laying around and might use it for my bench testing so I can leave the sensor attached when I am testing (plus I can do free air calibration with it without risk of burning anyone, or anything. But that also means I would need a power supply that supports a higher current draw.

EvoScan never logged my LC-1 correctly, but Logworks does it flawlessly and I greatly enjoy the graphical view of the live data over a .csv generated log.

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! :D

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

Thanks