Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Wiki Firmware Upgrade Tracker

This site may earn commission on affiliate links.

Wiki

Member
Mar 21, 2016
34
200
Thanks to HankLloydRight we now have a great way to track firmware upgrades and create statistics based on the data:

Go to the Firmware Tracker Web-App and enter your TMC user name and pick a PIN (simply something that prevents others from modifying your data) and then enter your data there. It will ask you for some data about your car, then the date, version and build of the firmware update and how you received it.

The cool thing is that his site then allows real time statistics on the data entered as you can see here in the Firmware Upgrade Report

This allows us to see the distribution of firmware updates across models, VIN groups, and types of Model S.

Attached to this wiki is a discussion thread (just click on discussion above) where you can leave feedback and suggestions for changes / improvements.
 
Last edited by a moderator:
From a data analysis perspective, I think you want each row to represent a firmware release date, not just one car with multiple dates. By having multiple releases in columns instead of rows, it's much harder to analyze the data for a particular release, since different cars will have different releases in the same column.

I would suggest each row being:
Owner/Type/VIN/Version/Date

So if you have multiple releases (like point upgrades, etc) you'd have one row for each. Also this way you don't need to add columns when someone has more than six updates.. It also makes the list easier to filter/sort for one specific release.
 
Last edited:
From a data analysis perspective, I think you want each row to represent a firmware release date, not just one car with multiple dates. By having multiple releases in columns instead of rows, it's much harder to analyze the data for a particular release, since different cars will have different releases in the same column.

I would suggest each row being:
Owner/Type/VIN/Version/Date

So if you have multiple releases (like point upgrades, etc) you'd have one row for each. Also this way you don't need to add columns when someone has more than six updates.. It also makes the list esker to filter/sort for one specific release.
All depends on how you plan to analyze this. But if we get anything near the frequency of updates that we had with 2.2.112/114/115/139/140/179 then this table will become completely unmanageable in no time.
I'd say stick with what I have suggested and instead be smarter when parsing the data.
 
I still strongly disagree. To store event data in columns is bad database design. Once you start out with a bad design, it's much hard to fix it later.

The current design makes it very hard to say,without looking at every row and every column: "which type and how many cars of each type cars have been updated with version 6.x yet". Or questions like "on what dates have all the 'D' cars been updated with version X?" or "What VIN ranges have been updated by date?"... and so on.

If you want to do all that manually by inspecting every row and every column pair (date/version) to extract that kind of useful info, go right ahead and do it the hard way.

And just because you can put it into Excel doesn't make it easier. How in Excel, with the current design would you be able to answer any of these questions without reformatting the data into rows, or using complicated macros every time, or inspecting every row and column? You can't use "Auto Filter" because people are going to have different versions in the same column. You'd have to normalize the dataset every time you want to apply any level of analysis.

But trust me, it's so much easier with the proper database design, which this is not.
 
Last edited:
All depends on how you plan to analyze this. But if we get anything near the frequency of updates that we had with 2.2.112/114/115/139/140/179 then this table will become completely unmanageable in no time.
I'd say stick with what I have suggested and instead be smarter when parsing the data.

But that's the beauty of a good database design, that one can very easily filter and sort on the keys (columns Owner/Vin/Type/Date) to only include the data you want. It's essentially impossible to do that with data in column format like this without a lot of work you'd have to repeat every time.
 
It's a free world. Design a different format. I would find a table with multiple rows for the same user / same car very confusing and it would get extremely long and hard to edit in no time.
So if you want something different, feel free to start a new page. Just like I started this one because I felt that the poll wasn't tracking the data that I was interested in.
 
It's a free world. Design a different format. I would find a table with multiple rows for the same user / same car very confusing and it would get extremely long and hard to edit in no time.
So if you want something different, feel free to start a new page. Just like I started this one because I felt that the poll wasn't tracking the data that I was interested in.

That's the thing.. you wouldn't need to "edit" such a design, only append new records as they come in.

What happens when an owner has a 7th update and your design is out of columns?

I'm not here to start a competing wiki page.. I think we all want data we can actually use and analyze. That's not possible with this design. It's unwieldy and not useful to answer any of the questions I posted. It's just record keeping by owner.
 
HankLloydRight - you keep stating that the data can't be analyzed. Repeated assertion doesn't make a claim into a fact.
I'll have fully automated analysis of these data ready that will answer every one of the questions you posted in your comment.
So instead of repeated assertion that I'm doing it wrong, either do your own and do it right, or help design the questions that are most interesting to have answered and I'll implement them.
 
I don't doubt you can create something to analyze the data, but that doesn't mean the design is optimal. I do this for a living and I can guarantee that whatever you design/develop to analyze this dataset will be much more complicated than actually need be.

I've seen my clients do this time and time again, and they have had to spend hundreds of thousands of dollars to correct a bad design when it could have been corrected at the start with the right design.

An optimal, normalized design as I propose wound be trivial to import into any number of analysis packages without any pre-parsing or transformations or additional code to do any analyses (like any SQL database). Your current design will require quite a bit of parsing and realignment before you can do any analysis. I'm sure you can code that up at be automated, but why do that when it's not necessary at all?

