Lucid Air's Number One Software Issue?

[segbrk]

I know that. But how does a virgin phone not made by lucid get to open the car? By what mechanism does , it acquire the needed security key? For example:

A - Does it use its BLE to communicate with the cars's BLE or
B - Does it use its cell transmitter to call Lucid central and Lucid central radios back to open the car?

Thanks

BLE to the car plus API requests to Lucid's cloud to authorize it.

 

[Steve181]

Thanks much. If that is correct, it leads to several thoughts:

The API rquests to Lucid's cloud are a likely source of delay.

If the non lucid phone ues BLE to the car, it must have some security token it got from somewhere when the lucid ap was first set up. If that is correct, then another device (say a new keyfob with buttons) could also acquire such a security token. If that is correct, a new keyfob is possible, without changing anything in the car and without reducing any security that now exists via the phone ap.

 

[segbrk]

Thanks much. If that is correct, it leads to several thoughts:

The API rquests to Lucid's cloud are a likely source of delay.

If the non lucid phone ues BLE to the car, it must have some security token it got from somewhere when the lucid ap was first set up. If that is correct, then another device (say a new keyfob with buttons) could also acquire such a security token. If that is correct, a new keyfob is possible, without changing anything in the car and without reducing any security that now exists via the phone ap.

Oh, no, to be clear the cloud is only involved for pairing, not for unlocking. Doesn't explain the delay when unlocking at all. And yes, it would absolutely be possible to create a new keyfob. The thought has crossed my mind.

 

[Steve181]

Oh, no, to be clear the cloud is only involved for pairing, not for unlocking. Doesn't explain the delay when unlocking at all. And yes, it would absolutely be possible to create a new keyfob. The thought has crossed my mind.

Thanks. I'm still curious about how the phone acquires the security token, and if another device can be designed by another vendor (with a lttle API help from Lucid) to acquire it in the same way.

 

[doubletwist]

Thanks. I'm still curious about how the phone acquires the security token, and if another device can be designed by another vendor (with a lttle API help from Lucid) to acquire it in the same way.

I would imagine it's done like any other public-key cryptographic process. An initial handshake is done, each device has or generates a private/public keypair (effectively a couple really long passwords), then gives the other it's public key.

Then any future communications is encrypted with the other devices public key so that only that device can read it, and signed by each devices private key so the other device can validate that the message came from the device it claims to the be.

 

[Steve181]

I would imagine it's done like any other public-key cryptographic process. An initial handshake is done, each device has or generates a private/public keypair (effectively a couple really long passwords), then gives the other it's public key.

Then any future communications is encrypted with the other devices public key so that only that device can read it, and signed by each devices private key so the other device can validate that the message came from the device it claims to the be.

Thanks: Then we should be able to have the following service with Lucid's OK: Send you fob to lucid or the manufacturer and pay a resaonable fee. The manufacturer or Lucid return the original Fob PLUS a new fob with buttons. Voila

 

[doubletwist]

Thanks: Then we should be able to have the following service with Lucid's OK: Send you fob to lucid or the manufacturer and pay a resaonable fee. The manufacturer or Lucid return the original Fob PLUS a new fob with buttons. Voila

Perhaps, but I don't think lack of buttons is really the core issue with the fobs.

 

[DeaneG]

Perhaps, but I don't think lack of buttons is really the core issue with the fobs.

It's the receivers in the car. Not enough of them, or a poor choice of antenna placement.

 

[Sue1955]

I agree with Lucken on the occasional loss of internet and its impact on audio,

 

[gowilk]

in my personal case the number 1 issue is their POOR implementation of all things bluetooth…from the keys to the profiles to the entertainment to carplay etecetra. bluetooth is grade school level tech hopefully the gravity people have refined that (crossing fingers).

 

[borski]

bluetooth is grade school level tech

