dirkhh
Middle-aged Member
You want the table sideways
And I'll add that I REALLY like the table you want, so I'll pitch in half the hourly rate that Hank will charge us...
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Firmware 6.2 poll to say when you got it
- Thread starter MikeBur
- Start date
And I'll add that I REALLY like the table you want, so I'll pitch in half the hourly rate that Hank will charge us...
Andyw2100
Well-Known Member
Yes, the fact that I'm suggesting an additional table is not in any way a criticism of HankLloydRight. What both of you have done is fantastic. I wouldn't be suggesting the table I'm suggesting if I thought I'd be the only person interested in it. (I would hope you would think more of me than that, dirk.) I really think that table would add to the overall usefulness of the data being collected. It will let people see a snapshot, at any time, of how many people with a given model have a given version of the software. And it will also let people see, historically, if a certain version was never pushed widely to certain models.
- - - Updated - - -
You want the table sideways
The difference isn't just sideways vs. vertical.
In Hank's most recent iteration, there still isn't a breakdown by version number and model number.
HankLloydRight
No Roads
dirkhh
Middle-aged Member
I was trying to be funny, not critical. I actually think that the table you are suggesting would be quite interesting to have...
Thanks for everyone reporting this morning! Please keep the entries coming. Is there really no one with a VIN in the 5xxxxx range who has received .153? That seems odd.
Andyw2100
Well-Known Member
I'm glad.
I guess I'm sensitive to that because I am so appreciative of what you both have done that the last thing I'd want is for either of you to think that I'm sitting around, "making demands" of Hank. The tool you two have come up with is going to really impact what people know about the updates as they are being delivered for a long time to come. So thanks again, to both of you!
HankLloydRight
No Roads
But your suggested table is not complete, since it leaves out the models with/without AutoPilot, which we know has been a factor in pushing the updates. So it would need more columns to account for each model with/without AP (as well as adding the new 70D models with and without AP). And then also gets more complicated when Model X and 3 are added too!
What I don't like about tables like that is that as the models change or are added, the table/code needs to frequently change to account for the additional columns/permutations. Things like "Models" and "Builds" which change and/or are added to frequently really should not be columns, but rather rows since rows can grow unbounded.. at some point adding those things as columns quickly becomes unwieldy.
The only table now where this is true is the VIN Range by Week table, but I only need to add one column to that for every 10,000 cars made, not every time Tesla comes out with new models or model permutations.
Because it's a little unwieldy either way, I added a table at the very bottom of the report with the data you desire, with build and model as rows. For more specific analysis, you can always export the dataset to do crosstabs/pivot tables in Excel, or use the "Search" field on the full data list to limit the table to a particular build (i.e. enter ".153" in the search box).. to see just those cars with that build version, and then you can sort/search on just that list for finer details.
Updates by Model/Build
| Build | Model | Trim | #Updates | #Cars | Auto Pilot | Non Auto Pilot |
|---|---|---|---|---|---|---|
| 2.4.124 | S | 60 | 5 | 5 | 3 | 2 |
| 2.4.124 | S | 85 | 18 | 18 | 16 | 2 |
| 2.4.124 | S | 85D | 9 | 9 | 9 | 0 |
| 2.4.124 | S | P85 | 8 | 8 | 5 | 3 |
| 2.4.124 | S | P85+ | 2 | 2 | 2 | 0 |
| 2.4.124 | S | P85D | 45 | 45 | 45 | 0 |
| 2.4.136 | S | 60 | 2 | 2 | 0 | 2 |
| 2.4.136 | S | 85 | 26 | 26 | 1 | 25 |
| 2.4.136 | S | P85 | 21 | 21 | 0 | 21 |
| 2.4.136 | S | P85+ | 3 | 3 | 0 | 3 |
| 2.4.136 | S | P85D | 3 | 3 | 3 | 0 |
| 2.4.153 | S | 60 | 3 | 3 | 0 | 3 |
| 2.4.153 | S | 85 | 6 | 6 | 0 | 6 |
| 2.4.153 | S | 85D | 6 | 6 | 6 | 0 |
| 2.4.153 | S | P85 | 7 | 7 | 1 | 6 |
| 2.4.153 | S | P85+ | 1 | 1 | 0 | 1 |
| 2.4.153 | S | P85D | 33 | 33 | 33 | 0 |
dirkhh
Middle-aged Member
ALL 'D' models have autopilot.
No 40 has autopilot (and I notice that we don't have a single 40 in the table).
Please take another look at the table Andy proposed. I really think it DOES give data that yours doesn't easily provide. And let's all hope that Tesla will continue to reach new 10k VIN milestones quicker than new models
HankLloydRight
No Roads
Just because there are exceptions doesn't mean they should be columns. It's just fewer. That doesn't change the fact that builds and models change frequently.
The data broken out by model/build is provided in the table at the bottom of the page, it just doesn't put models as columns.
HankLloydRight
No Roads
Also, you're a coder.. so you understand the difference between coding something general to take care of all cases present and future, or custom (hard) coding something to take care of specific cases.
In order to do the crosstab table (display models as columns), the SQL pseudo-code would have to be something like:
if the model='60' and autopilot do this..
else if the model='60' and not autopilot do this..
else if the model='85' and autopilot do this..
else if the model='85' and not autopilot do this..
else if the model='P85+' and not autopilot do this..
else if the model='P85+' and autopilot do this..
else if the model='85D' do this..
do this.. and so on for each/all models.
That's messy code to write and maintain as new models are added. There are better tools (like Excel Pivot Tables) to do things like that.
You can do crosstab queries in SQL, but that's even more messy with stored procedures that dynamically generate the custom SQL code. See: http://www.artfulsoftware.com/infotree/qrytip.php?id=523 .. and I'm definitely NOT doing that.
In order to do the crosstab table (display models as columns), the SQL pseudo-code would have to be something like:
if the model='60' and autopilot do this..
else if the model='60' and not autopilot do this..
else if the model='85' and autopilot do this..
else if the model='85' and not autopilot do this..
else if the model='P85+' and not autopilot do this..
else if the model='P85+' and autopilot do this..
else if the model='85D' do this..
do this.. and so on for each/all models.
That's messy code to write and maintain as new models are added. There are better tools (like Excel Pivot Tables) to do things like that.
You can do crosstab queries in SQL, but that's even more messy with stored procedures that dynamically generate the custom SQL code. See: http://www.artfulsoftware.com/infotree/qrytip.php?id=523 .. and I'm definitely NOT doing that.
Last edited:
dirkhh
Middle-aged Member
You do realize that it is considered unreasonable cruelty to make a geek say "you're right", right?
So let's say "I see your point".
And let's say that I don't know enough about how you create web services to have a good answer to this. In the framework that I tend to use this would be reasonably easy. You'd have a list of models and loop over them and then in an internal loop go over the versions and that way you could create the table quite easily.
But that's my tools and in my world. I repeat what I've said several times already. What we have is awesome and I really appreciate the amount of effort that you put into this and I think that we can already quite easily get a ton of very useful data from it. So don't read this as "I don't understand why you just do what you are told" - that's nowhere near what I'm trying to say, yet I know that posts like this could easily read this way. I simply liked the information that Andy's table seemed to make available at a glance. That's all.
BTW: I love this table:
Updates by Week/VIN Range
| Week# | Week ending | 0xxxx | 1xxxx | 2xxxx | 3xxxx | 4xxxx | 5xxxx | 6xxxx | 7xxxx | 8xxxx | 9xxxx |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 12 | 27-Mar-2015 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
| 13 | 4-Apr-2015 | 14 | 7 | 6 | 5 | 3 | 12 | 48 | 14 | 2 | 0 |
| 14 | 11-Apr-2015 | 6 | 1 | 6 | 2 | 6 | 3 | 31 | 11 | 2 | 0 |
| 15 | 14-Apr-2015 | 5 | 6 | 4 | 3 | 2 | 0 | 1 | 0 | 0 | 0 |
Andyw2100
Well-Known Member
Thanks very much.
I understand what you're getting at about the unwieldyness, and also the programming complexities. The above does let us see what I was looking for, though perhaps it makes patterns a little less easy to pick out. But it's certainly a good compromise.
I can see from the above, for example, that .136 did, in fact, basically exclude the P85Ds. I'm pretty sure I recall reading that the few P85D owners who received .136 received it while at service centers. It never went out as an OTA update. (I know I could confirm that using the tool.)
Thanks again!
MarcG
Active Member
The SC upgraded my P85D to .153 while it was getting checked yesterday.
I've tried to update the firmware tracker but it's not recognizing my PIN. Can someone please reset it for me? Thanks.
I've tried to update the firmware tracker but it's not recognizing my PIN. Can someone please reset it for me? Thanks.
HankLloydRight
No Roads
And therein lies the rub.
Database apps/coders don't like/do "loops." That's what the database engine is there to do for you. Loops are overrated.
That said, I'm working on something that will address the table display issue.
dirkhh
Middle-aged Member
PM HankLloydRight - he made the very wise decision not to ask for / track email addresses. This eases many people's privacy concerns, less overhead, etc. But it means no way to send you a password reset link.
So the price for improving all of our privacy is that Hank needs to do these resets manually.
Yet one more thing that I appreciate about his work on this tool.
Kalud
Active Member
HankLloydRight
No Roads
Similar threads
