Hacker News new | past | comments | ask | show | jobs | submit login

But that's not what happened.

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...

Tesla responded,

> 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.

I think gatherhunter hit it dead on. It’s metrics thing and they wanted to close tickets. I sincerely doubt the FW update they pushed had anything to do with the issue being resolved. It is common practice (according to Tesla forums) to push FW before a service appointment just to be sure the car has the latest version before it goes in.

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?

Presumably they know more about the root cause through looking at the logs. It would be so great if they could be more transparent about it.

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.

>left the cameras disconnected... AP worked but degraded

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.

Yeah I unbuckled once while AP was active to try to take off my coat and the car lost its shit on me. Red flashing alarms like, “WTF you doing?!”

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact