Log Parsing tool available

[tomsax]

Another Parser

I wrote a parser before Scott's was available. I haven't figured out as many data fields as Scott has, and Scott helped me to add or improve a few fields. My thanks to Scott for his huge contribution to the community and our understanding of our cars.

I focused on finding the values that you can read from the touch screen to have an automated way of collecting data that's easier than videotaping the screen. There is lots more data available on the screens that I haven't found in the logs yet, but I've got enough that I've been able to generate interesting graphs of charging, drag racing, etc.

My parser by default shows a summary of all of your drive and charging sessions, and allows you to type in human-readable dates for specifying date ranges for extracting the detailed records. You can have the output be tab-delimited for importing into other programs, or more human readable for manual inspection. There's also support for English vs. metric units. It's based on my 2008 Roadster logs, but I've done some testing on version 2.0 Roadsters.

You can download the latest version from this link: VMS Parser 0.9.7.

The download package includes Mac and Windows builds and a document describing what I've deduced about the log file format.

Send me a private message with your email address if you want to be kept informed on updates.

 

[S-2000 Roadster]

Thanks Tom and Scott.

 

[tomsax]

Yet Another Tesla Log Parser

The word gets out about parsing Tesla log files and a new parser is released as open source.

The above blog got a mention on SlashDot.

 

[scott451]

I wrote a parser before Scott's was available. I haven't figured out as many data fields as Scott has, and Scott helped me to add or improve a few fields.

Yeah, my parser has been in private circulation for quite a while. One of the early signature owners was particularly helpful in correcting some of my initial scaling values for drive and charge records. (this was before I was using the CAN bus to confirm value scaling)

I'm finalizing my next release, which will include a couple of new fields: Elevation, Battery Ahr capacity, Lowest brick Ahr capacity, lowest brick number. More error messge IDs->text messages

I'm planning on making this an open source release probably GNU or BSD...

I'm still trying to track down one last record type. I believe that 2010 roadsters will create a log entry when the GSM subsystem is used. I have been unable to locate a log file with the GSM record. If anyone has received a GSM message on their roadster, please send me a PM. [edit 11-16-2010: it turns out that this is not the case. If the GSM system is turned on, it is connected to telsa HQ and no log entry is made]

For the folks working on their own parsers, it probably a good idea to add support for verifying the checksum byte at the end of each record before parsing a record. Two reasons: 1) 2008 temp log will wrap when it is full, creating a partial record that needs to be discarded. 2) a partial record may be created if the VMS reboots unexpectedly.

-Scott

 

[scott451]

Sorry, I've been spending most of my spare time analyzing CAN bus data, I'll get a new version out in a week or two. I'm trying to release the source too, but I need to get the OK from work.

-Scott

Attached is the next version of my Tesla vms_log parser. It's ready for open source, but I haven't got the OK from work yet so I am just releasing another exe only version. Sorry no mac/linux version this time, but I will get one out soon. Web version is offline pending the release of the source code.

New stuff in this version:
Whr/mile and Elevation in Drive10m. Battery AmpHr capacity in Daily records. More messages...

The daily AmpHr capacity is a good find. With it, you should be able to determine the health of your battery. A new battery starts around 156 and after a short break-in rises to just under 160AmpHrs. After 24K miles my capacity has dropped to about 145 or about 9%

The sharp drop around the 15 month mark was caused by a firmware upgrade to 3.5.17. My guess is that the new FW more accurately estimates the Ahr capacity of the battery. A 9% drop after 24K miles, 18 months and 4 sets of tires, does not seem unreasonable for a LiIon battery. YMMV

-Scott

Std Disclaimer: My conclusions & data could be wrong. I don't work for Tesla nor have any friends that do. I'm just passionate about Tesla's products and understanding how they work. The data is the result of my own analysis of my roadster and discussions with (and log data from) other owners.

 

[TEG]

If Roadster is 375V, and shows as 160AmpHr doesn't that equate to 60kWh, not 53kWh?

For random comparison, the ~26kWh pack in my RangerEV started life as a 95AmpHr ~300V, and now ten years later it is about 85AmpHr. (NiMH seems to do well in the calendar life department.)

 

[scott451]

If Roadster is 375V, and shows as 160AmpHr doesn't that equate to 60kWh, not 53kWh?

