Ask HN: What's the hardest problem you've worked on recently? | Hacker News Reader

Ask HN: What's the hardest problem you've worked on recently?

3 pointsgffrd5 comments

… and how did you go about solving it?

Could be anything: relational, technical, political, physical, etc.

Asking because I'm just curious to hear what interesting problems people are working on, and to see the different (or similar!) approaches people take to solving them.

Maybe seeing how someone approached a problem in an unrelated field holds the key to solving one in your own …

View on HN

2FA. After reading Terrence Eden’s hypothetical post about being locked out of everything after a lightning strike I reconsidered a lot of my security practices. Whilst unlikely I have everything burned to a crisp it is plausible. For example if your Yubikey gets destroyed, you have to have a recovery code, but then where do you store the recovery code? We’re lost in a recursive 2FA hell. I have various strategies for this but I can’t publicly state them here but I am fairly certain I can bootstrap myself back into my digital life in the worst case.

Bridging the gap between the young bloods who knew the specifics of hot new technologies and the old dogs that had been designing systems for decades.

One cohort knew what tools to use, the other what design patterns to follow.

Each group had their own pre conceived notions to overcome and some pride to swallow.

So … how did you solve it? Did it solve itself organically, or did someone have to step in and broker a middle ground?

The hardest problem I worked on was only hard relative to my own ignorance level - it wasn't necessarily "hard" in any objective sense. And frankly, to an experienced EE it would have probably been trivial. But I'm mostly a self-taught hobbyist when it comes to electronics and there are lots of gaps in my knowledge, so...

Anyway. The problem was this: I want to power a Raspberry Pi from a battery. OK, that's easy enough in and of itself. Use a USB "Power Bank" device, and bob's yer uncle. But... I need this thing to be up and running close to 24x7 and it also needs to be portable. So AC for charging the battery will be coming and going on an unpredictable basis. Superficially this looks easy: just package a USB mains powered charger in the box, plug it into the charging port of the Power Bank and bob's yer uncle. But... it turns out that RPi's are fairly power hungry and (at least some) USB Power Bank devices limit their charging rate to less than the rate at which an RPi consumes current, so they battery can drain down even when the charger is plugged in. This is sub-optimal.

So I decided I wanted a circuit of some sort to let me connect both the mains adapter and the Power Bank to the Pi more or less simultaneously, and have it automatically switch between then using the rule "use power from the mains adapter when available, otherwise use the battery". Some constraints I set were:

1. The Pi can't reboot or glitch when the switch happens.

2. No "back current" can flow from either power source through the other, ever.

3. The battery cannot be discharging into the load at all when the mains power is available.

So I whipped up a few circuits to try to do this with a pair of MOSFETs, one for each power rail. But here's the big rub, that it took me embarrassingly long to understand: the power rails are ultimately bonded together at the output terminal, and electrical fields will spread wherever there is a conductor. And semiconductor devices that block current flow don't necessarily block electrical fields. The net-net being, the AC powered rail always has an apparent voltage on it, even when the mains adapter is unplugged, because it's coming from the battery. And that makes it very hard to implement any logic based around "turn this transistor on, and this one off, when power is present on this rail" and vice versa. But the rails are effectively the same in terms of always having an apparent 5V potential. And MOSFETs are, well, "field" effect transistors, so any apparent voltage affects the state of the FET even if a transistor or diode "upstream" is blocking current flow.

In the end, I "solved" this by ditching the semiconductor approach temporarily and using an old-fashioned electro-mechanical SPDT relay. But this has all the disadvantages of relays: they draw more power, generate more heat, take up more space, and have a limited lifespan.

So I still have some ideas about how to make it work in a semiconductor based approach, that I need to experiment with. One is to use BJT's for the power handling instead of FETs. I think this might "just work" since BJT's require current through the base->emitter path to "turn on". Another possibility is to add a current-sensing shunt resistor on that AC powered rail, and use the presence or absence of any current flow to make the logic decision about the system state. The reasoning being, when the power is coming from the mains adapter, there will be current flow through the shunt resistor. But if it's coming the "other way" so to speak, current flow can be blocked by a transistor or diode. So I think I can make something work based off of this idea.

Anyway... still some experimenting to do, but for now I do have something in place that works. But yeah, I pulled some hair out in frustration (and wasted a lot of components) while trying and failing to get this working.

Thank you for sharing this, and for actually walking through the problems you're hitting, your process for unravelling them, the decisions you're taking, and the outcome.

I see in your response a joy of being totally in an area that's unfamiliar and new, and full of new boundaries and rules to find.

(I'm a Designer—UX—by trade, and have been recently been working on some problems that require software engineering / systems architecture, which I have zero formal training in … and I'm having the time of my life.)

Questions: — What are the resources you found most valuable along the way? — What thing that you learned got you the most excited?

Also … hope you didn't burn out any Pi's, given how hard they are to come by at the moment …

Reply on news.ycombinator.com