> What kind of rollercoaster ride has more than ~10-20 g forces ?
I suppose that a regular crash but with a lucky ending can do a significant damage to phone in the pocket, because while the body is losing speed slowly, the phone and other things in pocket can hit the road hardly and ricochet with insane acceleration. I am a fan of downhill but I never carry my phone during that kind of ride when I am acknowledged about high chances of my crash. And in that risky kind of event I would rather go bombing the hill with a friend who can give me a proper help than rely on some computer.
To Apple's 100% credit they were willing to ship engineers out.
This happened day 1 (Thursday) of a 4-day festival. Even though they declined to have Apple come out you know they still sent a couple engineers out to gather data regardless.
On top of that, being proactive once it started happening and getting messaging out to attendees helped cut down the calls by ~50%, which definitely helped.
All you can do is continually refine it once you deploy it. A bit damned if you do, damned if you don't.
You're not damned if you practice judgment that keeps you from using machine learning anywhere just because you can, inflicting others with the hassle of inevitable false positives, false negatives, and false sense of security in a solution that will remain flawed regardless of your own level of patience to throw new versions out.
> All you can do is continually refine it once you deploy it. A bit damned if you do, damned if you don't
you could also get it to work with fewer false positives before deploying it, so more like damned if you do rush to market without proper testing and not-damned if you're thoughtful and do minimal testing first (which would obviously include dancing)
or, alternatively, just don't deploy and keep deployed a feature which fails so often and for which failures have such a significant impact on people
"fewer" obviously means fewer than it has now: the amount it currently has is too many, the amount it needs to have is fewer than the amount it currently has
this means they either didn't get it to work with fewer false positives than it has, or they did, then they discarded those improvements, leading to the inadequate release we have now (in which, again, the amount of false positives is too many)
> the amount it currently has is too many, the amount it needs to have is fewer than the amount it currently has
we can't define what "the amount it needs" is, and we don't know what Apple's definition of "the amount it needs" is. So this is ultimately a fruitless argument.
speak for yourself: perhaps you can't define it, if you want to admit so.
I can do so, easily: the amount it needs is an amount low enough to not prompt complaints from first responders.
In fact, that's the primary requirement. Doing fancy detection of whatever only comes when you know you aren't butt dialing paramedics and wasting their time.
Sorry, you can't push that negative externality onto society just for a neat slide at WWDC. Denied.
>I can do so, easily: the amount it needs is an amount low enough to not prompt complaints from first responders.
Great, you then deferred your meaning to another nebulous amount that is again, not defined. Maybe if you were willing to research and derive the current amount of false positives received, and if that threshold is acceptable as is, Id agree.
Otherwise: Maybe you consider mind reading as "easy" and I congratulate you on your talents. In the meantime I'll simply not assume what thresholds are what in the minds of operations that I'm not familiar with.
Alternatively you may be a 911 dispatcher with the power to define this. I hope you can communicate properly with apple becsuse your current estimate isn't really quantifiable.
I can only imagine that if I rushed a product to market that cost taxpayers thousands of dollars an interrupted emergency services, I'd be in serious trouble.
The problem is when stuff like this happens, it is hard to say how many individuals died or have been negatively affected due to resources having issues getting to the right individuals.
If dancing can make an iphone call 911, then Apple has not done their job. You cannot achieve g-forces dancing anywhere close to a serious crash. This is pathetic and unacceptable.
are we sure it's enough to excuse the failed crash detection described in the article (IE do we know the bouncing around generates multiple tens of Gs like an accident)?
without such a confirmation, the error is still inexcused
with it, the error seems like the feature is just poorly implemented or perhaps even poorly thought out
I had one of these alerts go off once from my watch. After a really hard fall from tripping during a trail run. I still have the scars.
The alert said: “You had a hard fall and stopped moving. Press this button or we call help”
The “stopped moving” part seems like the perfect proxy here. People in a car crash experience a huge spike in G-force once. Then it stops. Or maybe it goes for a few seconds if you’re rolling down the highway.
Car crashes don’t go on for minutes upon minutes. This seems like something a machine learning algorithm could handle. At the cost of calling 911 3min after a crash instead of 3sec. That’s still much faster than how long it takes people to call for help.
What percentage of 9-10mph crashes do you think result in any emergency services being called? I would hazard a guess that it's less than 50% including a non-emergency call to police and less than 10% for EMS. It absolutely does not warrant an automatic call to 911.
My assumption is that they want to trigger the alarm even for mild accidents.
Note that the Gs experienced by the dancers in my previously shared article approach the threshold for a mild accident. I wonder how they conducted the experiment, and if a phone held in a person's hand while they are dancing might experience even more Gs than the person's body.
I am not claiming it isn't a problem. But consider, the roll out of cell phones was also a problem for first responders. We can and should fix it to make it better.
And it isn't impossible to say how many were negatively affected, all told. It is hard in the moment, of course, but you can pull that signal out.
Again, they should work to fix this. But don't ignore the benefits of the feature, as well.
Edit: I also wouldn't be shocked to know that most of the dancing causing false reports were people dropping their phones. That will look a lot like a crash, for obvious reasons.
Edit2: For the "difficulty determining the impact," it is worth noting that they specifically callout that they were not overwhelmed, such that there is no reason to think this caused specific issues.
Crash Detection uses more than accelerometer and gyroscope input. Another major item it uses is listening for overall sound/noise from the microphones -- if it's loud, it's assuming a crash. Screaming and howling and bumping and grinding around the phone has no other clue other than "I must be in a crash".
It leverages the GPS, microphone, barometer, Bluetooth, Carplay status, accelerometer, and gyroscope in a sensor fusion.
Doesn't that just make it even more embarrassing that this is happening then? No Carplay connection, mostly stationary on the GPS, gyroscope and accelerometer not showing anything near the signs of a crash. But, "it's loud" so let's call 911.
I don't think we know what it _actually_ detected these events as. Gizmodo is reporting car crashes, but I don't think there's any way for them to know that.
The actual setting for the apple watch calls it a "severe crash" and has triggered for people crashing bicycles and things. There's also a separate "fall detection" setting that will call after a hard fall if you're not moving.
The thing is, this feature puts a negative externality on all taxpayers, while only benefiting iphone owners and Apple's profits. Apple should be held accountable for the false positive calls this causes, if for no other reason that it incentivizes them to reduce the number of false positives.
But, it doesn't? Save one person's elderly family member that took a hard fall, and it already more than paid off for them. Regardless of if they themselves have an apple device. Heck, get treatment more rapidly to anyone, and you probably saved costs all around.
I'm fine investigating. And reporting on a lot of this is fine, of course. But this very story says it did not overwhelm them, such that they were getting utilized. Probably net good for training, overall. As it let them practice runbooks that may not get a lot of use.
How on Earth are you ever going to reliably prevent false positives for a feature like this while still reliably detecting crashes?
I mean realistically unless you have a clear visual of the crash it's going to be very hard to tell a car crash from a loud noise + movement alone.
Really they should be asking you if you want to enable "crash detection" before setting off and it should remain disabled at all other times. If you can already ensure the user is in a car and then the phone happens to sense something like a crash then chances are much greater that it's actually a crash.
The G-forces in a crash are much higher than dancing.
Other implementations are better.
I carry an iPhone when I go biking, and I have a Garmin GPS. The Garmin crash detection works far better. The Garmin is tuned well enough to go off on a real crash mountain biking but won't go off if you have an accident that's not a full fall.
I have had a very "real" crash and seen the Garmin correctly identify it and the iPhone does not.
An easy way would be to calculate your speed ahead of time. If I’m going 55 mph (90 km/h), there’s a loud noise, and the phone gets jolted a bit, then it can check the distance it’s traveled for the next 3-4 seconds. If it’s clear that it’s not moving anymore, then it can begin alerting me; no response, it calls 911.
Apple currently checks your location periodically, so it can fulfill location-based reminder requests, so I honestly figured a similar tech was used for the crash detection. I’m pretty surprised that that’s not the case.
> Apple currently checks your location periodically, so it can fulfill location-based reminder requests, so I honestly figured a similar tech was used for the crash detection. I’m pretty surprised that that’s not the case.
GPS positioning at least used to be power-hungry, to the point it couldn't be run continuously. I'm not sure if that's still the case, but it could be a factor.
Unless the person has been going faster than 20mph at a turning radius of more than 30ft for more than a few seconds, it's unlikely to be a car accident. Whether the accuracy and sampling rate are always sufficient to distinguish these (or data could be cached with look back at high-g) I don't know.
That excludes most human only activities. Of course roller-coasters and various other rides could still trigger it.
Roller coasters should actually be an easy 'false positive' to avoid - the only time the movement actually 'stops' is at the end of the ride, and not with a high-G event.
Security alarms require obtaining an alarm permit. Automated alarms notify the alarm company who call the customer. They ask if help is needed and what their security code is. If the customer says an actual emergency happened they then call 911. In my jurisdiction more than three false alarms results in a fine for the resident/business.
The police generally don't respond to an alarm signal unless a person on site calls it in. Although once in the 1990s someone at work didn't know the burglar alarm keypad code and the police did eventually respond with guns drawn. That was a hair raising experience.
Apple knows exactly where you are, how fast you've been traveling and how much distance you've traveled.
If you've been standing in a field for the last 40 minutes, and haven't traveled more than 10 meters at a slow pace, and are surrounded by hundreds of other iphones that also have barely moved, you probably aren't suddenly in the middle of a car crash.
I think as Android and iOS release these new automated emergency reporting features, it should not tie up the existing voice-based 911 system. Maybe it goes to a call center where humans can interpret what they're seeing first. Or maybe we have a standardized API by which these devices can report directly to 911. But tying up a voice operator talking to a computer seems like a real waste of resources. I'm assuming that's what's happening, maybe I'm completely wrong.
At least the Android version requires manual input (pressing the power button five times in quick succession) but as reported some people seem to do that accidentally somehow (bad power button, I guess?).
It's crazy what large tech companies are allowed to do with public infrastructure. I bet you an app from a small developer would get cease and desisted within a month if it had false positives like these. At least put some of your own operators on the line first so you can verify that the emergency services are actually needed, and maybe don't even roll out the feature in areas that don't opt into receiving these automated alerts.
That feature is identical to iPhone's SOS call feature, but I think it has gotten recent coverage for false positives. I don't recall hearing that Apple's implementation has had the same level of false positives.
In this most recent situation it is crash detection, which I -think- Android also has, or at least Pixel phones do, but I don't know if they've had false positive problems.
They're different features - they're both available on iPhones and Pixel phones - One is automatic detection of accidents, the other is (supposed to be) manually triggered on an emergency.
I am aware. The iOS feature has some kind of auto detection going on based on gyroscopes, while the Android version requires the user to tap the power button five times.
The automatic speed and G force detection mechanism has completely different false positives from a button being pressed. Both can happen on accident, of course.
I don't really understand how the Android feature gets triggered by accident; my best guess is that the power button is resting against something and getting fake touches that would otherwise just launch the camera (the standard double power button tap on Android). The BBC article doesn't explain how this happens.
Burglar alarms often require alarm permits. Alarms first ring the alarm company's employees who ask if help is needed and your PIN. Also police just don't respond to automated burglar alarms, only manually reported ones.
Automated burglar alarms are generally supposed to stop unattended property crime, not save lives. Fire alarms get an automatic and immediate response because it is a life threatening emergency, just like a car crash.
This is a hard engineering problem to solve. Garmin bike computers and fitness trackers have a similar incident detection feature which uses the accelerometer. It doesn't automatically call 911 but it will automatically text designated emergency contacts via a Bluetooth link to your smartphone if it thinks you crashed your bike or something. I have had a few false positives when making hard stops on rough surfaces. Fortunately I was able to cancel the alert before it sent a message.
Then they need a private monitoring service to call them before 911 is called. The current level of public safety resources cannot handle robocalls to 911.
I like loose coupling. The car or bike computer handles crash detection and uses phone for its communications (calling or texting). The reality though is that the phone is the bike computer or functionally the car CMU for a lot of people.
From what I've heard, 911 operators regularly get people calling them for non-emergencies. The 911 operator's job is to judge whether the caller is actually reporting a legitimate emergency, and if so, route the report to the correct emergency personnel (fire/police/ambulance/etc) OR disregard the report as a non-emergency.
The end of the article seems to confirm the false positives didn't actually have any real negative impact. So legitimate emergencies were not drowned out by the accidental dialing.
> Thankfully, that wasn’t enough false 911 calls to overwhelm the local system and prevent responders from dealing with real emergencies that weekend, and with the help of festival organizers, the local authorities were able to locate the source of every false 911 call to determine that no actual emergencies were being reported.
Obviously eliminating false positives would be ideal. But if the false positives aren't overloading 911 operators, seems like maybe a non-issue? Especially if these things can be predicted, e.g. local emergency personell should be aware of a local festival anyway (and can be on alert for these false positives, assuming it's not so bad as to drown out actual emergencies).
Many people have an irrational fear of dialing 911. If you do it right now, someone will pickup the phone, and if you simply say "Sorry, I didn't mean to dial!" you won't get in trouble and the 911 operator will gladly let you off the line.
If no one speaks than you can't differentiate a false alarm from someone who can't breathe, or is hiding from an attacker, or is too hurt to put the phone to their ear.
It's a massive nuisance unless someone gets on to say it was a mistake...and if someone didn't notice their phone buzzing before it made the call they aren't gonna pick up.
This system doesn’t just open a voice line to 999, it dials 999 and then plays an automated message saying something along the lines of “The owner of this iPhone may have been involved in a crash, the device is currently located at [location]” and then repeats it a few times.
Ideally there’d be a better system for this where 999 can be notified in a machine readable format allowing them to filter out automated calls from known sites that are generating false positives, but it’s not like the operators don’t have information to work from.
It’s also possible operators could (maybe they already can) see which mobile cell the call came from, which would also help rule out false alerts because they’d be flagged as coming from the vicinity of a festival. Generally for large events 999 are going to contact the organisers and let them know they need to send out a first aid team anyway, they’re not going to automatically despatch an ambulance without someone having confirmed the need for one.
Just fine the person for negligent abuse of the system. The problem will get solved quickly enough if your badly configured phone calls 911 and you're not communicative, so they have to send an ambulance or whatever.
The "person" is Apple. This is an automated dialing based on various parameters.
I don't see a good outcome of fining this. Either the person turns off the feature and now there's a bunch of situations where it could have saved lives lost, or you charge Apple and they turn off the feature, effectively doing the same.
Or worse, because as of now every smartphone has requirements to dial emergency services, regardless of sim cards or passwords or whatnot. If it's not completely dead it can contact 911.
The person is the person buying apple phones and not turning off the feature when not needed in a situation where it's likely to produce a false positive.
It's a brand new feature so most may not even know it exists. These things are basically pocket computer these days, you can't expect a user to understand every available feature on them
If 911 calls go up by an order of magnitude (or more) due to a bug in a device that 25% of the population has, then yes that's a problem as there likely aren't enough 911 operators to handle the increased load.
I think one of the things that other posters are alluding to is that the phone can experience very significant forces if you are dancing, especially if it is being held in something like a purse or other bag that's flying around wildly as you dance (or if the phone is dropped). I'm pretty sure that if I threw my phone in a bag and caught it by the strap, it would experience far more G force than in any ordinary car crash, and if it is surrounded by screaming and general chaos, I think it's making a fairly understandable decision.
The sensor fusion algorithms get confused by this, and the phone decides to call 911. It displays a notification for 10 seconds, then it starts a further 10 second countdown where it buzzes at maximum power and plays a siren noise at maximum volume. Under normal circumstances a reasonable person would notice these very loud alerts, and cancel the call. In a festival scenario where the users are deafened by other noises and possibly drunk/high, you might not notice. The phone then makes a call to 911.
How would you alternatively design a system that calls emergency services in a crash? Where would you personally choose to calibrate the false positive/false negative rate? These are hard design choices, and there will always be incorrect detections with any automated system like this.
I think that's probably the best way to do something like this, but it certainly won't have the reach of putting the feature in people's phones. Only newer cars with the feature would be able to make the call. I think it would make sense to require some feature like this as part of the standard safety equipment on a new car.
I'm pretty sure that this iPhone feature has and will save lives, and it may also risk them due to resource mismanagement.
> ... but it certainly won't have the reach of putting the feature in people's phones.
I think this may be another job for Bayes. Apple's algorithm may be very accurate at detecting car crashes when there are car crashes, but most of the time there are not car crashes. As a result it may actually be super inaccurate at the 'population' level. So while it may have the reach, the incidence of false positives and the infrastructure misallocation may yield worse outcomes than not having the system in the first place.
Definitely. I think it is difficult to assess the scale of the issue here without any raw numbers. In terms of resource allocation, this quote in the article seems to suggest that they weren't so stretched thin that they had any issues.
>Our employees really stepped up, as first responders always do really step up in the line of duty and they did. And we didn’t have any situation where we couldn’t help someone because of the amount of calls.
Not to mention, car manufacturers would try to gate this feature behind a paid subscription model like OnStar. The industry took far too long to require rearview backup cameras, it would take years to require companies to have a system connected to a cellular network to phone 911.
The personal phone is the best place to fit this feature because it already has cellular communications and can work in any mode of transportation.
You can keep it in the phone, but use phone GPS to detect that a crash-like event correlates to something that looks like a crash from recent GPS data. That should reduce the false positives.
Phones don't keep a GPS fix in the background 24/7. This would be prohibitively expensive, battery-wise.
iPhones do have approximate location available at all times, via wi-fi scanning/databases and tower ~triangulation. This wouldn't be good enough to infer any sort of acute acceleration/deceleration.
All of that said, none of it helps if you were sitting at a red light for 3 minutes before being rear-ended.
The automatic detection and activation of "driving focus" in iOS has been extremely accurate in my experience. Seems like it'd be easiest to simply filter out "car crashes" when the phone isn't associated with a "driving" state.
On the other hand my iOS phone has never activated driving focus even when I'm driving. I suspect that's because I never connected my phone to the car over Bluetooth.
And then it would be worthless for hikers, bikers, elderly....
This is, all told, a fairly useful feature that has historically been accomplished only with dedicated hardware.
Such that I'm surprised at all of the indignation here. I remember when the watch came out, that there were many stories on how it had helped folks. Seems a straight line from those to false positives. There are probably also false negatives, such that the feature has work to do in both directions.
That's moving the goalposts? If the feature is for "car crashes" it's reasonable to put it int he car. A generic "this person had some sort of accident" is a much broader specification and much harder to manage all the edge cases for.
I'm not saying it's not valuable, I'm saying that without building a more specialized system you will never be able to filter a good chunk of false positives. And it's not great to have false calls on the emergency system, since it makes it worse for everyone.
You are massively underestimating the strain and resources expended for false positives for emergency services. This will be a major issue for municipalities. And it won't be apple footing the bill it will be your local tax dollars at work.
Put another way; if an emergency team arrives late to another accident because they were tied up on a false positive from an iphone and that results in less effective care, what happens? Do we just front the bill for more emergency workers? Do we hold apple accountable for false positives? Do we hold the user accountable for false positives (I guarantee most people are gonna start turning it off then).
Seems like emergency response centers are a little mixed in how they feel about the feature. But this last point is especially important as to why false positives are pretty irresponsible.
"An automated call from Crash Detection could cost responders as much as $10,000, and they have a limited budget."
I feel you are massively overstating, though? Largely, it doesn't help to compare costs of rescue and recovery in places with ski resorts to most municipalities. And the money saved from the legit crash notifications can add in to this well, such that this is an evolving space.
Again, they should improve it. And reporting and asking for changes makes sense. The disdain on this post is baffling to me, though. You don't have to search hard to find cases of this feature providing tangible help to people.
If you have solid data showing that it is overwhelming places, that changes things. So far, it has not been reported to be doing that.
> The disdain on this post is baffling to me, though. You don't have to search hard to find cases of this feature providing tangible help to people.
I know you mean well, but if this is that hard for you to understand then you aren't even trying to consider responders' wasted time or effort. Until the majority of automated calls are verifiable emergencies, this is adding more noise than signal. The handful of times it gets it right puts it a step above a broken clock in terms of usefulness. For what response costs in human capital, it needs to do better than occasionally getting it right. "If it saves one life..." isn't good enough when you're driving responders to apathy and exhaustion; others will suffer from their lack of attention.
Really, welfare checks borne from vaguely-substantiated malfunctions are a job for friends, not emergency services.
I confess that I don't know that you mean well, sadly.
For one, you haven't established that the majority are not verifiable emergencies. You are asserting that it can't possibly be the case that this is providing real value, as it is.
You also have not established that it causes a substantial increase in costs for most municipalities. Again, quoting how much a search and rescue can cost up to, in a place with many ski resorts, does little to actually convince me of good faith discussions here.
For places that have a convention or festival, I can already assume that they will have an increase in everything because of that. Per this very story, they were emphatically not overwhelmed. It was an increase, and is notable such that it is best if it is addressed.
But I see very little ways of framing the doom and gloom posts here other than FUD.
the cost of a false positive could be a life too. Someone could die because 911 was tied up with false reports and a person with a real emergency couldn't get though. Worse, first responders could be dispatched to a music festival and be unavailable when/where people really need them. This "feature" is broken and irresponsible.
My 2012 F150 behaves this way (supposedly) - the truck will try to call 911 using your BT-connected phone in the event of a crash. I’ve assumed that’s how GM cars with Onstar worked too, using their built in cell connection.
Shouldn't a system like that be part of the car, not the phone? Trying to force a feature to exist outside of the context where it makes sense can only lead to issues in my opinion.
The average age of a car in the states is 12.5 years. Mandating the tech in cars means that only a small fraction of comparatively well off Americans will benefit from crash detection. Rolling it out in smartphones democratizes this safety feature to a great extent.
Plus, there are pedestrians, cyclists, motorcyclists, etc., who can crash.
Do we have evidence that this feature is actually providing benefit? So much so that we as a society can't possibly wait 10 years for it to be ubiquitous in cars?
Was it common before to get in a serious accident but nobody calls 911?
If a call goes through when there was a legitimate accident, do the 911 operators even care, or do they assume all these automated calls are false positives?
I think it's likely that this feature does more harm than good by ddosing the 911 infrastructure.
Per the story, it didn't overwhelm them. It caused an increase, but they were able to field all calls. Such that you would need something other than this to show it caused actual harm.
I think conversations like this are difficult because in an indirect way, we're asking people to quantify the tradeoff of a human life vs mass human inconvenience. If the feature caused false-positives at a 1000:1 rate of real (unreported) accidents, would it be worth saving one life for 1000 wasted 911 calls? How about 10,000?
I don't have a confident answer for this at all, I think it's almost entirely subjective. There are folks who would confidently say that ANY amount of mass inconvenience is worth saving one life. There are others that would confidently say the opposite. Much more thoughtful people than I have spent a long time debating the topic on LessWrong, it's a pretty rich area of discussion.
First, there are the direct costs. If false auto-calls are clogging up 911 resources, then the taxpayers need to pay for more operators and infrastructure. This money could be used to "save lives" elsewhere.
Then there are second order effects such as lowering the signal/noise ratio of 911 calls. If operators get used to ignoring the automated calls, then the feature becomes a pure cost on society with little/no benefit.
Personal anecdote, but a friend of mine fell asleep at the wheel and rolled her car on a quiet road. Her watch called 911 while she was unconscious. I can't say for certain how long it would've taken for someone else to report the crash.
This system is also intended to detect other accidents besides car crashes. I would argue that those other types of accidents are more important as they are more likely to occur in private and less likely to be observed and reported by others.
To the point where I would actually consider suppressing this feature when used at car speeds at daytime in a city, since even when correct, the report would almost always be redundant, and thus provides a low value/noise ratio.
I'd filter cases where the phone wasn't previously traveling fast enough for the holder to have been in a vehicle, and cases where the phone wasn't near a road.
This would require AGPS rather than just the less power-hungry IMU, but maybe that's the price for not DDOSing 911 infrastructure.
I think this gets at a logical algorithmic improvement. I assume they use aggregate location data for things like real-time traffic. There’s no need for these alerts to trigger if there is a critical mass of iPhones near the ‘incident’.
Apple can't decide to do that? And if they cooperated with a manufacturer, that'd affect only its future cars, few compared to everyone with an iPhone.
I know apple can’t easily decide to do that, but they can decide to _not_ do this with such a high false positive rate. I don’t think selling iPhones is a universal good (even as an aapl shareholder). Selling aftermarket car sensors or whatever if they really wanted to be in the market for this makes sense to me.
But, I haven’t seen a good source on how frequently the false positive trigger versus real calls where the caller was unlikely to place it themselves. I could be totally wrong.
The solution is to move the system to the car. Cell phones are the wrong tool for the problem. Rollout will be much slower on the automotive side, but this can be addressed if we legistlate such systems up from luxury safety features to mandatory ones. Just like what we did in the past for airbags, automatic antilock braking, etc.
This feels like such an obvious failure-mode that I just assumed when they announced it that it would be smarter- incorporating different sensors, factoring in the exact way it tumbles, etc. If it really is just absolute acceleration, the false-positives are no surprise
> How would you alternatively design a system that calls emergency services in a crash?
If significant motion does not stop shortly after a candidate crash is identified then reject the candidate as a false positive.
Maybe also listen for voices. If you can detect people talking and they seem to be reasonably coherent that suggests that even if there was a crash there are people on site already who can take care of summoning emergency services if needed.
Apple maps automatically pops up with directions to home when I connect to my 2008 car’s bluetooth. I’d just enable it when connected to a vehicle’s bluetooth.
Or if the phone continually collects sensor data already for this feature, I’d just make sure the second preceding the supposed crash was consistent with traveling in a vehicle, not being in the same place. It won’t work when you are hit by something though in that case.
Light sensor. If the phone is in a handbag, there will hardly be any light. If it is in a car or flies away some amount of light would be perceptible by the sensors. Or just disable this feature. We got along ok before without it. First, do no harm.
Of course you are right. It won't work with them then. This feature can never work 100%. The point is to have less false positives.
Maybe the feature should ask the user: where do you put the phone normally? handbag, pocket; where while driving? while riding a bike? and the software would use sound, light sensors, based on the answers, etc.
Otherwise simply stop this feature, since it is more trouble than it is worth it.
Surely a false positive is better than a false negative right? Having such restrictive requirements for the call to activate seems like it'd do more harm than good.
I think exactly the opposite. Having all those fake calls is the harm. Not having this service is the default, so unless it provides a lot of accuracy it should not be implemented.
Worst case is real human calls start getting ignored or the response is delayed because of the noise of all these fake calls. This is a serious public safety issue, and it should not be up to a company to decide if they collapse it to sell more phones.
> How would you alternatively design a system that calls emergency services in a crash?
If you want to prevent false positives—then, same as you’ve described, but only enable when either:
- phone is connected to Carplay via USB or bluetooth
- phone is connected to a bluetooth device known to be an auto (inferred by manufacturer ID, and configurable in bluetooth settings)
- GPS data for the last 5 minutes indicate you’re driving
And display an indicator on lockscreen that shows this feature is enabled.
Of course, consider that the downside of false positives don’t affect consumers or manufacturers—rather, they affect public utilities. Then, it’s easy to understand why this happens.
I think it’s possible that the noise levels at a festival resemble the very loud noise of a car crash on some level, and that is part of the equation in triggering the crash detection.
If it were g-forces alone that are confusing the phone there might be more stories about fall detection rather than just car crash detection. Even though the age cohort at festivals might be less likely to explicitly enable fall detection, I think it’s a default setting.
They could build some better logic to determine how likely it is the phone is in a car at the moment and specifically for this kind of situation build longer baselines to determine if the user is likely to have heard the warning that the phone has determined it might have sensed a crash. The first option seems like it would solve a number of similar issues as well.
This whole iOS dialing 911 thing reminds me of the technology connections video on LED street lights. A perfect case of good intentions all around but with some emergent caveats that could not have been foreseen until the final result was in place. In the case of LED street lighting, a mild compromise or patch-around makes sense. In the case of your phone automatically dialing emergency services, the game theory seems a bit more difficult to mediate.
At this point I feel like the best course of action is to back out the feature. Adding a "are you sure" button to prevent a false dialing might as well just be turning it off. Making it less sensitive - effectively the same (maybe worse if you expect to rely on it). There really isn't a fundamental way to save this without yet-more-complexity. The user's intention will be betrayed from the perspective of their device in some percent of cases. You will never be able to solve this 100%.
Now the real question is, are we comfortable with some % error rate? Probably yes. A crank call to 911 isn't like an airbag going off unprovoked or your car deciding a plastic bag floating on the freeway is good cause to engage full emergency braking.
I wonder what happens when people start taking these things into mosh pits.
I would also think it's pretty easy to dismiss on the 911 operator side. Hey reported car crash. Oh wait, the location is in the middle of a dance club. Guess it's just another false positive.
Been there, done that. Why would you think that has yet to start? Never had a problem with the phone auto-dialing 911 in this scenario personally.
Maybe a difference is that people in the pit are more likely to have phone in pocket, whereas dancers are more likely to be holding phone in hand (cuz generally more likely to want it at the ready for selfies, etc?). I imagine that a phone’s accelerometer, when at the end of a moment arm (or literal arm in this scenario), is going to have a wilder experience than when held closer to the center of mass.
And yesterday there was a similar story about android.
Feels like these automated emergency things should go into a 2nd lower priority queue if they’re so low signal to noise ratio. Else it drowns out the higher quality sig/noise actual calls
It must be from slam dancing, moshing, ect. Sometimes it can get down right violent but most people are respectful but I can see how it can be set off and ignored as bodies are being slammed around.
Instead of Apple making a device and trying to convince all car makers to adopt it, they are putting it in phones. To sell phones. It shows that all our companies are in it for money and not for saving your life. There's no reason a feature like this needs to be in a phone. It should be in a car. Only
162 comments
[ 2.9 ms ] story [ 182 ms ] threadI could see how "negative" g forces could lead to a false positive but I think the absolute forces are too low.
On the other hand I could see how during dancing the phone gets thrown around and that may be a similar pattern to a car crash.
I suppose that a regular crash but with a lucky ending can do a significant damage to phone in the pocket, because while the body is losing speed slowly, the phone and other things in pocket can hit the road hardly and ricochet with insane acceleration. I am a fan of downhill but I never carry my phone during that kind of ride when I am acknowledged about high chances of my crash. And in that risky kind of event I would rather go bombing the hill with a friend who can give me a proper help than rely on some computer.
This happened day 1 (Thursday) of a 4-day festival. Even though they declined to have Apple come out you know they still sent a couple engineers out to gather data regardless.
On top of that, being proactive once it started happening and getting messaging out to attendees helped cut down the calls by ~50%, which definitely helped.
All you can do is continually refine it once you deploy it. A bit damned if you do, damned if you don't.
you could also get it to work with fewer false positives before deploying it, so more like damned if you do rush to market without proper testing and not-damned if you're thoughtful and do minimal testing first (which would obviously include dancing)
or, alternatively, just don't deploy and keep deployed a feature which fails so often and for which failures have such a significant impact on people
I'm sure they did.
this means they either didn't get it to work with fewer false positives than it has, or they did, then they discarded those improvements, leading to the inadequate release we have now (in which, again, the amount of false positives is too many)
we can't define what "the amount it needs" is, and we don't know what Apple's definition of "the amount it needs" is. So this is ultimately a fruitless argument.
speak for yourself: perhaps you can't define it, if you want to admit so.
I can do so, easily: the amount it needs is an amount low enough to not prompt complaints from first responders.
In fact, that's the primary requirement. Doing fancy detection of whatever only comes when you know you aren't butt dialing paramedics and wasting their time.
Sorry, you can't push that negative externality onto society just for a neat slide at WWDC. Denied.
Great, you then deferred your meaning to another nebulous amount that is again, not defined. Maybe if you were willing to research and derive the current amount of false positives received, and if that threshold is acceptable as is, Id agree.
Otherwise: Maybe you consider mind reading as "easy" and I congratulate you on your talents. In the meantime I'll simply not assume what thresholds are what in the minds of operations that I'm not familiar with.
Alternatively you may be a 911 dispatcher with the power to define this. I hope you can communicate properly with apple becsuse your current estimate isn't really quantifiable.
But when you are famous, they just let you do it.
That is, be careful not to strawman this such that they can't have any false positives. Do keep on them to make it ever better, of course.
If dancing can make an iphone call 911, then Apple has not done their job. You cannot achieve g-forces dancing anywhere close to a serious crash. This is pathetic and unacceptable.
You absolutely can, remember, the phone is recording the accelerations of the phone, not the acceleration of your brain or car or anything heavy.
did you just make up that fact?
https://www.bernards.cz/news/irish-dancers-get-pilot-g-force...
A 30mph car crash into a solid obstacle spikes at 30G https://www.jrlawfirm.com/blog/auto-accidents/car-accident-g...
Race car drivers have walked away from g-force as high as 78G https://www.essentiallysports.com/f1-news-from-max-verstappe...
We’re talking an order of magnitude here. Algorithms should be able to tell the difference.
are we sure it's enough to excuse the failed crash detection described in the article (IE do we know the bouncing around generates multiple tens of Gs like an accident)?
without such a confirmation, the error is still inexcused
with it, the error seems like the feature is just poorly implemented or perhaps even poorly thought out
The alert said: “You had a hard fall and stopped moving. Press this button or we call help”
The “stopped moving” part seems like the perfect proxy here. People in a car crash experience a huge spike in G-force once. Then it stops. Or maybe it goes for a few seconds if you’re rolling down the highway.
Car crashes don’t go on for minutes upon minutes. This seems like something a machine learning algorithm could handle. At the cost of calling 911 3min after a crash instead of 3sec. That’s still much faster than how long it takes people to call for help.
https://www.researchgate.net/figure/Thresholds-g-forces-for-...
I believe 4.5gs would be like a 9-10mph crash.
There are wildly different G-forces involved.
https://www.researchgate.net/figure/Thresholds-g-forces-for-...
My assumption is that they want to trigger the alarm even for mild accidents.
Note that the Gs experienced by the dancers in my previously shared article approach the threshold for a mild accident. I wonder how they conducted the experiment, and if a phone held in a person's hand while they are dancing might experience even more Gs than the person's body.
edit: I think 4.5gs is equal to a 9-10mph crash.
"A concussion occurs at roughly 90 to 100 g-force, which equates to smashing your skull against a wall at 20 mph" - https://news.umich.edu/football-helmet-sensors-help-research...
These comments are making it quite clear why stuff like this makes it to production.
https://www.researchgate.net/figure/Thresholds-g-forces-for-...
90-100g is a pretty extreme amount of force.
And it isn't impossible to say how many were negatively affected, all told. It is hard in the moment, of course, but you can pull that signal out.
Again, they should work to fix this. But don't ignore the benefits of the feature, as well.
Edit: I also wouldn't be shocked to know that most of the dancing causing false reports were people dropping their phones. That will look a lot like a crash, for obvious reasons.
Edit2: For the "difficulty determining the impact," it is worth noting that they specifically callout that they were not overwhelmed, such that there is no reason to think this caused specific issues.
It leverages the GPS, microphone, barometer, Bluetooth, Carplay status, accelerometer, and gyroscope in a sensor fusion.
The actual setting for the apple watch calls it a "severe crash" and has triggered for people crashing bicycles and things. There's also a separate "fall detection" setting that will call after a hard fall if you're not moving.
I'm fine investigating. And reporting on a lot of this is fine, of course. But this very story says it did not overwhelm them, such that they were getting utilized. Probably net good for training, overall. As it let them practice runbooks that may not get a lot of use.
We have a piss-poor track record of holding 'job creators' accountable for direct harm to our communities, let alone two-steps removed indirect harm.
Where do you see that they rushed it?
I mean realistically unless you have a clear visual of the crash it's going to be very hard to tell a car crash from a loud noise + movement alone.
Really they should be asking you if you want to enable "crash detection" before setting off and it should remain disabled at all other times. If you can already ensure the user is in a car and then the phone happens to sense something like a crash then chances are much greater that it's actually a crash.
The G-forces in a crash are much higher than dancing.
Other implementations are better.
I carry an iPhone when I go biking, and I have a Garmin GPS. The Garmin crash detection works far better. The Garmin is tuned well enough to go off on a real crash mountain biking but won't go off if you have an accident that's not a full fall.
I have had a very "real" crash and seen the Garmin correctly identify it and the iPhone does not.
Apple currently checks your location periodically, so it can fulfill location-based reminder requests, so I honestly figured a similar tech was used for the crash detection. I’m pretty surprised that that’s not the case.
GPS positioning at least used to be power-hungry, to the point it couldn't be run continuously. I'm not sure if that's still the case, but it could be a factor.
That excludes most human only activities. Of course roller-coasters and various other rides could still trigger it.
Security alarms require obtaining an alarm permit. Automated alarms notify the alarm company who call the customer. They ask if help is needed and what their security code is. If the customer says an actual emergency happened they then call 911. In my jurisdiction more than three false alarms results in a fine for the resident/business.
The police generally don't respond to an alarm signal unless a person on site calls it in. Although once in the 1990s someone at work didn't know the burglar alarm keypad code and the police did eventually respond with guns drawn. That was a hair raising experience.
This is much more like a fire alarm, which does trigger an automatic response.
In my view, we should be more lenient with false alarms when it could save someones life, compared to stopping theft.
If you've been standing in a field for the last 40 minutes, and haven't traveled more than 10 meters at a slow pace, and are surrounded by hundreds of other iphones that also have barely moved, you probably aren't suddenly in the middle of a car crash.
It's crazy what large tech companies are allowed to do with public infrastructure. I bet you an app from a small developer would get cease and desisted within a month if it had false positives like these. At least put some of your own operators on the line first so you can verify that the emergency services are actually needed, and maybe don't even roll out the feature in areas that don't opt into receiving these automated alerts.
That feature is identical to iPhone's SOS call feature, but I think it has gotten recent coverage for false positives. I don't recall hearing that Apple's implementation has had the same level of false positives.
In this most recent situation it is crash detection, which I -think- Android also has, or at least Pixel phones do, but I don't know if they've had false positive problems.
Yes, Pixel launched the feature on 2019. I didn't really find articles about false positives, but that's not at all empirical.
1. https://news.ycombinator.com/item?id=36479440
The automatic speed and G force detection mechanism has completely different false positives from a button being pressed. Both can happen on accident, of course.
I don't really understand how the Android feature gets triggered by accident; my best guess is that the power button is resting against something and getting fake touches that would otherwise just launch the camera (the standard double power button tap on Android). The BBC article doesn't explain how this happens.
https://support.garmin.com/en-US/?faq=RfaXahBWkH8Q7pVFLsuUmA
I have a feeling this creates more problems than they solve. A computer should never reach out to emergency calls without the user pressing something.
trash
From what I've heard, 911 operators regularly get people calling them for non-emergencies. The 911 operator's job is to judge whether the caller is actually reporting a legitimate emergency, and if so, route the report to the correct emergency personnel (fire/police/ambulance/etc) OR disregard the report as a non-emergency.
The end of the article seems to confirm the false positives didn't actually have any real negative impact. So legitimate emergencies were not drowned out by the accidental dialing.
> Thankfully, that wasn’t enough false 911 calls to overwhelm the local system and prevent responders from dealing with real emergencies that weekend, and with the help of festival organizers, the local authorities were able to locate the source of every false 911 call to determine that no actual emergencies were being reported.
Obviously eliminating false positives would be ideal. But if the false positives aren't overloading 911 operators, seems like maybe a non-issue? Especially if these things can be predicted, e.g. local emergency personell should be aware of a local festival anyway (and can be on alert for these false positives, assuming it's not so bad as to drown out actual emergencies).
Many people have an irrational fear of dialing 911. If you do it right now, someone will pickup the phone, and if you simply say "Sorry, I didn't mean to dial!" you won't get in trouble and the 911 operator will gladly let you off the line.
It's a massive nuisance unless someone gets on to say it was a mistake...and if someone didn't notice their phone buzzing before it made the call they aren't gonna pick up.
Ideally there’d be a better system for this where 999 can be notified in a machine readable format allowing them to filter out automated calls from known sites that are generating false positives, but it’s not like the operators don’t have information to work from.
It’s also possible operators could (maybe they already can) see which mobile cell the call came from, which would also help rule out false alerts because they’d be flagged as coming from the vicinity of a festival. Generally for large events 999 are going to contact the organisers and let them know they need to send out a first aid team anyway, they’re not going to automatically despatch an ambulance without someone having confirmed the need for one.
Just fine the person for negligent abuse of the system. The problem will get solved quickly enough if your badly configured phone calls 911 and you're not communicative, so they have to send an ambulance or whatever.
I don't see a good outcome of fining this. Either the person turns off the feature and now there's a bunch of situations where it could have saved lives lost, or you charge Apple and they turn off the feature, effectively doing the same.
Or worse, because as of now every smartphone has requirements to dial emergency services, regardless of sim cards or passwords or whatnot. If it's not completely dead it can contact 911.
People can be expected to behave responsibly.
The sensor fusion algorithms get confused by this, and the phone decides to call 911. It displays a notification for 10 seconds, then it starts a further 10 second countdown where it buzzes at maximum power and plays a siren noise at maximum volume. Under normal circumstances a reasonable person would notice these very loud alerts, and cancel the call. In a festival scenario where the users are deafened by other noises and possibly drunk/high, you might not notice. The phone then makes a call to 911.
How would you alternatively design a system that calls emergency services in a crash? Where would you personally choose to calibrate the false positive/false negative rate? These are hard design choices, and there will always be incorrect detections with any automated system like this.
I'd put it in the car. Make it use the same sensor as airbag deployment.
I'm pretty sure that this iPhone feature has and will save lives, and it may also risk them due to resource mismanagement.
I think this may be another job for Bayes. Apple's algorithm may be very accurate at detecting car crashes when there are car crashes, but most of the time there are not car crashes. As a result it may actually be super inaccurate at the 'population' level. So while it may have the reach, the incidence of false positives and the infrastructure misallocation may yield worse outcomes than not having the system in the first place.
Definitely. I think it is difficult to assess the scale of the issue here without any raw numbers. In terms of resource allocation, this quote in the article seems to suggest that they weren't so stretched thin that they had any issues.
>Our employees really stepped up, as first responders always do really step up in the line of duty and they did. And we didn’t have any situation where we couldn’t help someone because of the amount of calls.
A good individual idea not always turns out to be great when taken at a population level
"Apple will have to make the calculation actual lives saved vs. useless dispatches"
The personal phone is the best place to fit this feature because it already has cellular communications and can work in any mode of transportation.
Make a USB cigarette lighter charger which also has crash sensors that the phone can use.
(and/or put them in dashcams)
(or aftermarket stereo/infotainment systems)
https://en.wikipedia.org/wiki/ECall
And many modern cars have it as well in the USA. My BMW has it.
iPhones do have approximate location available at all times, via wi-fi scanning/databases and tower ~triangulation. This wouldn't be good enough to infer any sort of acute acceleration/deceleration.
All of that said, none of it helps if you were sitting at a red light for 3 minutes before being rear-ended.
This is, all told, a fairly useful feature that has historically been accomplished only with dedicated hardware.
Such that I'm surprised at all of the indignation here. I remember when the watch came out, that there were many stories on how it had helped folks. Seems a straight line from those to false positives. There are probably also false negatives, such that the feature has work to do in both directions.
Put another way; if an emergency team arrives late to another accident because they were tied up on a false positive from an iphone and that results in less effective care, what happens? Do we just front the bill for more emergency workers? Do we hold apple accountable for false positives? Do we hold the user accountable for false positives (I guarantee most people are gonna start turning it off then).
Seems like emergency response centers are a little mixed in how they feel about the feature. But this last point is especially important as to why false positives are pretty irresponsible.
"An automated call from Crash Detection could cost responders as much as $10,000, and they have a limited budget."
https://appleinsider.com/articles/23/01/09/apple-crash-detec...
Again, they should improve it. And reporting and asking for changes makes sense. The disdain on this post is baffling to me, though. You don't have to search hard to find cases of this feature providing tangible help to people.
If you have solid data showing that it is overwhelming places, that changes things. So far, it has not been reported to be doing that.
I know you mean well, but if this is that hard for you to understand then you aren't even trying to consider responders' wasted time or effort. Until the majority of automated calls are verifiable emergencies, this is adding more noise than signal. The handful of times it gets it right puts it a step above a broken clock in terms of usefulness. For what response costs in human capital, it needs to do better than occasionally getting it right. "If it saves one life..." isn't good enough when you're driving responders to apathy and exhaustion; others will suffer from their lack of attention.
Really, welfare checks borne from vaguely-substantiated malfunctions are a job for friends, not emergency services.
For one, you haven't established that the majority are not verifiable emergencies. You are asserting that it can't possibly be the case that this is providing real value, as it is.
You also have not established that it causes a substantial increase in costs for most municipalities. Again, quoting how much a search and rescue can cost up to, in a place with many ski resorts, does little to actually convince me of good faith discussions here.
For places that have a convention or festival, I can already assume that they will have an increase in everything because of that. Per this very story, they were emphatically not overwhelmed. It was an increase, and is notable such that it is best if it is addressed.
But I see very little ways of framing the doom and gloom posts here other than FUD.
The cost of a false negative could be a life.
Improved protocols and better algorithms from Apple will probably help tremendously with false positives.
Plus, there are pedestrians, cyclists, motorcyclists, etc., who can crash.
Most crashes have at least one car involved.
Was it common before to get in a serious accident but nobody calls 911?
If a call goes through when there was a legitimate accident, do the 911 operators even care, or do they assume all these automated calls are false positives?
I think it's likely that this feature does more harm than good by ddosing the 911 infrastructure.
You also don't have to search too hard to see that it has, in fact, been useful. First news search I found: https://9to5mac.com/2022/04/15/police-officer-apple-watch-fa... I see no reason to think there aren't others.
I don't have a confident answer for this at all, I think it's almost entirely subjective. There are folks who would confidently say that ANY amount of mass inconvenience is worth saving one life. There are others that would confidently say the opposite. Much more thoughtful people than I have spent a long time debating the topic on LessWrong, it's a pretty rich area of discussion.
First, there are the direct costs. If false auto-calls are clogging up 911 resources, then the taxpayers need to pay for more operators and infrastructure. This money could be used to "save lives" elsewhere.
Then there are second order effects such as lowering the signal/noise ratio of 911 calls. If operators get used to ignoring the automated calls, then the feature becomes a pure cost on society with little/no benefit.
My wife went out and bought a watch the next day.
To the point where I would actually consider suppressing this feature when used at car speeds at daytime in a city, since even when correct, the report would almost always be redundant, and thus provides a low value/noise ratio.
[1]https://europa.eu/youreurope/citizens/travel/security-and-em...
It is the part of the car in some... other countries. And it works, experienced it myself.
This would require AGPS rather than just the less power-hungry IMU, but maybe that's the price for not DDOSing 911 infrastructure.
I wouldn’t - it’s not clear to me this feature is saving lives. Why not incorporate it into the car?
And that'd sell more cars not more iPhones
But, I haven’t seen a good source on how frequently the false positive trigger versus real calls where the caller was unlikely to place it themselves. I could be totally wrong.
Seems a bit excessive to me. Especially since I’m not over 80 years or or whatever.
It's already done and mandated. Why design something new?
https://europa.eu/youreurope/citizens/travel/security-and-em...
If significant motion does not stop shortly after a candidate crash is identified then reject the candidate as a false positive.
Maybe also listen for voices. If you can detect people talking and they seem to be reasonably coherent that suggests that even if there was a crash there are people on site already who can take care of summoning emergency services if needed.
Or if the phone continually collects sensor data already for this feature, I’d just make sure the second preceding the supposed crash was consistent with traveling in a vehicle, not being in the same place. It won’t work when you are hit by something though in that case.
Maybe the feature should ask the user: where do you put the phone normally? handbag, pocket; where while driving? while riding a bike? and the software would use sound, light sensors, based on the answers, etc.
Otherwise simply stop this feature, since it is more trouble than it is worth it.
Worst case is real human calls start getting ignored or the response is delayed because of the noise of all these fake calls. This is a serious public safety issue, and it should not be up to a company to decide if they collapse it to sell more phones.
Pretty easy to filter all the car crashes coming from a grassy lawn somewhere.
If you want to prevent false positives—then, same as you’ve described, but only enable when either:
- phone is connected to Carplay via USB or bluetooth
- phone is connected to a bluetooth device known to be an auto (inferred by manufacturer ID, and configurable in bluetooth settings)
- GPS data for the last 5 minutes indicate you’re driving
And display an indicator on lockscreen that shows this feature is enabled.
Of course, consider that the downside of false positives don’t affect consumers or manufacturers—rather, they affect public utilities. Then, it’s easy to understand why this happens.
If it were g-forces alone that are confusing the phone there might be more stories about fall detection rather than just car crash detection. Even though the age cohort at festivals might be less likely to explicitly enable fall detection, I think it’s a default setting.
Really, this is effectively criminal under the statute iiuc
Keep state for a longer period of time.
Activate when you start driving and deactivate when parking.
Start could be triggered by gps detecting movement over longer period of time over roads.
That would avoid festival where you're stationary in a place where cars arent allowed.
Problem here is solved.
At this point I feel like the best course of action is to back out the feature. Adding a "are you sure" button to prevent a false dialing might as well just be turning it off. Making it less sensitive - effectively the same (maybe worse if you expect to rely on it). There really isn't a fundamental way to save this without yet-more-complexity. The user's intention will be betrayed from the perspective of their device in some percent of cases. You will never be able to solve this 100%.
Now the real question is, are we comfortable with some % error rate? Probably yes. A crank call to 911 isn't like an airbag going off unprovoked or your car deciding a plastic bag floating on the freeway is good cause to engage full emergency braking.
"I was going so hard that my phone thought I was dying and called an ambulance"
I would also think it's pretty easy to dismiss on the 911 operator side. Hey reported car crash. Oh wait, the location is in the middle of a dance club. Guess it's just another false positive.
Maybe a difference is that people in the pit are more likely to have phone in pocket, whereas dancers are more likely to be holding phone in hand (cuz generally more likely to want it at the ready for selfies, etc?). I imagine that a phone’s accelerometer, when at the end of a moment arm (or literal arm in this scenario), is going to have a wilder experience than when held closer to the center of mass.
Feels like these automated emergency things should go into a 2nd lower priority queue if they’re so low signal to noise ratio. Else it drowns out the higher quality sig/noise actual calls
Notable that not a single story that has been reported has mentioned places getting overwhelmed with calls from this.