MPScan

[MoparStephen]

If you selected 'custom' in MP Scan, then that's the problem. That uses 9600 baud; but the LM can't use that baud. It uses 976 and then 7812.

Interesting. The only way I can get MPScan to log without error, is using the custom (9600 baud). It makes sense that no data is returned since the LM cannot communicate at this rate. When trying to log using the LM setting, I get the unable to open port every time. I will email you the log file that was created.

[ShelGame]

Actually, I just looked and the opt_ flags you posted aren't even enabled in the template. They're commented out. I just put them in there for future use.

- - - Updated - - -

Interesting. The only way I can get MPScan to log without error, is using the custom (9600 baud). It makes sense that no data is returned since the LM cannot communicate at this rate. When trying to log using the LM setting, I get the unable to open port every time. I will email you the log file that was created.

What cable are you using to connect to the car?

[MoparStephen]

Actually, I just looked and the opt_ flags you posted aren't even enabled in the template. They're commented out. I just put them in there for future use.

What cable are you using to connect to the car?

I will have to verify that this is the exact part number when I get home, but I believe it is http://www.digikey.com/product-detai...028-ND/2003493. It is an FTDI USB to serial cable, and I configured it using screenshots from a thread here. This is not the cable I use with MPTune - for that, I use a standard USB cable going to my Ostrich2.

[wowzer]

he is using the ostrich to burn chips.

i think he needs to try flipping the tx/rx lines and see if that helps any. the ecu is not responding at all when the bytes are sent so either the rx/tx is messed up, the lines aren't inverted, or the ftdi cable is bad.


thats the same cable i use. i'll check my connections when i get home and let you know how i have them set up.

rob - isn't there some quirk with the lm and inverting the signals depending on how you hook up to the ecu?


*** from risens post***http://www.turbo-mopar.com/forums/sh...+invert+signal
FT232RL -
Orange cable (TX)-> Green wire on the SCI connector
Yellow cable (RX)-> Pink wire on the SCI connector
Black cable (GND)-> Black wire on SCI connector

and further down per rob L regarding inverting signals for the lm--
"I thought this (NOT inverting signals) was only true if you were wiring in the cable/adapter directly to the MCU. If you plug it into the SCI port like on the SMEC and SBEC, you still need to invert the logic levels, correct?"

and risen responded that rob was correct.

[MoparStephen]

he is using the ostrich to burn chips.

i think he needs to try flipping the tx/rx lines and see if that helps any. the ecu is not responding at all when the bytes are sent so either the rx/tx is messed up, the lines aren't inverted, or the ftdi cable is bad.


thats the same cable i use. i'll check my connections when i get home and let you know how i have them set up.

rob - isn't there some quirk with the lm and inverting the signals depending on how you hook up to the ecu?


*** from risens post***http://www.turbo-mopar.com/forums/sh...+invert+signal
FT232RL -
Orange cable (TX)-> Green wire on the SCI connector
Yellow cable (RX)-> Pink wire on the SCI connector
Black cable (GND)-> Black wire on SCI connector

and further down per rob L regarding inverting signals for the lm--
"I thought this (NOT inverting signals) was only true if you were wiring in the cable/adapter directly to the MCU. If you plug it into the SCI port like on the SMEC and SBEC, you still need to invert the logic levels, correct?"

and risen responded that rob was correct.

Thanks guys - I will mess with this some more when I get home.

- - - Updated - - -

It seems that it was the USB to serial port configuration setting (under Windows XP). I played with the read&write minimum timeout settings, send/receive packet size, and latency settings. Now I just have to get a layout setup, and figure out how to get a valid RPM reading. Speaking of - does anybody have a RAM template which is all set up with names and valid min/max settings? I did an import of my .lst file, but it did not set any values other than the address names.

Sorry for making you check your code due to a hardware issue.

[wowzer]

so - were you able to connect? post the mpscan log file.

***edit***

i just checked my connections. they are

ftdi Orange (tx) to sci light green (rx) pin 31
ftdi Yellow (rx) to sci pink (tx) pin 51
ftdi Black (gnd) to sci ground.

[MoparStephen]

Yes - I am now able to connect and properly log data. Since I was unable to find a nice named RAM file for the LM, I went through the SMEC asm file, and grabbed all of the MPScan comments for the 1st 256 RAM locations. I only used the ones where the variable name matched exactly. This way, when I did an import into MPScan from the new LST file, I have most useful variables filled in and configured.

I can post this file if you like. I am not sure what the rules are for posting modified files.

[wowzer]

all i want is the mpscanport.txt file that is created when you try to connect to the ecu to record a session. you can pm the file if you want. thx.

[MoparStephen]

all i want is the mpscanport.txt file that is created when you try to connect to the ecu to record a session. you can pm the file if you want. thx.

OK - the files are on my laptop at home - I will have to PM you when I get home (should be home by 4P)

[Force Fed Mopar]

