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

Firmware 8.0

This site may earn commission on affiliate links.
how high on the priority list was this "more precise fan speed" that it took precedence over auto wiper and auto high beams?
Sorry to hear of your irking but climate control is not only comfort but survival for some of us. Not that this one affects me much, I'm still waiting for Auto to keep my feet warm in the cold winter months...

Now if only we can get this addressed:
My feet are freezing!
 
Last edited:
  • Like
Reactions: 3s-a-charm
This is what irks me with Tesla - how high on the priority list was this "more precise fan speed" that it took precedence over auto wiper and auto high beams?

I highly doubt a limited rollout of lifting recirculate fan speed restrictions is delaying the computer vision models for rain / dusk / night conditions auto wipers and high beams need.

(To be honest, though, it seems like a huge mistake Tesla didn't just throw on the old remedial rain/light sensors at least as a stopgap. They can't even blame MobilEye for that)
 
  • Like
Reactions: disagree and _jal_
I own a model s 60 AP2. It was in for service so I got to drive an AP1 car. It was interesting to note that AP1 recognizes trucks and cars in adjacent lanes and shows them on the dash. My AP 2.0 display only shows cars and only in my lane

Nick I have an AP1 ModelS and initially as the system was turned on, I saw only vehicles in my lane as I recall. Trucks and motor cycles were not initially distinct either. Whether that was by design or a correction process is something Elon has not called me about yet.
 
  • Funny
Reactions: henderrj
My AP1 most often will recognize a motorcycle or bicycle and display it as a motorcycle... however, vans are shown as cars but only very rarely as a truck.

It does now, yes. But that was a late addition to AP - in 7.1 I believe? For the first several months of Autosteer everything was just a car, and it seems likely Tesla is taking the same phased approach on HW2 cars.
 
It does now, yes. But that was a late addition to AP - in 7.1 I believe? For the first several months of Autosteer everything was just a car, and it seems likely Tesla is taking the same phased approach on HW2 cars.

And that kind of makes sense. In the list of things I want to see improved with my car, having it change the little doodad it shows on the dash to match what kind of vehicle it is is pretty close to the bottom.
 
