Are My Devices So Smart That They're Dumb?

[anorlunda]

I have two portable USB battery chargers. They are different brands. See the picture.

Both of them charge a cell phone fine, but they won't charge my hearing aids in the aids charger. When I plug them in, they charge for 10-15 seconds, then shut off. Both devices do approximately the same.

It occurs to me that those devices may have circuitry to detect if a load is plugged in. If not, they shut themselves down. I have a theory that the hearing aids current draw is so low that the device thinks "no load at all."

Might I be correct on that theory? or is there a better theory?

 

[Bystander]

Might I be correct on that theory? or is there a better theory?

"Turnip friendly?"

 

[Baluncore]

Might I be correct on that theory? or is there a better theory?

Maybe and probably, but there are many possible theories.
Put a resistive load, with a volt meter, across the charger.
Find the resistive load needed to keep the charger operating.
That should answer your question, or refine the search.

 

[jedishrfu]

Yes, its happened to me. Try charging your hearing aids as you charge your phone with the same battery. It should work fine as the circuitry sees enough current being drawn.

 

[Wrichik Basu]

It occurs to me that those devices may have circuitry to detect if a load is plugged in. If not, they shut themselves down. I have a theory that the hearing aids current draw is so low that the device thinks "no load at all."

Might I be correct on that theory? or is there a better theory?

Seems you are correct. We have the same issue with our 27000 mAh power bank. It charges phones fine, but if we connect our digital blood pressure monitor or handheld nebulizer machine to it, it shuts down after some time. In fact, even what @jedishrfu suggested above doesn't work for this one, which probably implies that it can control the ports independently of each other.

 

[PeroK]

It will only get harder over time to outwit technology that thinks it knows best!

 

[nsaspook]

There are battery packs with Always On capability.
https://voltaicsystems.com/always-on-batteries/

We use these for online UPS backup power for small USB powered compute devices.

 

[Hornbein]

We rented a car. I chose to unlock the rear door by reaching in through the open rear window. The car shut down completely. We had to call the rental agency to get the secret code to reenable it. Good thing we had phone coverage and weren't in a life-threatening situation.

 

[anorlunda]

We rented a car. I chose to unlock the rear door by reaching in through the open rear window. The car shut down completely. We had to call the rental agency to get the secret code to reenable it. Good thing we had phone coverage and weren't in a life-threatening situation.

Wow! That's frightening. Thank God they don't allow security systems like that in the cockpits of airplanes or the cabs of fire trucks.

 

[Hornbein]

Wow! That's frightening. Thank God they don't allow security systems like that in the cockpits of airplanes or the cabs of fire trucks.

Actually unexpected things like this are a cause of major airplane accidents. The software gets into some unusual mode without the pilots being aware of it. Disaster may ensue.

 

[anorlunda]

Actually unexpected things like this are a cause of major airplane accidents. The software gets into some unusual mode without the pilots being aware of it. Disaster may ensue.

Agreed. Along with the theme of this thread, so smart that it is dumb, flight control issues such as you mention are exactly on target.

When I first became a volunteer firefighter, I was surprised to learn that no key is required to start a fire truck. But 5 seconds of thinking made me understand why.

My favorite book on computer security was the DEC VAX/VMS Security manual. They defined security as preventing unauthorized use, but more important to never impede authorized use. I have never seen that repeated in any other discussion about security. That is sort of the topic in this thread.

 

[Hornbein]

Every now and then software I use gets into a weird mode that are hard to get out of. If I had become an airplane pilot then this might result into my smashing into the Earth at high speed after five minutes of desperate struggle.

My "favorite" case was when the airliner software was so screwed up they resorted to rebooting it. Some unfathomable condition wasn't met so this attempt failed. All software shut down, the control panel went blank, catastrophe followed shortly afterward.

In my unscientific view passenger airplane crashes come down to either extreme weather, bigtime hardware failures, pilot error, software getting into an arcane mode, or murder/suicides by the pilot. There are dozens of controls and having even one knob be not set as it should may be fatal. I learned that the reason for the copilot isn't so much that the pilot might become incapacitated, it's that during landings and takeoffs there is more to deal with than one person can handle. During an emergency there may be more to deal with than two people can handle. Then whether the overflow gets you is largely a matter of chance.

 

[Remy Dyer]

Boeing 737 Max. MCAS qualifies I think: literally forced two planes straight into the ground. Broken sensor.
In all of these cases, a designer / programmer is being too clever: making design choices because they think they know best.

Wiser programmers stick to “Keep It Simple & Stupid” for a reason.

 

[jedishrfu]

The MCAS disaster was more complicated than that. MCAS was added to counteract an engineering fault as Boeing tried to compete with Airbus and added larger engines without a full redesign of the aircraft And wanted to avoid costly pilot retraining.

Effectively using software to correct a hardware defect. Ultimately this goes back to management overriding engineering concerns. But of course everyone blames the programmer.

https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System

