this post was submitted on 24 Jun 2024
205 points (98.6% liked)
RealTesla
477 readers
1 users here now
- Posts must be about Tesla, EV, or AV
- Meta Posts must be pre-approved.
- Shitposts are limited
- No Elon Worship
- All Links must include the original title of the Content
- Sites behind Paywalls must have text included.
- Don't be an asshole
- No Image Posts
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This story has been bouncing around for a couple days.
Lots of people were saying the reason this happened was the "cheetah launch" system that doesn't do much except warm the battery and lower the suspension...
Which, all that is fine.
The issue is to initiate it you hold the brakes and then floor it.
A glitch may be causing that juvenile and unnecessary feature to halfway activate while driving.
What I'm interested in is this is at least the third different story of an issue happening right at 4 hours after driving. I'm wondering if its so buggy that it can't run that long continuously, it sounds like there was a complete lack of long term testing, consumers might be the first one to run these for that long straight
Making the consumers pay to do beta testing. That's the sort of nonsense we get with AAA games, so I guess it fits the narrative of "Tesla as tech company, not car company" that Musk was going on about a couple months ago.
4 hours sounds familiar. I used to work in network engineering and polled equipment via SNMP for statistics. Some counters were measured at high resolutions that would hit their max after just a few hours of runtime.
Take an unsigned 32-bit integer or
uint32_t. It has a maximum value of4,294,967,295. That may seem like a lot, but if you had an FPGA that took measurements and provided a timestamp as ticks since boot for each message it sends back, you’d hit the maximum value after just a few hours.For example, imagine that they had a low-power FPGA running at 1MHz which increases the tick counter on every cycle. This would cause the counter to increase by 1,000,000 every second. You’d hit the max in just under 4,295 seconds, or roughly 71 minutes. To get closer to 4 hours we’d reduce the frequency by 4 to get 250KHz.
All of this is speculative. Could be that it’s not from a value failing to update but just a divide-by-zero error somewhere. Interested to see what the public is able to uncover as the core problem.
I'd be a lot easier for the public to do that if the code were open-source -- you know, so that the property owner could control their own property, as they have every right to be able to to do.
I don’t disagree with you. There should be a level of inspection possible by an owner on the functions and processes running, especially if they will be held liable for any outcomes from operating failures that cannot be attributed to the driver.
In other words, if my insurance covers an accident but I can be sued in civil court for additional damages then I should be able to update/fix/review everything in it given that all liability is transferred to me upon sale. If I cannot answer to something because it’s deemed “proprietary” and “property” of the manufacturer, then they should not be allowed to transfer that liability to me.
Transferring liability for Tesla Involved Accidents back to Tesla sounds like an absolutely fantastic idea. They should definitely be on the hook for stuff like this, if they aren't already.