In a nutshell, you are storing an event key (date) as a data element. It should be part of the key. Any analysis you do will need to convert your columns into keys. So why not just store them that way from the start and avoid these extra transformations?

And as I asked, what do you do when an owner has a 7th update? You have there options:
1. Expand your table to add more columns, but that's only good until you reach n number of updates before you have to keep expanding the number of columns and your parsing code to accommodate the extra columns.
2. Shift that user's data left one position, popping off their oldest data point to make room for their newest data point. You'd be losing data in this case.
3. Add a second row/record for the same owner and then somehow link the two records together. This would make your parsing and analysis code that much more complicated to handle that (i.e. to avoid double counting the second record as a different car).

Or you can store date as a key and not have any of these issues or limitations. Your dataset could handle any number of firmware updates over any period of time. Over the long term, you could create a very valuable database of firmware updates across all future firmware releases. Your current design can not do that.
 
Last edited:
You know what? You are right. I'll walk away and let you do it.
Go have fun with it.

I'm only trying to improve what you started, which is a great idea to quantify something that's only previously been the source of intense speculation. If people are willing to enter data to make it work, then I'd like to contribute my experience by making it as useful as possible for you, or anyone else that might want to analyze the dataset, to do so. Like I said, I've lived and breathed this stuff everyday for the last 25 years, so I'm only trying to improve what was started so it has the best chance to succeed and be usable by the widest group of people using any analysis tool they choose. I'm sorry if I offended you, that was not the intention. If you read my first post, I was just suggesting an alternate design to make the project more flexible and useful over the long term. It wasn't a personal attack.
 
I've been a software developer for the past 30+ years and have done my share of projects like this. I always felt that it was more important to have the input form make sense to the user and to then massage the data in the backend - regardless of format, unless you want to do this manually you'll need to write "something" that sucks this into a data base so you can process it, correct? And making this "something" a tiny bit smarter so it can parse what I have suggested seemed trivial to me.

The format that I have suggested seemed to me to make it easy for people to eye-ball things. Get a quick view of what are the latest versions that people have gotten and how, what version did they have before, etc.
With your design it would be hard to quickly see which version people were coming from, how many versions they have gotten, etc.
And it's a lot of redundant data entry. Every time you get an upgrade you have to add user name, type of car, VIN...
 
I've been a software developer for the past 30+ years and have done my share of projects like this. I always felt that it was more important to have the input form make sense to the user and to then massage the data in the backend - regardless of format, unless you want to do this manually you'll need to write "something" that sucks this into a data base so you can process it, correct? And making this "something" a tiny bit smarter so it can parse what I have suggested seemed trivial to me..The format that I have suggested seemed to me to make it easy for people to eye-ball things. Get a quick view of what are the latest versions that people have gotten and how, what version did they have before, etc.With your design it would be hard to quickly see which version people were coming from, how many versions they have gotten, etc.

But displaying those things shouldn't dictate the database design. The design I propose, it's trivial to give each user any view of the data they want without the downsides of a non-optimal database design for full dataset analysis or long term usefulness.

And it's a lot of redundant data entry. Every time you get an upgrade you have to add user name, type of car, VIN...

Not with a good user interface, it isn't. Again, that shouldn't drive the core database design. You mentioned up above that version 6.1 had the following point updates: 112/114/115/139/140/179 and there's also 200. That's 7 firmware updates right there which would max out the column design, which presents the issues I stated above. Any database engineer worth his salt would know that adding more columns is not the solution to this problem, but rather normalizing the columns to rows is the standard way to go. That's all I propose. Also, Excel is built to do these kinds of analyses using "Pivot Table", but that can't be used with column based key data, it would still need to be normalized into rows.

The format that I have suggested seemed to me to make it easy for people to eye-ball things. Get a quick view of what are the latest versions that people have gotten and how, what version did they have before, etc.

But that's only looking at it from a "per user" point of view. To see the "latest version" people have gotten, you'd have to scan the last populated column of every record, but that column could be different for each user since some users would have more updates than others.

Finally, taking a row based dataset and presenting it in a columnar view is very easy. Taking columns and converting them to rows for analysis is much harder. That's all I'm saying.

Look, I don't want to spend the night going over basic database design methodology. Obviously I'm not going to change your mind, as I said, I was only trying to improve the project, not start a big battle.
 
You really think that what's in the wiki is a data base?
Yeah, I think it's better that you don't try to explain "basic database design methodology" to me. I don't think that would go over too well.

Uh Oh,

I changed some of the names around so that P85/S85 (type) was always first, and then Classic, or Classic w/o Tech, comes after it.

Hope this is ok. Don't wanna aggravate anyone
 
You really think that what's in the wiki is a data base?
Yeah, I think it's better that you don't try to explain "basic database design methodology" to me. I don't think that would go over too well.

You're taking this too personally. My intention was to improve the system for greater usage and flexibility. No, the wiki itself is not a database. But you yourself said that it can easily be exported to other tools, so yeah, at the end of the day, yes, it is a database and the wiki is just a storage medium. Also, no need for the snark/snipiness -- I've only been trying to improve the system, not insult or offend anyone. If I proposed something that was non-optimal and someone suggested something better and infinitely more scalable, I would likely adopt it, rather than continue down a path that will not end well and will require significantly more work to accomplish the same end results.
 
Last edited: