Tesla Graphical Log Parser [Archive] - Tesla Motors Club

Doug_G

01-29-2011, 11:48 AM

Now available from http://www.teslaflux.com/

--

I am nearly finished writing my new Tesla Graphical Log Parser, or TeslaGLoP for short. This tool makes it much easier to review your logs. It has a graphical user interface instead of command line. It can display graphs for speed, SOC, voltage, current, torque, etc. It can also print the graphs, and export segments of interest to a CSV file.

Huge thanks go out to Tom Saxton for his excellent document on the log format. Saved me a lot of time.

I will be releasing the executable as freeware. It runs on Windows XP/Vista/7. A beta test version will be available shortly. Right now I'm finishing it up and doing some development testing.

Before I release the beta, I would appreciate getting a few more logs to test with. I've got a couple from #919, but I'd like to test logs from at least several different cars, plus earlier (1.0/1.5) Roadsters, and hopefully some with many more miles on them (I'm only at 6,000 km). Maybe also a 2.5 just in case there's some undocumented differences.

Doug_G

01-29-2011, 12:04 PM

http://www.teslaflux.com/Tesla.jpg

Here's a short trip in the Roadster. You'll note that the application is resizable, so you can make the graph bigger. It has navigation functions for moving forwards and back through the log (will probably add a search feature at some point). You can specify up to four lines to display simultaneously, and can choose imperial or metric display units. It also shows the peak speed over the time shown and the starting and ending odometer reading.

cinergi

01-29-2011, 01:48 PM

Links to my log files PM'ed.

strider

01-29-2011, 06:24 PM

Doug_G

01-29-2011, 06:36 PM

Looks like Cinergi has your 2.5 covered but your welcome to mine as well. I've never pulled them - do I just jack the Tesla thumb drive into the usb port near the 12V plug and wait?

Would be most appreciated! That's right, it's as simple as that.

Does the car need to be on?

Nope!

Doug_G

01-29-2011, 06:37 PM

Links to my log files PM'ed.

Got 'em. Thanks!

cinergi

01-29-2011, 07:43 PM

Looks like Cinergi has your 2.5 covered but your welcome to mine as well. I've never pulled them - do I just jack the Tesla thumb drive into the usb port near the 12V plug and wait? Does the car need to be on?

Takes about 15 minutes. When the message on the VDS about leaving the USB stick plugged in is gone, you're good to go.

suxxer

01-30-2011, 12:44 AM

Looks like Cinergi has your 2.5 covered but your welcome to mine as well. I've never pulled them - do I just jack the Tesla thumb drive into the usb port near the 12V plug and wait? Does the car need to be on?

To get the logs use a USB stick and add a folder named “VehicleLogs” to the root, plug it in, turn the key on and off and watch the screen tell you it is downloading the logs.

dsm363

01-30-2011, 05:53 AM

The USB keyfob that comes with your Roadster already has that folder 'VehicleLogs' on it too.

Doug_G

01-30-2011, 09:46 AM

Still looking for a 1.5 log... anyone?

TEG

01-30-2011, 05:42 PM

To get the logs use a USB stick and add a folder named “VehicleLogs” to the root, plug it in, turn the key on and off and watch the screen tell you it is downloading the logs.

Does it work for both FAT32 & NTFS formatted flash drives?

Doug_G

01-30-2011, 07:24 PM

Okay, here is the download link for the beta release.

http://www.teslaflux.com/SetupTeslaGLoP.exe

I'm sure there will be a glitch or two... please let me know!

Also I have yet to get a 1.5 log for testing purposes. There's a difference in one of the records, and I've not been able to test that.

scott451

01-30-2011, 08:47 PM

Does it work for both FAT32 & NTFS formatted flash drives?
NTFS is not supported. 2GB FAT drives work best. But I have also had success with 4GB FAT32.

dsm363

01-31-2011, 10:09 AM

Thanks Doug. Works great. How do you graph the watts/mile average people talk about during their drives?

Doug_G

01-31-2011, 10:45 AM

Thanks Doug. Works great. How do you graph the watts/mile average people talk about during their drives?

Hmmm... I'm not sure how well an instantaneous value plot would work, given that various pieces of information are logged at different times. I'll do some experiments.

Certainly it should be possible to calculate a single average number for the current plot. I was also thinking that it might be handy to show the total distance travelled (the odometer at start and end is shown, but not the difference).

I'll tinker with it tonight if I have time.

cinergi

01-31-2011, 10:49 AM

scott451

01-31-2011, 12:02 PM

Hmmm... I'm not sure how well an instantaneous value plot would work, given that various pieces of information are logged at different times. I'll do some experiments.

Certainly it should be possible to calculate a single average number for the current plot. I was also thinking that it might be handy to show the total distance traveled (the odometer at start and end is shown, but not the difference).

I'll tinker with it tonight if I have time.
The way I do it in excel, is to plot the ESS_V * ESS_I and then plot a trend line through the data. Tomsax has shown that you can use the [integral] of the speed to get a reasonable estimate of the distance. (the odometer log records only come every 10minutes)

Speaking of features, how about a page for battery health: (using data from the perm_daily records)

Histogram of average state of charge (SOC)
Histogram of Max brick temp
Histogram of average brick temp
Histogram of daily miles driven
Plot of capacity (Ahr) vs days

The daily record is stored in the perm section of the log once a day. It usually has all the data back to the birth of the car. In my case 21 months and 27K miles. Whereas the temp section where the drive and charge records are stored, is only big enough for a few months.

Send me a PM with your email and I can send you the parsing of the daily record.

dsm363

01-31-2011, 12:11 PM

Thanks for working on a graphical version of the already great programs people here have put together. Hopefully someone works on a Mac version at some point but I have an old PC laying around that I can turn on when I need it so this works perfectly.

doug

01-31-2011, 12:46 PM

Tomsax has shown that you can use the derivative of the speed to get a reasonable estimate of the distance.
I assume you meant the integral (wrt time).

Doug_G

01-31-2011, 01:39 PM

The way I do it in excel, is to plot the ESS_V * ESS_I and then plot a trend line through the data. Tomsax has shown that you can use the derivative of the speed to get a reasonable estimate of the distance. (the odometer log records only come every 10minutes)

I was thinking I might be able to kludge up something like that. That's why I said I would "tinker". Since you already know it works, I'll skip the experiments and just code it up. Thanks. (And the other doug is right... you obviously meant integral.)

Speaking of features, how about a page for battery health: (using data from the perm_daily records)

Okay, sounds like fun.

Send me a PM with your email and I can send you the parsing of the daily record.

Will do.

scott451

01-31-2011, 02:17 PM

I assume you meant the integral (wrt time).
Doh. Yes the integral. Thanks for catching it.

Doug_G

02-01-2011, 09:45 AM

http://www.teslaflux.com/Tesla.jpg

I just uploaded an update. This version includes an estimated Wh/mile (or km) display.

Download from http://www.TeslaFlux.com/SetupTeslaGLoP.exe

dsm363

02-01-2011, 10:20 AM

Doug_G

02-01-2011, 12:16 PM

Thanks Doug! Works great.
Is there a way to set a starting trip and keep it saved (maybe set last trip as well)? It defaults to 1989 or something then there around about 20 trips or so done while it was in production to scroll through.
Looks like I'm getting close to the 300 Wh/mile everyone talks about.

Glad to hear it's working for you. It's been a fun project.

Currently it doesn't save/restore any settings. I will probably get around to that eventually, but at the moment I'm more interested in making sure everything works, and perhaps adding some new display features. Also I'd like to integrate a TAR archive decoder, which will make it even easier to use.

After parsing the log it automatically scans forward until it finds the first trip. At some point I'll add a "Settings" button or something for you to select some extra options. Tailoring the startup behavior is on my to-do list (e.g. an option to skip the production log entries).

In the meantime, you can dial in N days, where N is enough to skip the early stuff, and click Forward. Then Next Drive will take you to the first "real" driving record. Or just click Next Drive enough times to skip through it.

Fuzzylogic

02-01-2011, 02:46 PM

Doug_G

02-01-2011, 03:14 PM

Can't get it to work. The program displays an error message ("The parameter is incorrect") as soon as i try to load the log file.

My VIN is displayed correctly, but that's it.
I tried two log files, created a new one today, tried two PC's but the error remains.

Doug, did you get my log file to work on your PC?

Yes, it did. Be sure to extract the vms_log file from the .tar archive first. Then load the vms_log file into the log parser.

I just tried loading a .tar file directly, and it actually worked to some degree. That just means the file didn't compress much; by rights the data should be gibberish.

bolosky

02-01-2011, 03:58 PM

Tomsax has shown that you can use the derivative of the speed to get a reasonable estimate of the distance.

As doug pointed out, you'd want to use the integral to find distance. The derivative measures fun.

(OK, it's not every day I get to make a calculus joke, so I've got to go for it when I can.)

scott451

02-01-2011, 05:38 PM

...The derivative measures fun.
:biggrin: :biggrin: :biggrin:

scott451

02-01-2011, 07:27 PM

[IMG]
I just uploaded an update. This version includes an estimated Wh/mile (or km) display.

Doug, for MY2010 you don't need to to estimate the wh/mile. It's in the drive10m record. if the length_byte >=22 then buf[3+19] is the first byte of a four byte long that is the whpm. Divide this value by 4.0 to get the actual Whr/Mile. I'm pretty sure it was in the last version of my log parser (http://www.teslamotorsclub.com/showthread.php/4032-Log-Parsing-tool-available?p=52602&viewfull=1#post52602)

I've sent you a PM with info on how to parse the data for the Daily records for battery capacity, temp, & soc. With this you should be able to plot the Ah Capacity of the battery vs time back to the birth of the car! Separate histogram plots of the SoC and temp will show how well the battery was cared for :)

Doug_G

02-02-2011, 07:44 AM

Doug, for MY2010 you don't need to to estimate the wh/mile. It's in the drive10m record. if the length_byte >=22 then buf[3+19] is the first byte of a four byte long that is the whpm. Divide this value by 4.0 to get the actual Whr/Mile. I'm pretty sure it was in the last version of my log parser (http://www.teslamotorsclub.com/showthread.php/4032-Log-Parsing-tool-available?p=52602&viewfull=1#post52602)

Okay, I went by Tom Saxton's document... I guess some other things have been discovered since. I'll add that in, and fall back to the current method if the information isn't available. Thanks.

I've sent you a PM with info on how to parse the data for the Daily records for battery capacity, temp, & soc. With this you should be able to plot the Ah Capacity of the battery vs time back to the birth of the car! Separate histogram plots of the SoC and temp will show how well the battery was cared for :)

Thanks for the PM. Lots of stuff to play with!

mpt

02-02-2011, 10:53 AM

Really interesting tool. One thing that sprang out, something that was niggling in the back of my mind... Hey TM, have fun on the 'Pre-delivery check'? :-)

