84Elky

Log File Analyzer - Version History
v11 – September 24, 2013
Changes were made to eliminate all samples where Injector BPW = 0. This was done to better report Average BLM and INT values, because during deceleration BLM and INT values are frozen in sample data at the value immediately before BPW = 0:

• Injector Tab
  • Now reporting both Batch Fire and Sequential Fire Duty Cycles
  • Now showing Averages of Battery and Pump voltages as well as Time Between Reference Pulses without regard to BPW=0
  • BPW Min and Max values show zero if all samples detected have BPW=0.
• VE Tables Tab
  • Added section of VE tables for BLM and INT that excludes samples where BPW=0. Not eliminating these samples has the potential of distorting Average BLM and INT values.

v10 - August 17, 2013

• VE Table Fueling Tab
  • Both Upper 3D VE Tables were incorrectly in Lower VE Table format. Can’t remember why. Likely because copy and paste was used to easily create the Upper tables once the lower table was developed.
  • Minor formula errors were corrected in both of the 3D Upper VE tables. Apologies to those using the upper table BLM and INT values for VE Correction. The “Average VE Table Change Factors” in the column to the left of the VE Tables are correct and did not require change.
• VE CORRECTION Tab
  • This new Tab was added to the right of the “VE Table Fueling” Tab to allow copying of data from this new Tab to a VE Correction Spreadsheet. Data cannot be copied from the VE Table Fueling Tab because it is Protected to avoid inadvertent formula changes.