For random comparison, the ~26kWh pack in my RangerEV started life as a 95AmpHr ~300V, and now ten years later it is about 85AmpHr. (NiMH seems to do well in the calendar life department.)

Good question. All I can say is that the AHr number in the log correlates well with AHr number on the VDS CAN bus. As far as the number goes, I would have expected 2.2Ahr x 69 cells = 151.8 Ahr Nominal.

 

[ChargeIt!]

Scott: I understand the "cliff" caused by the FW update. But notice the difference before the cliff to the behaviour after it. There's no significant capacity drop prior to the cliff, but essentially all of the 9% drop you are talking about happens after the FW update. What's up with that ?

 

[scott451]

Scott: I understand the "cliff" caused by the FW update. But notice the difference before the cliff to the behavior after it. There's no significant capacity drop prior to the cliff, but essentially all of the 9% drop you are talking about happens after the FW update. What's up with that ?

My guess is that the newer software is more accurate about the actual capacity of the battery. The table below (from battery university) shows the typical aging of a liIon battery.

So at 40% SOC at 25*C you'd lose 4% after a year. My average SOC is closer to 60% and my average temp is 28*C and its been 1.5 yrs. So 9% seems pretty good.

This table also explains why Tesla wants you to always plug in your car... It's not so much to keep it charged, but to keep the battery cool. One thing I have noticed, is now that my battery is older, it seems to heat up quicker. So a spirited drive to the store and back, can warm a cold battery to 33*C. So I'll immediately plug in for a 12A, 30min charge when I get home to cool the battery to 26*C

 

[Alan]

Scott,

Thanks for the parser. Ah is a great find.

Taking some very rough measurements from the graph the capacity since the firmware update seems to be dropping by 6 or 7 per 100 days. At first glance this would suggest that the capacity will drop below 50% of original capacity when its about 4 years old. I guess it depends on whether the decay continues at the current rate which looks fairly linear since the firmware update. Hopefully it will level off a bit. Its impossible to know what the slope would have looked like if you had had the current firmware all the time. As you say a 9% drop over 24K miles / 18 months is not nearly as fast a drop off in capacity as the data after the firmware upgrade.

It would be interesting to see more graphs from other users. My car has only 3000 miles on it but is 280 days old (it was a display car for a few months). I would post a graph, but not much point as the capacity only varies between 157 and 158 over this time. My graph looks a bit like yours before the firmware update but since my firmware was updated a couple of weeks ago I assume I have the latest. (BTW How do you read off the firmware version? I thought you could get it via the touchscreen but can not find it).

Interesting comment about plugging in to cool (rather than just to charge). At the risk of getting off topic, I thought the reason the fans / coolant continue for so long after you stop is to cool the battery pack. Does plugging in do anything different in terms of cooling?

Let me put this another way. If plugging it in does not cool the battery any better / faster then you could argue that in some cases its best not to plug in for small top ups as the average state of charge will be higher than if you left it unplugged. (Obviously this would not make sense if charge levels were low).

Alan

 

[vfx]

...
It would be interesting to see more graphs from other users....

Scott you can put up my graph it it helps here. (23K miles).

 

[scott451]

Taking some very rough measurements from the graph the capacity since the firmware update seems to be dropping by 6 or 7 per 100 days. At first glance this would suggest that the capacity will drop below 50% of original capacity when its about 4 years old.

Possibly... But there may be some settling into the new capacity algorithm. I'm trying to find a log that was an early upgrade to the new firmware so I can get more "after the upgrade" data...

I guess it depends on whether the decay continues at the current rate which looks fairly linear since the firmware update. Hopefully it will level off a bit. Its impossible to know what the slope would have looked like if you had had the current firmware all the time. As you say a 9% drop over 24K miles / 18 months is not nearly as fast a drop off in capacity as the data after the firmware upgrade.

I would guess that it drops quickly in the beginning and then the rate slows

It would be interesting to see more graphs from other users. My car has only 3000 miles on it but is 280 days old (it was a display car for a few months). I would post a graph, but not much point as the capacity only varies between 157 and 158 over this time. My graph looks a bit like yours before the firmware update but since my firmware was updated a couple of weeks ago I assume I have the latest.

Yes. I will post a few more graphs from other owners who've given me the OK. I'll try and find one that got the (2008 3.5) upgrade early so we can estimate the slope.

(BTW How do you read off the firmware version? I thought you could get it via the touchscreen but can not find it).

