What's new
By:

Software version 3.3.2

johnse said:
We've had instances of
* Rear wheel steering unavailable --Contact Service
* USB Charging unavailable --Contact Service

Are these known glitches, or something that needs service to address?

We are on 3.3.2.
Click to expand...
Yes, these seem to be intermittent but common, and don't seem to be factual.
 
Ironhorse said:
It did happen. 

The proximity sensor and all buttons on the FOB are working. However, the car screens are all black, and I’m unable to switch from park to drive.

I’m calling the service center now, but if anyone has some experience with this issue, I would greatly appreciate any pointers you can provide.
Click to expand...
Have you tried rebooting the infotainment system? Described in the manual on page 196:

1759435381755.webp
 
borski said:
Have you tried rebooting the infotainment system? Described in the manual on page 196:

View attachment 32997
Click to expand...
Apologies. I deleted my comment since the issue was resolved.

I tried to reboot but it didn’t quite work. Perhaps I wasn’t pressing right where I should be.

SC asked me to wait for 30s for Something called “bulb check”. I locked the car, walked away, came back in 2 mins and now it works .

Thanks for this reference again @borski
 
Ironhorse said:
Apologies. I deleted my comment since the issue was resolved.

I tried to reboot but it didn’t quite work. Perhaps I wasn’t pressing right where I should be.

SC asked me to wait for 30s for Something called “bulb check”. I locked the car, walked away, came back in 2 mins and now it works .

Thanks for this reference again @borski
Click to expand...
That is the 'vehicle power cycle' described in the manual; used to be that turning on a turn signal would help you know when the car was asleep.
 
borski said:
That is the 'vehicle power cycle' described in the manual; used to be that turning on a turn signal would help you know when the car was asleep.
Click to expand...
I’ll do more next time.

Mine sounded like a panic post. Even though it was for a few mins.
 
Ironhorse said:
I’ll do more next time.

Mine sounded like a panic post. Even though it was for a few mins.
Click to expand...
Haha no worries; you're not the first, and you won't be the last. We're pretty used to that here. :)
 
Has anyone else not even been offered the 3.3.2 update yet or am I the only one?
 
borski said:
Have you tried rebooting the infotainment system? Described in the manual on page 196:

View attachment 32997
Click to expand...
Dang it. I ended up having to reboot on my evening drive with the kids. Wasn't a pleasant experience but got me thinking.

1. After reboot the whole UI was much snappier.
2. The "Hey Lucid" assistant didn't work properly for a few seconds (likely takes a little bit for that module to load).

Essentially things start off great, and it gets progressively slower and slower, till we see screen blackouts or funky stuff, and an eventual console reboot is required. (Speculation on my part) Seems to me that there is a fairly decent memory leak in the system - most likely due to the myriad of sensor (software) drivers.

Once the system booted up, there was enough memory to bring up real time data, the auto high beam headlights started functioning properly , no black / blank screen ....

The developer part of my brain is screaming Memory leak(s) .
 
PGHGravity said:
Has anyone else not even been offered the 3.3.2 update yet or am I the only one?
Click to expand...
Maybe they pulled it from OTA due to all the "unexpected features"?
Did your car finish DreamDrive calibration yet? Mine is a week old, 400 miles, at least 100 of those on freeway, but still no DreamDrive.
Best part is that calibration status has no UI, so I have no clue what's going on and when it will end.
 
Ironhorse said:
Seems to me that there is a fairly decent memory leak in the system - most likely due to the myriad of sensor (software) drivers.
Click to expand...
This is actually my suspicion as well. Concurrency sucks to manage, and the infotainment system is Android Automotive, which is... Java/Kotlin for the UI / apps, and C++. You'll note none are memory-safe. :)

Parts of Android Automotive are currently being rewritten in Rust, for this very reason.
 
I’m curious if Lucid has a private test group or something ? Perhaps some anecdotal data from this forum will help them.

It’s tricky but I’m sure a lot of folks here will be happy to help in some way.
 
borski said:
This is actually my suspicion as well. Concurrency sucks to manage, and the infotainment system is Android Automotive, which is... Java/Kotlin for the UI / apps, and C++. You'll note none are memory-safe. :)