Doug_G

02-02-2011, 11:09 AM

Really interesting tool. One thing that sprang out, something that was niggling in the back of my mind... Hey TM, have fun on the 'Pre-delivery check'? :-)

LOL. Of course it might be done on a dynamometer...

mpt

02-02-2011, 11:10 AM

LOL. Of course it might be done on a dynamometer...

...And then we all woke up and had our breakfast :-)

scott451

02-02-2011, 01:51 PM

Okay, I went by Tom Saxton's document... I guess some other things have been discovered since. I'll add that in, and fall back to the current method if the information isn't available.
Actually whr/mile was in the log_parse_v15 release. While your at it, you might want to add elevation too. IIRC It's a INT16 that starts at the 8th byte after the length field.

Doug_G

02-02-2011, 05:24 PM

Actually whr/mile was in the log_parse_v15 release. While your at it, you might want to add elevation too. IIRC It's a INT16 that starts at the 8th byte after the length field.

Sounds like it's time to update Tom's document. (hint... maybe you could mark it up and pass it back to him for agreement...?)

tomsax

02-03-2011, 05:15 PM

Awesome work, Doug! If you're still looking for a log from a 1.5, PM me.

Sounds like it's time to update Tom's document. (hint... maybe you could mark it up and pass it back to him for agreement...?)

My document was never intended to be comprehensive. I just wanted to document what I knew, mostly stuff I figured out plus a few fields Scott helped me with. Scott was ahead of me from the beginning and has learned a lot more since I wrote that document. I'm hoping Scott will eventually be able to release the source code for his parser which will serve as documentation for what he's learned through heroic effort.

Doug_G

02-03-2011, 07:00 PM

Awesome work, Doug! If you're still looking for a log from a 1.5, PM me.

Thanks! I've been wanting to build this thing for a while now. Surprisingly it only took a few days work. I had done something similar-looking (but for an utterly different purpose) a couple of years ago, so I already had a significant code base to build it on.

