Log Parsing tool available

[scott451]

Thanks for the great work, Scott.
Can you describe the checksum byte mentioned earlier in this thread?
Since it appears that open source may not be possible, could you write a brief summary of anything you learned about the format that isn't in Tom's .doc?

How about this.... Use what you've learned from Tom's doc to develop your OSX graphical log parser. Post your free program on this forum and I'll send you my source code as a reference. You can use it to improve your program, you just can't give my source code to anyone else.

As far as the check sum goes. Here's some code to do it. Given that the first three bytes are of a record are in header[3]. The remaining bytes are in buf[]

//calculate checksum
    length = header[2];
    for (i=0, xsum=header[2]; i< length; i++)
	xsum+= (unsigned)buf[i];
    xsum&=0xff;
    if(xsum)
	{
	fprintf(stderr,"Bad record\n");
	continue; // Skip record
	}

 

[S-2000 Roadster]

How about this.... Use what you've learned from Tom's doc to develop your OSX graphical log parser. Post your free program on this forum and I'll send you my source code as a reference. You can use it to improve your program, you just can't give my source code to anyone else.

That works for me. As I mentioned, I won't be giving my source code out, either, so it will be easy for me to keep everything under wraps.

I may eventually help Tom expand his .doc based upon anything I glean from your source, provided that's fine with you. But, admittedly, I'll be working on my graphing app before I work on the .doc

 

[S-2000 Roadster]

Traction Control button in XX03 Input Event

I scanned my logs and learned that the 5-byte payload for the XX03 "Input Event" log entry has 0x04 for TC off and 0x84 for TC on. The remaining 4 bytes seem to carry unrelated information. This pattern is consistent everywhere the DR1S log event shows a change in state of the TC button. Note that the DR1S and XX03 events may appear in the log file in random order, but it should be obvious from the time stamp that they happen simultaneously, only they don't always make it to the log file in the same order.

I can report other findings here unless we should have another thread for parsing discoveries.

 

[btown]

Where can I get the latest version of the log parser? The URL at the top of the thread didn't seem to work for me (http://logparse.servebbs.com:10376/).

Thanks!

 

[tomsax]

Where can I get the latest version of the log parser?

There are several parsers available. Look back to September in this thread to see info on my parser.

Also, look at the thread on graphical parsers if you're not a command line junkie.

 

[scott451]

Where can I get the latest version of the log parser? The URL at the top of the thread didn't seem to work for me (http://logparse.servebbs.com:10376/).

Thanks!

Sorry the web based log parser is permanently off line. I will try and post a downloadable executable this week. It's command line only, but there are versions for PC, MAC, and Linux 2.x

 

[TEG]

Sorry the web based log parser is permanently off line...

Why is that?

 

[scott451]

Why is that?

Because I set up the web site as a way to make my parser available but if I needed to, I could quickly turn it off. Once I released an exe, it's out there...

Attached is the final version of my parser. No time limit.

-Scott

 

[tomsax]

I just posted a new version of my command-line-based parser that adds support for firmware versions earlier than 3.2 (prior to March, 2009), and improves support for the data aggregation that RichKae is collecting for his battery longevity study.

VMS Log Parser for Tesla Roadster

 

[dhrivnak]

Thank you Tom for a prompt reply the log file has been set. It looks like I may have a low brick as #49 has been low for the last 600+ readings.

 

[tennis_trs]

Thank you Tom for a prompt reply the log file has been set. It looks like I may have a low brick as #49 has been low for the last 600+ readings.

Has anyone asked Tesla whether they consider this an indication of a potential issue? They seem to have other methods of determining issues with the pack; I would think that they would use this method also if it is of real value.

 

[richkae]

Thank you Tom for a prompt reply the log file has been set. It looks like I may have a low brick as #49 has been low for the last 600+ readings.

Have you tried some deep cycles and range charges to see if it changes?

 

[tomsax]

A new version of my log parser is now available with support for reading an approximation (± 0.03) of the car's Calculated Amp-hour Capacity (CAC) and a few other minor updates.

CAC is a value that some Tesla service techs have been telling owners is the best measure of the battery pack's capacity. The CAC for a nominal new battery is 160 Ah. It seems to correlate very well with ideal range in both standard and range mode and makes for a simple, unambiguous way to compare different battery packs.

If you'd like to compare your car to others, you can see a bunch of cars with their CAC values on the Plug In America Roadster Survey results page. If you haven't already, please consider adding your vehicle info and CAC to the survey.

 

