the difference would be that I don't stop the car, I reach over, start the logger, log a pull, stop the logger, start it again to make a new file, log another pull etc...

that's why one button logging is nice and a more visible indicator would make it easier to confirm that it's started/stopped.

 

But why? Is your hard disk so small? Why not logging the whole time? Later, you can cut the WOT runs to a new file to get it compressed. The long file can be archived. If you have later on problems with the car, you can check the actual values with the archived ones. Even in none WOT areas the logs can then help.

 

I don't like spending time sifting through a sea of data and trying to guess which pull was a 3rd gear run etc... That's just how I've always done it

 

We have some of those nice PP remotes at work... I'll give it a try. I'll also check new egg for a cheap solution and test it out!

 

any update with innovative wideband? thanks MJ.

 

i think alot of people do it that way... i know i'm guilty as charged.

 

thanks for speaking up, I thought I was the only weirdo for a minute there

 

Its not weird or anything unusual.. Its just that with a program like Data Log Lab, it takes seconds to visually find a WOT pull in a large log. I don't find it inconvenient or troublesome at all. And people forget tuning is more than just WOT pulls, so logging data under varying conditions will allow you to resolve other issues and tune for better drivability.

I'll take the indicator into consideration, the one-button thing already works if the app is in the foreground. (hit enter it starts, hit enter again it stops) I'll just make the button change color or something when its running so its clearly visible.

My average logs are 60 minutes in duration, and about 2-3mb in size, they consist of my drive to work, several third gear pulls in several different locations on my way, plus plenty of stop and go, cruise, and idle logging. The data I gather is invaluable for creating a tune that is both drivabile, consistent, safe, and makes power.

I'm not going to debate what you guys are looking for in an app.. I just know from experience what works for me, and am open to any suggestions you guys feel are useful. If an indicator is useful, then its something worth considering, It takes less time to add the code to do this, than it does to debate this!

 

I'm trying to support the Entire Innovate MTS protocol so you can use all of their compatible products. In doing that, it means I have to implement all of the functionality of the protocol. The bad news is that takes longer to do. The good news is it means that the data will always be consistent and you will be able to log from any Innovate data aquisition device that is compatible with that MTS chain.

But, unfortunately it won't make it into 1.6 beta 1, I have pretty much finalized what I intended to work on, and am now just fixing up the things that need doing. I was hoping that It would, but its taking longer than expected. The AEM support was something I was able to add easily due to how simple its data stream is. And I can do that for any wideband that supports a simple output like the AEM. In fact, if you have a device that runs at 9600 baud, outputs a stream of single line items for AFR (14.7 on each line) then the odds are pretty good that the AEM logger will work with it. If you know of other loggers that work like this, but use different baud rates.. Then PLEASE let me know, as adding the ability to change the baud rate is easy.

 

Just a quick update, Added the ability to detect and select different FTDI Devices, while still automatically selecting the first Openport device. This means you can use any device, and also if you have an FTDI based serial port for logging other data it will coexist properly. If you have an Evoscan cable and an FTDI serial port, you would still have to manually select the right cable (unless someone can send me the description string for the evoscan cable)



Finally, I am attempting to get the Innovate MTS device chain implemented for the 1.6 release. I can't guarantee It'll make it in, but I'm doing my best to get it in.

My final major hurdle for today is getting the mini-dashboard to display only important items and be easily large enough to read and be a clear indication that the logger is running.

I am also looking into allowing the window to be resized, but I don't see that being completely necessary.