What do you mean? It sends you a push notification and shows an alert on the settings panel in the car whenever an update is available.
If I read the posts from @Jordan correctly, the problems described were attributed to the car not being able to successfully complete the update.
That is my impression, and also first hand experience with one of the updates, 2.0.15. Not the same errors, but quite a few =)If I read the posts from @Jordan correctly, the problems described were attributed to the car not being able to successfully complete the update.
Am I off base?
P.S.
I'm supposed to take delivery tomorrow. So this is the last chance to back out
If I read the posts from @Jordan correctly, the problems described were attributed to the car not being able to successfully complete the update.
Am I off base?
P.S.
I'm supposed to take delivery tomorrow. So this is the last chance to back out
Thanks.
That is a great description of a failure of basics for updating software... it is really quite old hat (basic OTA update 101) to have something (as simple as a parts list and check sum(s)) on an update to insure that it all has arrived in one piece. That this software system can "update" with a damaged update in hand is appalling (and scary AF). Poor cell service is a given in the world, it is not an excuse for a failed update.... rather it is a description of a failure of basics.
The system could well have downloaded and checksummed everything, but some other factor prevented a successful update. I wonder if there is a checkpointing process involved so the car could revert to "last known good".
Beat me to responding the same. Under specific circumstances (which I have no idea what they are), it does appear the system is capable of reverting. @Alex reported a long time ago that an update failed, car would not respond and an hour (maybe more) later, the software showed it was back to previous level and car was working again. Given the scenario @Jordan reported and that it might have happened to @hydbob too, Lucid will need to build a check routine for left/right synchronicity.
If it was validating the update before attempting to apply it then the description of this failed update would not have been as written... whatever the technology is to validate the update before application, the problem write up indicates that the update failed due to the update having been corrupted in some manner. This is "not good".
I agree this is not an optimal situation. We all know the software architecture was more than problematic at launch. And then the immediate priority was to get 2.0 out the door.
We're all just guessing from what was a recounting of what a tech explained to a customer in condensed form and the customer paraphrasing it back to us. We don't know if the update has separate left/right modules or 1 module is applied to both. From a fix perspective, I am not going to assume I can just apply whatever patches were in the current update. I am going to install the entire module(s) in question from my source library to be safe. We can guess all we want (which a lot of us like doing) but without talking to the engineering team, we don't know.
That's not how cell or wifi communications work. While you can build an unreliable data channel, you would have to work harder at doing so than you do to use the reliable data channel option that exists (and we have been told that the car is based upon tech such as Android, so that reliable channel's availability can be assumed a given). An example is this very forum: HTTP over TCP, highly reliable data communications (as opposed to running a UDP conversation, which is designed to provide a less reliable channel in exchange for other positive characteristics)... both a reliable TCP and an unreliable UDP are options over a cell or wifi physical network (this tech was designed in the 60s & 70s for battlefield operations after all). The signal strength has no effect on the ability to provide a channel (such as TCP) that can perform reliable communications (i.e. the data is either transferred correctly, or it is not transferred at all... corruption is not really a risk when the reliable channel is chosen). While other physical layers could have issues (and I have some interesting stories from my time in the 80s & 90s doing networking to tell on that front), they are not the ones in play here. This car is nothing but a "big phone" in this sense... it is capable of using both cell and wifi signals to provide the physical layer for its communications. While it is possible that Lucid has implemented a UDP (or similar unreliable) data channel based update system, that would be much more work than doing so based upon (reliable) TCP communications... which brings us right back to the sense that if this OTA update system is subject to this class of failures, then we (as customers) have a big problem.
I don't think it is particularly productive to speculate on the meaning and consequences of technical information relayed back (and mangled) through several layers of non-technical personnel. Lucid has software engineers; if there is a systemic problem they'll figure it out.
yikes. sounds like he's misinformed or he's communicating it poorly.
Sorry for my speculations.Disregard if it's nonsense. I think Lucid service knows that they are talking about; perhaps I dont.
I wish it were.
