Similarly my other half works from an office about 10metres from where my car is parked through a couple of walls. She rarely drives the car but I keep finding it has switched to her profile when I get in. Presumably it is seeing her phone key as present from time to time.I did some tests this evening and it turns out my paranoia is justified. The car can be unlocked with my phone (iPhoneX) on the other side of a timber partition wall about 4 metres away from drivers’ door. This basically replicates the situation I was in on Tuesday. Someone could have opened the door and driven away, and being totally silent, I would not have heard it
.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Turning Bluetooth off - am I being paranoid...
- Thread starter Vostok
- Start date
strykeroz
Member
Similar here. I'm glad it's not just us. I think her phone does a better BLE job than mine, she says it's because she's the car's fave driver.
This morning I was able to unlock the car, remove the charge cable, get in the car (my profile so it wasn't via the boss's phone) but it wouldn't start. It was happy enough with my phone for everything but shifting into R or D. Airplane mode on and off fixed this...but strange it let me into the car. I thought immediately of this thread and the varied experiences reported on unlocking.
It could be nature's way of saying I need a new phone?
Anecdotal evidence from other owners. Example: Phone is inside the house, car is parked outside just on the other side of the wall. Kid needs something from the car and goes out to get it without any key. The car just opens. If I was in that kind of situation, I would turn off the BT on my phone. Luckily, I have a private garage to park the 3 in, so I don't care if it's locked or not.
Since this function is completely in software, it could have been improved since this story was conveyed to me. In any case, I believe that the car always tries to determine the distance the phone is from the car with direction, by triangulation from the multiple BT radios on the car. I also believe the triangulation routine must think the phone is inside the car in order for it to start when you press the brake pedal.
Whilst inconvenient and undesirable, I reckon the car should unlock in this scenario. If the signal strength threshold has been met, there is no way it can know that phone is through a wall in the house. So like you say turning BT off is wise in this scenario.
Have not seen anything officially written to say triangulation is used, but I suppose it is quite reasonable to think it is.
Still the doc I read said at least one endpoint is needed for either unlock or start authentication suggesting triangulation is possible but not required. This could simply mean the security controller must be the endpoint for drive and any of the four can provide unlock.
If the only BTE endpoint with a connection is the Security Controller under the armrest and the signal threshold is met, presumably the car will authenticate for drive & disarm the immobiliser. Perhaps that is the difference between unlock and drive authentication. Might play around with shielding the various bte antennas and see what happens.
linux-works
Active Member
I was actually working on a BLE beacon project at work, funny enough.
the way beacons work is that they announce a unique ID (that the phone looks for, the tesla app, that is) and they announce their calibrated power levels (tx power) and you get the received signal (rssi) and you also get a flag that says 'near' or 'far' or some word that indicates distance.
the phone will collect all these and then talk to the cloud (or the car, not sure about how tesla does it) and reports if YOU are close enough or not.
what tesla did not give, was control over the range. sounds like you want a shorter range. its all in the app, so tesla would have to allow 'training' or a set-value for rssi threshold.
anyway, you should use PIN to drive and then, worst they could do is enter the car.
but I agree, we should have some control over what the lock-in distance should be.
the way beacons work is that they announce a unique ID (that the phone looks for, the tesla app, that is) and they announce their calibrated power levels (tx power) and you get the received signal (rssi) and you also get a flag that says 'near' or 'far' or some word that indicates distance.
the phone will collect all these and then talk to the cloud (or the car, not sure about how tesla does it) and reports if YOU are close enough or not.
what tesla did not give, was control over the range. sounds like you want a shorter range. its all in the app, so tesla would have to allow 'training' or a set-value for rssi threshold.
anyway, you should use PIN to drive and then, worst they could do is enter the car.
but I agree, we should have some control over what the lock-in distance should be.
linux-works
Active Member
oh, and for my 3 at least, they do not send out any more than ONE beacon. there were 4, once, but as I walk around the parking lot at work (many many 3's there) - they all just beacon ONE ble endpoint.
there is no triangulation (actually, the correct term is tri-lateration) since there is only one beacon.
(I think china did have 4 beacons, once; but for sure, my car in the US has only 1).
there is no triangulation (actually, the correct term is tri-lateration) since there is only one beacon.
(I think china did have 4 beacons, once; but for sure, my car in the US has only 1).
linux-works
Active Member
ok, one more post 
I thought of a way for tesla to improve this. I have no way to suggest it directly to them, though..
the idea would be to ONLY unlock if you see INCREASING signal strength (rssi gets close to 0; rssi normally is a negative number and the more negative, the weaker the signal).
they should never unlock on a signal that is steady. a 'walk up' is a signal strength that gets stronger in a steady fashion.
if they did that, it would be a lot more secure.
wish I could submit ideas to them. no way to do that, is there?
I thought of a way for tesla to improve this. I have no way to suggest it directly to them, though..
the idea would be to ONLY unlock if you see INCREASING signal strength (rssi gets close to 0; rssi normally is a negative number and the more negative, the weaker the signal).
they should never unlock on a signal that is steady. a 'walk up' is a signal strength that gets stronger in a steady fashion.
if they did that, it would be a lot more secure.
wish I could submit ideas to them. no way to do that, is there?
There were actually 5 once. Now there are supposedly only 4. The 3 endpoints and the security controller itself making 4.
“Model 3 continually advertises its identity via the 3 BLE endpoints, this advertisement is read by the Tesla app. The phone key automatically communicates with nearby Model 3 and when it receives an encrypted challenge from the security controller, the phone key replies with its encrypted response. If the response is validated by the security controller, the vehicle is authenticated, activating passive and active features”
“Model 3 continually advertises its identity via the 3 BLE endpoints, this advertisement is read by the Tesla app. The phone key automatically communicates with nearby Model 3 and when it receives an encrypted challenge from the security controller, the phone key replies with its encrypted response. If the response is validated by the security controller, the vehicle is authenticated, activating passive and active features”
Good idea, although if you walk up to the car then stand next to it while you finish to talking to your mate before opening the door... signal strength has been steady for the last 20 seconds and doors won’t open
And therein lies the rub with trying to eliminate edge cases with software... you’ll introduce new edge cases.
I’m not having a swing at Tesla for phone unlocking, generally it’s really brilliant (and I was a skeptic!). Just that owners should be aware this vulnerability exists in certain situations, and in situations where you think the risk exists, turn Bluetooth off for peace of mind.
linux-works
Active Member
even that would not be hard to write a code case/branch, for.
the idea is to reject things that have been 'far away' too long. or other smart heuristics.
you HAVE to, anyway. when I was testing ble beacons, on a car environment, it was chaos. lotsa filtering is needed, and some unconventional ways can help, too.
the idea is to reject things that have been 'far away' too long. or other smart heuristics.
you HAVE to, anyway. when I was testing ble beacons, on a car environment, it was chaos. lotsa filtering is needed, and some unconventional ways can help, too.
linux-works
Active Member
here's the reason (that I would use) - it takes some time for ble to actually work. channel scanning, exchanges between ble implementations, signals going up and down normally (lots of nearby 2.4ghz rf), sleep cycles in your phone, lots of areas where you need extra timeouts/retries for things like this to work.
I'd like it to 'start working' (start the protocol state machine) as I get near, then as I get *really* near, be at the end of the state machine, and really 'know' I'm there. I've had to wait longer than I should when I walk up and try to unlock.
now, imagine you are in a bad area and you really REALLY want to get the heck out of dodge, now. you don't want to mess around with a silly phone and ble. I DON'T! and so, speeding up the 'ok, I trust you, I know you, you can come inside' - it has to be fast. and detecting me as I come near lets lots of sluggish or latent systems get back up and working so that the unlock can happen at least a little before I'm really there.
I do see this as a safety issue. I could grade the vendor on how reliable and fast it unlocks. its really important that this gets to be as reliable as fobs (and fobs have been worked-out and pretty reliable for decades, now; and very low power, too. I've gotton 10 years on a fob battery for my old VW gas car).
[rant] ble and bluetooth is a mess, though. and so many versions, not to mention 'apple being apple' and not being standard enough to make it easier on vendors; and you *must* support apple, no one can be android-only [/rant]
Indeed, but there will always be some other edge case someone hasn’t thought of, or the “fix” creates a new one. The natural world is full of bell curves, and solving for the 0.01% still leaves the 0.001% unsolved (or unpredictable).
Beware the programmer showing complete confidence that all possible inputs now have resolved outputs and their software is 100% bug-free.
Frankly as an end user I don't give a rat's ass about the technical reasons, I just want it to work. And I say this as someone who's been writing software for 36 years. If it doesn't work properly, it doesn't matter how clever it is, it's no good. Vostok has found something that has shocked me a bit.
Yes, for all but simple cases this is mostly true but it depends on the complexity of the problem, and is a non-linear relationship.
Wol747
Active Member
I wonder if some of the issues are related to the old “head” meme re. garage door openers?
I saw something on TV a while back and it showed how a remote opener appeared to work normally outside the usual range if held against the head. I have often tried it and yes, it does seem to be true at least most of the time. If I walk well outside range then towards the garage until it works, then away 10 - 20m it still works with the transmitter held to the ear!
I saw something on TV a while back and it showed how a remote opener appeared to work normally outside the usual range if held against the head. I have often tried it and yes, it does seem to be true at least most of the time. If I walk well outside range then towards the garage until it works, then away 10 - 20m it still works with the transmitter held to the ear!
Similar threads
- Question
