Try downloading the latest setup files in mpscan. Maybe something is out of sync.
89 Voyager LE, 2.5T2 - rest in peace
87 Charger Shelby T2 (2.4 conversion in process)
ill give it a shot today or tomorrow.
Brian
Originally Posted by turbovanman
does this mean reinstall the program? i did that. then i let it update. then i went outside and hooked up and started the car and connected and logged. stuff still is jumping all over the place. here are my files.
https://www.dropbox.com/s/a3v1ec55ot...-log4.zip?dl=0
also, do i need to use any of my cal files with MPScan to make sure its looking at the correct locations?
I also tried an copy of Jeff Chojnacki's LMLog from around 2007/2008.
it logged just fine. i noticed in his setup file that he was using a different baud rate for low baud... 977 vs 976.
with both MPScan and LMLog, the car runs wonky when logging vs not logging. any idea why?
want me to monitor/log serial coms when im logging?
Brian
Originally Posted by turbovanman
brian - send me the .mpc file that goes with the log. thanks.
89 Voyager LE, 2.5T2 - rest in peace
87 Charger Shelby T2 (2.4 conversion in process)
Originally Posted by turbovanman
now thinking out loud here....
every time i logged the car with MPScan, it has ran all wonky. like hunting for idle, really lean, etc. when id stop logging, the rpms would jump up and it would run better.
today i hooked my otc scanner up to it and it ran fine. nice and smooth and good afrs. no wonkyness.
Brian
Originally Posted by turbovanman
the calculated lm rate is 1000000/1024 = 976.56. the diff in rate between 976 and 977 shouldn't matter. if you have a logic analyzer i would love to see a few seconds of logging from the beginning of a session using both mpscan and the otc scanner. maybe setup a new display in mpscan that shows the exact parameters that are being logged with the otc. then we can compare/analyze bytes sent/received. i'm not sure if the otc scanner logs at the high or low baud rates.
89 Voyager LE, 2.5T2 - rest in peace
87 Charger Shelby T2 (2.4 conversion in process)
Ive done this. For an SBEC-I anyhoo. The details start here:
http://www.turbo-mopar.com/forums/sh...=1#post1066219
No surprises....I think
i have one of those DSO Quad scopes and the firmware im running does serial decoding..... but only one channel..... which is kind of lame. i guess if i logged one channel, and then the other, i could take the files and combine them and align them but that might provide BS data lol.
there is another program that i can run on it that does 4 channel logic analyzing but it doesnt decode to hex i dont think but i think i can use GTKWave to decode.
that same guy wrote a USB decoder program too which looks pretty slick. can i just snag the USB signals rather than the regular serial ones?
now if i load these other firmwares, then ill have to recalibrate the DSO after i put my main program back on the device but thats not a big deal.
also, since you guys seem to be better than I at programming obviously.... any chance you can write up a little terminal program that will allow me to use 2 FTDI cables and log serial at 977 and 7812 baud rather than the standard bauds that most terminal programs offer... unless you know of one already?
thanks
Brian
Originally Posted by turbovanman
89 Voyager LE, 2.5T2 - rest in peace
87 Charger Shelby T2 (2.4 conversion in process)
I use realterm for diagnostic work at arbitrary baud rates. Its free. Run two instances on separate ports and you should have no problem logging two data streams and comparing afterwards.
What is the goal here again? To compare MPSCAN to OTC? But isnt it already known what MPSCAN outputs?
Yes but combine both streams in the program but space them out so you can see clearly the transmit and receive lines as they come in and see what flights are coming in incorrectly and try to determine why. Like transmitted in one column and received in another column or put a little better before and after to label or make transmitted one color and receive another color
I hate doing it with two programs and trying to merge the data.
- - - Updated - - -
Oh yeah and no I do not need to send data Morris. This is just to log and give feedback.
Originally Posted by turbovanman
oh I see you want to monitor both sides of one serial link. Thats a pretty routine operation in embedded development , and therefore there are many terminal programs that do it. I've used termite before and its free and seemed to work well. You would use it in a forwarding mode so that you dont have to make a breakout box.
http://www.compuphase.com/software_t...tm#FORWARDDATA
"You can use Termite to put a PC (or laptop) between two systems and monitor their RS232 communication. The PC or laptop that Termite runs on must have two RS232 ports. Instead of connecting both systems together, you connect both with the PC that runs Termite. Then, you have to choose one port as the primary port and the other as the "forward" port, see the Settings dialog of Termite."
And yes, Termite supports non standard baud rates.
yeah ive done that on other equipment to see what it was doing. I already have a few different breakout cables....
problem is that I dont have any laptops that have two native serial ports anymore and my other USB to serial adapters that i use for stuff with standard pc baud rates, dont support the weird baud rates that our ecus use.
now, once my other FTDI cable gets here, ill try that program. ive used a few others in the past. will it be ok with the switchover from 977 to 7812?
thats part of the reason that i asked morris if he could whip up a terminal program that could just listen on the TX and RX lines (not sitting between and forwarding the data back and forth) that was compatible with our ecu's be it 977 baud, 7812 baud or 62500 (or whatever the smec/sbec is) and record and help troubleshoot things like this.
i mean MPScan does all those functions already.... but gut the complex stuff and just display the communications seems like something that would be easy for him..... and impossibly hard for me.....
now, that could be added to MPScan to slow the coms when its logging?
and a MPSniff program that can listen to anything on the sci bus.... like if rob has the ecu just continually dump certain parameters rather than this ask-listen-receive data deal we have now that seems slow especially on LM's. I guess a hangup could be if the ECU switches to another data rate and you set the sniffer to the lower one.... but im sure its not hard to have autodetect and change bauds when the baud rate command is given?
Originally Posted by turbovanman
did this ever get resolved? chromguy is also experiencing the same issue. is this a T-LM phenomenon? i would love to see a logic log of jeff c's program to see what he did that is/was different. i don't understand the bad data/ram locations since mpscan uses exactly the same as T-LM is set up for. maybe Rob Lloyd can jump in on this........... weird that running mpscan would affect how the car runs unless it is consuming too many ecu cycles or somehow modifying a ram location based on the values being sent.
89 Voyager LE, 2.5T2 - rest in peace
87 Charger Shelby T2 (2.4 conversion in process)
I tried it again today.
Logging only coolant temp. It seemed to work when logging ok but once I closed the program, the idle shot to 1400 and got lean. Had to restart the car and restart the laptop to get any com ports working again.
Brian
Originally Posted by turbovanman