If you're willing to share your log, I'd still like a few more to add to my very modest test suite (6 logs from 4 Roadsters).

My document was never intended to be comprehensive. I just wanted to document what I knew, mostly stuff I figured out plus a few fields Scott helped me with. Scott was ahead of me from the beginning and has learned a lot more since I wrote that document. I'm hoping Scott will eventually be able to release the source code for his parser which will serve as documentation for what he's learned through heroic effort.

It definitely had most of the information I needed, and it was very well written. Thanks for that - saved me a load of time. You'll find that you have a credit in the "About" box of the application; click on the icon in the top left corner to find it.

Scott did send me a couple of tips, which I will probably integrate into the program on the weekend, assuming I have time.

scott451

02-08-2011, 12:22 PM

Awesome work, Doug! If you're still looking for a log from a 1.5, PM me.

My document was never intended to be comprehensive. I just wanted to document what I knew, mostly stuff I figured out plus a few fields Scott helped me with. Scott was ahead of me from the beginning and has learned a lot more since I wrote that document. I'm hoping Scott will eventually be able to release the source code for his parser which will serve as documentation for what he's learned through heroic effort.

The open source battle at work isn't worth fighting for this one (I'll save it for the tattler, if I go that route). You guys are making great progress on much more user friendly log parsers than mine... So I'll do a private release of source to you and doug. It's readable hack code, but it never got the cleaned up for the open source release... I haven't run lint in a while either.... and only runs on little endin machines (intel-mac, pc, intel-linux). I'm not sure if the latest version is (OSX 64 bit) clean (they define int as 64 bit, grr).

Doug_G

02-09-2011, 10:22 PM

I just uploaded a new version of the parser. Just a minor update; I've added a checksum algorithm to reject corrupted log entries.

http://www.teslaflux.com/SetupTeslaGLoP.exe

Doug_G

02-13-2011, 06:22 PM

I've just added the ability to plot the calculated ESS A-hr capacity over time. A brand-new battery has about 159 or 160 A-hr capacity. It actually starts up reading a little low and goes up to that value. Then sometime later it starts to slowly diminish. It's interesting to compare logs from older vehicles.

I also added some extra error checking, to get rid of records with wacky timestamps.

http://www.teslaflux.com/SetupTeslaGLoP.exe

