Tom/Whoever: do you have anything good for that? I believe it is drive time based, which may be tricky?
Executive Summary ----------------- The best method is to download every 50 hours of driving (meaning time while the car is turned on with the key, charging time doesn't contribute much to the log file). Drivers can track this via the trip meter. If that's impractical, downloading every 1,200 miles (1,900 km) will suffice in most cases. There are unusual cases where these strategies won't work. Background ---------- Roadster owners have an interest in downloading log files from their car. There's interesting information in there, and tools for extracting that info. The files may get even more interesting in the future if we figure out how to decode more of the data. Ideally, owners would collect a complete set of log files which must be done regularly as there is limited space for store the detailed records. The oldest records are being constantly overwritten by new records, so owners should download often enough that there are no gaps in the detailed transient records. In addition to regular downloads, it's also a good idea to download just before taking your Roadster in for service because sometimes they will do something that will erase the log file. It's also a good idea to download when you get it back from service, and look at the data because of a problem that's explained in the last section. For more information about log files and the nerdy tool I wrote for decoding them, see this page: http://www.idleloop.com/tesla/vmsparser/ If you really want to be sure to get a full set of logs, you'll need to read the rest of this novel. Capturing Log Files ------------------- The log file has two sections, which I call permanent and transient. The permanent section contains a little data going all the way back to when the car's computers were installed (unless something causes the log file to be reset, which is unusual but does happen). The transient section contains much more detailed information, but it is constantly overwriting the oldest records with new records. So, you want to download again while there's still some overlap between the records in your last download. Generally speaking, the transient section of the log gets filled mostly with records that get written once per second while the car is on, so driving time is the best measure of how quickly the log file fills and starts writing over old records. But there's another way that the log can fill up much more quickly; more on that below. The latest version of my log parser dumps out info on what range of data the transient section covers in number of miles driven, driving time, charging time, and calendar time elapsed. Here are some example entries: 06/29/2012 2340 mi, 60.3 hours driving, 122.8 hours charging, 35.6 days 08/31/2012 2058 mi, 60.0 hours driving, 131.2 hours charging, 62.9 days 11/19/2012 1903 mi, 60.3 hours driving, 126.4 hours charging, 108.2 days 01/21/2013 1853 mi, 59.7 hours driving, 131.9 hours charging, 149.6 days 02/28/2013 1856 mi, 59.3 hours driving, 115.4 hours charging, 186.6 days The first record is for a log I pulled shortly after Cathy and I completed a 12-day, 1,823-mile road trip from Seattle to San Francisco and back. Because we did so much driving in that time period, the log only went back 35.6 days. However, that was a leisurely trip down the coast. Even on the way back up I-5, we kept to about 200 miles per day. It's possible to do that roundtrip in four or five days, and thus fill up the log even faster. The last record shows the log I took at the end of February, after the car had been parked in Storage mode for a month, and not driven at lot for a couple of months before that. That log went back six months. So calendar time is pretty useless for predicting when you need to capture a log. Driving time is the best, showing consistently about 60 hours of driving. Miles driven is next best, but that's going to vary with how fast you drive. I have 120 log files I've captured from our car since December, 2009. Here's the range of values I see in those files: Distance Driven: 1,510 to 2,496 miles Time Driven: 58.8 to 62.4 hours Time Charging: 58.0 to 177.9 hours Elapsed Time: 29.4 to 192.4 days So, by my data if you download a log every 50 hours of driving, you'll probably get a complete log with no gaps in the more detailed transient section. (Unless you get hit with the problem described below.) You can track your driving time by using the trip meter. You'd probably also get a complete log if your driving isn't too different than mine and you download every 1,200 miles. That will fail if you do a lot of low-speed driving. Those driving records get written every second the car is on, so you don't actually have to be driving. If you leave your car turned on for an extended period, that will fill the log file without adding miles to the odometer. A Nasty Problem --------------- But there's another (unusual) issue over, which the owner has no control, that can fill up the log much more quickly than you'd expect. Consider these log files from a different Roadster: 04/29 1725 mi, 60.9 hours driving, 80.0 hours charging, 114.5 days 06/18 1601 mi, 61.6 hours driving, 74.0 hours charging, 122.6 days 06/27 413 mi, 17.1 hours driving, 31.8 hours charging, 30.5 days 07/09 37 mi, 2.5 hours driving, 3.4 hours charging, 8.0 days 07/13 59 mi, 2.4 hours driving, 3.4 hours charging, 8.0 days 07/18 115 mi, 3.8 hours driving, 2.9 hours charging, 6.9 days 07/26 54 mi, 2.6 hours driving, 2.6 hours charging, 6.7 days The first and second are pretty normal, but then it goes crazy. Between June 18 and June 27, something happened that started filling the log much more quickly than normal. Once all of the older records got overwritten, we can see the log is getting cycled every 7 to 8 days, with very little driving or charging! The problem: the car was taken in for service and the Tesla service tech put it into a verbose logging mode, which writes a record to the log once per second, 24x7. Presumably it was an accident that it was left in this state when returned to the owner. This is totally invisible to the owner unless the log files are being downloaded and closely examined, even then it might be a few weeks before the problem is noticed and a bunch of data is lost. This owner lost log data from a track event, not a good thing. So, I try to download a log just before I take it in for service and again when I get it back, and take a look for unusual record distributions. If you run my parser with the -v flag, the last thing printed is a table of stats on the records in the transient section. A normal log file looks like this: rt t2 t3 cb firmware count bytes tag notes -- -- -- -- ----------- ------- -------- ---- ----- 01 FF 03 29 3.6.7 15 63 2709 VINF Vehicle Info 03 01 00 0D 3.6.7 15 3604 54060 XX03 Input Events? 04 03 00 0D 3.6.7 15 4651 69765 XX04 Car Operating State? 05 0F 00 11 3.6.7 15 27 513 XX05 05 1F 00 14 3.6.7 15 96 2112 XX05 05 1F 00 15 3.6.7 15 1106 25438 XX05 05 1F 00 19 3.6.7 15 406 10962 XX05 07 1F 00 19 3.6.7 15 4452 120204 IDLE Every 60 minutes when idle 08 FF 7F 31 3.6.7 15 6926 353226 C1MA 1-minute charge status 09 FF 01 15 3.6.7 15 322 7406 C30M 30-minute charge status 0A EF 03 21 3.6.7 15 213307 7465745 DR1S 1-second drive status 0B 0F 04 21 3.6.7 15 1 35 DR1M 1-minute drive status 0B FF 07 21 3.6.7 15 3888 136080 DR1M 1-minute drive status 0C 2A 00 15 3.6.7 15 1 23 D10M 10-minute drive status 0C 3E 00 15 3.6.7 15 281 6463 D10M 10-minute drive status 0C 3F 00 15 3.6.7 15 389 8947 D10M 10-minute drive status 14 01 00 21 3.6.7 15 5 175 TPMS Tire Pressure Monitor System You can see that the biggest contributor by size, at 7,465,745 bytes, is the 1-second drive status record, which I designate as DR1S. That's what we expect. Here's a table with verbose logging turned on: rt t2 t3 cb firmware count bytes tag notes -- -- -- -- ----------- ------- -------- ---- ----- 01 FF 03 29 3.6.7 11 63 2709 VINF Vehicle Info 03 01 00 0D 3.6.7 11 187 2805 XX03 Input Events? 04 03 00 0D 3.6.7 11 241 3615 XX04 Car Operating State? 05 0F 00 11 3.6.7 11 1 19 XX05 05 1F 00 14 3.6.7 11 2 44 XX05 05 1F 00 15 3.6.7 11 313138 7202174 XX05 05 1F 00 19 3.6.7 11 1951 52677 XX05 05 1F 00 21 3.6.7 11 1922 67270 XX05 07 1F 00 19 3.6.7 11 160 4320 IDLE Every 60 minutes when idle 08 FF 7F 31 3.6.7 11 158 8058 C1MA 1-minute charge status 09 FF 01 15 3.6.7 11 6 138 C30M 30-minute charge status 0A EF 03 21 3.6.7 11 9389 328615 DR1S 1-second drive status 0B FF 07 21 3.6.7 11 166 5810 DR1M 1-minute drive status 0C 3F 00 15 3.6.7 11 22 506 D10M 10-minute drive status 0E FF 83 35 3.6.7 11 10789 593395 13 00 00 11 3.6.7 11 4583 87077 13 07 00 11 3.6.7 11 205 3895 14 01 00 21 3.6.7 11 150 5250 TPMS Tire Pressure Monitor System In this table, the biggest contributor is one of the variations on the XX05 record. I have no idea what that record stores, but there's a whole lot of it! I've only heard of this happening once, but not many owners collect log files and I'll bet even fewer look at them regularly. It's definitely something to watch out for, especially if the Tesla service folks are looking into diagnosing an unusual problem. Tom