The initial version was posted here (https://www.thirdgen.org/forums/diy-...er-easier.html) in 2010. Since then, many changes have been made to enhance functionality. Now, all files are located in this Thread.

The Log File Analyzer program automatically reads and analyzes all samples of an Excel-formatted Log File (.csv, .xls, .xlsx) and presents the analyzed data in BLM Table and VE Table formats. The user can use the Analyzer’s output to quickly and easily correct VE and Spark tables in appropriate RPM and kPa ranges. Other important data are also provided from the analyzed Log File to aid in tuning.

Would appreciate feedback as to usability, changes needed, etc.

84Elky

Updated Analyzer file that provides 3-D VE and Spark Tables in TunerPro format. Each cell of the tables that was accessed during a logging session shows the average BLM or INT value (VE Tables), or SA-TDC value (SA Tables).

profootbrake2

84Elky thank you for the use of the tool. The formula file worked good for me after I figured it out. The ADX file that I use is worded different from what your file used and the formula didn’t work at first.

84Elky

You're welcome. Glad it's working for you. Yea, the Analyzer was designed to work seamlessly and automatically with TPro $8d log file output. But, as you noted, because other ADX files create log files with different column heading text is why there is a provision to also enter the column letter of the data to be analyzed. That will override the $8d text the Analyzer looks for. Then, once the column letters are entered, the Analyzer can be saved (File>Save as) and the entered information will be available for future uses.

JP86SS

iTrader: (1)

Works great!
Nice tool with a ton of time put into it.

RJMcEachern

Hello, nice job on this. One question, have you tried this with open office calc? I do not have excel and use open office. I get error 504 in all cells, I have specified the path to the csv file and also have specified the tab as Sheet1 to work with. when i calculate it gives the error 504 in all cells.

RJMcEachern

EDIT: Looks to be an error with OpenOffice, not in the sheet, researching if there is a fix.

Here is the error code from OpenOffice:
504
Parameter list error
Function parameter is not valid, for example, text instead of a number, or a domain reference instead of a cell reference.
apparently it does not like the way excel formulas work, so no workie for me

Raynmaker

Great job. With some adaptation this will work for any data log and is so much easier to read than the log itself. Thank you so much.

84Elky

Sorry it's not working with Open Office. Given the error code, my suspicion is that some of the formulas I had to use to read another workbook are in some way incompatible with OOff. See if this Excel reader will work: http://www.microsoft.com/en-us/downl...ils.aspx?id=10

RJMcEachern

yea i tried the excel reader but it would not open a csv file

RJMcEachern

84Elky

Don't want to make this a programming thread, but you might try saving the csv as xls from OOff and then see if the Excel reader will function, or possibly this (https://public.sheet.zoho.com/excelviewer). If neither works, sorry. It just proves that OOff is not 100% compatible with Microsoft's Excel formattiing and there is no solution other than to use Excel -- with which the Analyzer was designed to seamlessly function.

profootbrake2

Question where can i find IAC Commanded in the log file? I was able to get the rest working

84Elky

IAC Commanded Steps are not available in the $8d Data Stream from which the Log file data is obtained. See post #4 here as to why: https://www.thirdgen.org/forums/diy-prom/666367-iac-throttle-follower-logic.html.



Further to the above, analysis of the code to date indicates the $8d AUJP variable L011F=IAC Commanded Steps is only used for:

• Adding/subtracting Fan 1, Fan 2 and Warm Kickdown Steps. Four Steps each can be commanded for Fan 1 and 2 when turned on (pintle is Retracted/Opened to compensate for the additional load), and 10 steps commanded if Warm Kickdown is enabled (pintle is Extended/Closed when coolant temp >= 113*F).
• These steps, when commanded, are also added to L0120=IAC Adjustment Position which in turn is used to calculate other IAC pintle positioning variables.

RBob

iTrader: (1)

It is the 23-rd byte of data in the ALDL stream. No conversion required.

RBob.

profootbrake2

I would like to thank both of yall for the help

Dominic Sorresso

This isn't producing a revised SA table is it?

Ronny

iTrader: (1)

Good observation Dom.

84Elky

Dom --
SA Table presented is NOT a revised table. It is merely reporting the Average SA for a given RPM .vs. kPa cell during a logging session. Comparison of cell values reported by the Log File Analyzer against SA table cells of the calibration will reveal what actually happened versus the calibration settings. While sometimes not meaningful, it does at least show how the code is using the entered calibration values. What I generally find is that the actual, logged values are a couple of degrees lower than that of the calibration. Don't know why because have not analyzed that area of the code. But recognize that the cell values reported cover a range of 10 kPa and 200-400 RPM.

Dominic Sorresso

Elky,

Just wishful thinking on my part. Wishing there was a way that would adjust SA to optimize MAP other than trial and error.

84Elky

Dom –--

Not an elegant solution, but here’s what can be done to check the effect on MAP with SA changes. Do a log and bring it up in the Log Analyzer Program. Print out the ‘Spark TDC & MAP (kPa) Analysis’ tab data. Then increase or decrease SA and relog in the same manner as before (same temps, speeds, etc.). Then compare the new log data table with the old at each SA value. Again, not elegant, but does give changing MAP at changed SA values so can see what changing SA does to MAP. Hope this helps.

Dominic Sorresso

With fuel we have BLMs, but nothing like that for SA.you might need to build something that looks at TPS% v RPM and look for decreasing MAP.

Ronny

iTrader: (1)

It seems the only practical way of mapping an improved SA is on a dyno.

I presume the General spends hours or days on dyno looking for the best of all worlds.

EvelBist

iTrader: (1)

does this apply to all ALDL streams or just the 8D? I am logging a stock '91 ZR1 BFXB bin.

RBob

iTrader: (1)

The ALDL streams vary across the various mask id's. If a '91 uses the same mask ($D0) as a '92, the commanded IAC position is the 40th byte.

RBob.

dave w

Excellent tool!

The BLM Averaging is AWESOME!

Now if I could only figure out how to copy / past the BLM Averages into my VE Fixer spreadsheet.

dave w

84Elky

Quote:

Originally Posted by profootbrake2

Question where can i find IAC Commanded in the log file? I was able to get the rest working

Quote:

Originally Posted by RBob

It is the 23-rd byte of data in the ALDL stream. No conversion required.

I've received some PMs on this matter so would like to clear up what apparently was confusing. Long post, but necessary for complete explanation.

I do not believe the 23-rd byte in the AUJP ALDL data stream is Commanded Steps; it's TPS%. Because some 1227730 ads/adx files are in error, it's easy to see why this is felt to be the case. Hopefully, the following will explain.

Commanded Steps are reported in log files by some of the 1227730 ads/adx files that can be downloaded today (as of 8/13/2013). When the definition is edited, the Commanded Steps item is identified in the list of Values as "IAC commanded direction". The file 1227730_8d.ads on TunerPro.net no longer contains this Value as it has been removed. It is not in S_AUJP 4. However, the file 1227730.zip containing the .ads file includes the Value (here: http://gearhead-efi.com/gearhead-efi...20Definitions/.

Tpro, TCat,etc. only report in a log what's in the code’s Diagnostic Data Stream (DDS). I believe it's 63 bytes of data.The first attachement, DDS.jpg, is the AUJP DDS code entry for TPS% (bear with me as it will make sense in a minute).

Note the number “24.” to the left of the TPS% description. That’s a 1-based number and indicates that TPS% is the 24th (1-based) item listed in the DDS. Next, note how TPS% is defined in the TPro ADX file in the second attachment, TPS%.jpg. You can see this in TPro using Acquisition>Edit>Definition>Values and then select TPS %. Note the numbers in the “Packet Offset” line: 17(hex) and 23(decimal). The “23” is a 0-based number that identifies TPS% as the 23rd 0-based item in the DDS. 23, 0-based is the same as 24, 1-based, which is the DDS identifier in the DDS.jpg attachment. And this is how the log file reports TPS% as one of the its variables. TPro retrieves the 23rd, 0-based item from the DDS and converts it according to the ADX file conversion factor and puts the converted value into the log file.

Now look at the third attachment, Commanded.jpg. Oops, it has the same Packet Offset as TPS%. Not good & wrong!. So regardless of how an ADX file describes a Value, the only thing that matters is the 0-based Packet Offset to identify the variable it is reporting on.


And the reason you see 2 different values in the log file (one value correctly reported in the TPS% column, and what is an incorrect value in the IAC commanded direction column), has to do with the way the variables are converted for presentation by the ADX file. Below are the conversion factors for each Value. They are different and that is why the log file values are different.:

• TPS% = X * 0.392100 + 0.000000
• IAC commanded direction = X

So, for example, if the hex number TPro gets in a given sample is 0x40, the decimal equivalent is 64, and TPS% would be presented in the log file as (64 x 0.3921 = 25.09%). IAC commanded direction on the other hand would be presented at X = 64.

This can be verified in a log file containing IAC commanded direction. Just pick any sample and multiply the IAC commanded direction value by 0.3921 and it will equal the value reported for TPS% in that sample. Only took me 3 months to find this error.

Bottom line, without all this detail, one would look at the log file and think that everything is OK. Further, Commanded Steps is a valid variable in the AUJP code, but that variable is NOT in the DDS and that's why it's not reported in the log file.

Hope this makes sense.

EagleMark

I believe we fixed that along time ago. The updated $8D ADX version $8D-1227730-V1.1.adx shows IAC counts at byte 22 and TPS% is byte 23.

File is here:
http://www.gearhead-efi.com/Fuel-Inj...Information-8D

84Elky

Mark -- Yes, it was fixed in S_AUJP as noted in the post, but for anyone not using a S_AUJP ads/adx fie, and using one that preeeded it such as the one linked to in post #25, they will see the referenced "IAC commanded direction" which is presenting incorrect data.

And yes, Item #22 (23 1-based) is IAC Counts, but that is not IAC Cmmanded Steps. Comanded Steps are a special class of Steps included in IAC Counts tha are only invoked when Fans are requested on or for Warm Kickdown when coolant reaches113*F.

;---------------------------------------------------
.word 0x002B ; 23. CURRENT IAC, N = IAC STEPS
;---------------------------------------------------
.word 0x0095 ; 24. TPS = 0-100% ,N / 2.55
; or , N * 0.39216
;------------------------------------------

JP86SS

iTrader: (1)

Correct that it only indicates 'current step position".
There is no commanded value available in the stock datastream.
you could reference the "Commanded Idle speed" as a clue to what it "should" be doing.
Even so (as I'm currently struggling with...)
The IAC position is only an estimate for how many forward and reverse pulses have been output.
The actual position may or may not be actual.
If the device is moving smoothly, it should be reletive to the position output in the datastream.

I'm just trying out your analyzer on some current tuning. Haven't got the files to link up right but I know its me causing the problem
Jp

84Elky

JP --Just posted "AUJP ($8D) Idle Air Control (IAC) Logic". Maybe that will resolve some issues. Let me know if I can help with the Analyzer

dave w

I want to post a HUGE "Thank You" to 84Elky for the changes in V10 that allow the BLM Averages to be copied / pasted into a VE Fixer spreadsheet.

Log File Analyzer V10 exceeds all $8D tuning tools I've used, including auto tuning tools for $8D!

dave w