ejiblabahaba

Depends what you're doing. Most smaller surface-mount components and these days even a lot of standardized through-hole components can be assembled via pick and place machines and reflow ovens, which are largely automated. Larger components may require some extra steps like a small blob of glue to fix them in place - this comes up a lot for edge connectors, switches, or other larger mechanical components where the weight distribution doesn't allow them to rest flat on the board during reflow. Larger through-hole devices might need assistance with initial insertion or may be paired to other mechanical interfaces like a heatsink which requires some manual interaction. In some cases (particularly for boards with through-hole components all on one side) the soldering step can be automated by wave soldering. There's still some constraints on what can be automated, but it's all a lot less manual than the 90s/00s.

Some components, particularly transformers, might also be constructed by hand for custom/complex structures. That's component assembly rather than board assembly, but it's a consistent source of manual labor involvement in the supply chain.

Design for manufacturability is one of the important goals being considered in any PCB design. High-volume or low-cost boards will optimize for automated assembly and find ways to substitute or eliminate components with higher assembly costs. Extremely high-volume boards like in smartphones can justify custom tooling if it helps automate assembly.

There's basically no point. Desktop PSU is a solved problem, most designs are all about cost engineering and the tiny sliver of higher power and ultra high efficiency options are not struggling with their current form factor.

In the data center, where power (and cooling) are the only significant OpEx, GaN point-of-load conversion is everywhere. Common as a rack distributed 48V to 12V bus or direct to processor Vdd (2% duty cycle is feasible with GaN thanks to fast on/off times). There was a while where GaN was used as part of the power factor correction for AC to DC in the server power supply, back when passing 400VAC or 800VAC bus around made sense. I think these days it's mostly back to DC buses, and AC-to-DC is all happening farther back, in part because of widespread solar deployments and trying to avoid DC->AC->DC double conversion losses when possible. So maybe GaN gets use on active secondary rectifier in the bus -> 48V now too.

Well, kinda. The value is in meeting the spec, yes, but the "certifiable" part is very often a subset of the actual spec. Sort of like in software how someone will inevitably depend on every feature of a public API (including the defects), a lot of early military electronics depend on implementation details of their component processes, usually by accident. The cost for semiconductor companies is not meeting the spec, it's keeping a production line from the 1960s running exactly the same way for a single customer who buys a handful of parts every year.

The problem with Chinese semiconductors isn't performance or meeting specs, at least not these days. It's counterfeits, life expectancy of the source companies, and the obvious risk of basing your supply chain on a foreign political actor that can leverage this dependency against you.

I wouldn't be so quick to make guarantees. There's cheaper spec-equivalent devices, sure, but a frequent and recurring feature of military hardware prior to the 2000s is an unexpected dependence on non-spec device characteristics. I've seen seemingly inconsequential cost-saving process tweaks identified as the root cause for novel testing failures for more than one ancient US military project.

Setting aside that approximately no one is shooting down quadcopters with missiles, that quadcopters and missiles are entirely different categories of weapon with substantially different range/payload/response time targets, and that the availability logistics and acceptable failure rates of paramilitary gangs and impoverished former Soviet belligerents from whom we are likely drawing conclusions about drone warfare economics are maybe just a step or two below the average US military procurement contract requirements; and charitably interpreting your argument as a generalization that repurposed consumer-grade electronics offers a cost reduction over military-grade selections for equivalent performance: true in most modern cases. The US has plenty of cheap domestic options for seemingly pricy problem domains, just ask SpaceX. SOTA in aerospace and defense routinely uses commercial products to great effect. To the extent that shelling out for a $60 military-grade 1960s transistor instead of a $0.06 commercial equivalent is a problem for the US military, it is downstream of enormous legacy cold war capital investment in technology that was novel for its time but is comparatively brittle by modern standards. This is still a problem, to be clear, but a small one in the grand scheme of US military spending.

Suppose an asteroid strikes the Earth and all human life becomes extinct. What power, specifically, has been transferred, and to where?

I think the question was less about the efficacy of ABS, and more about the failure mode. Is it possible for the ABS system to "fail open" unintentionally, such that depressing the brake pedal has no effect whatsoever?

