TMC is an independent, primarily volunteer organization that relies on ad revenue to cover its operating costs. Please consider whitelisting TMC on your ad blocker or making a Paypal contribution here: paypal.me/SupportTMC

Firmware Upgrade Tracker

Discussion in 'Wiki' started by Wiki, Mar 29, 2015.

Tags:
Thread Status:
The first post in this thread is a WikiPost, and can be edited by anyone with the appropriate permissions.
  1. Wiki

    Wiki Member

    Joined:
    Mar 21, 2016
    Messages:
    26
    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.


     
  2. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    #2 HankLloydRight, Mar 29, 2015
    Last edited: Mar 29, 2015
    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.
     
  3. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    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.
     
  4. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    I've experimented with this a bit. It's really easy to copy the data into a spread sheet - and there you can do pretty much whatever you want. So yes, let's leave the data with one row per car.
     
  5. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    #5 HankLloydRight, Mar 29, 2015
    Last edited: Mar 29, 2015
    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.
     
  6. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    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.
     
  7. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    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.
     
  8. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    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.
     
  9. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    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.
     
  10. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    #10 HankLloydRight, Mar 29, 2015
    Last edited: Mar 29, 2015
    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.
     
  11. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    You know what? You are right. I'll walk away and let you do it.
    Go have fun with it.
     
  12. mrElbe

    mrElbe Member

    Joined:
    Aug 17, 2014
    Messages:
    869
    Location:
    Stouffville, ON Canada
    Hey folks, dirkh made a very good effort to track this for our pleasure. If someone has a better idea, start your own thread!
     
  13. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    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.
     
  14. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    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...
     
  15. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    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.

    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.

    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.
     
  16. spentan

    spentan Active Member

    Joined:
    Dec 26, 2012
    Messages:
    1,256
    Location:
    SoCal
    Hi, I hope everyone doesn't mind, I went in and cleaned/standardised some of the responses, so that its all in line and uniform.

    My OCD got the better of me, :/
     
  17. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    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.
     
  18. spentan

    spentan Active Member

    Joined:
    Dec 26, 2012
    Messages:
    1,256
    Location:
    SoCal
    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
     
  19. HankLloydRight

    HankLloydRight Fluxing

    Joined:
    Jan 18, 2014
    Messages:
    5,790
    Location:
    Connecticut
    #19 HankLloydRight, Mar 29, 2015
    Last edited: Mar 29, 2015
    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.
     
  20. dirkhh

    dirkhh Middle-aged Member

    Joined:
    Jul 7, 2013
    Messages:
    3,645
    Location:
    Portland, OR, USA
    Then why don't you do that? I repeat what I said earlier. Go ahead, it's a wiki, change it.
    I don't care
     
Thread Status:
The first post in this thread is a WikiPost, and can be edited by anyone with the appropriate permissions.

Share This Page