-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
new Unknown Error decoded
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.
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.
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
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
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.
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
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
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.
Unfortunately no, it appears not. We should all be asking Tesla for access to this information.
JakeP
S P4996 ==> P02547
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
... 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.
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. )
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
Member
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. 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.
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.
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.
Interesting observation. I have a little drop at the end too, and that was after a long road trip where I brought the Roadster down to about 30 km reserve.
My earlier dip was also close to a road trip, although I had assumed the firmware update was responsible... perhaps not. Can anyone prove/disprove the thesis by looking at their CAC log and firmware update history?
My earlier dip was also close to a road trip, although I had assumed the firmware update was responsible... perhaps not. Can anyone prove/disprove the thesis by looking at their CAC log and firmware update history?
Someone else has already done one - Tesla Vehicle Log Graphing application for Mac OS X
I haven't tried it, so I can't comment on its capabilities, but it might do the job for you.
I haven't tried it, so I can't comment on its capabilities, but it might do the job for you.
tomsax
Member
My command-line VMS parser comes in both Mac and Windows flavors. It's too nerdy for most owners, but if you know your way around a command line it lets you get all the data that's known from the Roadster log files.
Similar threads
- Article
- Article
