Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y Newsgroups: sci.electronics.design Subject: Re: iPhone battery replacement Date: Sat, 8 Jun 2024 14:42:34 -0700 Organization: A noiseless patient Spider Lines: 60 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 08 Jun 2024 23:43:12 +0200 (CEST) Injection-Info: dont-email.me; posting-host="06ad93f0b9851620f6d01b846ed5bed9"; logging-data="2987766"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18asDesJJtrUIDAyepiyHYo" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:63FoMuU3eGN2e/FXLFnSPFYu6jg= In-Reply-To: Content-Language: en-US Bytes: 4487 On 6/8/2024 1:57 PM, Bertrand Sindri wrote: >> I.e., whatever criteria are used, it obviously is designed to reject >> MOST sources of line noise. Pity the folks trapped in that burning >> building who fail to hit whatever design window is accepted (WHILE >> the copper is burning) > > Which is just what the atty., worried about a possible lawsuit, is > worried about, and why they force the engineers to program the switch > to recognize "stuff" that isn't perfectly to spec. Remember, here, this is all covered by law that clearly defines the responsibilities of the provider. One could see the telco's lawyer arguing: "And, should we also detect two hookflashes, followed by a 3 minute delay and another four hookflashes, a 2 second delay and three more in rapid succession as the leading '9' -- and, not an elderly person slowly dialing 2 4 3..." Recognizing "outliers" isn't easy. I suspect the switch doesn't even look for a '9' followed by a '1' and another '1'. Rather, some "abnormal" line activity. Could a two-year-old playing with a phone happen to dial an emergency services number -- how is 6 2 1 1 1 not seen as 9 1 1? The switch likely can't store much state for each possible subscriber. So, it can't "learn" what to expect from a particular line: "Oh, that's Don's line and the insulation on his pair have obviously degraded to result in lots of noise on an otherwise functioning pair." Instead, it has to adopt a one-size-fits-all algorithm. But, this has to address legitimate 911 (dial pulsed) calls accepting the tolerances on how fast the dial can "return to home" (in the presence of a "fat finger") as well as all of these hypothesized attempts at POSSIBLY needing assistance and being inept in your dialing. The downside of false positives is that of increased externalities; someone ELSE pays for the problem (potentially, adding bias to future emergency responses -- "boy who cried wolf"). "In Grand County, home to a busy mountain called Winter Park, Sheriff Brett Schroetlin decided in late December to devote less attention to the crash-detection calls. Now if a 911 operator receives one from the slopes and no one is on the other end of the line, they know to ignore the call; no more referrals or follow-ups. None of the ghost calls so far have been real emergencies, Sheriff Schroetlin reasoned, and he couldn’t afford to waste limited resources." I put a weight on each "potential emergency" scenario that I detect. I will bother the occupant before I will bother a (remote) family member. The family member before a nearby neighbor. And, the neighbor before the police. But, I can do this because I have more information than a string of break/makes as well as intimate knowledge of the occupant and scene.