I haven't tried it in mine again yet. I'll see if I can make time tomorrow.

[ShelGame]

FWIW, MP Scan also worked just fine with my SBECII this afternoon...

[wowzer]

FWIW, MP Scan also worked just fine with my SBECII this afternoon...

rob - what version of mpscan were you using? can you email me the mpscanport.txt file.

[ShelGame]

rob - what version of mpscan were you using? can you email me the mpscanport.txt file.

I wasn't using the test version on my netbook, just the regular download...

[wowzer]

so it was using the old connection method for the sbec ii, ie. i assume in the port settings you selected sbec 2 which uses 0x12 to go into hi baud and 0xc4 to confirm hi baud.

[ShelGame]

so it was using the old connection method for the sbec ii, ie. i assume in the port settings you selected sbec 2 which uses 0x12 to go into hi baud and 0xc4 to confirm hi baud.

I didn't check, which means it was probably still set for SMEC...

[wheming]

I don't want to clutter this thread, but can someone tell me if what I observed in the thread below indicates a setup issue with MPScan?
http://www.turbo-mopar.com/forums/sh....php?p=1001855
Slugmobile's datalog anomalies

I got mostly good data, but at times the data was like failed high. Meaning read at the top of the range. When looking at the data through my dashboard setup, it showed valves at the peak displayed range like speedo at 200 mph and tach at 8000rpm.
Raw data was even higher values.

I'm trying to find out if I have a wiring or hardware issue, or if I have a tuning or software setup issue. But I'm no expert with this.

Thanks for any assistance or direction.

[ShelGame]

I don't want to clutter this thread, but can someone tell me if what I observed in the thread below indicates a setup issue with MPScan?
http://www.turbo-mopar.com/forums/sh....php?p=1001855
Slugmobile's datalog anomalies

I got mostly good data, but at times the data was like failed high. Meaning read at the top of the range. When looking at the data through my dashboard setup, it showed valves at the peak displayed range like speedo at 200 mph and tach at 8000rpm.
Raw data was even higher values.

I'm trying to find out if I have a wiring or hardware issue, or if I have a tuning or software setup issue. But I'm no expert with this.

Thanks for any assistance or direction.

I see that from time to time as well...

[wowzer]

any time the logs show a number of samples in a row that are all the same data it usually indicates mpscan is not getting back info from the ecu timely. mpscan only updates the logged sample after it has gotten back all the bytes requested for each "cycle". you are requesting around 23 bytes at a time so the "sample" is not updated until mpscan gets all 23 back. if that takes quite a while because of a poor quality connection or some other issue mpscan will use the same sample several times. i see in the logs you have a number of times where all the samples are duplicated for 4 or 5 rows. also, when there is a huge number it usually is because mpscan got out of sync with the data being sent and the data being received. i do use a "bad byte" counter when getting a sample so i can retry that byte but i don't keep track or report the total number of bad samples. maybe i should.

i'll take a look and see if i can figure out how mpscan can get out of sync, causing the wild numbers periodically. that's my problem. the duplicate samples will be hard to track down. worst case is not to log so many gauges at one time.

as a side note. you need to change your ram location file settings for map. the default ecu min/max is set up in error to go from 0 to 30. it really needs to be -14.7 to 14.7 for a 2 bar map and -14.7 to 29.4 for a 3 bar. also, there is a setting if you want to report the psi below 0 as vacuum. if you look back thru the mpscan thread you will see how to do it using breakpoints and a multiplier. rob L probably needs to change that in the asm file for the cals. also, the afr gauge does NOT work and the injector pulsewidth setup is unknown. rob and i fooled with the injpw a bit but still don't know the proper settings to use for it or what that ram location truly is reporting.

[wheming]

Yes, I realized after I set this up as my first attempt that some of that RAM location point setup was wrong and couldn't be adjusted later. I also found where you had said some of the points I added were not ever fully worked out to be used for logs like the afr and wideband. Injector pulsewidth appeared to be close just off by a x100 factor or something.

I'll try to reconfigure the ram setup for my application and clear out those gauges that don't function usefully and try it again.

When those issues occur though the failed data, that is just in the reporting to MPScan and not a data issue in the SMEC right? One reason for me trying to set up the log was to troubleshoot seeing a CEL flash and having an otc scanner see some timing being pulled. But the otc only saw -1 deg in #4 at about 17 psi. That's why I never pushed the boost further at sdac until i could determine why.

Thank you for that info. I'll try to get things set up properly for my retry.

[wowzer]

if you are brave enough to edit the .mpc file you can make the changes to the gauge settings in there. however, it is best to change the ram location file and then just delete the gauge and re-add it to the layout screen.

i can't guarantee that the smec is not producing errors but MOST LIKELY there is just some periodic noise/interruption that i am not handling effectively in mpscan. i've never had the problem using my smecstim but in a "real" environment i'm sure there are other issues that will arise.