First off,
@tps5352 - Thanks for linking some amazing threads with a ton of good information - especially the summaries which were very helpful. This reply is going to be long, but I've been closely monitoring my updates (and taking notes) since purchasing my first Tesla 9/29/2023 and have made sense of a lot of things (and even more after reading some of those threads). I also have significant personal experience running similar hardware/software platforms so you'll see some additional thoughts added from my experience. If you don't want to read the whole thing, just look for a bolded section of interest.
Observations, Speculation and Commentary:
- The 'break-in' period seems real. It took me exactly two months (on the 'standard' software update setting) to get my first software update. (2023.32.100/11.4.4 to 2023.38.9/11.4.4). And I when I say exactly, note that I say 'months' and not 'days' and that time also appears to matter. I took delivery official delivery of my vehicle on 9/29/23 at 1804 (signed off after inspection, vehicle then showed up in my app). My first software update was available 11/29/23 at 1928.
- Those 'break-in' period builds ('new car builds'?) appear to be numbered .100 (and .200, .300, etc.) and combined with these build process details from NotATeslaApp as well as using his software update history (specifically, the first available date on each), make a lot of sense. When I took delivery, the .32 build family was the latest available. Those .100+ builds are likely just equivalent to another stable .32 build (2023.32.6 for instance) but tagged (copied) to a very high build number so as to prevent updates. As newer stable builds are found in one of those build families, a new 'new car build' is tagged and made available for new vehicles (.200, .300, etc.) likely also dependent on model/region. Once you reach the end of your break-in period, you join the regular software update cycle (the non .100, etc. builds) and then all of the other things that matter take hold (region, model, hardware platform, etc.) as has already been described.
- "The standard/advance toggle is a placebo" - I don't believe this is true.. at least, not always true. It's common to want (need) customers willing to be first (on 'advanced'). That doesn't mean they are always first. I have similar customers for a platform I run (which has a similar build/release process as Tesla) and when things are running on our normal cadence, the 'advanced' customers get what everyone else gets at the same time. But when I have a deadline, (a holiday update has to come in time for the holidays, right?), I sometimes have to put software out the door before it's fully tested...or maybe I've fully tested it but I need more people to help test in situations that I'm not able to test in... and that's when I tap into these customers willing to be first. They get it first, we check for crashes/problems/etc., if issues are found, we fix them quickly (as quickly as an hour), give them a new build, rinse and repeat. Only after we see stability do we then gate it to the rest of the customer population (on 'standard'). I've received 3 builds in the last 11 days on 'Advanced' - the latest one (2023.44.30.7) literally as I type this reply. It's also interesting that different builds to the same models with the same hardware platform in the same region are in-flight at the same time and this toggle could also have something to do with that. Also of note, this is how things work for iOS and Android these days as well. When new mobile software builds for phones are ready to 'publish', almost all developers use the App Store Connect and Google Play Store functionality for developers to slow-roll the new build so they have time to check firebase crashlytics (or similar) for problems only doing a full rollout when a time period has expired or when manually overridden when things are looking good.
- The 24hr software update period doesn't mean much. I agree. Multiple times now, I have been within the window (after manually checking) and have had an update become available that wasn't when I checked less than 24 hours prior. Read below for how close proximity to the vehicle may also be involved.
- On versions 'disappearing' - When an issue is found, and depending on the criticality of the issue, a software rollout can be stopped even though I would say this is fairly uncommon for a modern product development team (because quality checks and automated testing largely prevent this). There are threads with some pretty severe issues this time around with the holiday update and I'm willing to bet Tesla had to stop rollouts as a result - quite possibly, multiple times.
- Does rebooting help get an update faster? On one occasion, it might have for me (2023.44.1/11.4.4) - No notifications, no nothing. I had not checked within a 24hr update window. Did a double steering wheel button hold (no brake pedal), rebooted, went to the software update screen, had an update. What isn't clear is whether checking the software update first would have yielded the same result. I have this case open for future testing.
- Does Tesla rollout by VIN? One comment said that two Teslas purchased ~month apart always update in the same order. This makes tons of sense. Most modern device management systems (whether home grown or developed off of many of the base platforms available) do things based on batches of serial numbers. Tesla uses the VINs for everything and any amount of batching of vehicles, at least within a model/region/hardware platform, and almost certainly excepting those in the 'break-in period', is likely done by batches of VINs. This might materialize in a console where someone at Tesla chooses a % of a fleet to roll a version to...but the system still has to decide which ones get it next and I doubt based on my update history that this is random.
Proximity to your vehicle matters for updates? Finally, I do have one new item to contribute. I believe in addition to other things mentioned (car having woken up, being on wifi, and having a build available), I also now believe a vehicle owner's phone running the Tesla App must be close to their vehicle for the update to be made available. I define close as within ~10ft, with the App running (in the background is fine - and on iOS at least, even without 'Always' location access). I doubt this matters for most people because they just drive their Teslas and are often close to them..but if no driver is near your tesla and you are trying to get the latest update, it might matter. I'm betting this is an attempt to prevent a software update from being authorized by someone who is not close to the vehicle (which might prevent the next driver of the vehicle from being able to drive it until the software update was completed).
Way more detail in case anyone's curious:
I've been testing trying to get 2023.44.30.7 (I've been on .6 since 12/22/23). My 24hr update time was 11:13pm and I checked it last night before going to bed - no update available. I woke up this morning and was just lying in bed reading TMC posts, opened up the app, no software updates popped up. While in bed, and generally moving around upstairs in my home, my phone is close enough to the vehicle to maintain the phone key connection but bluetooth RSSI is weak (~ -87 to -92dB). I walked downstairs, and when I reached the bottom of the stairs, which is very close to the vehicle (on the other side of the wall in the garage - ~ -72dB RSSI), I received a push notification that a software update was available. Opened the app, there was the update, started the install. Future testing will tell for sure.
FWIW, these RSSI numbers are not arbitrary. I actually tested and measured RSSI at different physical spots in relation to the vehicle based on the bluetooth device (the 'key' under bluetooth) and its connection (I did not go deeper to identify the UUID of which bluetooth device was transmitting since there are multiple on each vehicle). The iOS app uses the Core Location framework for bluetooth ranging and region monitoring and the FCC limits BLE transmission from the vehicle to no more frequently than every 100ms... and given what iOS permits in their public APIs, that means with the app in the background (in your pocket) without 'always' location access, it does take many seconds to understand the RSSI of a known bluetooth device. This is the reason that if you haven't granted 'always' location access, and your phone has been in your pocket, and you walk up to your vehicle, it sometimes won't open for you immediately. It's also the reason that a few Tesla app updates ago, they added the 'Improve Phone Key' option on iOS with directions to enable 'always' for location permissions as with this permission, the App is granted permission for region monitoring even when the app is in the background (in your pocket).
For kicks, I also went and started surfing some of Tesla's FCC filings. For all of the hardware they build that uses bluetooth, UWB and NFC, they need type certification - governed by the FCC in the US. You can lookup the devices at
fcc.gov here. Tesla's Grantee Code is 2AEIM. The first result happens to be a B pillar Bluetooth / UWB endpoint. They've invoked the confidentiality clause on the internal photos which will keep them suppressed for 6 months but you can read the docs and test results. I plan on some digging when I have some time...