There is a flag for the nose and I know the avatar in our cars use certain flags (I've had mine changed, for instance, to include the spoiler), but I am unsure if the flag for the nose is used by other processes such as firmware component selection filters. I doubt it is designed this way, but it could be that have a refreshed flag include the firmware variations for the extra sensor pucks in the wheel well of AutoPilot since every Tesla-build refresh car has the AutoPilot hardware. You wouldn't want a parking sensor only or no parking sensor car complaining that those two wheel well pucks are not responding.

Again, I am NOT saying this would happen and I would hope Tesla designed the firmware filters and avatars as separate flags, but we just don't know.

They aren't talking about the little image of the Tesla in the autopilot display not matching the car (WRT nosecone, spoiler, whatever). They are talking about how autopilot displays the traffic around you. When initially rolled out, AP1 cars displayed all traffic around them as little cars, whether the vehicle detected was a car, truck or motorcycle. About 6-9 months after AP1 went live, there was a software update and the images displayed on the screen would show other vehicles as a car, motorcycle or truck. At present, AP2 cars display the traffic around them only as cars (sedans) and do not show motorcycles and trucks as anything but cars.
 
They aren't talking about the little image of the Tesla in the autopilot display not matching the car (WRT nosecone, spoiler, whatever). They are talking about how autopilot displays the traffic around you. When initially rolled out, AP1 cars displayed all traffic around them as little cars, whether the vehicle detected was a car, truck or motorcycle. About 6-9 months after AP1 went live, there was a software update and the images displayed on the screen would show other vehicles as a car, motorcycle or truck. At present, AP2 cars display the traffic around them only as cars (sedans) and do not show motorcycles and trucks as anything but cars.

I don't know how this happened. That post was a reply to this in a different thread. Odd?!?

I read somewhere in the forum that the SC changed car image (color & red brake calipers) on an owners car while getting service. Maybe this was a top-notch service person & maybe not all will do it but he/she posted a photo of it maybe as long as a year ago.

Back in 2014 when I switched to black aftermarket TSP Sportline wheels, I asked my service center, and they were able to switch the wheel colors on the touchscreen. I am not sure if they have a option on the nose cone/front design. Worth a shot at asking them.

There is a flag for the nose and I know the avatar in our cars use certain flags (I've had mine changed, for instance, to include the spoiler), but I am unsure if the flag for the nose is used by other processes such as firmware component selection filters. I doubt it is designed this way, but it could be that have a refreshed flag include the firmware variations for the extra sensor pucks in the wheel well of AutoPilot since every Tesla-build refresh car has the AutoPilot hardware. You wouldn't want a parking sensor only or no parking sensor car complaining that those two wheel well pucks are not responding.

Again, I am NOT saying this would happen and I would hope Tesla designed the firmware filters and avatars as separate flags, but we just don't know.

Instructions for facelift bumper/fascia installation on nosecone Model S
 
Something to keep in mind about the order in which features appear is that software development is somewhat a hodgepodge. Writing Item A might also give you 80% of Item Y and since you're in that bit of code already then completing Item Y at the same time makes a lot of sense. Then while working on Item B you also do 95% of Item M and 90% of Item S so you do S&M then as well. Item C is expected to take 30,000 hrs of coding while D, E, and F can all be done in 8,000 and that 8,000 all contributes to C so DEF get done, tested, and rolled out and then Item C built on top of them. Then someone realizes that all of the back-end for Item Q was built in all of these previous things and all that's needed to roll it out is a quick bit of UI and QA so Q gets done.

Much to the chagrin of sales & marketing, I developed stuff largely based on my schedule, not theirs. I was a strong believer in short-term deliverables. Typically no project was more than 3 months (and that was a functional deliverable) and then all of these little functional projects added up to a big app. Fairly consistently the shorter the delivery timeframe the greater likelihood of something being on time. Teams would usually complete a 2-3 month project on time while 4 month projects would be a couple of weeks late and 6 month projects would be 2 months late. They didn't like the order I did things but they never complained that we remained ahead of the competition.

Tesla are developing stuff at a breakneck pace and accomplishing a lot. My hats off to them for what they're able to accomplish.
 
Last edited:
Re: "...so you do S&M then as well."

Yes, waiting for long-promised features does feel like that sometimes.

I've had lots of experience in systems development, but in my case errors in the delivered product could not result in people dying. I would imagine that such life-or-death code needs to be integrated and tested somewhat more systematically rather than opportunistically.
 
I've had lots of experience in systems development, but in my case errors in the delivered product could not result in people dying. I would imagine that such life-or-death code needs to be integrated and tested somewhat more systematically rather than opportunistically.
Tested / QA more systematically, yes. Code written to higher level specs for safety, yes. But order of development will still often follow what is practical for coders rather than only what marketing wants. If a code team says that they've already done all of the other bits for the fan speed (that's way down on the marketing priority list) and can finish it up with a few hours UI work then they'll likely be given the green light. Especially if going back to it later will take a lot longer for people to get their heads back in to the code.
 
Ok, this might sound crazy, though bear with me:
First time using supercharger since installing 17.6.15 FW.

Back up as normal, get out of car to charge and grab handle. Move handle toward charge port and think "oh, I must have pressed the button to open charge port door already". Half asleep I don't think anything unusual.

Coming back at night, same thing. This time I am convinced I did not press the supercharger handle button to open charge port.

Has this firmware version gotten smarter with recognizing I'm at supercharge and unlocking port upon arrival? Anyone else noticed this? It was 5am and 9pm at Centralia, WA

Seriously want to test again, though Seattle is pretty much equally distant from any supercharger... sigh Washington ;-)