Software update 2.3.0

I just got 2.3.3 pushed to me. Note that I’ve had issues with the blind spot cameras after the 2.3.0 update. I’ll get back to the thread once 2.3.3 is installed and update if the issues have been fixed.
 
Were they specifically able to look it up for you or was it a general comment? What trim and options are you running? And I wonder if that plays a role?
I supplied my VIN from the outset of the conversation. Whether they referenced that information, and how accurate the information is, I don't know, however, I notice they specified "2 to 3 weeks," rather than "up to 3 weeks," so my guess is that the CC rep did take a moment to check the VIN. It's a GT with SSPro/DDPro
 
it's great that they are pushing 2.3.3. I contacted customer care yesterday as I hadn't gotten 2.3.0 pushed and they said the roll out was on hold and would start batch rolling out the update this week
 
We had the update installed on Friday and experienced the following. On 2 occasions the car has behaved in an unexpected and concerning way as follows: 1) backing up out of the garage and 2) backing into a driveway the car sensed, incorrectly, an object in the way and instantly applied the brakes with dashboard warnings and alerts. It was rather startling to say the least.
I'm curious if anyone has experienced this behavior? It seems to me that the 'Rear Parking Protection' is the culprit and overly sensitive to what's around the back of the car.
Yes, I've got this issue as well. I'm now getting a double brake situation where before the update I was only getting one. Now when I reverse into my garage I still here the "ding, ding, ding" sound with the brakes applied and on top of that I get this new "rear parking protection" message with brakes applied as well. The sensors are really sensitive it seems because even looking at the screen the little waves that are around the car are typically yellow\orange, not red. Yet, it still slams on the brakes whilst in yellow\orange
 
The reason this interests me (impatience aside) is that I'm also a software developer by trade. Version checking upon startup for network-connected application is very common. What is LESS common is throttling the updates across your user base. Typically, when a new version (beta channels notwithstanding) becomes available, the software phones home to see if there is a new version available, and if so, prompts the user to see if they want to upgrade there and then.

I'm trying to understand the rationale of limiting the rollout. I'm sure there IS a reason for it, and that it goes beyond simple server bandwidth limitations given modern day hosting options and the relatively low number of deployed vehicles.

Anyone know what it is they're trying to achieve with the throttled release schedule?
 
The reason this interests me (impatience aside) is that I'm also a software developer by trade. Version checking upon startup for network-connected application is very common. What is LESS common is throttling the updates across your user base. Typically, when a new version (beta channels notwithstanding) becomes available, the software phones home to see if there is a new version available, and if so, prompts the user to see if they want to upgrade there and then.

I'm trying to understand the rationale of limiting the rollout. I'm sure there IS a reason for it, and that it goes beyond simple server bandwidth limitations given modern day hosting options and the relatively low number of deployed vehicles.

Anyone know what it is they're trying to achieve with the throttled release schedule?
Wasn't this answered earlier in the thread? Staggered release is common because it means if a bug sneaks through QA, it may impact 1% of customers before being reported rather than 100%. That's 1% of customers that may have to get special service for something broken by software, rather than an unmanageable 100%. Even our smartphones do this. When a new iOS release comes out, everybody doesn't get it at once. Apple has had bugs sneak through QA as well, and they were able to stop the rollout before affecting millions of people.
 
The reason this interests me (impatience aside) is that I'm also a software developer by trade. Version checking upon startup for network-connected application is very common. What is LESS common is throttling the updates across your user base. Typically, when a new version (beta channels notwithstanding) becomes available, the software phones home to see if there is a new version available, and if so, prompts the user to see if they want to upgrade there and then.

I'm trying to understand the rationale of limiting the rollout. I'm sure there IS a reason for it, and that it goes beyond simple server bandwidth limitations given modern day hosting options and the relatively low number of deployed vehicles.

Anyone know what it is they're trying to achieve with the throttled release schedule?
Lucid doesn't really have a beta group. Maybe it's employees are classed as a beta group but to date, I'm not aware of them having a group of owners in an official public beta. I suspect along with just being overly cautious in the first place that by sending out in batches they make sure to not kill the entire fleet should a nasty bug show up that wasn't discovered in QA.

