[Ovmsdev] Tesla Roadster VDS Alerts
Tom Saxton
tom at idleloop.com
Tue Mar 5 02:44:30 HKT 2013
> 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
More information about the OvmsDev
mailing list