When you first turn on the car and the "Tesla" shield logo appears, the firmware is in the upper right hand corner in dark grey letters.

Interesting comment about plugging in to cool (rather than just to charge). At the risk of getting off topic, I thought the reason the fans / coolant continue for so long after you stop is to cool the battery pack.

No. I as far as I can tell, the fans cool the motor and the PEM. AFAIK there is not a "battery" fan. The only way to cool the battery is when the AC runs. In my 2008, if the battery temp is at or above 30*C, the pump will run continuously (unless the SOC is low). So I know if the pump is running after 10minutes, I need to charge the battery to cool it. YMMV

Does plugging in do anything different in terms of cooling? Let me put this another way. If plugging it in does not cool the battery any better / faster then you could argue that in some cases its best not to plug in for small top ups as the average state of charge will be higher than if you left it unplugged.

The only way to cool the battery when the car is off is to charge the battery. When the car is first plugged in, the cooling cycle begins. Take a look at graph in the first post of this thread. Notice that the ESS current drops by about 5 Amps. This occurs when the battery is being cooled. Also notice that the cooling continues to cycle at a high rate until the battery coolant temp reaches 15*C. After that, cooling cycles at a slower rate just to take out the heat added when charging.

 

[scott451]

Scott you can put up my graph it it helps here. (23K miles).

 

[dsm363]

Just downloaded my log file and looking forward to using your program. I've got a Mac but have an old PC laying around so I'll try and use that for now. Thanks for working on a Mac version as well.

I was able to download the .tar file you mention in the readme file and I dragged it onto your program. It then seemed like it ran through a bunch of text on a window that popped up for about 3 minutes. Where does the converted .csv file go? I looked for it in the folder the program was in and the desktop but don't see it. Thanks.

 

[tennis_trs]

...

I was able to download the .tar file you mention in the readme file and I dragged it onto your program. It then seemed like it ran through a bunch of text on a window that popped up for about 3 minutes. Where does the converted .csv file go? I looked for it in the folder the program was in and the desktop but don't see it. Thanks.

If it's his parser version I downloaded, I believe it's meant to be run on a Windows Command Prompt window (the included Readme*.txt file says it's a command line version) and when it runs the output just goes to the window so I got a csv file by redirecting the window output to a file:

log_parse.exe [various options] mylogfile.tar > output_csv_filename.csv

 

[dsm363]

Thanks. I don't think I would have ever figured that out. I've had a Mac forever but was able to get the CSV file created and over to my Mac to open up in Excel.

There are a ton of fields. How do you sort through them and what useful stuff do you look for?

on a related not, I'm trying Tom's program VMSParser since I have a Mac. What do I type in terminal to get the program to run?
I've typed VMSParser 2011xxxxxx.tar and get -bash: VMSParser: command not found

 

[dsm363]

Anyone know exactly what to type in the terminal program to get VMSParser to work on a Mac? Thanks.

 

[tomsax]

Anyone know exactly what to type in the terminal program to get VMSParser to work on a Mac? Thanks.

Both Scott's log_parser and my VMSParser are command line apps. Giving a full introduction to the command line and how to do things efficiently is probably not appropriate on this forum (entire books are available on the subject), but here's a quick intro for Mac users... (Most applies equally well to the Mac versions of both parsers, although the command line options are completely different.)

First, you have to enter the path to where the program is. The easiest way to do that is to open a fresh Terminal window and drag VMSParser into the window. This will insert the full path to the file into the window. If you hit return after doing that, it will run the program with no options which will dump the help text into the window with the list of all the command options and some sample command lines.

If you then hit the up arrow, it will put the previous command back on the command line. Make sure there's a space after the path to VMSParser, which should happen automatically. To get the summary of what's in your log file, next drag the log file into the window. You should now have <path to VMSParser><space><path to your log file>. Hit return.

Hit the up arrow to get that command line back, and append "> filename.txt" (without the quotes) to have the output dumped to a file.

You can get more detail and different information by inserting command-line options between the VMSParser path and the log file path. See the help text for more info. Direct message me if you have more specific questions.

 

[dsm363]

Thanks Tom! That worked perfectly. I looked online for a brief command line intro but your post was much better than anything I found. I appreciate it.

Have you thought about adding the text of your post above your help file included with the program? It does a great job of explaining the basics.

 

[S-2000 Roadster]

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?