nemosaltat didn't provide a complete chronology, but did say they had a service appointment on 4-13, received a FW update on 4/4, and a rep contacted them on 4/5 saying they reviewed the logs and the new FW fixed the issue.
Then nemosaltat responded to Tesla;
> Ok- I’d still like to understand what happened....It’s significantly less understandable, that the issue mysteriously resolves it self...
> It was found to be a software bug in the last update that was performed causing your cruise control not to function. That was resolved in the last update you performed.
> The issue returned yesterday (5-13) and now the earliest appointment is mid June.
So the issue was fixed, and then it returned. It's unfortunate but hardly sketchy.
The sketchy part for me is the inconsistency between the Service Tech and the rep who canceled the appointment. The tech (HW flaw) was very convincing, and the rep (SW flaw) was very vague. The functionality did not return immediately after the FW update, and I think the timing may have been coincidental. It’s even more frustrating that they weren’t/aren’t the least bit apologetic or accommodating. I can’t seem to get a straight answer on why basic cruise can’t be restored via a FW patch while I wait for my appointment. Is the same hardware/software required for Cruise on Model 3s without NoAP and FSD?
On the surface it doesn’t make sense that a FW issue would be causing an issue with your TM3. What about the other ~200,000 cars on the road?
But to answer your last question, yes, it’s layers of incremental software functionality on the same hardware stack. Without knowing at which point it’s failing it’s hard to say if cruise could be enabled without AP.
As a point of comparison, I had my TM3 wrapped in protective film. As part of that process they removed trim including the side cameras to lay the film flat with fewer cuts. The shop (not Tesla affiliated) left the side cameras disconnected. Upon starting the car it reported an issue with side cameras. AP worked but degraded — wouldn’t change lanes, and cruise still worked fine. Some some hardware faults do not fully disable the feature.
That’s very interesting, and closer to what I would expect.
The newest development, when I drove in this morning, the Service Tech said it’s a seatbelt sensor malfunction.
There is a “driver seat buckled” interlock for cruise control, but the alert for that explains the reason. I’m just getting “cruise not available” with no explanation.
I think that service tech was grasping at straws, unless he actually examined the logs and saw it written there. If it was the seat belt, wouldn’t you see it indicated on the display that the seat belt was unbuckled? It displays the unbuckled indicator for all seats that have occupants detected (weight sensor).
Presumably the logs will contain the exact reason it fails? Next time they text you maybe ask if they can tell you exactly what the log file says when AP engagement fails.