My employer blocks access to Google Docs as part of our confidential information protection policy. They're certainly not the only ones. I'd hesitate to call on-premises file management "specialized needs" - rather, it's (still) the default, particularly if you take a peek outside of the software bubble.

Historically this was a huge concern because not every manufacturer implemented their ESD protection properly; or, on occasion, the process technology meant that ESD protection would hinder the functionality of the device. This happened a lot in RF circuits, and still to this day many RF instruments are extremely sensitive to ESD events. Board assembly was also a lot less automated in the early days of integrated circuits, so more human handlers and more opportunities for ESD events were anticipated.

Modern IC ESD protection is very effective against a few moderate energy events distributed on different pins, and there's a few industry standards that help determine the required amount of caution for dealing with a particular IC (HBM or human-body model, and CDM or charged-device model, are common - targeted toward human assembly procedures and things like triboelectric or inductive charge buildup). In the right climate, a single high energy event is sometimes enough to degrade functionality or (rarely) completely destroy the device, so board assembly and semiconductor manufacturing facilities still require workers to use wrist straps, shoe grounders, mats, treated floors, climate control, etc. Some high voltage GaN work I did years ago required ionizing blowers (basically a spark gap with a fan) because GaN gates are easy to destroy with gate overstress, and there are risks involved with unintended high voltage contact with typical ESD protective solutions. In another embedded-focused lab, the only time I've ever seen someone put on a wrist strap was for handling customer hardware returns. It really depends what you're working with, and in what environment.

I've more frequently (once or twice a year) had devices which exhibit symptoms of something being wrong at the inputs or the outputs, but only on a specific pin or port. For outputs, some symptoms include the output slew rate is inadequate, or the output appears stuck sometimes, or the output has higher than expected voltage noise (though this is a non-exhaustive list). For inputs, the symptoms are more complex - sometimes there's a manifestation at the outputs for amplifiers or other linear circuits, but for feedback systems or digital systems they might behave as though an input is stuck, toggling slowly, etc. which is difficult to distinguish from other, more common errors. I've also directly been the cause of several ESD failures, but in these cases the test objective was to determine the failure thresholds for the system, so I'm not sure that counts.

I've had a customer hardware failure that was eventually traced back to electrical overstress damage on a single pin of an IC near the corner of a board, right where someone might put their thumb if they were holding the board in one hand. In the absence of a better explanation, I suggested this was an ESD failure due to handling error. I never heard about it again, which is weak evidence in favor of a one-off ESD event.

These parts are bonkers. The ringing on its own outputs with a few inches of trace or (heaven forbid) a connector is regularly sufficient to self-trigger the automatic direction reversal. These things genuinely deserve the "experts only" label - they are close to unusable in the situations where you'd be most inclined to reach for them.

Learned a few tricks that I'm sure are buried on fstring.help somewhere (^ for centering, # for 0x/0b/0o prefixes, !a for ascii). I missed the nested f-strings question, because I've been stuck with 3.11 rules, where nested f-strings are still allowed but require different quote characters (e.g. print(f"{f'{{}}'}") would work). I guess this got cleaned up (along with a bunch of other restrictions like backslashes and newlines) in 3.12.

F-strings are great, but trying to remember the minute differences between string interpolation, old-style formatting with %, and new-style formatting with .format(), is sort of a headache, and there's cases where it's unavoidable to switch between them with some regularity (custom __format__ methods, templating strings, logging, etc). It's great that there's ergonomic new ways of doing things, which makes it all the more frustrating to regularly have to revert to older, less polished solutions.

Because, unlike most professions, ATC is immediately, personally responsible for making decisions for which a slight mistake could instantly claim the lives of hundreds of people.

Which language is this? I'm sure some people can clue this together from the hints, but I'm not one of them.

For what it's worth, this post just helped me explain several years of failure to wake from sleep state, across several different MSI-based machines, when I've connected them to an HDMI port in my TV. I think this debug is interesting in its own right, and unlike 99% of the content on this website, it was directly and immediately useful to me. I doubt I'm the only one, too.

A lot of these environments inherit a visual presentation style (ladder logic) that comes from the pre-computer era, and that works extremely well for electrical schematics when conveying asynchronous conditional behaviors to anyone, even people without much of a math background. There's a lot of more advanced functions these days that you write in plain C code in a hierarchical block, mostly for things like motor control.