Tip: Set Line 1 to "ESS A-hr". Set Display Scan to, say, 1000 days (or however long you've owned the car). And hit the Back button to make sure you're seeing the very beginning of the log.

Also a very special thanks to scot451 for figuring out how to parse that information!

Doug_G

02-13-2011, 07:35 PM

I seem to recall a discussion about a firmware update changing the A-hr capacity aka range estimation. A couple of logs I've collected seem to confirm that, with stepwise drops in calculated capacity around mid-summer to mid-fall of 2010, followed by a gradual increase afterwards.

The highest mileage log I have is over 58,000 km. He's down to about 83% estimated capacity. That would be about EPA 200 miles.

I'm still adding features... more to come!

Alan

02-13-2011, 09:43 PM

My car is a year old / 6000 miles and the A-hr is still going up a bit but has been a pretty flat line (started at 157, now 160).

Doug_G

02-13-2011, 11:25 PM

Well I got carried away and added another feature. You no longer have to extract the vms_log file from the .tar file. You can just directly read the .tar file.

Download from:

http://www.teslaflux.com/SetupTeslaGLoP.exe

And don't forget to try the new A-hr plot feature.

Doug_G

02-15-2011, 11:08 AM

Some people reported that the parser wouldn't work on certain European-localized versions of Windows. "fox" was kind enough to set up a vmware server for me to log into and debug.

It turned out to be an absolutely horrendous bug in the localized version of Windows. One of the API calls failed to work as documented, and instead of reporting the error back normally, an exception handler popped an incredibly vague message to the user and then stopped executing my code! Never seen anything like it.

Anyway, the workaround was simple and I've posted a new version:

http://www.TeslaFlux.com/SetupTeslaGLoP.exe

Fuzzylogic

02-15-2011, 05:57 PM

Great stuff!

Works fine now. Thanks!
(small bug, the year is not displayed as 11 but as 41)

Doug_G

02-15-2011, 06:40 PM

Great stuff!
Works fine now. Thanks!
(small bug, the year is not displayed as 11 but as 41)

DOH!

I'll fix that when I have a moment.

Doug_G

02-15-2011, 07:48 PM

Okay, I've just posted an update with a better workaround that doesn't cause the date to come out wrong.

http://www.teslaflux.com/SetupTeslaGLoP.exe

scott451

03-15-2011, 05:09 PM

Doug,
When you get a chance, would you please add the following plots to your graphical parser:

The data is from items in the Daily record of the vms_log file. (other records, e.g drive10m SOC, are not used)

Daily Ahr capacity vs miles
Daily Ahr capacity vs date

histogram of Daily SOC, bounded by start/stop date interval.
histogram of Daily SOC at a set temperature or range of temps. E.g histogram of SOC for all temps >= 30C
histogram of daily brick max temp

daily brick max temp brick number vs time
daily lowest brick Ahr capacity brick number vs time

These last two plots should appear semi-random. If one brick starts to dominate, it is the weaker brick...

The above plots will allow us to better understand the health of our batteries. Since all of these plots are taken from data in the "daily" record, each vms_log has the entire history starting from the birth of the car and ending on the date of the log dump.

-Scott

Doug_G

03-15-2011, 05:49 PM

I should be able to spend some time on it over the next week or so.

Doug,

daily brick max temp brick number vs time
daily lowest brick Ahr capacity brick number vs time

I can probably use symbols for the points instead of drawing lines; it will look a lot less cluttered.

Might these last two be more informative as histograms? Or are you looking to see a progression?

scott451

03-15-2011, 06:55 PM

Might these last two be more informative as histograms? Or are you looking to see a progression?

Sure, but it's not more informative, it's less because what happend in the last month is more important than what happend in the first month. You need to plot it vs time because you need to see the "consecutive" days where the brick in question was hottest or had the lowest capacity.

Example: brick number of the lowest capacity brick
1,2,3,1,4,5,1,2,6,1 ; brick number one is a low performer.
2,3,4,5,2,6,1,1,1,1 ; brick number one will probably fail.

Both of the above data sets have the same histogram plot. We're interested in the consecutive days, not just the number of occurrences.

Doug_G

06-11-2011, 06:39 PM

P.S. For those of us who are 'new' here, what is this "Tesla Graphical Log Parser" application, and where can I get the source code?

The Tesla Graphical Log Parser reads the files that you can download from your Roadster using a memory stick. It displays the information graphically, and can export data to a spreadsheet.

I wrote the application, based on reverse engineering work by Tom Saxton and scott451. It's fully functional but I have a bunch of additional features on my to-do list, which hopefully I will find time to add in the next few weeks.

I have no plans to release the source code; however, the Windows executable is available for free from:

http://www.teslaflux.com

S-2000 Roadster

06-12-2011, 02:43 AM

I have no plans to release the source code; however, the Windows executable is available for free
Well, I can't argue with your choice because I've never released source code, either. But considering that I don't own any peecees, I'm going to have to write an OSX version of this. I guess I'll have to go back to Tom and Scott for the information.

Thanks anyway.

AndrewBissell

06-12-2011, 03:26 AM

An OSX version would be very welcome. A private source code exchange perhaps? Go on Doug_G help S-2000 along!

markwj

06-12-2011, 05:58 AM

Well, I can't argue with your choice because I've never released source code, either. But considering that I don't own any peecees, I'm going to have to write an OSX version of this. I guess I'll have to go back to Tom and Scott for the information.

Thanks anyway.

I'm in the same boat. Only macs around, and a pain to dig up a PC (and wait for it to windows update).

Perhaps we could collaborate. I've also been toying with the idea of an iOS version (but wondering how to get an iPhone in disk mode with /VehicleLogs without jailbreak).

richkae

06-12-2011, 09:15 AM

Is temperature data recorded for the PEM and motor?
I would love to be able to chart temperatures.

SByer

06-12-2011, 10:50 AM

Might I make a suggestion that someone get an open source version of a parser up somewhere, preferably on GitHub (collaboration there works better than I've seen on other sites)? I'd contribute if i were. it would be great to keep the parser / data structure separate from the presentation, so that multiple front ends could be added quickly. I was thinking a web frontend so I could get the logs graphed on any device would be pretty slick.

Doug_G

06-12-2011, 12:59 PM

I'll look into whether I can share some part of the parser code. I can't share the whole application because there is some proprietary code in there.

Doug_G

06-12-2011, 01:00 PM

Maybe the admins should move the parser stuff to Tesla Graphical Log Parser (http://www.teslamotorsclub.com/showthread.php/5004-Tesla-Graphical-Log-Parser?highlight=teslaglop)

[Moderator: Done]

tomsax

06-17-2011, 10:03 AM

Figuring out the data fields in the log file is hard. Figuring out how to present the data is hard. Figuring out how to let a user navigate through a gigantic set of data to extract out the bits they care about is hard.

If you know the data fields, writing a parser isn't hard. Even if you had a parser from someone else, you're still going to have to learn the format to understand what's in the log so you can build an appropriate user interface. Figuring out an existing parser and how to interface with it isn't a big obvious win compared to writing your own. If writing the parser is a barrier to writing a graphical app, I think you're underestimating how much work you're signing up for.

That's why I went to the work of publishing the format and data fields instead of giving away my source code. That was enough to get Doug rolling. I've thought about writing a graphical version for Mac OS X, but I find that every time I dive into the logs I want different data and charts than I did the previous times. I have a pretty good idea of how hard it is to write a robust charting engine, so there's no way I want to tackle that. As much as Excel drives me crazy, it's a nice charting package that makes it easier for me to get the charts I want than writing custom code.

Kudos to Doug for writing a graphical app for Windows. It's a big job I'm not willing to take on for my preferred platform.

smorgasbord

06-17-2011, 10:40 AM

I'm in the same boat. Only macs around, and a pain to dig up a PC (and wait for it to windows update).

FYI, it runs fine under Parallels for Mac.

Doug_G

06-17-2011, 12:10 PM

FYI, it runs fine under Parallels for Mac.

Yes, it should work just fine under Boot Camp, Parallels, or VMWare.

If insanity overcomes me I may at some point port it to Qt for multiplatform support, but I have a bunch of functionality I want to add first.

S-2000 Roadster

06-17-2011, 04:06 PM

...

That's why I went to the work of publishing the format and data fields instead of giving away my source code. That was enough to get Doug rolling. I've thought about writing a graphical version for Mac OS X, but I find that every time I dive into the logs I want different data and charts than I did the previous times.
You're absolutely right! Even if someone were willing to share their Win32 source with me, I'd end up throwing out 80% of it anyway. I totally agree that documentation is more useful than source code, with the possible exception that someone could write a standard C parser for the Tesla files and maybe share that without any GUI code.

I've been through your documentation, Tom, and it's excellent! My only hesitation is that Scott seems to have already deciphered extensions to the format, so I'm wary that I'd be missing something if I start developing a new app.

What would be great is if someone were to revise the documentation and share a 2.0 specification. I wouldn't expect Tom to do this, necessarily, since he's already contributed a great deal just by making the documentation that exists so far. Who knows, if I find a lull in my work, I might have time to look into this. I'll certainly share my OSX app if I ever make one.

tomsax

06-17-2011, 05:09 PM

My only hesitation is that Scott seems to have already deciphered extensions to the format, so I'm wary that I'd be missing something if I start developing a new app.

The basic format of the log file hasn't changed except in the ways I have documented.

Some new records were added with the 2.0 Roadsters, and a few fields in existing records changed. Even apart from that, our collective understanding of the data fields is a moving target as we continue to decode more data fields.

Over the last few days, I've been working on fixing a data field that changed between 1.5 and 2.0, a field that was added in 2.0 and also trying to crack four fields that have long been flagged as interesting candidates but not yet reversed.

Even if you started with everything we know perfectly combined and documented, it would still change. I'm sure if you started looking at the data, you'd find new stuff as well.

If you can implement a graphical parser that supports just the stuff in my document, you'll have a lot of cool stuff to show. If/when I get done with the stuff I've been working on recently, I'll update the document and try to do a good job of documenting the changes.

SByer

06-17-2011, 08:04 PM

If writing the parser is a barrier to writing a graphical app, I think you're underestimating how much work you're signing up for.

Hah! Fair enough. But I do know exactly how much is required to write a full GUI, which is why I don't create GUIs using any of the platform native tools any more if it can at all be avoided (just too darned painful!). It sounds like what's really needed is to try and come up with some database schemas to keep flexibility for the future. It's pretty easy to go from there to a reasonable web UI (there are a couple of good JS+Canvas charting packages out there, but then: open source, gift horse, mouth...). I can see where creeping feature-itis would permanently extend that, and it's also just me flapping about what I would do in my copious free time. Heck, I'm still trying to finish fixing up a raw Perforce -> Git converter (open source, gift horse, mouth...) so I can re-start working on the other things in the stack of programming to do at home...

S-2000 Roadster

06-20-2011, 03:20 AM

I hope that questions about the VehicleLogs file format are acceptable on this forum, and that this is the appropriate thread.

Tom's .doc mentions that the 2nd section is 8 MB, but I can't find anything documenting how to determine the size of the 1st section (other than that it is 'small'). Anyone know?

tomsax

06-20-2011, 09:22 AM

I hope that questions about the VehicleLogs file format are acceptable on this forum, and that this is the appropriate thread.

This is certainly the active log thread, but it might be better to have the more technical discussion on the format in the original log parser thread (http://www.teslamotorsclub.com/showthread.php/4032-Log-Parsing-tool-available) just so we keep this one focused on the apps.

Tom's .doc mentions that the 2nd section is 8 MB, but I can't find anything documenting how to determine the size of the 1st section (other than that it is 'small'). Anyone know?

Hmm. I totally skipped explaining that.

The key is the vehicle info record, record type 1. The log seems to use them as markers for subsections, especially in the transient section. In those records, the top bit in the byte I call t3 in the document is set in the permanent section and clear in the transient section. The transient section begins with the first vehicle info record that has the most significant bit of t3 cleared.

I'll add that info to my document.

scott451

06-20-2011, 04:19 PM

Tom's .doc mentions that the 2nd section is 8 MB, but I can't find anything documenting how to determine the size of the 1st section (other than that it is 'small'). Anyone know?

The key is the vehicle info record, record type 1. The log seems to use them as markers for subsections, especially in the transient section. In those records, the top bit in the byte I call t3 in the document is set in the permanent section and clear in the transient section. The transient section begins with the first vehicle info record that has the most significant bit of t3 cleared.

The Roadster 1.x uses a 32MB NOR flash. There were two flash partitions used for the logs. The permlog was 4MB and the tmplog was 8MB. vms_log was created by concatenating both logs and saving them in the 2011xxxxxxx.tar file. The log_offset file in the tarball tells you where each of the logs ends. This is important because the logs will wrap. If you ignore it, you can read records in the file that are older than the ones in the beginning. You should also verify the Xsum of each record.

The Roadster 2.x uses a much larger NAND flash. There are no dedicated partitions for the temp and perm log files. The log files can be as large or small as needed, but they seem to still wrap at the 4MB and 8MB size and use the log_offset file. It's possible that the permlog can now grow with out limit as I have not seen a 4MB wrapped perm log from a Roadster 2.x. As Tom said, there is a header or ident record (type 1) at the beginning of each section. I didn't notice the bit Tom found to distinguish between the perm and temp sections. It appears that all the record type numbers are unique, so it doesn't really matter which section (i.e. log) they are stored in.

vfx

06-20-2011, 06:08 PM

The Roadster 1.x uses a 32MB NOR flash. There were two flash partitions used for the logs. The permlog was 4MB and the tmplog was 8MB. vms_log was created by concatenating both logs and saving them in the 2011xxxxxxx.tar file. The log_offset file in the tarball tells you where each of the logs ends. This is important because the logs will wrap. If you ignore it, you can read records in the file that are older than the ones in the beginning. You should also verify the Xsum of each record.

The Roadster 2.x uses a much larger NAND flash. There are no dedicated partitions for the temp and perm log files. The log files can be as large or small as needed, but they seem to still wrap at the 4MB and 8MB size and use the log_offset file. It's possible that the permlog can now grow with out limit as I have not seen a 4MB wrapped perm log from a Roadster 2.x. As Tom said, there is a header or ident record (type 1) at the beginning of each section. I didn't notice the bit Tom found to distinguish between the perm and temp sections. It appears that all the record type numbers are unique, so it doesn't really matter which section (i.e. log) they are stored in.

The only word I understood in the above paragraphs was "Roadster".

Doug_G

06-20-2011, 06:32 PM

My approach was to simply read all the valid records then sort them by date/time. That way I don't care if it wraps.

SByer

06-20-2011, 10:53 PM

The only word I understood in the above paragraphs was "Roadster".

And I understood every word like it was English. I don't know which is more scary...

vfx

06-20-2011, 11:38 PM

And I understood every word like it was English. I don't know which is more scary...lol

Both!

Doug_G

06-21-2011, 07:33 AM

The only word I understood in the above paragraphs was "Roadster".

Gee and I thought that was interesting information. Of course I'm an electronics engineer so that's kinda cheating.

Scott sure likes to dig into things and find out how they work!

vfx

06-21-2011, 07:44 AM

Gee and I thought that was interesting information. Of course I'm an electronics engineer so that's kinda cheating.

Scott sure likes to dig into things and find out how they work!

I have the utmost respect for Scott and his passion for building and deconstruction and more building. My high school electronics, EE father, and Heathkit building ('member those?) just gets me so far.

Doug_G

06-21-2011, 08:15 AM

Heathkit building ('member those?)

Yeah, I still have some Heathkit electronics test equipment in boxes in my basement; some of them even still work. The oscilloscope gave up the ghost years ago and has been discarded, but I still have a working frequency generator and frequency counter, which have even seen use on rare occasions. I also have a VTVM and capacitance/inductance bridge that might still work, although they've got tubes and I've not turned them on in a dog's age.

benji4

07-11-2011, 06:40 PM

I deleted logs I had saved on the USB as I assumed the car would output a full log rather than just the last piece if there were no files on the USB. After deleting the files, however, I still only get the portion of the log since the last download when I insert the USD. Is the portion I deleted now permanently gone? Is there anyway to make the car output a complete log rather than just data since the previous download?

Doug_G

07-11-2011, 07:10 PM

It's not the data since the last download. It's the data that fits in the memory store. It's a rotating buffer, with oldest data being overwritten by the newest. Depending on your driving you might get the last month or two worth.

In other words, never delete the data. Copy it to your hard drive. It doesn't take much space.

benji4

07-11-2011, 07:15 PM

vfx

07-11-2011, 07:21 PM

If we want a contiguous running record of the car should we be downloading the USB an a regular basis?

Doug_G

07-11-2011, 08:08 PM

Got it, that makes sense! That leads to this question: Can the graphical log analyzer use multiple files? Also, one other thing that might be nice: the graphs should probably scale better instead of being 0 to max value. Many thanks!

Right now it can't read multiple files. I suggest that you download periodically, so that the successive logs overlap.

I can autoscale the graphs, but that often has undesirable side-effects unless you do it carefully. I'll look into it.

It's been a while since I've posted an update, and I have a bunch of things I want to add to the parser. I should have a bit more time available in the next few weeks, so I'll try to get a new update out.

Doug_G

07-11-2011, 08:09 PM

If we want a contiguous running record of the car should we be downloading the USB an a regular basis?

Yes, absolutely.

Doug_G

07-25-2011, 01:52 PM

A bunch of improvements to Tesla Graphical Log Parser:

- You can now enter a specific date to jump to
- You can now plot temperatures for ESS, Coolant, PEM, and Motor
- Improved the algorithm that recognizes and suppresses plotting of gaps in the log data

Download from TeslaFlux (http://www.TeslaFlux.com)

I still have a bunch of To-Dos on my list... but if you have any requests, please let me know!

Fuzzylogic

07-25-2011, 03:24 PM

Thanks! I like the improvements.

Always wanted to know at what temperature of the ESS the A/C would kick in to cool the pack. Seems it's 38 deg C.

It doesn't seem to show the ESS temperature while the car is charging.

Doug_G

07-25-2011, 03:50 PM

It doesn't seem to show the ESS temperature while the car is charging.

I'm getting the temperature information from the "drive 1 minute" record. I think Scott figured that one out.

It looks like a version of ESS temperature is also available from the "charge 30 minute" record. I'll see about adding that. Obviously the time resolution will be somewhat limited.

Slackjaw

07-28-2011, 09:08 AM

I still have a bunch of To-Dos on my list... but if you have any requests, please let me know!

Thanks for the update Doug. This is a very cool piece of software and I downloaded it long before I had any logs to look at!

I now pull my logs after any long drives and stare at them for a bit, but due to my inexperience, I haven't really got to the point where I really feel I'm taking advantage of this. There are some features which might be very hard to add and if so please forgive my ignorance. But here are some requests.

1) The option to either split logs by date en masse or to save out the log corresponding to the current view. This would get me over the current problem of having a ton of log files which overlap, many of them covering quite unremarkable drives. Probably being able to split a log into dated individual one-day logs would be most handy.

2) Option to "bookmark" current settings with some corresponding label such as "driving to Princeton to see Model S" or "test drive with so-and-so", so I can jump back to that. The settings could include the log file name, or this could be combined with (1) above and save a named sub-log along with the user preferences.

3) Some way to appreciate the distance traveled graphically. Is this accessible inside the log with any good resolution? If not maybe it could be estimated by integrating the speed curve over time. Then I could see distance and SOC on the same screen, and probably export them to plot one against the other rather than both against time. SOC vs Distance is probably the most interesting plot to me now as I'm learning to drive more efficiently and it will let me gauge my progress without constantly writing down the estimated vs ideal range.

If any of this is already done, I apologise for not R'ing TFM and finding it myself, just set me right on that... Thanks!

P.S. (4), I like the ability to pick the date but a list of available dates would be even better. Either a menu (probably my preferred choice) or a calendar where available dates are bold and clickable. Thanks again.

Doug_G

07-28-2011, 09:35 AM

Thanks for the feedback. I'm glad you're enjoying using it.

1/2 - currently you can jump to a particular date, but you have to load the needed file. I have considered the possibility of letting you load multiple logs simultaneously, sorting the data, deleting the duplicates, and thereby giving you a longer time period to view. I might implement that.

3 - So you want an integrated distance curve? From start of the current plot? I could do that. Right now there is a display of the distance traveled (e.g. left side shows 9625.8 km, right side 9649.0 km +23.2)

4. Nice idea; I'll look into it. (Not sure how useful it will be for me as I drive it on most days!)

Doug

Thanks for the update Doug. This is a very cool piece of software and I downloaded it long before I had any logs to look at!

I now pull my logs after any long drives and stare at them for a bit, but due to my inexperience, I haven't really got to the point where I really feel I'm taking advantage of this. There are some features which might be very hard to add and if so please forgive my ignorance. But here are some requests.

1) The option to either split logs by date en masse or to save out the log corresponding to the current view. This would get me over the current problem of having a ton of log files which overlap, many of them covering quite unremarkable drives. Probably being able to split a log into dated individual one-day logs would be most handy.

2) Option to "bookmark" current settings with some corresponding label such as "driving to Princeton to see Model S" or "test drive with so-and-so", so I can jump back to that. The settings could include the log file name, or this could be combined with (1) above and save a named sub-log along with the user preferences.

3) Some way to appreciate the distance traveled graphically. Is this accessible inside the log with any good resolution? If not maybe it could be estimated by integrating the speed curve over time. Then I could see distance and SOC on the same screen, and probably export them to plot one against the other rather than both against time. SOC vs Distance is probably the most interesting plot to me now as I'm learning to drive more efficiently and it will let me gauge my progress without constantly writing down the estimated vs ideal range.

If any of this is already done, I apologise for not R'ing TFM and finding it myself, just set me right on that... Thanks!

P.S. (4), I like the ability to pick the date but a list of available dates would be even better. Either a menu (probably my preferred choice) or a calendar where available dates are bold and clickable. Thanks again.

Slackjaw

07-28-2011, 10:30 AM

3 - So you want an integrated distance curve? From start of the current plot? I could do that. Right now there is a display of the distance traveled (e.g. left side shows 9625.8 km, right side 9649.0 km +23.2)

An integrated distance curve would be ideal; then later on you could even add an "estimated range" line (based on your own algorithm or just the past 40 miles). And the next step from that would be curve of driving efficiency, defined as something like estimated_range / ideal_range. I appreciate this might be a lot of work so I'm just thinking out loud.

4. Nice idea; I'll look into it. (Not sure how useful it will be for me as I drive it on most days!)Doug

Our car gets used most days too but I guess what I'm talking about is some way to find the interesting drives. Maybe you could populate a drop-down menu (or dialog box) with something like this (but better formatted):

20110720 trip 1 : 191.6 miles : -200 Wh/mile
20110720 trip 2 : 2.7 miles : -300 Wh/mile
20110721 trip 1 : 63.2 miles : -219 Wh/mile

That would just make it easier to find the critical trips and weed out the cases where I go to the supermarket to buy one banana :biggrin: ...but these are only suggestions of course. I know what it's like when you're developing software and someone asks for a bunch of wacky features.

It's a real shame the log doesn't include GPS data. Integrating the TeslaGLOP with google maps to show your route and efficiency in different places would be interesting too.

Thanks.

Doug_G

08-04-2011, 04:06 PM

The new V1.08 adds the ability to inspect any point on the graph with the mouse. Simply point the mouse at one of the graphs, and a vertical line appears, corresponding to the mouse position. It will then read off the data point at that position, and display it in the lower right-hand status box (where it usually shows the end-of-graph date/time and mileage).

You can use this, for example, to find out the exact speed you were traveling at a certain point in your trip.

Download from TeslaFlux (http://www.teslaflux.com)

More to come!

Doug

Doug_G

09-25-2011, 05:28 PM

The lastest update to the Tesla Graphical Log Parser has some cool new features. (Thanks to Scott451 for suggesting several of them!)

Download from TeslaFlux (http://www.teslaflux.com/)

New Features

1. You can now select multiple logs at the same time, so you can cover a larger span of dates. The data will be merged together seamlessly. Any overlap is removed automatically. Simply click the Select Log button and use SHIFT or CTRL to select multiple log files.*

2. New menu added; it's the little arrow under the Date button. This brings up a menu with more features:

3. Daily Lowest Brick - shows the lowest brick each day. This should semi-randomly change over time. If it gets stuck on one brick, that brick is under-performing.

4. SOC Histogram - displays a histogram of State of Charge. You can do this for the whole log, or over the currently-selected range of dates.

5. Firmware History - the firmware version is recorded periodically in the log. You can see the version change whenever your firmware was updated.

6. Error Report - displays error reports over the currently-selected range of dates. Right now I've only got a few errors decoded. If anyone has a more extensive list of error messages and codes, please let me know (Scott?)

*Note: the graphs are set up to plot at most 500,000 data points, so in extreme cases you might not be able to see all your data at once.

Dragon

09-26-2011, 11:05 PM

Great improvements! Will test it as soon as I can. Thanks for the work!

fraccy

09-27-2011, 02:13 AM

Just to add, thank you for sharing this. I can appreciate you've done a lot of work, and I'm already very much enjoying the benefit. Very kind of you.

fraccy

09-27-2011, 09:00 PM

Please can I ask about the motor temperature shown in the parser. The temperature is denoted as (C), which doesn't change if I switch between metric and imperial. The highest reading it shows from my log is around about 60C. When I'm driving, the "M" (top line) which I presume to be motor temperature on the VDS will usually read between 80 and 100 "C" (top or second from top blue bar).

When I queried Tesla, I was told motor temperature should "average around 60c" and power limited up around "130C" (that was two different people). Anyway none of these numbers make sense. Is the log definitely right or is the Tesla showing it right?

[Edit: Just to add, the PEM and ESS temperatures I see in the Tesla and in the parser do however seem to match, its just the motor temperature]

Doug_G

09-27-2011, 09:25 PM

Thanks for the report; I'll look into it.

dhrivnak

10-09-2011, 10:13 AM

Hi Doug I just downloaded the file and have been looking at some of my 1.5V logs. Thank you and this is very interesting. I appreciate you providing this.

rajeshkallur

11-07-2011, 04:58 PM

Hello,
i'm an automotive engineering student from Cranfield University, UK. We are doing a student design project(as part of our course) with a lotus elise as a electric car with range extender. We would like to compare the performance of our car with the Tesla for component sizing. For this we have developed some Matlab models, where we can input the track details and spped-time graphs, and then use that to gauge the capability of the motors and subsequently develop basic control algorithms.

It would be nice if any of you could PM me your 'Track race' data. I have downloaded the parser and couldd view and subsequently extract the data speed-time data logs. it would be great step in our design project if we could actively compare race-track performance of our car with the Tesla and other likes.

Thanks a lot!

Rajesh

Alan

11-26-2011, 06:01 AM

Thanks for the updates (I know they were ages ago, but only just found time to play with them).

My "Daily Lowest Brick" has been the same for the last 300 odd readings. Should I be worried?

I have done about 14,000 miles and the A-hr when new was 156. For the first year it went up (159 peak) and for the second year its come down, now at 158. Tiny changes really.

Dragon

12-09-2011, 11:54 AM

Lloyd

12-09-2011, 12:22 PM

It may be easier for you to install a meter such as this. (http://www.ebay.com/itm/kWh-Meter-Tesla-Motors-Model-S-Roadster-Charger-Energy-Remote-Readings-24-/180762531650?pt=LH_DefaultDomain_0&hash=item2a16495742)

Doug_G

12-09-2011, 01:17 PM

Hey Doug, I have one request and one question.
Could you please implement a Max-Function? Which would show all the max values of the logs, example maximal speed, maximal temperatures etc.
The question is, how can I see how much KW I charged on every day? I need this data.

I'll try to find time to add the max feature. Also min where appropriate.

I assume you're interested in kWh per day? That requires integrating the kW over time. Probably can do that at the same time as the max feature. Maybe call it a "statistics" page.

Dragon

12-09-2011, 03:01 PM

That sounds great! :cool:
Don't make it too complicated, kWh per charge would be good. :smile:

tomsax

12-09-2011, 05:39 PM

Hey Doug, I have one request and one question.
Could you please implement a Max-Function? Which would show all the max values of the logs, example maximal speed, maximal temperatures etc.
The question is, how can I see how much KW I charged on every day? I need this data.

My parser gives the maximum and average speed on each drive segment, also the approximate net energy used on each drive segment and approximate energy drawn from the wall on each charge segment. You have to run my parser from the command line, so it's not as pretty or friendly as Doug's parser.

More info and download instructions are available on my VMSParser page (http://www.idleloop.com/tesla/vmsparser).

Dragon

12-19-2011, 11:30 AM

My parser gives the maximum and average speed on each drive segment, also the approximate net energy used on each drive segment and approximate energy drawn from the wall on each charge segment. You have to run my parser from the command line, so it's not as pretty or friendly as Doug's parser.

More info and download instructions are available on my VMSParser page (http://www.idleloop.com/tesla/vmsparser).

Thanks Tom! Should have looked at it much sooner. A nice and clean output with some valuable information. Many thanks!

Saftwerk

12-21-2012, 04:46 PM

6. Error Report - displays error reports over the currently-selected range of dates. Right now I've only got a few errors decoded. If anyone has a more extensive list of error messages and codes, please let me know

This:
12/10/12 01:35:23 Unknown Error 0C 00 00 00 19 02 08 00 20 00 00 00 00 00 00 00

Decodes to that message:
"Check left front signal bulb."

The front left yellow turn indikator is dead.

greensportcars.at

01-27-2013, 11:03 AM

hello,

thanks to Doug_G for this great tool !

but for further analytics with excel i want to export the data into a csv-file.
i get the message "wrong parameter" if i want to export the graph to a csv-file. i'm using w7 and office2010. changing the decimal from , to . in w7 and also
in excel2010 did't work, still the same message (TeslaGloP Version 1.09).

any idea?

thank you
manfred

Doug_G

01-27-2013, 01:56 PM

I'm not sure. It works on my system okay. Might be the comma versus period thing.

Doug_G

04-14-2013, 07:47 AM

markwj

04-14-2013, 07:56 AM

New Version 1.10! The Tesla Graphical Log Parser now graphs CAC - Calculated Amp-hour Capacity. A big thanks to Tom Saxton for sussing out the CAC information, based on Scott's earlier work.

Fantastic. Glad you guys found it in the logs.

I hope the OVMS work that found this on the can bus was helpful. V2.3.1 of OVMS firmware should be available tomorrow (assuming final testing goes ok), and that supports real-time query of CAC.

20116

Rodolfo Paiz

04-14-2013, 09:04 AM

My apologies if I missed it somewhere, but is there a way to get the Model S logs out of the car for analysis?

Doug_G

04-14-2013, 02:15 PM

Unfortunately no, it appears not. We should all be asking Tesla for access to this information.

JakeP

04-14-2013, 06:08 PM

brianman

04-14-2013, 06:16 PM

In a conversation with Dave from Columbus service, he seemed to indicate that the capability to pull logs would be available soon, if it wasn't already. He mentioned how on the Roadster, just inserting a USB drive caused the logs to be immediately downloaded to the drive.
For the 2nd time in as many years, I did try the guidance here...
Tesla Graphical Log Parser (http://www.teslamotorsclub.com/showthread.php/5004-Tesla-Graphical-Log-Parser?p=57649&viewfull=1#post57649)
... except for the part about "turning the key" but no signs from Model S that it noticed or reacted to the USB key in any interesting way.

ChargeIt!

04-21-2013, 06:22 PM

New Version 1.10! The Tesla Graphical Log Parser now graphs CAC - Calculated Amp-hour Capacity. A big thanks to Tom Saxton for sussing out the CAC information, based on Scott's earlier work.

...

To get a lifetime plot for your Roadster, simply open ALL of the log files you have downloaded simultaneously, ...
Is there a feature which allows the creation of a cumulative history file ("CHF") from all of your old individual TAR files ? This feature would allow us to avoid re-loading and re-analyzing the entire set ( several dozen ! ) each time. An additional feature could allow an append of the latest TAR file to the end of the "CHF" ... :) ( In either case, naturally, any overlapping data would be purged before writing CHF. )

Doug_G

04-21-2013, 11:42 PM

Overlapping data is purged automatically; that's the main reason it takes some time to load multiple files. This is done after the data is parsed, so I can't write it back out in the same format. I'm sorry but I haven't created a way to save and restore the parsed data.

tomsax

04-22-2013, 10:21 AM

Is there a feature which allows the creation of a cumulative history file ("CHF") from all of your old individual TAR files ?
My parser has a feature that sort of does this, but it doesn't work very well. It's not as easy as you'd think. There are two streams of records, sparse records going back to when the car was built and verbose, detailed records that cover the most recent history (typically covering the last ~60 hours of driving). Every record has a date and time, so it should be easy to put all of the records into one single sequence, removing duplicates, either preserving the two sections or merging them.

Except sometimes there are multiple records with the same time stamp. How do you order those? By original file order, I suppose, but it makes detecting duplicates more complex. Even worse, sometimes the time stamps are wrong; sometimes a little wrong, and sometimes really wrong. How do you order those into the file and detect duplicates?

It could definitely be done, but it's a lot easier to just scan all of the log files. It's slow, tedious work, but honestly computers don't mind that sort of thing. Every time I've thought of revisiting that part of the parser, I've had a dozen other ideas that offer more benefit.

If someone wants to do it, everything you need to know about the format is available from my VMSParser page (http://www.idleloop.com/tesla/vmsparser/). Just be careful you don't lose or mangle any data. Stuff we don't understand today may be figured out and made useful in the future. If people start keeping a CHF file and tossing their log files, we don't want to lose anything.

Doug_G

04-22-2013, 12:47 PM

I'm with Tom. The simple answer is there are more important things to add. I spent a fair bit of time developing the ability to load multiple log files, and the incremental benefit (saving 10-15 seconds) isn't worth the surprisingly large amount of extra effort involved.

hcsharp

04-23-2013, 12:50 PM

New Version 1.10! The Tesla Graphical Log Parser now graphs CAC - Calculated Amp-hour Capacity. A big thanks to Tom Saxton for sussing out the CAC information, based on Scott's earlier work.

20113

This is the CAC value from my Roadster over its entire lifetime. To get a lifetime plot for your Roadster, simply open ALL of the log files you have downloaded simultaneously, and dial the Display Span up high enough to see everything.

You'll notice a big drop in early February 2012. This appears to have been triggered by Roadster firmware upgrade 4.6.4, which was installed at the end of January (my Roadster is currently at 4.6.5). It appears they changed the algorithm that calculates the value. The decline in my CAC value seems to match quite well with the decline in Standard mode range.

Download the new version from TeslaFlux (http://www.teslaflux.com/)

I got a chance to d/l the new version today (a big thank you to Doug_G and tomsax for their work on each ver) and noticed that I have two large steps similar to the one you have in Feb 2012. My first one is in September 2012 (I had no drop when 4.6.4 was installed earlier - not saying that wasn't a factor in your case). The second drop was about a month ago with no firmware upgrade. Both steps in my data correspond with long trips where the battery was depleted to about 25 miles remaining. There were other trips of similar distance but no corresponding significant change in CAC.

We've heard from various sources (various levels of reliability), and observed empirically that range and CAC will often get recalculated the most after a long trip. I was a bit upset when I lost almost 4 CAC a month ago. I've since recovered 1. That makes me wonder about the margin of error in all this data. Obviously it's the best we have. Perhaps I should say the best Tesla can calculate. It makes it hard to find correlations between things like average SOC or pack temp and capacity loss.