I saw a few posts on this topic a day or so ago on the ls1-edit mailing list, and it made me think there might actually be some interest in this.

I have been working on a solution for the quick analysis of scanner trace files. I routinely talk performance/tracing/ls1-edit w/ friends of mine here locally (in KY), and I needed a way to maintain a trace library so we could all pool our traces together and analyze them very quickly.

I tried the excel route, but managing all of the spurious excel files became a problem, especially when each file has the 'logic' for analysis in it.... I had a hard time trying to retro-fit logic changes into previous scans, simply because it was duplicated everywhere.

Excel is an awesome data analysis tool, but I didn't like having to work the data in that format - to me, it was just too clunky for what I was after.

So, in an effort to solve my problem, I have been working on this
software: http://www.whitneyroberts.com/lsxtra...ograminfo.aspx

I'd appreciate everyone taking a look at the page, and offering any comments/suggestions back to me. Thanks! :cheers:

 

Whitney,
when this program is available I would like to buy acopy!!!
I have just started using LS1 edit and this looks like what I need
to figure out how to tune.....

I have been manually going thru spreadsheets looking at MAF calibration
and as you know it is no fun.......

This program looks like just what the Doctor ordered.......

I f you want or need any more beta testers , I would be glad to help

Dick


[Modified by 98GreenC5, 4:24 PM 1/22/2003]

 

Excel is terrible for true data analysis. I import my OBDII Data in SQL Server on my desktop PC (MS Access on my laptop while on the road) and I design custom queries to return what I want. Much, much better than Excel.

At this point in time the .Net framework requires a lot of stuff on the client PC and it does not even run on Win 95. You are talking about a 20 MB distributable (minimum), plus service packs. If you want to run the app on the WWW with ASP then you do not have to use .NET. Make sure that you really want to go this route.


Your app might be good for someone who is unfamiliar with SQL. It does show an average for all trim cells lumped into one average and this is a trend that should be avoided. All trim cells should be looked at individually. You also have to make sure that you handle the "data transition points" in the OBDII data. For example, when you lift the gas in the middle of a scan line. When you do that half the scan line contains data for one load type, the other half of the scan line contains data for a different load type. These "data transition points" will throw off the accuracy of your calculations and ruin your 'averages'. You are also averaging readings from the stock O2 sensors. That info is fairly useless at WOT. The stock O2 sensors do not help the end user much during closed loop since they swing back & forth like a sine wave when at stoich.


[Modified by rbartick, 5:48 PM 1/22/2003]

 

Dick,

Thanks for the kind words! I'm a little bit off from beta testing as of yet. I need to get a few more features nailed, then it'll be ready. Check back to the website from time to time, and I'll be sure to keep everyone up-to-date on the program's release!

Rbartick,

I don't want to get into a software tussle. You brought up good UI point - the screen (I'm assuming you are talking about the main trace analysis screen - you didn't say which one(s)) do look busy. I had a heck of a time getting all the pertinent information that I thought one would want in a 'snapshot' on the screen. The UI is still fluid, so I hope to clean stuff up as I go.

The .net framework redistributable (what you would need to run my software) is a single 21mb download. True, the framework is not supported on Windows95, but let's get real.... Windows95 is now an unsupported OS by Microsoft, and I cannot see anyone using that OS (It's almost 10 years old) on today's computing platforms. Your point is technically valid, but I don't think it's a major detractor from using my software. If anyone has current hardware, Win98 (and its variants) and anything newer than that will run my software w/ aplomb. I've tested my .MSI setup file on Win98 and every OS newer, and it works great.

Given time, I truly think that .NET (and the redistributable) will be as ubiquitous as VB (and its runtime .dll) is today. I really do want to go this route. That's another topic, though.

Your point about data transitions and trim cells is noted. I will try to address that issue. My logic is pretty good, though, I will admit, as I have analyzed quite a few cars w/ the software so far, and changes in the PCM flash w/ LS1-Edit show up in this software, so the analysis the program shows and the changes made via LS1-Edit are jiving together (so far).

