I had a 400 as a kid, and one of my first successful reverse-engineering projects was rewiring an old surplus microswitch terminal keyboard to connect to the 400's keyboard port. Good times.

If an airplane on autopilot flies into the side of a mountain, it's the pilot's fault. No difference in this case.

Besides the mentioned error in estimated reserve energy capacity:

Back in the days of carbon-zinc batteries, you could safely run them down to "near-dead" (~0.6v) and they would keep their physical integrity, for up to a few months perhaps, before the zinc outer casing ate through and exposed the corrosive electrolyte paste to the insides of your hapless electronic device.

If you do that with an alkaline battery, they tend to start leaking a corrosive liquid much more quickly, in days to weeks. And their liquid leakage gets everywhere and is more damaging.

This "Batterizer" idea isn't being promoted by someone who understands battery physics.

Comcast business subscriber here and have what appears to be a very similar config to yours. No problems with mail, checked mxtoolbox anyway and all is green. As many others have said, it's probably something your network did. I've had folks get into mine over the years and cause similar problems for me.

The FDA and other regulating bodies have meticulous requirements for the archival of all medical device records, software, design history files, test reports, etc. Compliance with these requirements is one of their favorite things to audit, and medical firms typically have an entire document control department on hand to look after these things. Implantables have archiving requirements which can exceed 100 years.

^THIS

Implantable pacing devices, cardioverters, and pumps (life-sustaining devices) depend on complex custom hardware designs as their platform, and that hardware is *highly* interactive with the software. Many of these devices can only achieve their miraculous longevities on a primary cell by deferring functions to hardware. If you don't have access to the information re: the hardware, the code itself might as well be inscriptions in Atlantean glyphs. You'd have to bust trade-secret protection to get a public viewing of everything needed to review the code, because you'd have to see, *everything*.

Implantable pulse generator firmware isn't written for a standardized platform. These devices all contain highly customized hardware, very complex ASIC's with lots of hardware-assisted power savings functions, sleep timers, bidirectional control registers, etc. and the designs vary greatly from model to model, company to company. Without at least a working understanding of this hardware you will only have a cursory and likely somewhat inaccurate view of what's really going on inside an IPG just from looking at the source code. I'm quite familiar with this, I design automated test systems and test code to validate and perform quality test on IPG's!

I grew up in the woods just north of Duluth. I've seen what happens to folks from CA who go there in winter (frostbite is a damn ugly thing, when the parts start falling off). ^^