there are some limited settings that could be persisted. There are actually two (three, but third is only for dev cars) sets, some ap-related stuff in ap firmwares, some ap related stuff on infotainment most of which (but not all) you can control in the settings UI.
And then there are maps. I was exploring mapping recently and discovered that not only Tesla has those pretty frequent incremental updates, but when you have a route set - it asks the mothership and receives a route outline with very detailed info including where various intersections, crosswalks, stop signs, traffic control devices, speed limits, lanes, ... are. Every time you use "navigate to" function (and a bunch of that data is fleet-collected). As you can imagine updates in that sort of thing can have big impact on performance of AP without any code changes.
Thanks for that great information. What you just described about maps - route-specific data that is downloaded in near real time - is potentially very significant, and fairly surprising (to me) in a number of ways:
First, because most users agree that a great number of today's FSD foibles seem to stem from mapping errors or inadequacies.
Second, because the map database and updates have been kind of mysterious and often are assumed to be chronically out of date.
Third, because there's always a background debate smoldering here, about Tesla's supposed lack of interest or dependence on detailed maps for its real time driving performance.
Fourth, because I for one had assumed that drive-time data connectivity was basically irrelevant to Tesla driving operations, things like media streaming voice command processing, data collection uploads and so on are all things that don't really affect actual driving, so lack of connectivity is a temporary inconvenience.
But what you just revealed is something that could make a real difference in FSD capability, depending on whether the data connection is available. It begs a few further questions (answers for which may be unknown now, but if you have any insight please comment):
- Is this drive time server download a new thing, or something that has been added recently? Is it applicable only to FSD beta, or has it been around for legacy NoA as well?
- What happens if the call to the Mothership server fails during the route planning or route execution? Is there a timeout, or does it keep trying as the drive proceeds along the route? Upon failure, does the information devolve to the in-car stored map database (with presumably coarser and/or very stale information), or does it remember data from the most recent drive on or near that route?
- Do you think this map details feature will be an integral enabler of things like parking lot mapping for Actual Smart Summon and presumably required robotaxi pickup/dropoff operation?
Finally, is it your sense that this discovered capability is indeed highly significant for the upcoming development of FSD, or am I extrapolating too far from what you explained? Thanks so much for whatever additional commentary you can provide.