[dhrivnak]

Has anyone asked Tesla whether they consider this an indication of a potential issue? They seem to have other methods of determining issues with the pack; I would think that they would use this method also if it is of real value.

Yes I have asked two different rangers and I am told the car passes the "bleed test" with no issues. To be fair from what I can tell while the one brick is low it is not much different than the others. While my battery pack is on the low side "176 ideal miles" it does not appear to be abnormally low.

 

[tomsax]

Version 1.1.4

Version 1.1.3 of my parser is now available for Mac OS X and Windows.

• show odometer to tenths in drive/charge summary
• use the odometer for drive segment distance in more cases, less use of integration
• better detection of start/end when a charge and drive segment are very close
• fix formatting error in Ah out for drive segments
• allow larger gaps between valid timestamps (5 days -> 30 days)
• add approximate CAC to output for DAY records

 

[supersnoop]

I've been trying to read errors from the log file with the "-r ERR" command, but it never produces any results. Is there some other way to check if error records are stored in the log?

I'm also curious if there's any way to calculate the CAC for each brick, rather than just the lowest. My lowest brick has dropped significantly in the last few months, and I'm trying to determine if it's a single failing brick, or the whole battery.

 

[tomsax]

I've been trying to read errors from the log file with the "-r ERR" command, but it never produces any results. Is there some other way to check if error records are stored in the log?

The ERR records are in the permanent section, so you have to specify the -p flag as well as -r ERR.

I'm also curious if there's any way to calculate the CAC for each brick, rather than just the lowest. My lowest brick has dropped significantly in the last few months, and I'm trying to determine if it's a single failing brick, or the whole battery.

The DAY records show the CAC, the average brick Ah, the minimum brick Ah, and the brick number of that weakest brick. The DAY records are also in the permanent section, so put -p -r DAY on the command line.

Make sure you are using the latest version, 1.1.3, to get all of the data from the DAY records. You can download the latest version from the VMSParser page.

 

[tvuolo]

Hi, I have some VMSParser and battery questions.

Is there any way to see the ideal miles after a charge using VMSParser? I forgot to note it, and it's too long gone to pull from the OVMS server.

I see this from the log after a range charge with top-off - using VMSParser -c:
08/28/2015 23:26:32 | 1440825992 | IDLE | range soc = 96% ESS 21.07C - 22.35C, 4.137V min, 4.171V max, 81 brick min V, 30 brick max V
08/29/2015 07:46:25 | 1440855985 | IDLE | range soc = 94% ESS 19.27C - 20.85C, 4.132V min, 4.176V max, 81 brick min V, 0 brick max V

Using VMSParser -u:

08/28/2015 19:41:22 - 08/28/2015 23:25:32 (03:44:10) Charge 57% -> 96% 241V 40A of 70A 29.6 kWh 59.1 Ah 0.0 Ah
08/29/2015 07:08:38 - 08/29/2015 07:45:39 (00:37:01) Charge 92% -> 94% 247V 31A of 70A 2.5 kWh 3.3 Ah 0.0 Ah

Why does it say 96% SOC at the end of a range charge? Shouldn't that be 100%? Or does that mean I've lost 4%?

Why does the top-off stop at 94% instead of going to 96% or 100%?

Thanks!

 

[tomsax]

We haven't found the ideal miles number in the logs.

The state-of-charge percent shown corresponds to what you see on the battery graphic in Range mode on the touch screen. For whatever reason, that doesn't show 100% and never has in our Roadster even when it was new. It can show 100% immediately after a charge, but then drops after it's done settling and calculated a more accurate state of charge. The same settling happens after a drive segment.

I wouldn't attach a lot of meaning to the 96%. The CAC is a better measure of your pack's capacity. That gets recorded every day in the long-term section of the log file. To extract those values:

VMSParser -p -r DAY your-log-file.tar

Add -t and redirect to a file to get a tab-delimited version you can load into a spreadsheet or other graphing program.

VMSParser -pt -r DAY your-log-file.tar > output.txt

If you have logging enabled in OVMS, that goes back a long ways, over 600 drive and change segments on our Roadster, and that does record the ideal miles at the start and end of every charge, although it does record the value immediately after charging/driving, not the value after the 10-minute settling period.

 

[tomsax]

VMSParser 1.1.5 is now available with these minor updates:

• note when a charge or drive segment crosses a daylight saving time transition
• add example to show how to extract records from permanent section (-p)
• add CAC to output for battery data summary (-b)