Parts of Android Automotive are currently being rewritten in Rust, for this very reason.
Click to expand...
I've never learned Kotlin, but Java is conventionally considered to be memory safe, modulo potential JNI issues. Memory leaks aren't normally considered part of "memory safe". Only the most restrictive of real-time/embedded programing paradigms entirely avoid the issue of memory leaks. Rust is a great language in many ways, but memory leaks isn't a problem it solves. People have very successfully used Java and C++ in memory constrained embedded environments. But doing that successfully is hard when you're constantly tempted to leverage the vast array of open source libraries that weren't really built with the reliability of embedded systems in mind.
 
TahoeMichael said:
I've never learned Kotlin, but Java is conventionally considered to be memory safe, modulo potential JNI issues. Memory leaks aren't normally considered part of "memory safe". Only the most restrictive of real-time/embedded programing paradigms entirely avoid the issue of memory leaks. Rust is a great language in many ways, but memory leaks isn't a problem it solves. People have very successfully used Java and C++ in memory constrained embedded environments. But doing that successfully is hard when you're constantly tempted to leverage the vast array of open source libraries that weren't really built with the reliability of embedded systems in mind.
Click to expand...
Sorry, you’re right, I misspoke. I meant threadsafe.
 
TahoeMichael said:
but Java is conventionally considered to be memory safe, modulo potential JNI issues.
Click to expand...
Java simply has different categories of memory leaks. Circular references is the most common A references B references C references A. Those will stick around in memory.

Also, while Java is relatively good with cleaning up highly transient garbage, it can fall down in the deeper generation garbage.

In Java-based games, we tend to force GC once per frame to minimize hitching due to longer GC passes. That only works to some extent, but it helps.

In data centers, it's somewhat common to simply restart servers on a scheduled basis, because 4th gen GC, when triggered, can take longer than a reboot. This has taken entire services offline as all the servers behind a load balancer would tend to hit the deep GC at similar times. As servers go offline, the traffic is shed to other servers, causing them to reach deep GC sooner, and so on into cascade failure.

Every language can leak memory. Every language can have multithreading issues.
 
TahoeMichael said:
I've never learned Kotlin, but Java is conventionally considered to be memory safe, modulo potential JNI issues. Memory leaks aren't normally considered part of "memory safe". Only the most restrictive of real-time/embedded programing paradigms entirely avoid the issue of memory leaks. Rust is a great language in many ways, but memory leaks isn't a problem it solves. People have very successfully used Java and C++ in memory constrained embedded environments. But doing that successfully is hard when you're constantly tempted to leverage the vast array of open source libraries that weren't really built with the reliability of embedded systems in mind.
Click to expand...
My understanding is that the drivers that listen to signals from hardware are not in Java or a memory safe language. That’s typically the cause of leaks.

Good example is the TPMS. Even though it’s a solved problem for most cars, a new tire pressure monitor hardware vendor may have a brand new firmware implementation that may have small memory issues.

Other simple things like door opening or proximity sensors. They are used 100s of times in normal operation. A single byte adds up over time.

Even on the Teslas, the simple switching the screen between music, and going back to maps, can lead to slow downs over time.
 
Ironhorse said:
My understanding is that the drivers that listen to signals from hardware are not in Java or a memory safe language. That’s typically the cause of leaks.

Good example is the TPMS. Even though it’s a solved problem for most cars, a new tire pressure monitor hardware vendor may have a brand new firmware implementation that may have small memory issues.

Other simple things like door opening or proximity sensors. They are used 100s of times in normal operation. A single byte adds up over time.

Even on the Teslas, the simple switching the screen between music, and going back to maps, can lead to slow downs over time.
Click to expand...
the drivers that listen to signals from hardware are not in Java.....nor are they in their Gravities, or they would be listening to their Tidal on Surreal Sound Pro! :-)
 
Today I unlocked the last 2 Easter Eggs - no volume via Bluetooth and a full blast of air.
I think I officially unlocked all of the Easter Eggs hidden in 3.3.2 listed in this thread, I'm ready for the next round in 3.3.3.
Is there a trophy for getting them all?
 
A little birdie told me that 3.3.3 is going to be released sooner than lucid was expecting.
Not unexpected- and glad they are on it.

For my specific situation, I’ll know more tomorrow. They were able to diagnose and swap something. I can see the firmware being applied.
 
You must log in or register to reply here.
Back
Top