The 02 topic has been beat to death on every board. Since it is what we have on the car, I use it. If the user wants to use a WB02, then I might write a routine that will allow for the importing of that data and 'pair' it with a trace. Until then, most everyone I know who can't use a dyno for every trace, and who doesn't have a WB02, uses the stock 02's, as that is all that we have! ;)

I appreciate your comments, but I'm trying to provide something that everyone can use. I think there is a real lack of a standardized way of looking at these traces, and it'd be nice to have a good summary of a trace sitting right in front of you, especially when you can click a mouse, and compare 3 or 4 in a few seconds and see the trends; I doubt that people really want to write their own queries in T-SQL just to analyze their traces. :smash:

----

I'm keeping an e-mail list of interested parties, so if you want to be on a notify list, drop me an e-mail!


[Modified by AllCammedUp, 6:11 PM 1/22/2003]

 

That was one of my main points. That is one crazy distributable. Consider the ramifications of installing a 21mb distributable on your user's PCs. I would not do it. What happens if you replace a boat load of DLLs on someone's PC and then the PC does not work properly anymore? That is also a download that will never happen if someone is still using a dial-up connection. How many retail apps do you see with a huge download like that? None that I've come across.

As far as the tuning goes, using the stock O2s as a WOT guide is a pretty big mistake. Those things are fairly useless at WOT. This is a fact, not an opinion. Also, just recommending a MAF table change to 'fix' an average fuel trim situation is not the proper way to tune.

You asked for opinions, just trying to help.... Good luck.

 

Trust me man, I do appreciate your comments. I've not decided on whether I'll package the runtime w/ the program, or offer a link to the download off the Microsoft site. The framework installs all new .DLL's that shouldn't confilict with any existing .DLL's, so I *hope* that won't be a problem. I'll have to do more testing to make sure, though. Most 'retail' software that is written w/ VB6 distributes the runtime with the software, so I'd say the framework will eventually be the same way.

It is a honkin' download, though! ;)

 

Most good retail apps are not written with VB. You can spot a VB app from a mile away. The LS1Edit editor is VB and it leaves a lot to be desired. Thanks goodness the Ls1Edit programmer is a C app. Autotap for Windows is also VB and it is downright horrible. Autotap for DOS is a much more stable C app.

I develop client-server DB apps at work with VB & Interdev ASP, but I would never do a retail app with it. For example:

http://www.rbartick.com/rbcap

 

Isn't that the truth. I knew LS1-Edit was in VB the instant I opened it up. That's not a bad thing, but it takes some work to get the UI 'clean'.

Maybe I should have clarified what I was referring to by 'retail'. I was referring to any application that could be considered 'finished' and ready for public consumption.

We are going OT pretty bad, though. :banghead: BTW, your video capture app looks really nice.

If anyone else would like to offer some comments/suggestions, I'd be happy to hear them! :flag :yesnod:

 

ttt :thumbs: :cheers:

 

Thanks, blinks! The reporting is coming along nicely, so progress is being made! ;)

 

I saw your post on the ls1-edit list and your software looks good. I modified my autotap DOS parameters to capture the fields that you handle. However what is the difference between 11) Air Flow Rate MAF Sensor in lb/min and 21 Air Flow Rate MAF Sensor in gm/sec. It seems like you only need one and could compute the other? Also what field is misfire indicator? I didn't see that in my autotap select. I used misfire count instead.

Your program sounds great and I look forward to analyzing my autotap logs with it. :cheers:

 

Thank you!

The only difference is how they are measured. I like to have both, as the different values are used at different places in the program. However, with that being said, if one of the values are not present, I use the other to calculate the missing value. It's just easier to have them in the scan database for me to use. The program will work fine either way.


That is fine. I used the 'EASE' terminology for that PID. What you've selected will work great!

I'll add you to my e-mail list and let you know when I'm closer to release!

 

Thanks :thumbs: