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

FSD Beta 10.69

This site may earn commission on affiliate links.
Interesting.

So, it could be that a subset of the Grumpy-The-FSDb-Can't-Do-Anything-Right could be suffering from the effects of a malfunctioning computer. bhakan had issues with nags and FSD strikes that seem, now, to have cleared. And, while I've had the occasional nag, it was nothing like what he was complaining about.

Note that whatever self-diagnostics run on the computer that was replaced, it wasn't good enough to catch a bad comp. And that could imply that there might be other malfunctioning computers that have different things wrong in there. Which might explain, well, some (but I'm sure, not all) of the complaints around here.

Hmm.. I'm a getting to be retired these days, but, when I was designing hardware for telecom, for that hardware we had factory diagnostics, out of service diagnostics, in-service diagnostics, and background diagnostics. The general idea was kind of like that bit about a tree falling in the woods: If there was a failure, one should be able to catch it.

As time went on I've run into systems where, well, there might be an error bit somewhere that wasn't monitored by software; in fact, given the push to get hardware out the door, there might be a lot of those error bits. Usually the logic is that if something does go bad on Device A, it would very likely make Device B fail in an obvious way. Hence, if Device B failures are what you monitor, then, in principle, one doesn't have to monitor Device A. Which is nice when it works and saves development time. But only works well when it's failures that one knows about. (As compared to the unexpected ones that one doesn't.)

And I don't want to get into the area where hardware designers don't even put diagnostic hardware into the design. Silent failures, anybody?

As if we don't have enough trouble getting things to work right. Hmm...
Prior to the swap some of those software updates helped to some extent. I don't deny that. But, it is very refreshing and less stressful drives and the fact that I can drive at nights without any worry of getting a strike is priceless!
 
  • Like
Reactions: FSDtester#1
An "employee" vehicle that previously was the first to install 10.69.25 on December 19th before most of us now is pending an update to 2022.44.30.10:

2022.44.30.10.png


Maybe it's 10.69.25.2 or FSD Beta 11.x updated to the latest release version (previously spotted as 2022.44.25.20 on the older branch)?
 
For more background context that we discussed before that tweet, across TeslaFi and Teslascope, there seems to be 3 groups of "employee" updates for FSD Beta recently:
  1. Teslascope originally spotted FSD Beta 11 on 11/11 at 11:11pm as 2022.40.5 but this employee has since deleted the account
  2. TeslaFi had an employee receive what seems to be 11.2 on Christmas Day with 2022.44.25.20 and does not have any newer updates
  3. Both TeslaFi's 1-other and Teslascope's 3 employee vehicles received this new FSD Beta as 2022.44.30.10 last night
Teslascope allows vehicles to hide their vehicle software status, so that's why its website doesn't show a page for 2022.44.30.10. But those 3 vehicles in addition to the TeslaFi employee vehicle that didn't get 11.x were all on 10.69.25/.1 when getting this newest version. That's why we're leaning more towards it being 10.69.25.2 while watching for the TeslaFi vehicle with 11.x to get an update. (There was another TeslaFi employee 2022 Y Long Range vehicle based in California but it has since deleted/deactivated the account.)
 
Note that whatever self-diagnostics run on the computer that was replaced, it wasn't good enough to catch a bad comp.
Peripheral hardware can be beyond the scope of software diagnostics. I recently had to replace an iPhone due to inoperative near field communication ( i.e. no apple-pay scanning ) which passed all the diagnostics but wouldn't scan anything. Perhaps a disconnected antenna? Who knows. Out of warranty repair was more costly than a replacement phone, sigh.

My Model 3 had an intermittent false frunk open indication. Tesla's first failed "fix" was telling me to wait for the next software revision which didn't help. Next, mobile service accidentally bricked the car while replacing some grounding screws inside the front body controller (FBC). They then mis-diagnosed the problem cause many times over 6 months. Eventually they replaced everything between the main cpu and the hood: the FBC, the wire harness, a grounding strap, the latch assembly. This finally made the problem go away, but they never did find the cause. But no amount of internal diagnostics was going to find an intermittent open in a micro-switch, or noise in the circuit, or whatever the real cause was. Dozens of other owners reported the same problem.

I recently read a thread about a strange noise affecting a number of 2022 3's and Y's. Tesla has replaced a few front drive units, but in other cases claims it is within specs. Unpublished specs, of course.

Tesla service is not exactly with the program of chasing these failures down to find root causes. This means they will continue to infuriate customers with all sorts of minor failures. Toyota has a Kaizen process, Japanese for improvement, and dubed it "The Toyota Way". Working from "first principles" as Elon claims to, it is not hard to see the importance of nailing down every failure mode.
 
About time. I just installed 25.1 on my car yesterday ;)
Approximately two weeks time you might say from the time others were getting the update? 😉 I wonder if the "automatic" strike / suspension reset wasn't actually implemented in 10.69.25.1 and needed a future update to clear it.

(Side note, did you end up checking the Software settings screen to get the update or you saw it in the app?)
 
If so it's curious they are spending resources fixing the 69 path when V11 is apparently so good and its release imminent. Path 69 remains hospice appropriate.

I assume it’s the same code in the end, so not really any lost effort. Just get to merge things later.

Everything the same except for the different stuff.

Makes sense if you have no idea when v11 will be good enough but you want to be ready and not playing regression whack-a-mole.
 
If so it's curious they are spending resources fixing the 69 path when V11 is apparently so good and its release imminent. Path 69 remains hospice appropriate.
You always have to make fixes on the current wide release. Probably different folks working on 69 & v11.

I mean most companies have multiple versions on the market simultaneously and you stop the support only years later ...
 
I assume it’s the same code in the end, so not really any lost effort. Just get to merge things later.

Everything the same except for the different stuff.

Makes sense if you have no idea when v11 will be good enough but you want to be ready and not playing regression whack-a-mole.
I vote this for the “Line of the Day”
 
I vote this for the “Line of the Day”
Really just saying is that it’s possible that the effort being put in can be merged later.

Especially possible if v11 is not really “single stack.” (I don’t expect it will be actually single stack. Obviously just a guess on my part but seems entirely possible based on what we are hearing about it.)

Can tune up City Streets separately from the freeways, etc. - which makes a lot of sense anyway. Presumably will be a lot of commonality though.

Will still be single stack, meaning a single stack at a time.

😜
 
Last edited:
  • Funny
Reactions: FSDtester#1
You always have to make fixes on the current wide release. Probably different folks working on 69 & v11.

I mean most companies have multiple versions on the market simultaneously and you stop the support only years later ...
Changes may be to things other than just FSDb or to code that is common to 10.69 and 11.x. Improvements to defeat device detection, or any number of MCU updates, for example. Of course, it may be a while before 11.x goes really wide...
 
Last example of my benchmark run on this release. Not doing any more after this - the picture is clear!

I see improvements (maybe) in positioning at the ULT. “Maybe” because I need to do a few more tries to see if it really is setting up slightly more to the right.

The stopping for lights and stopped traffic continues to be a massive disaster as we all know. At least that is easy to fix!

One safety intervention - apply accelerator to roll through the right turn with no stop sign, one safety disengagement on ULT due to lack of speed and slowness to turn, three comfort disengagements (all the standard inability to stop smoothly), and a comfort intervention to get through on the yellow (plenty of margin, though it was a close call - notice how much better my reaction time was compared to FSD, though - I had plenty of time to exclaim before FSD braking began, beating FSD by a half second at least - this was a “maintain 50mph” scenario, for sure, entering on yellow).


Total of six in five minutes.
 
Last edited:
  • Helpful
Reactions: FSDtester#1