AF sensors give you the fuel trim.
Correction is akin to STFT, immediate changes made from the base map.
Learning is akin to LTFT, learned values +/- from the base map.
O2 sensors give you the volume of oxygen exiting the CAT.
MAF tells you how much volume of air is entering the engine.
MAP Relative gives you the pressure in PSI on the intake. Negative number is vacuum, positive number is boost.
TPS voltage and % give you throttle position and the V value the ECM sees.
With the turbo definitions you can also look at the wastegate and boost timers.
On the transmission side, you can look at the torque request signals, TCC lockup, etc..

 

Thanks! I'll do some more reading, probably try some logs this weekend.

 

I would suggest starting with a few logs of all available PIDs for both the engine and transmission. If everything is working well now, they will provide a reference for comparison if in future there's a problem. Perhaps a log at idle, cold start and fully warmed up, one at steady highway cruise, and one with acceleration (e.g., some city driving).

 

Seabass covered it. When you load up the logger, it slows down the data rate. Less is more.

To get a wide variety of data, use a low number of parameters, make a run, then use another set on the same road and conditions. Then you'll see a more accurate picture.

 

Thank You, great suggestions...comparison data.

 

Definitely a good idea to play around with as many as you have time for. Just don't do too many at once.

Since your goal is to make sure everything is working properly, start with a learning view. Make sure there is very little or no knock on the chart. Make sure the fuel trims on top are near 0. If any of them are over 5 or under -5, especially the 40+ one, there's a leak somewhere.