On the MAX, MCAS was intended to mimic flight behavior of the previous generation of the series, the Boeing 737 NG. During MAX flight tests, Boeing discovered that the position and larger size of the engines tended to push the nose up during certain maneuvers. Engineers decided to use MCAS to counter that tendency, since major structural redesign would have been prohibitively expensive and time-consuming. Boeing's goal was to have the MAX certified as another 737 version, which would appeal to airlines for the reduced cost of pilot training. The Federal Aviation Administration (FAA) approved Boeing's request to remove a description of MCAS from the aircraft manual, leaving pilots unaware of the system when the airplane entered service in 2017.[2]

 

[Remy Dyer]

Boeing 737 Max. MCAS qualifies I think: literally forced two planes straight into the ground. Broken sensor.
In all of these cases, a designer / programmer is being too clever: making design choices because they think they know best.

Wiser programmers stick to “Keep It Simple & Stupid” for a reason.

Having thought about this a little longer: I think I've done a disservice to many junior programmers. The ones who are actually doing the work.

What's most likely, is that said programmers realized there would be an issue, and probably just set about following the obvious train of logic and the requirements necessary to fix it, when their boss noticed, and forbade them 'wasting time', because 'that will never happen'.

If you're the junior programmer, I'd like to recommend you read Chris Voss's works on negotiation, because guess what? It's not your bosses reputation on the line here, it's your reputation and future career, and you have in fact in the right to follow the 'obviously this is the only correct thing to do' logic. Your boss doesn't care because he's a lot closer to retirement, and probably he already leaves all the actual programming, ie, the work, to you anyway.

My advice then is to care, and not let this sort of thing through, but do so as sensibly as you can. You'll need to be a good negotiator, and you'll need to arrive at a solution that honestly makes everyone happier. Maybe point out how this is an advantage, and will create market differentiation (good if he uses the 'it's ok because no-one else does' excuse).

Either way, not doing anything, or just sticking your head down and failing to fix the problem - all of these are fails, that may haunt you. It's not always easy to figure out what is necessary and what is not - be aware that it's all too easy to become invested in your own work, because it's your own work.

The litmus test is whether the failure more you are concerned about is 'reasonably foreseeable'.

If it's something you have evidence of, however oblique, then it does meet that test. Preferably bring up such a case your boss knows of, and give him a 'searching for a no' question. (one he'll say 'No' to, like 'do you want us to look like fools?' or some-such. Saying no will make him feel in control. For other great little nuggets of wisdom - again, Chris Voss).

From there you want to note that this is really just a 'little thing' of the kind that when taken care of, will ensure that the 'big things' fall neatly into place. Also note the 'devil is in the details' and details like this one is what separates the good from the trash. Try to sell it as what it really is: An opportunity to improve.

The whole KISS thing isn't wrong, but making allowances for such as 'what if it needs to reboot in flight' are actually things you DO need to chase down and do something about. Robustness is the expectation, and you'd better meet it.

For the battery pack, it could have gone down something like this: (PFY is the guy doing the work, PHB is the pointy-haired-boss in charge. Yes, it really is just like Dilbert).

PFY:'Boss, we need a more accurate chip so we can detect if someone's charging their hearing-aids".
PHB: Don't worry about it, it'll blow our parts budget. We'd need it to work down to 0.1% current and that's not reasonably cheap. Our competitors don't bother, and we have to be competitive, so we don't need to fix this.
PFY: 'Oh, ok'.

In this specific case, the PFY could have even realized that there was a cheap solution available that would work in all cases - but it would take a little more prototyping time to figure it out, which the boss would have vetoed as 'a waste of time'.

The problem isn't dumb engineers/programmers, it's bosses who think they have everything figured out, but who no longer actually do real technical work any more.

They push papers, remember how quick and easy all that technical work once was (never remembering the long hours that they were so busy their brains couldn't even note that time was passing) and feel like the new generation is slow and stupid, and won't to pursue flights of fancy and other yak-shaving exercises.

Thus they feel like the timelines they estimate all work should be completed by are perfectly accurate, even though they are always unrealistically optimistic - and try to force everyone to keep up with their broken expectations. So the poor guy doing the actual work, is probably trying to fix things just having discovered this new issue, and is already probably running deep 'behind schedule'.

The only solution for all of the above? If you are the guy actually doing the work, and your boss isn't listening, you need to learn better negotiation skills. Don't 'look up' to your boss for their negotiation skills, because in this situation, it's clear they have actually atrophied away from disuse, being that they're in a position of power. Although honestly, they were probably equally bad when younger: It's just that now they have authority. so they no longer need to get any better.

There's no easy solution - we all face situations where the room is against us, where we have something unpopular to say, and where we don't have the authority to just 'have our way'. But it turns out, you don't actually need that authority, you just have to learn how to get about without it.

 

[berkeman]

Ack. Thread closed temporarily for Moderation and possible split-off of off-topic dicsussion. Ack again...

 

[berkeman]

Actually, upon further review, @anorlunda is the OP and he is actively participating in this diversion of the discussion, so as long as he's okay with it, the thread is reopened. Thank folks (interesting discussion BTW).

 

[anorlunda]

Thanks @berkeman.

Yes, I like the idea of this thread being a more wide discussion.

 

[Rive]

My favorite book on computer security was the DEC VAX/VMS Security manual. They defined security as preventing unauthorized use, but more important to never impede authorized use. I have never seen that repeated in any other discussion about security.

...Wish I could explain that to our IT department