MPScan LM Log file

[wowzer]

would someone either post up or pm me the mpscanport.txt file that is created when you SUCCESSFULLY log with MPScan using an LM ecu? i need one for reference.

THX

[iangoround]

Subscribed.

My bench LM is toast now, so I've moved on to other projects for now. Eventually I'll get my car back and I can plug it in and see what mpscan says. I'm willing to bet that LM I was using had some issue before I cooked it though.

[wowzer]

would someone either post up or pm me the mpscanport.txt file that is created when you SUCCESSFULLY log with MPScan using an LM ecu? i need one for reference.

THX

bump for log

[iangoround]

I have my car back now. Here's the log file after connecting to my LM.

mpscan ver - 2.0.2.8Microsoft Windows 7 Professional - Win32NT
trying to open port COM1 - ctlrecord_click
got a good port back - ctlrecord_click
try to open port COM1 -initport
COM1 is a legit port -initport
usb is available on COM1 -initport
usb ftdi serial number 12WQC1T3 is available - initport
setting port baud rate to 976
ftdi open successful on COM1 -usbportinit
using protocol LM:0
attempt to change ecu baud rate to 7812
Sending byte 18
Received byte 0
Read confirm byte failed (status:0 - count:0)
Sending byte 18
Received byte 255
Changing mpscan baud rate to 7812
Sending byte 18
Received byte 18
Byte 18 was sent 1 times to make the change.
usb ftdi
Successfully opened port - ctlrecord_click

[wowzer]

thank you

[wowzer]

I have my car back now. Here's the log file after connecting to my LM.

would you also post up the mpt2coms.txt file as well as a short log file you have done? thx.

[iangoround]

Sure. I can go do a fresh log sometime this week if it stops raining.

[iangoround]

https://drive.google.com/folderview?...jA&usp=sharing

I will say that I was having a lot of the same problems as Brian. About half of the time I can't get MPScan to connect. There's no telling what makes combination of things will make it work. Sometimes if I switch USB ports it works. Sometimes cycling power on the car works. Sometimes I have to restart the computer. It usually works best if I can get it to connect before I start the car.

Looking at this log, the gauges are really jumpy, and RPM reads about half of what it really is. I just added a 2x multiplier in the display for now.

[wowzer]

thanks for sharing. a couple thoughts.

1) rpm in the lm is usually represented at half the value of the smec. in other words dec 19 in the lm may represent 1220 while in the smec dec 38 represents 1220. rob L will need to comment on this but perhaps there needs to be an "LM" rpm gauge that sets the ecu max value at 4096 vs 8192 (smec value).

2) the gauges are jumpy because it appears that the bytes being returned are getting out of sync with the ram addresses sent. usually it appears an extra "0" is returned. i don't know if this is related to some type of "noise" issue on the line or if my logic is screwed up somewhere. i don't see the problem with the smec/sbec ecus however. i will review my logic. i'ld be interested to see what happens if you would slow the sample rate down from 100 mS to 150 or 200. your log file shows the lm ecu return 84 bytes per second, or a byte every 11mS. a 10 byte sample would therefore take 110 mS, so logging any faster really doesn't do you any good. i am surprised the ecu is that slow. the smec will run 275-300 bytes per second so you would thing the lm would do at least half of that.

3) i am uncertain still exactly how the lm "boot" sequence works. not quite sure what to expect in return every time you send a 0x12 byte to the ecu and when to flip to the high baud rate. it appears that it is working but that is why i need to see a BUNCH more lm log files from other users.

4) lastly, the latest version of mpscan is 2.0.3.0. i made a couple tweaks in the way layouts are managed as well as adding a couple extra things in the com port log files. i would suggest you reload the display layout under the new version and then resave it. if you could then do a quick log again and send me the same 3 files you posted above that would be excellent.

*edit*
that is why i would love to see an lm log that is experiencing the bad data on a logic analyzer to see if the ecu is sending back the extra/bad bytes.

thx.

[ShelGame]

thanks for sharing. a couple thoughts.

1) rpm in the lm is usually represented at half the value of the smec. in other words dec 19 in the lm may represent 1220 while in the smec dec 38 represents 1220. rob L will need to comment on this but perhaps there needs to be an "LM" rpm gauge that sets the ecu max value at 4096 vs 8192 (smec value).

Yes, the LM's RPM scale is double the SMEC and SBEC; 0-16368rpm. Yet another reason to write new code for the LM.

2) the gauges are jumpy because it appears that the bytes being returned are getting out of sync with the ram addresses sent. usually it appears an extra "0" is returned. i don't know if this is related to some type of "noise" issue on the line or if my logic is screwed up somewhere. i don't see the problem with the smec/sbec ecus however. i will review my logic. i'ld be interested to see what happens if you would slow the sample rate down from 100 mS to 150 or 200. your log file shows the lm ecu return 84 bytes per second, or a byte every 11mS. a 10 byte sample would therefore take 110 mS, so logging any faster really doesn't do you any good. i am surprised the ecu is that slow. the smec will run 275-300 bytes per second so you would thing the lm would do at least half of that.

I think 11ms might be the limit for the LM. The data loop is part of the main loop, not an interrupt.

[iangoround]

I'll attempt to try that tonight.

[iangoround]

https://drive.google.com/open?id=0Bw...1h2RjRwbWJBSWs

I changed the sample rate to 200ms, and set the latency on my FTDI port to 1ms. Also set the ECU Max to 16320 for all of the RPM fields I could find so the RPM gauge reads accurate. The MAP gauge still jumps around. I took this log sitting in my garage revving it a bit. The highest actual reading I saw on my autometer was just below 0. My autometer also disagrees with my MAP sensor by about 2inHg.

sidenote: this thing lopes like a cammed out mini V8 with the TU R5 camshaft.

[wowzer]

there was only 1 file in the link. i noticed it said the vcp driver was not loaded. make sure you check that the vcp option in the driver setup is checked. usually get to it through the windows device manager. also, the ecu max may be 16384. it would be nice if you could verify the rpm outside of mpscan to see what value works best (16320 or 16384).

i'll be waiting for the other files :-). thx again

fyi

[iangoround]

Oops. Here's the folder.

https://drive.google.com/open?id=0Bw...UhTbXdOalNjSjA

[Aries_Turbo]

I'll see if I can do a log tonight.

[iangoround]

VCP is/was enabled. Not sure why it didn't report as that in the log file.

I'll upload all of my files to that same google drive folder, so the one link should always be good.

[wowzer]

thanks

[iangoround]

Hard to tell which RPM value is more accurate, since the sample rate is now 200ms, the gauge jumps around a bit, and my car lopes with the R5 camshaft. I THINK 16368 might be a little closer.

Log files from this morning uploaded with the suffix "81315"

[wowzer]

to all --

can anybody record a short (1 to 2 min) LM ecu logging session with mpscan AND a logic analyzer. i need to really figure out if the bytes coming back from the ecu are bad or if it is something in mpscan.

lmk.

[iangoround]

I don't have a logic analyzer, unless I can turn my arduino in to a crude one. Might be a little over my head though.