As for romraider, start with rpm, load (I think it's the 1 or 2byte), manifold relative pressure (MRP), wastegate duty cycle (WGDC), target boost, knock sum, fine learning knock correction (FLKC), feedback knock correction (FBKC).

Start by logging normal around town driving. If everything looks good, then find somewhere to do a few 3rd gear pulls from 2krpm to redline. That's around 90mph IIRC, so you need a bit of room.

You're looking for knock. FLKC is learned knock from previous events or if knock sum goes up at the same time, it could be from that event. FBKC are events that the ecu doesn't learn from, usually shift knock. You're making sure MRP is very close to target boost when you get on the pedal. rpm and load are just markers so you know the conditions that any events happen.

Once you make sure those things are ok, then just play around with whatever looks interesting.

 

For the tcu, there really isn't much there to tell you about health other than temp. But it is interesting to log and see what it's doing.

 

^^^Again, thanks so much. All of you big guys...and everyone are always very helpful.

 

Your right, time is a factor in catching intermittent issues. With a code stored in the ECM, you will know the parameters you need to look at to catch it. First and foremost with intermittent issues is the battery and alternator combined with engine load and rpm signals. From there, you move on to data parameters the computer uses to determine the "failure" that set the code. Fuel trims or catalytic efficiency, you add in ignition and fueling. EVAP includes tank pressure and solenoid activation with the MAP. Idle control, would be MAP, IACV, TPS and RPM.

If the engine is operating as it should, then a large amount of data can be gathered and compared. It can be segmented in groups and separated from the whole in order to see what is going on in a narrow view from the log file. And a greater number of parameters recorded means the curve increases. But when you need to find a glitch, less is more because the software will be able to record more frames of each parameter and the curve is narrow with the faster data rate.

 

If you're not looking for anything specific, then its probably no big deal. Where it becomes important is when you want to know exactly when an event is happening. The more parameters, the more off the event will be from the rpm/load it actually happened at.

 

Well, I tried my hand at some logging today. I am actually looking to identify the low idle/throttle issue. But, I thought I would just log everything available to start. I did have an issue, exeything connected alright, but when I started to log, a red error popped up in the lower left/like dialog box...to fast to read. Something about a "header" thenit tries to connect, connects, then is cycles like this.

I'll make sure I have the right ECU definitions in there, do I load them all, or try to find my specific car?

Also, what would be a good approximate, length of time to log. I was going to do cold/idle, warm/idle some average driving when the idle issue is happening.

 

Length of time depends on how much you want to scroll through or graph. Short logs are best. You can start, run about 3-5 minutes, stop and immediately start again. As long as you know where RR is saving the files, no sweat.

On average, a 10 minute drive yields a 1MB log.

 

Exactly what I need to know, thanks.

 

Still having trouble here. Since I am only trying to log data, I do not yet have a Tractrix cable. My plan was to use my Vag-Com cable for the logging. I am trying to figure which of the ecu definitions I need to be using. I currently have all of the OBXT and GT(XT) definitions saved in the definitions manager, about 10 total. How does the DM manager work, does it prioritize the top?

RR site says the only real way to know which version is to read via EcuFlash. Is there any other way to determine which is correct? Try to connect and log trying each one?(Process of elimination?) Does the VIN help or is the a number on the actual ECU? Anyone know where it is located on the Gen-3?

 

Ok. I think I am just not real confident. I was able to connect and log some short data. Just a test to see if it was working, it is.

Time to jump back into the pool.

 

More Issues. I don't know what I am doing wrong. I have logged some sessions, still tests only. The file is being save as an .XML file and my open office won't open it, I get an error. RR site says the file should be saved as a .csv file. I really want to make this work. I am following the RR site step by step. They are kind of vague in some spots. Any suggestions?

 

It should be saving in .csv form. IIRC, openoffice doesn't play nice.

You can always download the free excel viewer from microsoft.

 

It should be saving in .csv form. IIRC, openoffice doesn't play nice.

You can always download the free excel viewer from microsoft.

Thanks, I have the new Windows8/now 8.1 and some issues from there maybe. Currently, my save-as choices don't allow anything other than a single choice of an XLM file. I will follow advice.

 

Wondering, are you using the "Logger" function in Romraider, or the Romraider ECU Editor?

I believe that for the ECU Editor to work, the Tactrix cable is required. But I also know that to use the Logger, the Vag-Com and the one general file of Logger definitions is all that's needed.

In my case, Romraider does not yet have my specific ECU ROM listed, so I can't use the ECU Editor or "Learning Table Values" function, both of which require the specific ROM to have been "defined". However, I can log, and have logged, all the parameters (sensor data etc) that the ECU can provide (according to the FSM). I think that's been the case with many others; it should not be necessary to download multiple different definition files to use the Logger.

When Romraider is installed, the basic shortcut will open it in the ECU Editor function. The Logger is then selected from the menu list at the top left (Logger/Launch Logger). (I have a separate Logger shortcut which saves that step.)

But I might be way off here, so my apologies if that's the case . . .

 

The ecu editor only edits saved rom files. On the 05-06 xt/lgt ecu's, those can be read, edited, and reflashed with a vag-com cable.

I think he's on the right track so far, but I have no idea how romraider works in win8. But even if it decides to save it as an xml, it should still be readable with excel.

 

I'm using Romraider (Logger) with Windows 8. It saves the logged files in .csv format, same as it does with earlier versions of Romraider (I now have 0.5.7 RC2 Build #561, with the single-version 193 of the Logger Definitions), and as it did with Windows 7.

Currently, my save-as choices don't allow anything other than a single choice of an XLM file

Is this "choice" in RR? That choice seems to be in the "File" drop down menu, but it's in "Save Profile As . . ."; not for saving logged PID files. Those are automatically csv. RR does ask that the "location" for saved .csv log files be defined -- e.g., Desktop -- and that choice is in the "Settings" drop-down menu.

Go to Settings/Log File Output Location. That will show where RR is currently saving log files. Perhaps they are there!

p.s. doesn't Excel and similar programs use xls or .csv files, and perhaps others, rather than. xml? If it's XLM, then isn't that a macro, which doesn't sound right for a log file. But then, perhaps . . . .

Okay, I'm going in circles here. My fault. The RR "definition" files are xml.

But still, it's strange that your RR seems to want to save the logged files as xml.

 

Thanks for all of the help, I am not GEEK Squad. That is for sure.

Alright, I figured what was going on here. At least I figured how to save logged data. The xlm files were mearly nothing more than the "log profiles" being saved. Under "logger settings" I also had the "control log with defogger button" turned on. So I was actually never recording anything before.

I can get the spreadsheet open...then what? So do I want to log data or log a graph of the parameters.

 

Under "logger settings" I also had the "control log with defogger button" turned on.

That should not be a problem. I have it enabled as well. The idea is simple. In order to get RR to record data, if you use the screen the curser has to be moved and clicked on the "Start File Log" button at the top. The button changes to "Stop File Log, and it then has to be pressed to end the recording session. This can be rather awkward if one is also driving, and can even be a challenge if the computer is being operated by a passenger.

The "control log with defogger button" bypasses the button. Instead, with the computer already connected and reading selected data, the recording function can be turned on, and off, by pressing the Defogger button. RR monitors the "Rear Defogger Switch" position (it's one of the "switches" listed under the "Switches" tab) and simply responds to it.

The Rear Defogger button control option does not prevent use of the "Start File Log" button; RR will still record if the button is used.

I can get the spreadsheet open...then what? So do I want to log data or log a graph of the parameters.

If by "log" you mean "record", then I believe RR will only record "data" even if you have the RR display set up to show "graphs" or "dashboard" (although I must admit I've never tried this, so I might be wrong.)

The Excel-displayed .csv spreadsheet of the recorded data will look something like this, depending on what parameters were selected:

Then (at least within Excel) individual columns, or series of data can be selected and displayed as graphs. (See the "P0420 Diagnosis" thread for lots of examples.) But that might need a mini-course in how to use the spreadsheet program, so let's see if this helps to this point.

And, of course, cardoc, Seabass, or others might want to add/correct -- always welcome.

 

Thanks. I think SeeBass' comment about "openoffice" might have some merit. What I am looking at looks more like code...data but not organized in the spreadsheet with headings and the like. My I will get a hold of exel and try my hand there.

BTW...this Forum is the s*!t. You all are the best. Learning new thing is what keeps us young, and relevant.

 

Take a screen shot of the spreadsheet with the data on it and post it as a pic.

Maybe we'll be able to put some notes on it to help you see what's what.

 

Aren't there on-line sites where files, etc, can be stored, similar to photobucket.com?

I wonder if the RR .csv file(s) could be uploaded to one of those sites, and then a link to it provided in a post here. I don't know about security/identification issues that might be involved, but if there's no risk, this might be an easy way to transfer files from one member to another, perhaps as easy, if not easier, than "zipping" the .csv, or .xls file(s) and attaching to a post.

 

You mean like wxgeek did here: http://www.subaruoutback.org/forums/66-problems-maintenance/89338-0420-again-4.html#post1008793

 

Yes, that's the idea.

However, while exploring this, I realized that Window 7 and 8, and perhaps other systems, can "zip" files, as well as "unzip" them. (I had thought we needed a proprietary zip program, but I guess it's become generic now.)

traildogck:

If you're running Window 8 and have a couple of short test files recorded by Romraider, try this procedure to compress the file into a .zip format:
Compress and uncompress files (zip files)

Then attach the zip folder that's created to a post here. (While .csv and .xls files cannot be attached to posts, .zip files can be sent this way.) We should be able to open the file, and at least verify the data, even limited, that you are getting.