the XXX is when one of the values in the variable is invalid.. Its intentional..

I think the program is trying to read the ECU faster than the ECU is sending data so every so often its dropping.. your right about a missing item shifting a row.. I never took that into account.. I think I'll use the previous value in the appropriate request if the new value is invalid..

If you notice there are quite a few items that don't update very frequently anyway.. I may have to slow the sample rate down.. Its trying to sample about 15-20 items every 1/10th of a second.. I think it needs to be alittle slower. But I do notice that the data doesnt change as frequently as its sampled as it is.. 2-3 samples in a row can be the same.. so obviously the ability to read the data is pretty fast, but the ECU isn't updating it as frequently..

 

BTW what speed is your laptop.. the one I've been testing with is a 1.2ghz Pentium M.. never had it drop data..

 

Yeah, it seems like a lot of values are just silly to bother logging fast (like coolant temp or barometer, for example).


It's a 1.5GHz Pentium M (IBM Thinkpad T40).

 

Okay.. the Data Log Lab issue is NOT the definition file.. the import will quit working when it parses a rediculously high value.. (20000, 80000, 90000) Its actually probably some sort of overflow error in Data Log Lab due to an abhorrant value... once I get the load calculation fixed and it doesnt drop data, that issue will go away.

 

Yeah it looks like RPM and MAF frequency are the only ones that update fast.. the rest don't seem to update as often..

It looks like I'll reduce the logging speed to 5 lines per second.. each line has about 20 samples which means its about 100 samples per second is the fastest rate it can reasonably do.. I don't think its the speed of the laptop.. I just think cramming anything in there faster will just cause requests to never reply..

I'll try to fix it up tonight or tomorrow..

In the mean time, uncheck 5 or 6 of the less important requestID's and see if the dropped items goes away..

 

Okay, I took two more logs. See attached. The first file is same as before (logging all channels). The same problem is shown again (missing values causing the columns to shift left).

For the second file, I unchecked six channels. No dice. There are still many missing data values.. perhaps more overall. This file is also the first time I've seen two values missing in a single sample row.

I still say this is a heckuva big accomplishment for your first sample release, Jack.

I have to go to bed. Let me know if there's anything else specific you'd like me to check tomorrow.

 

I just did one log cruising the neighborhood. I had the same problem with the data shifting to the left. My computer is using the Centrino Duo 1.66GHz with 1G RAM. I think the laptop is fast enough. I posted my log on www.aktivematrix.com.

Thanks for this awesome logger MJ.

 

Thanks guys..

I was looking at my source code, for each "Tick" which is every 100ms, (to make it 10 lines per second) It loops through all the items.. I completely overlooked to put a small wait between the requestID and response data.. Its not needed for the calculations, but a few MS is needed on some requests to get a response (timing is everything.. )

I am going to make these two items (sample spacing and line rate) configurable and let you guys have at it until you find a rate that works well for your car..

I have to take a day or two off on the program, but I should have another beta posted Sunday or Monday night. (as you know I generally release files on the date I say)

The Data Log Lab problem has nothing to do with either DLL, or its definition problem.. Actually it does, but its not the programs fault... It doesnt like values that are unexpectedly high.. I'm not sure at what point that it dies, and I never noticed it before, but it seems to happen with values over 16000 (How do I know this? because the only other time I had this problem was with a Evoscan log that had more than 16000 samples) It wasnt the quantity of the samples, just the number for something was out of range..

The reason my logger would cause it to choke in DLL was due to the dropped entries would place really high numbers in the InjPulseWidth column, and the mathematic results in either the load or gear calc would be extremely off (80000 was one result I saw.. LOL) (btw you guys can disable logger values perminently in the XML, I recommend doing it for the gear calc until I publish a formula that is actually right, the formula in there was just a quick test and I forgot to remove it)

If you notice, the first item logged is always correct.. The second is usually correct.. Then it goes down hill, thats what made me realize I needed to place a small wait between each request.. I completely overlooked that but you do have to give the MUT protocol time to respond.. In some cases you were getting queued up values from a previous call, hence the weird values...

Watch for Beta 3... Most of this stuff will be fixed..

 

Are you guys happy with the simple UI though?

My biggest problem with all the other programs is either their complex, or require too much user interaction to quickly start and stop the logger..

I'll also set threshold settings so it will be in standby. When in standby it will log RPM, TPS, speed, and one or two other items to the screen only until you hit a threshold when it will automatically start logging and stop logging.. I'll try to get that into Beta 3..

 

BTW If you guys want to create your own tools, create them as a COM Object with an interface exposed.. If its a DLL or EXE, the app can launch it as a process in a seperate thread, the exposed interface should really just be a simple collection or array of the "immediate sample" available, and each element should be each of the available pieces of data..

For instance, the component I wrote for the TurbXS tuner responds with an array of 3 items, the first is AFR, Second is Boost, Third is EGT (thats all I have configured) I then have an embedded script that retrieves only the data I want, and appends it into the log using the XML definition.. the XML def basically calls the exposed objects variable..

I'll document this better so you guys can create your own addons and contribute them to the community.

 

The UI is very simple and nice. One feature I really like in EvoScan though is how they now have the yellow (logging initializing) and red (logging active) status colors. It makes it much easier to know you're truly logging while driving w/out having to read the screen.

Threshold logging would be GREAT. I'd love to have the logger start automatically at 3000rpm so I don't have to click the button while driving, etc.

Post #25 went so far over my head I won't even bother trying to figure it out.

 

I can do the init and logging indicators.. Honestly the app seems to initialize so quickly now that it doesn't seem necessary...

 

I'm just trying to figure out if this IS or WILL BE better than Evoscan.

 

Its not intended to be better than anything.. Just a tool tailored to the way I prefer to work.

 

I'll definitely try it out tomorrow or in the next few days. Thanks Jack.