I love hearing people say things like this because it makes it very clear they have never tried to implement a full Bluetooth stack (and if you have, I'm sorry for my assumption, but respectfully, I completely disagree). Bluetooth sucks. UWB is better, but bluetooth, like time zones and people's names, always sucks.

One factor is Bluetooth is on the 2.4GHz band, and WiFi on that band is many times more powerful - so Bluetooth packets can only get through in the gaps between Wifi transmissions. Also the short wavelength (~10cm) means the RF bounces and refracts all over the place, often resulting in small dead spots where devices fail to communicate (and the dead spots move about as the environment changes, i.e. people moving around).

As a result, getting anything through relies on lots of error handling. It's also not helped by lying user interfaces telling you a device is connected when snooping packets manifestly shows its not (looking at you, Apple).

Bluetooth can be pretty reliable - in RF-quiet environments. Low data rate stuff with error handlng/repeat transmissions often works by getting through during periods when there happen to be few interfering signals. Trying to use BT for relatively high rate date (e.g. audio) with lots of nearby wireless access points is always going to be hit and miss.

As an interesting experiment, take a connected bluetooth speaker and put it in a microwave oven (without turning it on, and if there is any question of it being on, unplug it). You will find that the bluetooth connection is nearly instantly broken by the shielding when the door is closed.

Bluetooth also has to put up with leaky microwave ovens, in addition to other users of the 2.4GHz band.

Bluetooth sucks. Period.

 

[borski]

To be clear, this is why I wish the keyfob used RF, and not bluetooth.

Because Bluetooth sucks.

Bluetooth sucking is not Lucid's fault, because as mentioned earlier, Bluetooth always sucks.

Choosing Bluetooth as their technology of choice for the keyfob? Yes, that is Lucid's fault.

And before anyone tells me their AirPods work fine, most Apple devices including AirPods support Bluetooth Class 1, which have a 40 times higher maximum transmit power than the more common Class 2.

From the Air manual:
Component: Bluetooth® Vehicle Key
- Manufacturer: Pektron Group Ltd
- Model: A-0820G01
- Operating Frequency: 2402-2480 MHz
- FCC ID/ISED ID: AQO013/IC: 10176A-013
- Maximum Transmit Power: 2402 – 2480 MHz: ≤ 1.36 mW EIRP

Component: Access Control Module BTLE/LF Node
- Manufacturer: Pektron Group Ltd
- Model: A-0819G13,A-0819G16
- Operating Frequency: 125 KHz, 2402-2480 MHz
- FCC ID/ISED ID: AQO012/IC: 10176A-012
- Maximum Transmit Power: 125kHz: ≤ 0.0057mW EIRP, 2402 – 2480 MHz: ≤ 1.35 mWEIRP

From the Gravity manual:
Component: Keyfob

• Manufacturer: Marquardt GmbH
• Model: UK1
• Operating Frequency:
  UWB: 5-9 GHz
  NFC: 13.56 MHz (passive tag)
  BLE: 2.4 GHZ
• FCC ID: IYZUK1
  IC: 2701A-UK1
• Maximum Transmit Power: UWB: ≤ -41.3 dB/MHz
  BLE: ≤-1 dBm

Component: UWB/BT Anchor MQD

• Manufacturer: Marquardt GmbH
• Model: MUB1
• Operating Frequency: UWB: 5-9 GHz, BLE: 2.4 GHz
• FCC ID: IYZMUB1
  IC: 2701A-MUB1
• Maximum Transmit Power: UWB: ≤ -40 dBm/ 0.001 mW
  BLE: ≤ -3.19dBm / 0.48mW

Component: UWB/BT Anchor MQD

• Manufacturer: Marquardt GmbH
• Model: MU3
• Operating Frequency: 5-9 GHz
• FCC ID: YZMU3
  IC: 2701A-MU3
• Maximum Transmit Power: ≤ -40 dBm/ 0.001 mW

 

[Steve181]

Thanks Borski. That is very interesting information.