You just need to look at what happened to Rivian last year where they started doing a mass deployment and cars got bricked, all because a developer pushed the wrong branch to Prod. They had to quickly halt the update and it took them days to figure out how to get the cars that received the update working again.

Frustrating as it may be, the slow and steady approach is a lot more manageable should something go wrong
 
Wasn't this answered earlier in the thread? Staggered release is common because it means if a bug sneaks through QA, it may impact 1% of customers before being reported rather than 100%. That's 1% of customers that may have to get special service for something broken by software, rather than an unmanageable 100%. Even our smartphones do this. When a new iOS release comes out, everybody doesn't get it at once. Apple has had bugs sneak through QA as well, and they were able to stop the rollout before affecting millions of people.
I didn't realize it was covered earlier, thanks for the heads up.

Ironically, based on an earlier post about updates being halted while they start pushing 2.3.3 instead, it sounds like what you're describing above is precisely what happened.
 
The reason this interests me (impatience aside) is that I'm also a software developer by trade. Version checking upon startup for network-connected application is very common. What is LESS common is throttling the updates across your user base. Typically, when a new version (beta channels notwithstanding) becomes available, the software phones home to see if there is a new version available, and if so, prompts the user to see if they want to upgrade there and then.

I'm trying to understand the rationale of limiting the rollout. I'm sure there IS a reason for it, and that it goes beyond simple server bandwidth limitations given modern day hosting options and the relatively low number of deployed vehicles.

Anyone know what it is they're trying to achieve with the throttled release schedule?
Maybe they are trying to avoid a CrowdStrike situation? I’m sure that’s the reason for staggered rollouts. Both iOS and Android supports it. Any software company who has competent leadership would only do slow rollouts.
 
I got the update but now have a problem. My backup guidance is gone. Now only displays two parallel white lines. I've advised customer support of my issue. I was instructed of two ways to do soft reset and neither worked to initiate the reset.
Your backup camera isn’t correctly loading. Try a nuke reset. If that still doesn’t fix it, contact service.
 
The reason this interests me (impatience aside) is that I'm also a software developer by trade. Version checking upon startup for network-connected application is very common. What is LESS common is throttling the updates across your user base.
That is not uncommon at all. Staggered rollouts happen literally all the time at enterprise companies. It matter less for consumer software, but vehicle software requirements are much closer to enterprise software than B2C.

Typically, when a new version (beta channels notwithstanding) becomes available, the software phones home to see if there is a new version available, and if so, prompts the user to see if they want to upgrade there and then.
That is one method. Plenty of others exist, and almost every large company does a staggered rollout. Apple does staggered rollouts for their releases.

I'm trying to understand the rationale of limiting the rollout. I'm sure there IS a reason for it, and that it goes beyond simple server bandwidth limitations given modern day hosting options and the relatively low number of deployed vehicles.
Limiting damage if something goes awry.
 
So has anyone else in this forum had issues with the blind spot cameras? I’ve seen replies earlier in this thread saying some have had the issue but haven’t heard much since then. I have a Touring and they still aren’t working after the update.
I had an issue creep up with a front camera fault. Logo reset seems to have fixed but will stay alert and taking photos to memorialize any glitches and easy to text to Lucid service.
 
Can you share the release notes for 2.3.3?
They’re probably the same just with whatever bug was causing the cameras to stop fixed.

Could be wrong but I’m guessing people who didn’t get 2.3.0 may go straight to 2.3.3
 
I didn't take a screenshot but it was just boilerplate like "Enhancements for the robustness of the software." They didn't state anything specifically.
You can log in to your Portal on lucidmotors.com and click 'Owner’s manual & Software Updates' to get your update history. The release notes should be there.
 
You can log in to your Portal on lucidmotors.com and click 'Owner’s manual & Software Updates' to get your update history. The release notes should be there.
Ah ha. Here yall go.
 

Attachments

  • IMG_9931.webp
    IMG_9931.webp
    55.1 KB · Views: 186
Back
Top