EDN Network

Many folks have bench type LCR meters available and employ the usual general purpose Kelvin type clips or direct connect fixtures for most measurements. When encountering SMD components these measurement tools/methods can become difficult and frustrating for quality repeatable measurements, especially true for low Z components.

Wow the engineering world with your unique design: Design Ideas Submission Guide

The specialized SMD fixtures which utilize horizontal “plungers” perform well except with very low-Z components. The difficulty is due to the force and sense Kelvin connections being made at the small brass bolt that threads into the bottom of each plated brass plunger.

This leave the path from the small brass bolt through the plunger to the device under test (DUT) surface connection uncompensated and relies on the zero/short calibration for correction, which often leaves more measurement uncertainty than desired. Which is especially noticeable with very-low-Z SMD components such as resistive current sensing shunts, where one desires an accurate and repeatable low resistance measurement.

Having suffered with low-Z SMD components and measurement issues often, this created an opportunity to investigate other approaches outside the usual expensive OEM solutions (well out of budget). One idea came to mind was the technique of utilizing a lever toggle arm that worked well in the SMD adapter created for the Tek 577 Curve Tracer.

A custom PCB was developed to directly connect via 4 BNC connectors to the benchtop LCR meter, similar to the way OEM LCR meter fixtures behave. The SMD DUT would be held in place against the PCB exposed surface with the lever toggle arm similar to the concept with the Tek 577 adapter.

Both sides of the PCB were originally utilized to allow the lever arm to be located on the left or right and not interfere with the LCR meter controls and display as shown in Figure 1. This also shows the Tek 577 adapter along with another PCB version which doesn’t have direct BNC connections. 

Figure 1 A custom PCB developed to directly connect to the benchtop LCR meter via 4 BNC connectors. 

Figure 2 shows the LCR meter connection on a Tonghui TH2830 bench LCR meter.

Figure 2 The custom PCB connected to a Tonghui TH2830 benchtop LCR meter.

The LCR meter and SMD DUT fixture connections for meter Hcur (force) and Lcur (sense) contribute significant impedances, some meters can deliver over 100 mA, which can produce errors in the meters sense terminal Hpot and Lpot affecting results.

Using the PCB split-Kelvin technique developed where the DUT SMD makes contact with the exposed PCB surface but the force and sense connections are made separately by the DUT end conductive terminals because the PCB contact area is “split” between force and sense on the high and low sides. This allows the impedances “looking back towards the meter” and the highly variable DUT contact impedance to be within the meter Kelvin control grasp and significantly reducing DUT measurement uncertainty. 

Another PCB version was also developed where the PCB doesn’t host the BNC connectors, but is smaller and fits onto a smaller supporting case with the BNC connectors that is a repurposed cheap LCR meter Kelvin cable/clips case as shown in Figure 3 and Figure 4.

Figure 3 Layout of another custom PCB version developed to directly connect to the benchtop LCR meter via 4 BNC connectors. 

Figure 4 The alternative fixture developed, where the PCB does not host the BNC connectors. Instead, it is smaller and fits onto a smaller supporting case with the BNC connector.

Note in Figure 5 where a shield was added in the case between the high- and low-side BNC connectors to improve isolation.

Figure 5 Wiring inside the smaller, alternative fixture that directly connects to the benchtop LCR meter via 4 BNC connectors. 

Various PCBs were investigated over the span of a few months and it was observed that the PCB surface contact with the SMD DUT could be improved by having gold-plated contact areas and/or by increasing surface contact roughness.

Surface roughness was improved by adding copper filings mixed with solder paste and flux and reflowed onto the DUT contact, see Figure 6.

Figure 6  Surface roughness was improved by adding copper filings mixed with solder paste and flux and reflowed onto the DUT contact. 

A small piece of thin copper sheet cut to 2512 size makes a good zero/short calibration reference device. Caution with the so called “zero-ohm” SMD components, these were found to have significant impedance for most all sizes, and the thin copper custom cut proved the better reference.

Operation with the Hioki IM3536 LCR meter is shown in Figure 7.

Figure 7 Testing “zero-ohm” SMD components on the custom fixture for low-z components with the Hioki IM3536 LCR meter.

Anyway, these various custom fixtures have proven beneficial in daily LCR SMD measurements, and the latter version with the repurposed case (Figures 4, 5 and 6) especially useful and highly stable and repeatable. Hopefully others will find these custom DIY LCR Meter fixtures useful.

Michael A Wyatt is a life member with IEEE and has continued to enjoy electronics ever since his childhood. Mike has a long career spanning Honeywell, Northrop Grumman, Insyte/ITT/Ex-elis/Harris, ViaSat and retiring (semi) with Wyatt Labs. During his career he accumulated 32 US Patents and in the past published a few EDN Articles including Best Idea of the Year in 1989. All posts by Mike Wyatt below:

Related Content

• DIY custom Tektronix 576 & 577 curve tracer adapters
• Tracing a transistor’s curves
• Throw it a curve (tracer)
• Trace voltage-current curves on your PC
• Using oscilloscope X-Y displays

The post Custom DIY LCR SMD fixture for low-Z components appeared first on EDN.

The pages of Design Ideas (DIs) have recently been awash in a veritable cascade of designs for variable frequency oscillators with frequency ranges tunable over multiple decades:

• Self-oscillating sawtooth generator spans 5 decades of frequencies
• 555 VCO revisited
• 5 octave linear(ish)-in-pitch power VCO
• Tune 555 frequency over 4 decades
• Wide-range tunable RC Schmitt trigger oscillator

But despite the size of this crowd, a notable feature missing from all is provision for digital control (e.g., from an MCU GPIO pin) of the oscillation frequency. This DI will address that topic.

Wow the engineering world with your unique design: Design Ideas Submission Guide

When starting the design of any digital to analog interface, the first question to be answered is how much resolution (bits) do we need? For the applications listed above, the answer isn’t obvious. That’s because of the extremely wide range  of  the analog quantity (frequency) involved, e.g., 100,000:1 for Christopher Paul’s 5-decade 10 Hz to 1 MHz sawtooth generator.

5 decimal decades = 10ppm and is equivalent to a linear binary resolution of 16.6 bits.  So even if we went with the overkill choice of 16bits (1/65536 = 15ppm), we’d still lose resolution at the bottom end. The first least significant bit (lsbit) increment up from 10 Hz would comprise a 15 ppm of 1 MHz = 15 Hz jump to 25 Hz, nearly trebling the output frequency. 

Figure 1’s circuit takes an approach very different from linear conversion. Working from mere 8bit PWM, it makes lsbit incremental resolution constant and uniformly distributed at ~5% of output.  Here’s how it works.

Figure 1 Antilogarithmic 8-bit PWM gives s constant incremental ~5% per lsbit. Asterisked parts are 1% or better precision (metal film or C0G).

Antilog conversion occurs in a four step ~1ms cycle defined by the combined states of the GPIO PWM bit and D flip/flop decoded by the 4052 analog switch as shown in Figure 2.

Figure 2 Tw = antilog RtCt timeout = 1 to 250 counts = 2 to 500 µs, where
PWM = 1 + 21.63*Ln(Imax/Iout)

The antilog conversion sequence is as follows: 

• BA = 3. duration 12 µs. Timing capacitor Ct charged to Vdd – 1.24 V.
• BA = 2. duration Tw = 2 µs to 500 µs. Ct exponentially discharged toward Vdd with time-constant RtCt = 43.4 µs.
• BA = 1: duration 0 to 498 µs. Ct  residual charge transferred to Csh sample and hold cap.
• BA = 0: duration 2 µs to 500 µs. Ct  residual charge continues to transfer to Csh.

At the end of each 4-step, 1024-µs cycle, Csh will converge toward a charge relative to Vdd between 12 µV and 1.2 V, determined by the antilog of the 2 µs to 500 µs duration of phase 2 of the conversion sequence. The 1-µV typical input offset of the LT2066 makes this adequate for (reasonably) accurate digital to analog conversion. Convergence of Vcsh to 8-bit precision takes a maximum of 8 cycles = 8.2 ms.

Final conversion of the resulting 5-decade current source to a 5-decade frequency output (the point of the exercise) can be done simply (if admittedly kind of crudely) with the circuit in Figure 3.

Figure 3 A minimal 5-decade sawtooth oscillator that enables final conversion of the resulting 5-decade current source to a 5-decade frequency output.

Or it can be done much more precisely with Christopher Paul’s DI by substituting Figure 1 for his original resistor-programmed current source (highlighted in yellow), as shown in Figure 4.

Figure 4 Maximal 5-decade sawtooth oscillator, using Christopher Paul’s DI.

Figure 5 Log (red) and linear (black) plot of source current versus PWM.

Stephen Woodward‘s relationship with EDN’s DI column goes back quite a long way. Over 200 submissions have been accepted since his first contribution back in 1974.  They have included best Design Idea of the year in 1974 and 2001.

 Related Content

• Self-oscillating sawtooth generator spans 5 decades of frequencies
• 555 VCO revisited
• 5 octave linear(ish)-in-pitch power VCO
• Tune 555 frequency over 4 decades
• Wide-range tunable RC Schmitt trigger oscillator

The post 5 decade antilogarithmic PWM current source appeared first on EDN.

Fuel cell sensors are electrochemical devices designed for precise measurement. In measurement applications, they have become the gold standard for breath alcohol concentration detection, valued for their ethanol specificity, stability, and courtroom-grade accuracy. Compact and low power, they form the backbone of law enforcement breathalyzers, workplace safety programs, and consumer devices, consistently outperforming semiconductor and infrared (IR) alternatives.

Their proven reliability in complex breath matrices has made them indispensable for safety and compliance, while ongoing innovation is extending their reach into broader analytical domains. And while fuel cells generate clean energy, fuel cell sensors generate precise measurements—a distinction that defines their unique role in modern technology.

Applications and history

Before we get into the basics of how fuel cell sensors work, it’s worth noting their application landscape. While research has explored microbial fuel cell biosensors for environmental monitoring and niche industrial uses, the overwhelming commercial reality today is breath alcohol concentration (BAC) measurement.

Fuel cell sensors have become synonymous with BAC detection because of their unmatched ethanol specificity, stability, and courtroom-grade accuracy. Although BAC formally refers to blood alcohol concentration, in practice it is estimated through breath alcohol analysis. This singular focus has defined their role in law enforcement, workplace safety, and consumer devices, making BAC not just their flagship application but essentially their identity in the marketplace.

Technology itself traces its roots to the 1960s, when early electrochemical cells were adapted to detect ethanol in breath samples. By the late 1970s and early 1980s, law enforcement agencies began adopting fuel cell-based breathalyzers, recognizing their superior specificity compared to semiconductor sensors.

Over time, improvements in miniaturization, catalyst stability, and calibration protocols transformed them from bulky instruments into compact, portable devices. This evolution cemented fuel cell sensors as the trusted backbone of alcohol detection, setting the stage for their enduring role in safety and compliance.

Figure 1 A compact breathalyzer with a fuel cell breath alcohol sensor—Alcotest 4000—simplifies portable BAC measurement. Source: Dräger

As a quick aside, while fuel cells rely on chemical reactions, IR spectroscopy uses light to identify alcohol’s unique spectral fingerprint. By directing an IR beam through a breath sample, the instrument measures the specific wavelengths absorbed by ethanol molecules.

This physics-based method is non-destructive and highly precise, enabling real-time detection of “mouth alcohol” that could otherwise distort results. Because of their sophistication, accuracy, and long-term stability, IR units are reserved as definitive, desktop-based instruments in police stations, providing the courtroom-grade evidence required for testimony.

Fuel cell breath alcohol sensors

Now is the time for a gentle dive into a bit of theory and practice. At their core, these sensors operate on an electrochemical principle: ethanol molecules in exhaled breath are oxidized at a platinum electrode, producing an electrical current directly proportional to concentration. This reaction is simple yet elegant, converting chemical energy into a measurable signal that reflects blood alcohol concentration (BAC).

In practice, this design delivers a combination of portability, stability, and specificity that has made fuel cell sensors the dominant choice for breath alcohol testing. Unlike semiconductor sensors, which can be affected by other volatile compounds, fuel cells respond almost exclusively to ethanol.

Their compact form factor allows integration into handheld devices, while their long-term consistency ensures reliable results in roadside, workplace, and consumer contexts. This balance of theory and application explains why fuel cell sensors remain the benchmark technology for BAC measurement today.

In a nutshell, a fuel cell breath alcohol sensor is essentially a pair of platinum electrodes immersed in a dilute acid electrolyte. When a trace amount of ethanol from exhaled breath reaches the electrodes, it undergoes oxidation, releasing electrons that flow as current. The magnitude of this current is directly proportional to ethanol concentration, providing a simple yet highly reliable way to quantify blood alcohol concentration.

And fundamentally, the fuel cell breath alcohol sensor consists of a porous, chemically inert layer coated on both sides with finely divided platinum black. The porous layer is impregnated with an acidic electrolyte solution, and platinum wire connections are attached to the platinum black surfaces. The assembly is mounted in a plastic case with a gas inlet for introducing a breath sample. While manufacturers add proprietary refinements to this design, the basic configuration is shown in Figure 2.

Figure 2 Drawing illustrates the basic construction of a fuel cell breath alcohol sensor. Source: Author

Hands-on with fuel cell alcohol detection

For those eager to explore fuel cell alcohol sensors, the FS00702 electrochemical ethanol content module offers a robust solution. This fuel cell–type sensor operates through oxidation and reduction reactions at the working and counter electrodes, generating charges that form a measurable current. Current’s magnitude is directly proportional to alcohol concentration, in accordance with Faraday’s law, enabling accurate determination of ethanol levels.

Equipped with a high-stability gas sensor and a high-performance microprocessor, the module supports both UART and analog signal outputs for seamless integration. Its precise automatic calibration and advanced detection systems minimize human interference, ensuring consistent accuracy and reliability in large-scale production environments.

Figure 3 Highlighting FS00702 key specs: enabling makers to detect ethanol with precision, rapid updates, and easy microcontroller integration. Source: Henan Fosen Electronics Technology

As a side note worth mentioning, ethanol is one specific type of alcohol—the compound found in beverages and fuels—whereas “alcohol” broadly refers to a family of related molecules such as methanol, propanol, and isopropanol.

Fuel cell sensors like FS00702 are calibrated for ethanol detection since it’s the relevant analyte for intoxication measurement and fuel monitoring. While the sensor may respond to other alcohols, its accuracy is optimized for ethanol, making precise terminology important in technical contexts.

Practically speaking, sourcing high-quality fuel cell alcohol sensors for hobbyist projects is challenging, since most manufacturers prioritize finished breathalyzer units or bulk industrial modules.

Still, there are accessible alternatives to FS00702 for makers who value the accuracy and specificity of fuel cell technology. The Dart Sensors 2-Electrode fuel cell is considered a gold standard for precision, though it requires a custom amplifier circuit.

Fosensor’s FS00701 provides a smaller footprint than FS00702, ideal for portable builds. Meanwhile, FS00702 itself remains versatile, offering both raw analog output for custom conditioning and a built-in UART option for straightforward microcontroller integration.

Winsen’s ZE321 automotive alcohol module offers a compact design with a convenient UART interface, making it more user-friendly for DIY integration. The ZE321 module operates on the fuel cell electrochemical principle. When the built-in pressure sensor detects exhaled air flowing through the sampling tube at the required rate, the solenoid valve quickly opens to admit a measured volume of breath.

Within the sensor, alcohol and oxygen undergo a redox reaction, generating an electrical current proportional to ethanol concentration. The module’s circuitry measures this current and, after algorithmic processing, outputs an accurate determination of breath alcohol content.

Figure 4 The ZE321 automotive alcohol module monitors exhaled breath flow, samples a fixed volume of gas, and actively detects alcohol content through its fuel cell electrochemical reaction. The onboard circuitry processes the resulting current signal to deliver accurate breath alcohol measurements. Source: Winsen

Accuracy today, innovation ahead

In practical terms, fuel cell–based alcohol testing devices deliver the highest accuracy in measuring breath alcohol content, leaving little room for error. Even so, it’s wise to allow for a small margin of discrepancy. When evaluating any alcohol detection instrument—whether for personal safety, workplace compliance, or automotive use—the sensor type is critical. If precision matters most, fuel cell sensor technology remains the benchmark to aim for.

For makers and engineers, the challenge is clear: fuel cell sensors are not confined to alcohol testing; they are gateways to precision sensing, sustainable energy, and inventive applications across domains. Experiment boldly, share your builds, and push the boundaries of what these devices can achieve. The next breakthrough could start on your workbench.

T. K. Hareendran is a self-taught electronics enthusiast with a strong passion for innovative circuit design and hands-on technology. He develops both experimental and practical electronic projects, documenting and sharing his work to support fellow tinkerers and learners. Beyond the workbench, he dedicates time to technical writing and hardware evaluations to contribute meaningfully to the maker community.

Related Content

• Hydrogen Fuel-Cell Vehicles
• Paper-Based Biofuel Cells Power Disposable Electronics
• xEVs Opening New Opportunities for Sensor Development
• Designing a portable system for in situ failure prediction in fuel cells

The post Fuel cell sensors: From breath to benchmark appeared first on EDN.

This two-part Design Idea (DI) follows on from a couple of previous articles relating to 100-Ω platinum resistance temperature detectors (Pt100 RTDs). The first of those (which we’ll call Ref 1) used a simple current-driven bridge to give an output of 1 mV/°C (or /K, if you prefer) that could be read directly on a DMM, while the second (Ref 2) had a ratiometric output to emulate an NTC thermistor but with greater range and accuracy.

Wow the engineering world with your unique design: Design Ideas Submission Guide

Ref 1 was useful but too simple: it was precise at its calibration temperatures of 0 and 100°C, but had an inherent error of nearly 0.4° at 50°C because an RTD’s resistance is not quite linear with temperature. Ref 2 compensated for that with good precision—and discussed how the Callender–Van Dusen (CVD) equations are key to doing so—but was rather specialized.

Finalizing and extending the circuit must wait for the second part of this DI. Its first part will use the heart of Ref 2 to implement the function of Ref 1 and find out what else needs fixing.

That heart is the fairly conventional circuit shown in Figure 1.

Figure 1 A simple circuit feeds the RTD, amplifies the resulting voltage, and uses some positive feedback to compensate for the sensor’s non-linear response to temperature.

Fairly obviously, Vref and Rfeed drive current through the RTD producing a voltage that is amplified by 1 + Rgain1 / Rgain2. That voltage is only nearly proportional to absolute temperature, so Rpfbk adds a little positive feedback to (almost) linearize the output. Its value is critically dependent on Rfeed and the gain, and, as described in Ref 2, is best found by iterated simulation. (Though later, we’ll see a useful shortcut.) Figure 2 shows the resulting error curve, which scarcely changes for gains above ~3 once Rpfbk has been optimized.

Figure 2 With compensation, the circuit’s output can be very close to ideal. (Real-world components may modify this somewhat.)

Our aim is to make a box that will give a DMM-useful 1 mV/°C output, but properly compensated. Figure 1’s circuit was a good starting point; now Figure 3 shows the end point.

Figure 3 Compensated gain stage A1a gives an output of just over 1 mV/°C, with an offset. A1b generates a voltage corresponding to that offset at 0°C. Tracking of the two op-amp halves should minimize errors.

A1a works just like Figure 1, using a 1.24 V reference. Using 3k3 for Rfeed and a gain of 6.6, its output sits close to 258 mV for an RTD resistance of 100Ω (0°C) and increases by ~1.05 mV/°C, which is dropped to a precise 1 mV/°C by R6 and R7. Keeping the gain trim passive and away from A1a’s feedback loops avoids any interactions. R5, our former Rpfbk, was calculated—or rather, homed in on—in the same way as its counterpart in Ref 2, using successive approximations in the graphical sim until the error curve was flattest.

A2b provides an offset reference at that ~258 mV level, so that 0°C at the sensor will give 0 mV across the outputs. It’s basically a clone of A1a to ensure good thermal matching. Calibration is easy: set the 0°C/0 mV point with R14, then trim R6 for an exact 100 mV at 100°C.

Even easier calibration

Ice-buckets and kettles are not really needed yet and are best saved for the final calibration with the actual sensor connected. For experimenting and troubleshooting, make up a gadget involving a carefully-selected 100-Ω resistor, a nominal 39 Ω with something in parallel to give 38.5 Ω, and a decent switch to short out the latter pair. Now you can easily flick between simulated 0 and 100°C inputs: easier and quicker than my original pot-based kludge.

Nicely balanced?

As noted above, A1b’s circuit is very similar to A1a’s. A trimmable resistive network could provide the reference, but this active approach ensures that any thermal effects in A1a will be balanced by those in A1b. After all, if two identical op-amps are sat side-by-side on a sub-squillimeter speck of silicon, they will behave identically, especially where temperature drifts are concerned, right?

Wrong!

Figure 3’s circuit worked perfectly, but for one thing: it wasn’t temperature-stable—not a good thing in a thermometer. Checking half-a-dozen MCP6002s mostly showed bad input-offset mismatches between the two halves. Those could be trimmed out, but unbalanced temperature drifts couldn’t—and they predominated, leading to reading errors of up to 1° for a 10° change in the circuit’s temperature. I did find one IC that was okay, but making this idea work properly called for a slightly different approach. All will be revealed in Part 2.

That feedback resistor

For the greatest accuracy at and around the 0 to 100°C calibration points, the value for Rpfbk is critical. (Those points are also used to define the slope against which the response is checked.)

For a wider range but with a different balance of errors, Rpfbk needs to be reduced. (Again, we’ll explore that further in Part 2.) Throughout, R5 or Rpfbk is shown to 4 or 5 places; it needs a little work to find the best series/parallel combinations. All other components were chosen from E12/24 values, though some need to be closely toleranced.

Now for that shortcut to determine Rpfbk. Some work with the simulator gave optimized values for Rpfbk with gain values from 4 to 100, with ad hoc curve-fitting suggesting equations giving good approximations to the target values. Here they are:

                Rpfbk = Rfeed × Gain × k
                where   Rfeed = 3k3
                                k = (2.19 – exp(1 / Gain)) / 2.70 [for Gains from 4 to 10]
                                or (2.035 – exp(1 / Gain)) / 2.31 [—from 8 to 100]

“Good approximations” means that the errors are always <0.05°C and mostly around 0.01°C, giving a good fit for temperatures from below -55 to above +125°C. If R3–5 are within 0.1%, errors due to their tolerances will be in the same range. All these circuits use a 3k3 feed resistor; I’ve not checked these equations with other values.

Await Part 2

We now have a basic circuit capable of decent performance, apart from its own tempco. The second part of this DI will fix that flaw, show some interesting variants—hence the plural in the title—and even add some bells and whistles. Think of this part as the theme, with Part 2 exploring the variations.

—Nick Cornford built his first crystal set at 10, and since then has designed professional audio equipment, many datacomm products, and a technical security kit. He has at last retired. Mostly. Sort of.

Related Content

• DIY RTD for a DMM
• Dropping a PRTD into a thermistor slot—impossible?
• Improved PRTD circuit is product of EDN DI teamwork
• Fake contacts, bounced to order
• Calculation of temperature from PRTD resistance

The post Newer, shinier DMM RTDs—part 1 appeared first on EDN.

How visibly different (if at all) inside are two generations of smart plugs, and is the more recent device’s comparative connectivity issue due to hardware, software, or a combination of the two?

Back in early December, EDN published my initial write-up in a planned series of posts covering experiences setting up and using devices from TP-Link’s two somewhat-overlapping smart home hardware, software, and service ecosystems, Kasa and Tapo. The first two products I’ve tried out (I’ve since added several more to the stable; stand by for additional details in future blog posts and teardowns) were both Kasa-branded and were also both smart plugs: the HS103, which I subsequently dissected here:

and its more diminutive successor, the EP10:

Newer is not necessarily better

My so-far sample set is small, so conclusions should be accordingly calibrated. That said, I’ve had no issues with any of the multiple HS103 devices I’ve so far activated here at the residence, whether in the initial setup steps or during subsequent usage. The same can’t be said, however, for the EP10. None of the devices I tried in either of the first two four-packs I purchased would successfully setup-connect to my Wi-Fi network. But both devices in the third two-pack worked fine…at least until I subsequently disassembled one of them. Meet today’s teardown candidate, as usual, accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes:

This particular two-pack was sourced from Amazon’s Resale (formerly Warehouse) sub-site, therefore rationalizing the non-TP-Link sticker stuck to the top of the box:

And since, as I’d mentioned previously, I got the idea to do a comparative teardown between the HS103 and EP10 after sending back for refund the original two four-packs of the latter, I can’t say whether their hardware versions matched this device’s v1.6 ID. v1.0 and v1.8 EP10 designs have also been shipped by the company (all three with multiple firmware releases):

Inside…

and underneath a sliver of literature, along with a bit of protective foam:

is our patient:

whose sibling, I’ve already noted, is in active use:

Chassis compaction and invasion

Some as-usual overview shots to start; the EP10 has dimensions of 2.36 x 1.50 x 1.21 in (60 x 38 x 33 mm) and weighs 0.13 lb (59 g) versus its slightly heftier HS103 predecessor at 2.62 x 1.57 x 1.5 in (66.5 x 40 x 38 mm) and 0.25 lb (113 g):

The LED-augmented on/off, pairing and reset switch is on the left side this time:

Theoretically, at least, the visible presence of a screw head implies a potentially simpler disassembly process as compared to the HS103 of the past. We shall see…

Once again, there’s a seam-inclusive topside, suggestive of the pathway inside:

And, last but not least, the bottom-side stamped specification suite, including the always-insightful FCC ID (2AXJ4EP10):

Speaking of pathways inside, let’s take the first step in the journey, shall we?

I wish I could say the two halves of the case then separated straightaway…but that’d be a lie:

Still, the mission was eventually accomplished, this time with an added bonus: no blood loss!

This YouTuber’s video (which, although it claims to be of an HS103, is actually of an EP10; note the switch location, along with glimpses of the bottom-side markings) bolsters my opinion as to the device’s lingering disassembly difficulty. Alas, I didn’t come across it until afterwards:

Comparatively boring front half first:

including a closeup of the left-side mechanical switch’s translucent insides:

Hardware commonality and variation

Now for the (rear) half I suspect you all mostly care about:

The relay on the right side is, at least in my v1.6 hardware version of the design, a Hongfa HF32FV-16, the exact same component I found a month back in my HS103 teardown:

However, the one in the video I just showed you, complete with a convenient “v1.8” hardware version sticker atop it, is blue in color, therefore presumably from a different manufacturer. As is the one shown in the FCC certification internal photos, which is sticker-less, but I’m assuming it references the initial v1.0 hardware design. And now for the other end, containing the digital and RF (control and wireless communications) sections, of which I’m most interested, both in an absolute sense and functionally relative to the HS103 predecessor:

Once again, there’s the on/off, pairing, and reset switch, this time right next to the LED, and with both now surrounded by the previously encountered LED-only light leak-preventing foam. The embedded antenna runs along the PCB’s right edge. And the “brains” of the operation at the end of the antenna are seemingly also the same as in the HS103: Realtek’s RTL8710, which, as I noted before, supports a complete TCP/IP “stack” and integrates a 166 MHz Arm Cortex M3 processor core, 512 Kbytes of RAM, and 1 Mbyte of flash memory. The only differences, perhaps reflective of a silicon revision, are in the IC’s bottom two marking lines. The IC in the HS103 says:

08F01H3
G038A2

while the Realtek RTL87210 in the EP10 design is marked as follows for the 2nd and 3rd lines:

08EL0C1
G031A2

The rest of the story

Alas, and as with the HS103 precursor, I was unsuccessful in my attempt to free the EP10’s PCB from the rear-half case within which it was ensconced. I’ll alternatively attempt to pacify your curiosity by first pointing out that a scattering-of-passive PCB backside image is included in the FCC certification internal photo set. And I’ll also point you toward another video, this one also showing both PCB sides but also more broadly of interest to me (and you as well, I suspect):

I found it within a Reddit post I stumbled across while doing my initial research. The OP (original poster, for those of you not yet familiar with frequently used Reddit verbiage) had an EP10 whose relay had developed perpetually clicking behavior. Turns out one of the “can” capacitors on the board had gone bad; replacing it restored normal functionality (not to mention ending the din). Note that the relay in the version of the hardware shown in this video (which I think also says v1.8, although the video-frame images aren’t clear) is also blue in color.

(Not-) working theories

This internal information is all well and good, I hope you agree, but it still doesn’t answer my fundamental question: why was I successful in using only a subset of the EP10s I tried setting up? I’ll first reiterate something I said in my initial December 2025 coverage:

I wondered if these particular smart plugs, which, like their seemingly more reliable HS103 precursors, are 2.4 GHz Wi-Fi-only, were somehow getting confused by one or more of the several relatively unique quirks of my Google Nest Wifi wireless network:

1. The 2.4 GHz and 5 GHz Wi-Fi SSIDs broadcast by any node are the same name, and
2. Being a mesh configuration, all nodes (both stronger-signal nearby and weaker, more distant, to which clients sometimes connect instead) also have the exact same SSID.

If I was right, the issue might have been caused by an EP10 software shortcoming, which a newer version of the firmware could conceivably resolve. But this leads to a chicken-and-egg situation. Downloading and installing the latest firmware to the device requires that I first connect the EP10 to TP-Link’s “cloud” firmware repository via my smartphone intermediary. But absent a sufficiently functional initial firmware version, I can’t get the device online in the first place. To wit, note that the TP-Link devices’ lack of Bluetooth support precludes using this alternative wireless communications interface to get them updated; it’s Wi-Fi or nothing.

A fundamental hardware limitation is also a possibility, of course. Via both documented and pictorial evidence, I’m aware (as, now, are you as well) of at least three different hardware versions of the EP10. For that matter, TP-Link’s website currently lists six different hardware versions of the HS103 “in the wild”, ranging from v1.0 to v5.8. All five of the HS103s currently active in my home are v5 units, the Kasa app conveniently tells me via the Device Info screen in each device’s advanced settings. Again, the sample sizes are small and therefore statistically suspect: did I just get lucky with the HS103s, and unlucky with the first two batches of EP10s?

With that, I’ll wrap up and refer you to the comments section below for any answers you might be willing to publicly posit for my closing questions, and/or any other thoughts you might have! Stay tuned, as I alluded to earlier both in this post and a prior one in the series, for additional teardowns to come of products from both TP-Link’s Kasa and Tapo smart plug families, along with other, potentially even more interesting, smart home ecosystem devices.

—Brian Dipert is the Principal at Sierra Media and a former technical editor at EDN Magazine, where he still regularly contributes as a freelancer.

Related Content

• Tapo or Kasa: Which TP-Link ecosystem best suits ya?
• How smart plugs can make your life easier and safer
• Teardown: Smart plug adds energy consumption monitoring
• Teardown: A Wi-Fi smart plug for home automation
• Teardown: Smart switch provides Bluetooth power control

The post TP-Link’s Kasa EP10: If at first it doesn’t connect, buy, buy again appeared first on EDN.

I recently saw an announcement from a major IC vendor, posted in September 2025, letting users know that “STMicroelectronics sets 20-year availability for popular automotive microcontrollers.” The news is that ST was committed to maintaining the cited parts for 20 years instead of their present 15-year assurance.

“Good for them” was my first thought, as that’s the right thig to do for both their OEM and actual vehicle customers. After all, with the average age of cars on the road in the United States approaching 15 years and with little sign of slowing down or even leveling off, that makes sense.

There are two presumed reasons for the longer lifetime. First, cars are built better; the “rust-bucket” and “fall apart” tendencies of many of those pre-1980/90 cars have greatly diminished due to better design, materials, paints, tests, and processes. Second, the cost of a new car is so high that even costly repairs make sense for many.

Ironically, those less reliable, mostly mechanical cars did have one major virtue: they were repairable then and can generally be repaired/restored even today. Many of their old parts are available via specialty sources either as “new old stock” (NOS) or slightly used. And those that can’t be sourced can be machined or 3D printed if the owner has time and resources.

The issue is not limited solely to cars; unavailable mechanical assemblies are a very different case than electronic ones. In 2022, a team at Verisurf was contracted by the U.S. Air Force to reverse engineer and recreate a 300-piece “throttle quadrant” from the E-3 Airborne Early Warning and Control System (AWACS), by disassembling an existing unit piece-by-piece (Figure 1). See “Reverse Engineering the Boeing E-3 Sentry’s Secondary Flight Controls”.

Figure 1 This throttle quadrant from an E-3 AWACS radar aircraft was recreated via precise piece-by-piece measurement and fabrication of each of its 300 pieces. Source: Verisurf

They used a combination of tools, including basic calipers, advanced metrology systems, CAD/CAM software, close-up photographs, and more to capture and then recreate this control unit-top tolerances of better than 0.005 inches.

For the computers-on-wheels electronics of today’s cars, it’s a very different reality. Will you be able to get an engine control module, or one of the other hundred or so MCU-based modules, even 15 years from now? I’m betting the answer is “no” or “very unlikely,” but we’ll have to wait and see how that story unfolds.

The issue of unavailable parts is not limited solely to automobiles, although that is the largest and most visible application. Unlike most consumer products, there are many areas where useful lives of 20, 30, and more years are expected. Among these are industrial applications, railways, mil/aero, critical infrastructure, and even some home systems such as HVACs.

The challenge of replacement parts and their relatively low volume is not being ignored, as the ST announcement shows. The U.S. Defense Microelectronics Agency (DMEA) has instituted an Advanced Technology Supplier Program V (ATSP V) with 13 companies that, among other objectives, includes approaches to developing and creating components in ultra-low volumes for repair and replacement.

What about “analog”?

With all these legitimate concerns about long-term component availability, there’s one interesting aspect. One fact does stand out: unlike digital ICs and processors, the analog world has a different mindset. Analog-circuit designers tend to stick with a component that they have used successfully, even if it’s a few years old and could easily be replaced by a nominally better part.

Ther are several reasons for this tactic. Once an analog part is in the signal chain meeting specs, there’s a reluctance to take change on a new part and design which may have unknown issues and idiosyncrasies. Factors such as parasitics, layout, and power-supply sensitivity (to cite a few) likely will affect design validation, in contrast to the field experience with the existing design.

There are classic analog parts that have been available for decades, and while not recommended for new designs, they are still available if needed for repair, replacement, or even a newer design. Even better, if they are not available, there is often a drop-in replacement with superior performance; this is especially the case for basic 8-pin op amps.

I can think of three “ancient” analog components as examples:

• The AD574 “complete” 12-bit A/D converter from Analog Devices, introduced in the 1978–1980, became the industry-standard ADC for microprocessor interfacing (Figure 2). It was notable for integrating a buried Zener reference clock and 3-state output buffers for direct 8/16-bit bus interfacing. While its die and process have been upgraded and it’s now available in other packages, you can still get it in the original 28-pin housing.

Figure 2 The 12-bit ADC was the first complete unit with “tight” specifications and is still offered 45 years after its initial release. Source: Analog Devices

• The INA133 instrumentation amplifier from Burr-Brown was introduced around 1998 (Burr-Brown was acquired by Texas Instruments in 2000), and it’s still offered in a variety of packages and grades by TI (Figure 3). Like AD574, it’s not recommended for new designs; you can see its top-tier specifications on page 40 of the 2000 Burr-Brown Product Selection Guide.

Figure 3 Burr-Brown’s INA133 instrumentation amplifier provided excellent performance with modest power requirements and has been continuously available since its introduction in 1998. Source: Texas Instruments

• Finally, we can’t look at the 555 timer-oscillator-multivibrator, a clear contender as one of the most classic components of all time and the longest-lived along with the 74 op amp (Figure 4). Devised by Hans Camenzind and marketed as an 8-pin DIP by Signetics in 1971, it’s still available in many versions, including duals and quads as well as CMOS variations. Despite its age, it’s often used to solve annoying timing and oscillator problems at low cost, and there are many “cookbooks” showing innovative ways in which it can be used.

Figure 4 It’s very likely that no IC has spawned more creative and clever design ideas and handbooks and solved as many circuit problems as the 555 timer-oscillator-multivibrator. Source: Wikipedia

There are others, of course, such as the 60-year-old 2N3905 or 2N2222 transistors—it doesn’t get more basic than that.

While many analog components have a long and viable life with their original or descendent vendors, there is even a solution for the many cases where that source does not want to manufacture or support that IC forever. Companies such as Rochester Electronics work out a formal arrangement and license to take over the rights, tooling, support, and test procedures for the parts. Users who need the part don’t need to consider grey-market or even counterfeit products; instead, they get ICs which are 100% legitimate but via a different supplier.

ST’s announcement is welcome, of course. I wish that more vendors would make that sort of commitment, difficult as it may be, or at least commit to licensing unwanted products to non-competing vendors. For now, if you want long-term continuity, stick with analog parts as much as possible.

Have you ever had to deal with repairing a product having electronic components that were no longer available, or even doing regular production on a long-lived product where you needed more than just a few? Did you find parts, or did you have to do a full redesign? How painful was that process?

Related Content

• Go offline, and crack open a design book
• 2N3904: Why use a 60-year-old transistor?
• Vacuum tubes are dead; long live vacuum tubes
• Thermal printers: should be obsolete, but still going strong
• Appliance schematic, wiring diagram bring troubleshooting joy

The post Analog IC longevity is an underappreciated reality appeared first on EDN.

Risks come in more than one form. There are risks that arise from science and technology, and there are risks that arise from human motivations, which are not always of an obvious sort. This is about the latter.

I had a client company that was owned by a husband and wife for whom I had once solved a power supply thermal runaway problem. I had measured temperature rise versus time and temperature fall versus time, and of course, the two were not exactly the same. Their difference was quite pronounced when I first looked at the issue, but they were almost identical to each other after I had solved their problem. If you’re curious about that, please see the How2Power article here. 

A couple of years went by, and I got a call from that same company about a different power supply that also seemed to have a thermal runaway problem. By then, sadly, the husband had passed away, and only the wife remained to run the business.

During the first time frame, the wife had displayed a hair-trigger temper. Any moment of uncertainty as events unfolded would result in a raging torrent from her, to which her husband would make great efforts to calm her down. I would hear lines like “It’s okay. It’s oh-kay! Please relax. Things are going well.” to which she would then go silent, but now she didn’t have anyone to give her any assurance when it was needed.

An employee who had been promoted to Chief Engineer was my new point of contact. I explained to him that I would examine the thermal rise and thermal fall traits of this new power supply to see if indeed the same situation pertained as it did in the first case or not.

“There’s no need for that. I’ve already made those measurements.” He handed me a sheet of paper with columns of numbers, purportedly the data I had planned to acquire. That night, I examined those numbers and discovered that if you plotted the thermal rise and inverted a plot of the thermal fall, the two curves precisely lined up and were EXACTLY the same!! There was absolutely zero difference. They were totally spot on, no ifs, ands, buts, hows, whys, or wherefores, exactly the same, which meant that the rising and falling curves given to me were not the results of actual testing. They were false.

Confronted with a Chief Engineer whom I then knew to be dishonest and confronted with the woman whom I knew to be extremely volatile and prone to bursts of rage, I assessed the risk of dealing with it all to be unacceptable.

I made up some excuse (I don’t remember what it was) and declined to offer my services.

John Dunn is an electronics consultant and a graduate of The Polytechnic Institute of Brooklyn (BSEE) and of New York University (MSEE).

Related Content

• Burning power lines
• Safe operating area
• The Big Allis generator sixty years ago
• Power pole collapse

The post Risk assessment in the workplace appeared first on EDN.

As AI workloads extend across nearly every technology sector, systems must move more data, use memory more efficiently, and respond more predictably than traditional design methodologies allow. These pressures are exposing limitations in conventional system-on-chip (SoC) architectures as compute becomes increasingly heterogeneous and traffic patterns become more complex.

Modern SoCs integrate CPUs, GPUs, NPUs, and specialized accelerators that must operate concurrently, placing unprecedented strain on memory hierarchies and interconnects. To Keep processing units fully utilized requires high-bandwidth, low-latency access to data, making the memory hierarchy as critical to overall system effectiveness as raw performance.

On-chip interconnects move data quickly and predictably, but once requests reach external memory, latency increases, and timing becomes less consistent. As more data accesses go off chip, the gap between compute throughput and data availability widens. In these conditions, processing engines stall while waiting for memory transactions to complete, creating data starvation.

 

The role of last-level cache

To mitigate this imbalance, SoC designers are increasingly turning to last-level cache (LLC). Positioned between external memory and internal subsystems, LLC stores frequently accessed data close to compute resources, allowing requests to be served with significantly lower latency.

Unlike static buffers, an LLC dynamically fetches and evicts cache lines based on runtime behavior without direct CPU intervention. When deployed effectively, this architectural layer delivers measurable benefits, including substantial reductions in external memory traffic and power consumption.

Simply including an LLC does not guarantee improved performance. Configuring the cache correctly is a complex task that must account for workload characteristics, compute-unit behavior, and real-time constraints. Poorly chosen parameters can waste area without meaningful gains, while under-provisioned configurations may fail to alleviate memory bottlenecks.

Architects must carefully determine cache capacity, the number of cache instances, and internal banking structures to support sufficient parallelism. Partitioning strategies must also be defined to ensure that individual IP blocks receive the bandwidth and predictability they require. While some settings can be adjusted later through software, foundational decisions on cache size, banking, and associativity must be finalized early in the development cycle.

The role of last-level cache is shown in successful designs. Source: Arteris

Factors influencing cache behavior

Banking configuration illustrates this trade-off clearly. Increasing the number of cache banks improves internal parallelism and throughput, but it also increases silicon area. Workloads with largely sequential access patterns may see limited benefit from aggressive banking.

In contrast, highly parallel workloads, especially those driven by AI accelerators or GPUs, require substantial internal concurrency to maintain utilization. Because these characteristics vary by application, banking decisions must be informed by realistic workload analysis during the architectural phase.

Cache capacity is just as important. A cache that is too small struggles to achieve acceptable hit rates, pushing excessive traffic to external memory. Conversely, oversizing the cache often yields diminishing returns relative to the additional area consumed. The optimal balance depends on actual runtime behavior rather than theoretical assumptions.

In practice, acceptable hit rates vary widely. Some systems can tolerate moderate miss rates if latency and power reductions outweigh the cost, while real-time applications demand consistently high hit rates to maintain deterministic behavior.

This variability underscores why no single LLC configuration is universally optimal. Mobile devices may require only a few megabytes of cache to balance power efficiency and responsiveness. At the same time, servers and HPC platforms often deploy tens or hundreds of megabytes to reduce DRAM pressure. Despite these differences, successful designs rely on a common principle in which cache parameters are derived from the workloads the system will actually execute.

Managing shared caches

Diversity in system demands further complicates how an LLC must be structured. Automotive chips built around concurrent vision processing and strict timing requirements operate under very different constraints than data-center platforms optimized for accelerator-heavy inference at scale. Even within a single chip, CPUs, accelerators, and I/O subsystems generate distinct access patterns with different latency sensitivities.

The LLC must accommodate all of them without allowing one workload to interfere with another’s real-time guarantees. This makes early understanding of system-level access behavior essential, since cache configuration otherwise becomes speculative at best.

Partitioning provides a powerful mechanism for preserving determinism in such environments. By allocating portions of cache capacity to specific clients, architects can prevent high-bandwidth workloads from starving latency-sensitive subsystems. This capability is particularly critical in environments that must meet strict timing guarantees. Partition sizes must be tuned carefully, as oversizing wastes area while undersizing risks violating latency requirements.

Configuring a last-level cache is ultimately a multidimensional challenge shaped by workload demands, compute topology, latency requirements, and silicon constraints. Achieving the right balance between performance, determinism, power, and area depends on understanding how an SoC behaves under real operating conditions.

To address this, SoC teams increasingly rely on system-level simulation using realistic data flow profiles generated by multiple on-chip request sources. This approach allows teams to evaluate cache behavior before key architectural decisions are finalized. It helps identify bottlenecks, validate cache sizing, and determine when isolation mechanisms such as partitioning are required to preserve real-time guarantees.

Arteris developed its CodaCache IP, which operates as a configurable last-level cache between on-chip initiators and different types of external memories such as DDR-DRAM, HBM and even NVM for execution in place (EIP) use cases. With CodaCache, architects can equip their SoC fabric with the optimal configuration to address intelligent, scalable, and automated data management in a wide range of applications.

Andre Bonnardot is product marketing manager at Arteris.

Related Content

• Understanding cache placement
• Optimizing for instruction caches
• How to Turbo Charge Your SoC’s CPU(s)
• Bringing SOT-MRAM Tech Closer to Cache Memory
• SoC design: When a network-on-chip meets cache coherency

The post Last-level cache has become a critical SoC design element appeared first on EDN.

With smartphone and tablet news already discussed, what else did Apple unveil this week? Read on for all the goodies and their details.

As I teased at the end of my prior piece, computers and displays were also on the plate for Apple’s “big week of news” announcements suite. With today’s (as I write this on Wednesday in the late afternoon) New York, London, and Shanghai “Experience” in-person events now concluded:

(No, alas, I wasn’t invited)

I’m guessing that Apple’s wrapped up its rollouts for now, therefore compelling me to revisit my keyboard for concluding part 2. That said, I realized in retrospect that there was one additional earlier hardware announcement that, had I remembered at the time (and in time), I would have also included in part 1, since it also covered mobile devices. So, let’s start there.

AirTag 2

In late April 2021, Apple introduced its first-generation AirTag trackers, leveraging Bluetooth LE connectivity to mate them with owner-paired smartphones and tablets and more broadly (when a tagged device is lost) the broader Find My crowdsourced network ecosystem to assist in identifying their whereabouts and monitoring their movements. Integrated ultrawideband (UWB) support, when also comprehended by the paired mobile device, affords even more precise location discernment (i.e., not just somewhere in the living room, but having fallen between the sofa cushions). And built-in NFC support assists anyone who might find a tag (and whatever it’s attached to), to notify the person that it belongs to. Here’s my first-gen teardown.

Nearly five years later, and quoting Wikipedia:

An updated model with the U2 chip, upgraded Bluetooth, and a louder speaker was released in January 2026 [editor note: Monday the 26th, to be precise]. It has enhanced range for precision detection with iPhones equipped with a U2 chip such as the iPhone 15/Pro or later (excluding iPhone 16e), and also allows an Apple Watch with a U2 chip such as the Apple Watch Series 9 or later, or Apple Watch Ultra 2 or later (excluding Apple Watch SE), to precisely locate items.

Now fast-forwarding a month-plus to this week’s announcements…

The M5 Pro and Max SoCs

2.5 years back, within my coverage of Intel’s then leading-edge and first-time chiplet-implemented Meteor Lake CPU architecture:

I noted that the company was, to at least some degree, following in the footsteps of AMD and Apple, both having already productized chiplet-based designs. In AMD’s case, I was on solid footing with my stance, as the company had already been embedding and interconnecting discrete processors, graphics, and other logic circuits for several years. In Apple’s case, conversely, my definition of a chiplet implementation was a bit more loosey-goosey, at least at the time:

Above is a de-lidded photo of Apple’s M1 SoC. At left is the single-die implementation of the entirety of the logic circuitry, plus cache. And on the right are two DRAM memory chips. Admittedly, the “Ultra” variant of the eventual M1 product family, at far right:

upped the ante a bit more, “stitching together two distinct M1 Max die via a silicon interposer”. But I’ve long wondered when Apple would go “full monty” on disaggregation, mixing-and-matching various slivers of logic silicon attached to and interconnected via a shared packaging substrate, to keep each die’s dimensions to a reasonable manufacturing-yield size and to afford fuller implementation flexibility. To wit, the points I made back in September 2023 remain valid:

• Leading-edge processes have become incredibly difficult and costly to develop and ramp into high-volume production,
• That struggle and expense, coupled with the exponentially growing transistor counts on modern ICs, have negatively (and significantly so) impacted large-die manufacturing yields not only during initial semiconductor process ramps but also long-term, and
• Desirable variability both in process technology (DRAM versus logic, for example), process optimization (low power consumption versus high performance) and IC sourcing (internal fab versus foundry), not to mention the attractiveness of being able to rapidly mix-and-match various feature set combinations to address different (and evolving) market needs, also enhance the appeal of a multi- vs monolithic-die IC implementation.

That time is now, branded as the “Fusion Architecture” and ironically foreshadowed by a then-subtle Apple online store tweak a month ago. Quoting from the press release subhead:

M5 Pro and M5 Max are built using the new Apple-designed Fusion Architecture that connects two dies with advanced IP blocks into a single SoC, delivering significant performance increases that push the limits of what’s possible…

In an interesting twist from the past, this time the two product proliferations seemingly share a common processor die, although the variety and number of guaranteed-functional cores varies both between the two devices and within a given device’s binning variants. Conversely, the graphics core counts diverge more substantially between the two devices. To some degree this is reflective of the high-end “Max” device’s professional content creator target demographic, although I’d wager that it more broadly affords more robust on-device deep learning inference capabilities in conjunction with the chips’ presumed-still-existent neural processing cores. And what of an “Ultra” variant of the M5…is it on the way? Maybe…

Tomato, tomahto

Speaking of cores, by the way…sigh. Look back at my M5 SoC (and initial devices based on it) coverage from last October, and you’ll see that, just as with prior generations of both A- and M-based Apple-developed silicon, it contains a mix of both performance (speed- optimized) and efficiency (power consumption-tuned) cores. Here’s the specific press release quote again:

M5 features the world’s fastest performance core, with up to a 10-core CPU made up of six efficiency cores and up to four performance cores. Together, they deliver up to 15 percent faster multithreaded performance over M4.

All well and good; the Arm-developed architecture analogy is big.LITTLE. Revisiting that page on Arm’s website just now, however, I curiously noticed that whereas it historically called out two different types of cores, now there are apparently three. Check out the subhead:

Arm big.LITTLE technology is a heterogeneous processing architecture that uses up to three types of processors. LITTLE processors are designed for maximum power efficiency, while big processors are designed to provide efficient, sustained compute performance.

Keep in mind that Apple is an Arm architecture licensee, so it develops its own (still instruction set-compatible, of course) cores. That said, beginning with the M5 Pro/Max processing chiplet, Apple has also developed a third core, this one an intermediate half-step between the performance and efficiency endpoints. You might think that Apple would call this new one the “balanced” core, say. But alas, you’d be wrong. Here’s long-time Apple observer Jason Snell, quoted in a post from another Apple prognosticator, “graybeard,” John Gruber:

With every new generation of Apple’s Mac-series processors, I’ve gotten the impression from Apple execs that they’ve been a little frustrated with the perception that their “lesser” efficiency cores were weak sauce. I’ve lost count of the number of briefings and conversations I’ve had where they’ve had to go out of their way to point out that, actually, the lesser cores on an M-series chip are quite fast on their own, in addition to being very good at saving power! Clearly they’ve had enough of that, so they’re changing how those cores are marketed to emphasize their performance, rather than their efficiency.

What did Apple decide to do instead, including a retrofit of published M5 documentation?

• The prior-named “Performance” core is now instead called, believe it or not, “Super.”
• The “Efficiency” core retains its original name, for a brief moment of sanity
• And the new in-between “balanced” core? It’s the recycled ”Performance” moniker.

The following summary table originated with another recent John Gruber post; I’ve simplified the SoC options, reordered the CPU core columns, and added a column for GPU core counts:

	CPU (Super)	CPU (Performance)	CPU (Efficiency)	GPU
M5	3-4	N/A	6	8-10
M5 Pro	5-6	10-12	N/A	16-20
M5 Max	6	12	N/A	32-40

That’s just…super. Sigh.

(More) M5 MacBook Pros

(nifty video animation, eh?)

“Super” SoCs inside aside, the new 14” and 16” MacBook Pros are effectively identical to their M4-based forebears (note that the sole M5 version initially announced last fall was the 14” model). The only other items of particular note both involve memory. Baseline and upgraded DRAM capacity option prices remain the same as last time, despite current industry memory supply constraints; an upper-end 64 GByte option for the M5 Pro has even been added. And regarding flash memory, Apple has obsoleted last November’s entry-level 512 GByte SSD option for the baseline 14” M5 MacBook Pro, making the new capacity starting point for that product (1 TByte) more expensive than before. That said, it’s now $100 lower than the 1 TByte variant price at intro just a few months ago, and capacity-upgrade prices have also decreased.

The M5 MacBook Air(s)

Here’s another example of not being able to tell, based solely on external appearances, which generation of devices you’re looking at. Coming, as with its M3- and M4-based forebears, in both 13” and 15” versions, the M5 MacBook Air also upgrades to Apple’s N1 network connectivity chip. But, speaking once again of (flash, specifically) memory, and akin to the product line option slimming for the 14” M5 MacBook Pro mentioned in the prior section, the lowest-available capacity for the new devices is 512 GBytes, versus 256 GBytes in previous generation. I’m guessing that the reasoning is two-fold this time; as with the 14” M5 MacBook Pro’s option-culling, the company’s “hiding” its higher flash memory costs by only offering more profitable capacity choices to customers. Plus, by doing so, Apple can more clearly differentiate the MacBook Air from its other products. Speaking of which…

The MacBook Neo

I’ll kick off this section with a few history lessons. Back in 2015, Apple introduced the “new MacBook” (also commonly referred to as the “12” MacBook), with a Retina-resolution display and based on Intel m-series (and later, i-series) CPUs. It slotted between the then-non-Retina MacBook Air and the high-end MacBook Pro in Apple’s product portfolio from a pricing standpoint, even though its processing performance undershot that of the notably less expensive MacBook Air. Plus, it was hampered by the unreliable “butterfly” keyboard. It was discontinued after only three hardware iterations and four years of production.

In addition to its unfavorable price comparison to the MacBook Air, the “new MacBook” was also still competing to a degree against then-popular Windows-based “netbooks”, which were even lower priced. Back in late 2008, Former CEO Steve Jobs had (in)famously quipped re netbooks, “We don’t know how to make a $500 computer that’s not a piece of junk.” Hold that thought.

My last history lesson is, conversely, a Steve Jobs success story. Back in mid-1999, two years (and change) after Jobs’ return to Apple and less than a year after launching the consumer-tailored iMac desktop, Apple unveiled the iBook laptop:

which came in multiple eye-catching, intentionally non-“business” color options:

Quoting Wikipedia:

The line targeted entry-level, consumer and education markets, with lower specifications and prices than the PowerBook, Apple’s higher-end line of laptop computers. It was the first mass consumer product to offer Wi-Fi network connectivity, which was then branded by Apple as AirPort.

Look again at the image of the iBook’s color options. Now look at the photo at the beginning of this section. See where I’m going?

The newly unveiled MacBook Neo comes in two price tiers: $599 (with a further $100 discount for education customers; take that, Chromebooks) and $699. The higher-end variant gets you twice the SSD capacity—512 GBytes versus 256 GBytes—along with a Touch ID fingerprint reader built into the keyboard. That’s it. 8 GBytes of DRAM, with no upgrade option. No Thunderbolt, only two USB-C ports, one of them supporting only USB 2 speeds. The first-time use of an A-series processor, the (Apple Intelligence-capable) A18 Pro (albeit with one fewer graphics core enabled than the initial version in the iPhone 16 Pro series); that said, it seems to benchmark (at least) roughly on par with the M1 that until recently was still being sold by Walmart in the MacBook Air. And a networking subsystem rumored to come from MediaTek, versus developed internally.

In closing, at least for this section: what’s with the name? Some folks had forecasted that it’d just be called the “MacBook”, but as I’ve already noted, that particular name is now “damaged goods”. Others thought that an “iBook” resurrection was in the cards, but Apple stopped referring to devices via “i” monikers a while ago. That said, “Neo” was definitely not on my bingo card. Maybe someone in Cupertino is a fan of The Matrix, but thought that “MacBook Mr. Anderson” would be too ponderous?

Displays

Having already passed through 2,000 words, I’m going to keep this section short. Apple announced two new Studio Display models, its first updates to this particular product category in many years. They’re both 27” in size, with 5K Retina resolutions, although their refresh rates, dynamic ranges, and other image quality measures vary. The “inexpensive” one starts at $1,599, with its pricier sibling beginning at $3,299; both are available in standard or (upgrade) nano-texture glass options, and mounting and other accessories are also available. And interestingly, at least to me, they don’t work with legacy Intel-based Macs, even the scant few models (one of which I’m currently typing on) that are still supported by MacOS 26. For more details, check out the press release.

And what about…

The M5 Mac mini, whose possibility I alluded to yesterday? Didn’t happen, even though the current M4-based models are popular with the agentic AI enthusiast community (and others). That said, in revisiting my prognostication yesterday afternoon, I remembered that Apple had also skipped the M3 Mac mini generation, and that said, the time-consuming form factor redesign development from the M2 to the M4 might have at least partly explained that delay.

And what of the upgrade to the “vanilla” iPad that lots of folks were forecasting would happen this week? Another nope. The primary rationale here was that it was the only remaining member of Apple’s current product line whose CPU (the A16) doesn’t support Apple Intelligence. But there was no evidence of the telltale indicator of a new product’s arrival: depleted retail inventories of the current model. My guess: Apple will be happily talking about AI again at this year’s WWDC, now that Google’s on board as the company’s development partner, and that’d be a perfect time to announce the “iPad 12”…or maybe “iPad Neo”? I jest (I hope).

Time to put down my cyber-pen and turn it over to you for your thoughts in the comments!

—Brian Dipert is the Principal at Sierra Media and a former technical editor at EDN Magazine, where he still regularly contributes as a freelancer.

Related Content

• MWC 2026: Apple, Google, Samsung and Other Contending Contestants
• Intel’s next-generation CPUs hide chiplets inside*
• Apple’s obvious misfires
• Evaluating value-oriented x86 CPUs: The price of falling prices

The post Apple’s spring 2026 soirée: The rest of the story appeared first on EDN.

Built on a 28-nm process, the Renesas RH850/U2C automotive microcontroller delivers robust connectivity and security for modern E/E architectures. This 32-bit MCU expands the RH850 lineup with a cost-optimized option for chassis and safety systems, battery management, body control, and other ASIL D–rated applications.

The device integrates four RH850 CPU cores running at up to 320 MHz, including two lockstep cores, and up to 8 MB of on-chip flash memory. It combines 10BASE-T1S and TSN Ethernet (1 Gbps/100 Mbps), CAN XL, and I3C with widely used interfaces such as CAN FD, LIN, UART, CXPI, I2C, I2S, and PSI5.

In addition to functional safety support up to ASIL D under ISO 26262, the RH850/U2C meets current cybersecurity requirements in accordance with ISO/SAE 21434. The MCU integrates hardware acceleration for cryptographic algorithms, ranging from post-quantum cryptography (PQC) to those mandated by current Chinese and other international regulations.

The RH850/U2C is available in BGA292 and HLQFP144 packages.

RH850/U2C product page 

Renesas Electronics 

The post MCU enables ASIL D safety and control appeared first on EDN.

With typical measurement speeds of 25 µs/point, Copper Mountain’s three SC series VNAs enable efficient testing in both R&D and manufacturing environments. The SC0402, SC0602, and SC0902 two-port analyzers cover a common frequency start of 9 kHz, with upper ranges of 4.5 GHz, 6.5 GHz, and 9 GHz, respectively.

These instruments offer a typical dynamic range of 130 dB (10 Hz IF BW) for precise characterization of RF components and complex systems. Output power can be adjusted from -50 dBm to +5 dBm, with up to 500,001 measurement points/sweep. Measured parameters include S11, S21, S12, and S22.

Standard software capabilities, available without a paid license, include linear and logarithmic sweeps, power sweeps, and time-domain conversion with gating. Additional functions include S-parameter embedding and de-embedding, limit testing, frequency offset, and vector mixer calibration.

Automation is supported through LabVIEW, Python, MATLAB, .NET, and other programming environments, allowing up to 16 independent channels with 16 traces/channel. A manufacturing test plug-in is available as an add-on to integrate the VNA software into existing automated manufacturing and QA processes.

The SC series VNAs carry MSRPs of $13,995 (SC0402), $15,995 (SC0602), and $17,995 (SC0902).

Copper Mountain Technologies 

The post VNAs perform production test up to 9 GHz appeared first on EDN.

Infineon’s EZ-PD PMG1-B2 MCU integrates a single-port USB Type-C PD controller with a 55-V buck-boost controller for charging 2- to 12-cell Li-ion battery packs. Compliant with the latest USB Type-C and PD specifications, the device accepts an input voltage range of 4.5 V to 55 V with switching frequencies programmable from 200 kHz to 700 kHz.

The MCU targets USB-C-powered embedded devices in consumer, industrial, and communications markets, where devices make use of its integrated functions. Typical applications include cordless power and gardening tools, vacuum cleaners, kitchen appliances, e-bikes, drones, and robots.

The EZ-PD PMG1-B2 features a 32-bit Arm Cortex-M0 processor with 128 KB of flash and 8 KB of SRAM for customizable embedded applications. It integrates analog and digital peripherals—including ADCs, PWMs, UART/I2C/SPI interfaces, and timers—reducing PCB space and BOM. A comprehensive SDK and software suite simplify development and system design.

Production of the EZ-PD PMG1-B2 is expected to begin in the second quarter of 2026. Samples, technical documentation, and evaluation boards are available upon request.

EZ-PD PMG1-B2 product page 

Infineon Technologies 

The post MCU brings USB-C power to embedded devices appeared first on EDN.

Teledyne Microwave UK’s B3LT98026 is a passive wideband limiter designed to protect sensitive receiver front ends in defense and military communication systems. It operates from 0.1 GHz to 20 GHz and withstands up to 10 W peak input power under defined pulse width and duty cycle conditions.

The device enhances the survivability of Radar Electronic Support Measures (R-ESM) and Electronic Warfare (EW) systems operating in complex threat environments. It provides continuous, always-on protection against high-power RF and emerging Directed Energy Weapons (DEWs).

Across the operating band, the limiter maintains a maximum insertion loss/noise figure of 2.0 dB and a maximum input/output VSWR of 1.5:1. A fast 40-ns recovery time enables rapid return to nominal sensitivity following high-power events. The device operates over a temperature range of −20°C to +85°C, supporting deployment in demanding environments.

The compact SMA-based housing supports straightforward integration into existing architectures without requiring system redesign. The B3LT98026 is also compatible with Teledyne’s Phobos mast top unit and can accommodate additional RF elements, such as filters, when required.

The B3LT98026 is now available for evaluation in defense and EW systems.

B3LT98026 product page 

Teledyne Microwave UK 

The post Passive limiter shields electronics from RF threats appeared first on EDN.

Nordic Semiconductor expands its ultra-low-power cellular IoT portfolio with Cat 1 bis, satellite NTN, and advanced LTE-M/NB-IoT with edge AI. Leveraging the proven nRF91 series, the nRF92 and nRF93 deliver a scalable, secure platform for global connectivity.

The nRF92 LTE-M/NB-IoT and satellite NTN series introduces the company’s smallest, most highly integrated, and power-efficient cellular solution. It combines a high-performance application MCU with Axon neural processing units, a multi-constellation GNSS receiver, Wi-Fi positioning, and sensor coprocessing. Lead customer sampling is underway, with general availability expected in early 2027.

The nRF93M1 is an LTE Cat 1 bis cellular IoT module with integrated MCU, LTE modem, GNSS receiver, and Wi-Fi positioning. It supports up to 10 Mbps downlink and 5 Mbps uplink, offers global LTE coverage, and is designed for low-power, compact applications. The module is compatible with nRF Cloud for device management, firmware updates, and location services. Lead customers are currently developing products with the nRF93M1, with general availability starting mid-2026.

Additionally, Nordic has enhanced the nRF91 LTE-M/NB-IoT series with 3GPP-compliant GEO and LEO satellite NTN connectivity and sub-GHz fallback to maintain connectivity when public networks are unavailable. The company also introduced the nRF91M1 module, a compact Smart Modem that simplifies adding cellular connectivity to host–modem designs.

Nordic Semiconductor 

The post Nordic debuts multiple cellular IoT products appeared first on EDN.

Electric vehicle (EV) design at the system level is a rapidly evolving landscape encompassing components, hardware modules, and software platforms. So, on the first day of Automotive Tech Forum 2026, which was dedicated to EV designs, a panel titled “Powering the Electric Vehicle: From Semiconductors to Systems” took a deep dive into the system-level intricacies of EV designs.

Carsten Himmele, marketing manager for automotive at Allegro MicroSystems, highlighted the growing presence of silicon carbide (SiC) in traction inverters due to its ability to deliver higher bandwidth and efficiency. However, while talking about motor control for EV traction, he also mentioned challenges in operating in harsher electrical environments.

“SiC brings in higher bandwidth for motor control, but it also makes the electrical environment somewhat harsher,” he said. Himmele added that advanced phase-current sensing and inductive rotor-position sensing are essential for overcoming these challenges. “Moreover, system-grade building blocks reduce the number of external components and improve design efficiency,” he concluded.

That’s where gallium nitride (GaN) offers key advantages, said Alex Lidow, CEO and co-founder of Efficient Power Conversion (EPC). “GaN is smaller, more efficient, and more rugged compared to silicon and SiC,” he said. “It’s particularly effective in 48-V systems, which complement the emerging 800-V architectures.”

Lidow added that while EVs with 48-V systems are now leading the way, GaN devices are 5 to 7 times more efficient than their MOSFET ancestors. “GaN is powering onboard chargers, DC/DC converters, battery cooling pumps, steering systems, and infotainment.”

Rohan Samsi, VP of GaN Business Division at Renesas, also talked about the paradigm shift GaN brings to power converters, enabling simplified single-stage designs. “The bidirectional switch allows you to take out something that was a multi-stage converter and replace it with a single stage.” To achive integration synergy, Samsi emphasized that GaN’s strengths in current sensing, temperature sensing, and gate drive enable holistic EV solutions.

Finally, Kerry Grand, marketing manager for Simulink Automotive at MathWorks, turned the discussion toward the software aspects of design. He was asked to inform the panel on the latest developments in EV traction from a system-integration standpoint. And what does hardware testing uncover about the present and future of EV drivetrain?

Grand began with an insight into EV system-level design through simulation and model-based design. Then he identified enduring challenges in EV system design, including high-voltage isolation, battery life optimization, and thermal management. “Simulating detailed thermal systems offers automotive OEMs the ability to trade off temperature limits without compromising system performance.”

At a time when EV design building blocks like traction inverters and battery management systems (BMS) are continually adding functionality, system-level challenges are a critical area to watch. The panel discussion in Automotive Tech Forum 2026 provides a glimpse of design challenges and viable solutions in this design realm.

You can watch this session along with all sessions from the Automotive Tech Forum 2026 virtual event on demand at www.automotiveforum.eetimes.com.

Related Content

• Stop EMI from spreading in an EV design
• Are EVs Peaking? Exploring the Next Step in EV Design
• This is how an electronic system design platform works
• Shifting the EV Bus to 800 V: Benefits and Design Challenges
• How specialized MCUs meet on-board charger design needs

The post EV system design from components to modules to software appeared first on EDN.

As follow-up to last month’s narrative of a cardiac abnormality thankfully detected by wearable devices, this engineer details the monitoring system he subsequently donned for a month.

Two-plus years ago, my contributor-colleague John Dunn described his most recent experience with a wearable cardiac monitor. And, as any of you who read one of my last-month blog posts already know, I more recently followed in his footsteps. I don’t yet know the outcome of my heart health study; my follow-up appointment with the cardiologist is a week away as I type these words. Regardless, I thought you might still find it interesting to learn about the gear I toted around, stuck to my chest (and in my pocket) for 30 days, and my experiences using it.

The system I used was Philips’ MCOT (Mobile Cardiac Telemetry), specifically its “patch” variant:

Here’s an overview video; others, plus documentation, are at the product support page:

I took several “selfies” of the sensor in place on my chest but ultimately decided to save you all the abject horror of seeing any of them. Instead, I’ll stick with these stock images:

My initial scheduled meeting with the cardiologist took place on December 12, 3+ weeks after our “introduction” at the emergency room. I’d been on both beta blockers (to regulate my heartbeat) and blood thinners (in case my prior irregular rhythm had resulted in the formation of a clot) since my initial visit to the hospital in mid-November. The cardiologist ordered the monitor, which arrived a bit more than a week later; I began wearing it the day after Christmas.

Here’s the box that the system comes in:

Open sesame:

The first thing I saw was the initial sensor patch, along with the return shipping packaging bag. Below it was the template I used for proper placement each time I stuck a patch on my chest:

The bulk of the contents were contained in two inner boxes, the first labeled “Getting Started” and the second referred to as “Monitoring”. Inside the first:

were several primary items:

along with installation and operation overview instructions:

The monitoring device, both here and in subsequent photos accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes:

whose dimensions and Android operating system foundation, along with the legacy presence of an analog headphone jack alongside the USB-C port:

and a multi-camera rear array in a specific arrangement:

suggest it to be a custom-software derivative of Samsung’s Galaxy A52 smartphone, introduced in March 2021:

It came with the translucent green case pre-installed, by the way. Here are some other overview images of the smartphone…err…monitoring device (its left side was unmemorable so I didn’t bother):

Next up was a small scrub pad used to further prepare my chest for patch application, after initial hair shaving. And, of course, there was the sensor itself:

Its edge arrived already abraded; I’m guessing that it had already been popped open, with its rechargeable battery subsequently replaced, at least once prior to its arrival at my residence:

Now for box #2:

More instructions, of course:

along with more patches, a more detailed instruction booklet, and the dual-charging unit:

The AC/DC adapter has two USB-A outputs:

which can be used in parallel:

One, connected to a red USB-A to USB-C cable, is used for daily recharge of the “monitoring device” (smartphone). The other (black, this time) cable terminates in a charging dock for the sensor, which I used every five days in conjunction with (and in-between) the patch removal and replacement steps:

Here’s how the initial “monitoring device” bootup went (since this was a custom Android-plus-app build, I wasn’t able to grab screenshots directly from the smartphone, perhaps obviously):

After initial charging of both the monitoring device and sensor, I continued the setup process:

Here’s what a patch looks like when you first take it out of the package; top:

and bottom:

Pressing down on the sensor while aligned with the patch base snaps it into place:

A briefly illuminated LED subsequently indicates that the sensor is correctly installed, at which point the monitoring device is able to “see” it (broadcasting over Bluetooth, presumably Low Energy):

At this point, you can peel away the protective clear plastic cover over the back side adhesive:

All that’s left is to press it into place on your chest…and then peel off the existing patch, pop out and recharge the sensor and redo the installation process five days later:

Lather, rinse, and repeat until the total 30-day cycle is over, which the system thoughtfully tracks on your behalf. Then ship it all back to the manufacturer.

The monitoring device, which regularly receives data transmissions from the sensor, periodically then uploads the data to the “cloud” server over an LTE or EV-DO cellular data connection.

If you forget to keep the monitoring device close by, data won’t be lost, at least for a while. There’s an unknown amount of memory onboard the sensor (yes, I searched for a teardown, alas unsuccessfully), albeit presumably not the full 2 GBytes allocated to this alternative device designed solely for local data logging. But the monitoring device will still alert you (both visually and audibly) to the lost wireless (again, presumably Bluetooth’s LE variant) connection:

You’ll also be alerted if the sensor’s integrated battery drops to a low level and recharge is necessary (I proactively did this every five days, as previously noted, since I’d received six total patches):

If you feel like something’s amiss with your “ticker” (heart pounding, fatigue, etc.) you can tap on the icon at the center of the display and the monitoring device will send an alert “flag” for subsequent correlation with the potential cardiac arrythmia data collected at that same time:

And in closing, here are some shots of other monitoring device display screens that I captured:

By the time you see this, assuming I don’t need to reschedule for some reason, I will have met with my cardiologist and gotten the (hopefully positive) results. I’ll follow up in the comments. And please also share your thoughts there! Thanks as always for reading.

—Brian Dipert is the Principal at Sierra Media and a former technical editor at EDN Magazine, where he still regularly contributes as a freelancer.

Related Content

• Adventures with a remote heart monitor
• Wearables for health analysis: A gratefulness-inducing personal experience
• Avoiding blood pressure measurement errors
• Avoiding blood pressure measurement errors – Part 2
• How to design an optical heart rate sensor into a wearable device’s wristband

 

The post Cardiac monitors: Inconspicuous, robust data collectors appeared first on EDN.

Ever imagine that memory supply (translating to system capacity and price) concerns would ever dominate multiple companies’ announcements? “And so it goes”, to quote Kurt Vonnegut.

The Mobile World Congress (MWC) show, held each year in Barcelona, Spain (one of my favorite cities in the world) and in progress as I write these words, doesn’t have quite the same cachet as previously. Two primary reasons rationalize this impermanence: the cellphone market has subsequently (and notably so) consolidated, and it’s increasingly common for the market participants that remain to announce new products at their own events.

That said, these go-it-alone suppliers still often chronologically cluster their announcements at or near the MWC timeframe. Plus, the conference organizers have broadened the scope of the show beyond just cellphones (nowadays: smartphones) to also encompass other mobile devices such as tablets and laptop computers…although classifying a static desktop-based, AC-powered robot as “mobile” is a stretch, no matter how dynamic its joints and display may be:

Apple, Google, and Samsung were among the companies who made notable(-ish) news over the past week. I’ll cover them chronologically in the following sections.

Mountain View gets the jump on Cupertino (once again)

Last spring, Google unveiled its then-latest cost-focused phone, the Pixel 9a, a few weeks after Apple had rolled out its initial (albeit iPhone 16-numbered) “e” rebrand of prior “SE” multi-gen economical-tuned offerings. I subsequently bought a Pixel 9a for myself, replacing (and leveraging a then-lucrative trade-in value promotion for) my prior backup handset, a Pixel 6a.

That said, Google had already flip-flopped prior longstanding fast-follower precedence with the late summer 2024 launch of the mainstream Pixel 9 and high-end Pixel 9 Pro, which predated their iPhone 16 competitors by a month (versus the historical cadence of being a month belated). The same thing happened last year. And now, Google has extended its “eager beaver” behavior to the entry-level end of its smartphone product suite with the Pixel 10a, which the company sneak-peeked in early February, with a full unveil two weeks later complete with a pre-order opportunity, and shipments starting later this week.

Good news: skyrocketing DRAM and NAND flash memory prices haven’t led to handset price increases (or, alternatively, either integrated memory capacity decreases or the culling of lower-capacity product variants); the Pixel 10a price ($499) is unchanged from its Pixel 9a predecessor. Bad news (albeit good news for me, no longer FOMO-fraught): unless you’re insistent on a completely flat backside absent any camera “bumps”, the design is largely unchanged as well. Same chipset. Same memory generations and speed bins. The display is modestly enhanced—peak brightness, bezel thickness, and cover glass shock resistance—as are the wired and wireless charging power, therefore speeds, but that’s basically it. Oh…and still no Qi magnet inclusion. Hold that thought.

A higher-end attack

A week later, and a week ago, Samsung rolled out its Galaxy S26 product line, which competes against Apple’s iPhone 17 series launched last September, along with new-generation earbuds (but no new smart ring; was Oura’s legal-pressure campaign effective?):

Here again, not much has changed from the year-prior Galaxy S25 predecessors. The “adder” that seemingly got all the media attention, Privacy Display, derives from an OLED display tweak and is only available on the high-end Ultra variant. Unlike Google, Samsung is generationally raising prices, predominantly blaming memory cost increases as the root cause, and is also not offering comparable low-end storage capacity options as with S25-series predecessors. The memory blame assignment is particularly ironic in this case because the Samsung parent company also has a semiconductor (memory, specifically) division under its corporate umbrella.

That said, as my colleague Majeed recently wrote about at length and I’d also noted in my earlier 2026-forecast coverage, HBM memory is AI-cultivating the lion’s share of customer demand (therefore also supplier attention) right now, versus the DDR4- and DDR5-generation DRAM technologies found in computers, smartphones, tablets, and the like. Speaking of AI, Samsung Mobile (like Google, and in partnership with Google, along with Perplexity) is betting on it as a trend-setting differentiator from Apple’s underperforming alternative, no matter that it ended up not being a broadly effective sales pitch motivator last year. That Apple has now partnered with Google, too, must have been a hard pill for Cupertino to swallow. Oh, and by the way, once again, no Qi magnets, although the argument is pretty pervasive, at least to me. Paraphrasing: “Why bother doing so, bumping up the bill-of-materials cost in the process, since most everybody also uses phone cases anyway, and they already come with magnets?”

Not a one-trick pony

All of which leads us to Apple itself, which yesterday (as I’m writing these words on Tuesday afternoon, March 3) released its latest entry-level smartphone, the iPhone 17e:

Minutia first: a year ago, I gave the company grief for busting through the $500 price barrier while, as the original MagSafe innovator, bafflingly leaving magnets off its wireless charging implementation. First World problem solved: unlike with Google and Samsung, as earlier mentioned, they’re there in the iPhone 17e. We can all now once again sleep soundly.

Now, for memory, specifically (in this case) flash memory. Like Samsung but unlike Google, Apple lopped the prior-generation 128 GByte storage capacity option off the low end of the product suite. But unlike both Samsung and Google, the capacity increase comes with no associated price increase; Apple has stuck with $599 for the now-256 GByte variant this time. The SoC is also upgraded, from the A18 to A19 (the same generation as in the iPhone 17), albeit with only 4 GPU cores (versus 5 with the iPhone 17), as is the cellular modem (the newer C1X). And a few other tweaks: a third color option (pink) and updated Ceramic Shield 2 front glass protection.

Since, as I mentioned at the beginning, MWC has expanded beyond phones into tablets (among other things), I’ll also lump into today’s coverage the latest M4 SoC-based generation of the iPad Air, which Apple also announced yesterday.

As before, it comes in both 11” and 13” variants; the N1 networking and C1X cellular chips are also on board for the ride this time. Echoing back to my earlier highlight of the iPhone 17-vs-17e A19 SoC core-count discrepancy, the version of the M4 SoC in the new iPad Air is also downbinned from the ones in the various versions of the M4 iPad Pro, albeit this time from both CPU (both performance and efficiency, in fact) and GPU core-count standpoints, with requisite benchmarking-results impacts. And once again, memory is the most notable news (IMHO, at least) with these devices. But this time, DRAM is in the spotlight. Likely with locally stored AI model sizes in mind, the low-end M4 iPad Air variants deliver a 50% capacity increase (from 8 GBytes to 12 GBytes), still with no corresponding price increase…

…which circles us back to my memory-related comments that kicked off this piece. If volatile (DRAM) and nonvolatile (flash memory) supplies are constrained, and prices are therefore skyrocketing, why is Google able to hold steady on its device pricing, and Apple to go even further, holding prices while simultaneously boosting on-device capacities? Right now, I suspect, both companies’ sizes have enabled them to negotiate favorable pricing and volume contracts with memory suppliers. And further to the “sizes” point, even after those contracts time out, I suspect that both companies will be willing (albeit not necessarily delighted) to endure short-term profit margin pain in order to squeeze smaller, less profitable competitors out of the long-term market.

More to come

When I saw yesterday that Apple had released new public beta versions of its next operating system updates for phones and tablets, but not for computers, I suspected that this delay was only temporary and related to new computers planned for announcement today. And right on schedule, they (therefore it) came this morning; updated versions of the 14” and 16” MacBook Pro, based on the new Pro and Max variants of last fall’s M5 SoC (now also inside the MacBook Air), along with a duet of new displays.

I doubt we’re done; a new low-end MacBook (likely named the Neo) based on the iPhone 16 Pro’s A18 Pro SoC is rumored to still be on queue for Apple’s “big week ahead”, for example, and I can’t help but wonder if we’ll also get a M5-based Mac mini (last updated in November 2024). Stay tuned for more coverage to come from yours truly, hopefully later this week. And until then, let me know your so-far thoughts in the comments!

p.s…Two more MWC-related tidbits. Qualcomm has a promising next-generation SoC for smart watches and other wearables on the way. And speaking of Qualcomm, ready or not, 6G is coming…

—Brian Dipert is the Principal at Sierra Media and a former technical editor at EDN Magazine, where he still regularly contributes as a freelancer.

Related Content

• Google’s Pixel Smartphone Line: Extended and…Distended?
• The Apple iPhone 16e: No more fiscally friendly “SE” for thee (or me)
• Google’s fall…err…summer launch: One-upping Apple with a sizeable product tranche
• It’s September in Apple land, so guess what it’s time for?
• If you made it through the schtick, Google’s latest products were pretty fantastic

The post MWC 2026: Apple, Google, Samsung and Other Contending Contestants appeared first on EDN.

I love Design Ideas (DIs) with a backstory.  Recently, frequent DI contributor Jayapal Ramalingam published an engaging tale of engineering ingenuity coping with a design feature requirement added unexpectedly and very (very!) late in product development: “Using a single MCU port pin to drive a multi-digit display.”

Jayapal writes, “Imagine a situation where you have only one port line left out, and you are suddenly required to add a four-digit display.”

Yikes!  Add a looming delivery deadline to build suspense, and this becomes a classic nightmare scenario. It could easily develop, from an engineering standpoint, into a horror story straight out of the pages of Stephen King. Well, okay. Almost.

Wow the engineering world with your unique design: Design Ideas Submission Guide

But in a clever plot twist, engineer Jayapal shows how a bit (no pun!) of ingenuity turns this tale of terror into an opportunity for some cool circuit design. In his DI, different durations of software-generated pulses on that lonely port line become the control signals necessary for running the newly needed decimal display.

Crisis and calamity averted.

So I wondered how the same basic plot could make a basis for a more generalized storyline. In this version, not just four digits of numerical binary-coded decimal (BCD), but N bits of arbitrary parallel binary outputs would be driven in a similar solitary serial fashion. And all this would be achieved by the same singleton GPIO port bit. Figure 1 shows how the story takes shape.

Figure 1 A lonely GPIO bit loads a lengthy serial string of parallel registers. 

Incoming pulses of variable length on GPIO are buffered by noninverting gate U1a and drive three sets of inputs. 

1. Timing circuits U1b (400us R1C3 SER input zero/one discriminator),
2. U1cd (2.4ms R4C2 parallel RCLK clock AC coupled Schmidt trigger),
3. SRCLK shift registers serial clock.

As illustrated in Figure 2, the interpulse (idle) state of the GPIO is high = 1. 

Figure 2 GPIO pulse timing.

A serial bit transfer pulse starts when the GPIO goes low = 0, releasing the timing RCs. Whether the pulse shifts to a 0 or 1 bit depends on its duration.  If < 100 μs (T0), the R1C3 timeconstant will still hold SER low when the rising edge of SRCLK clocks the serial registers. This will cause a 0 bit to be shifted in. If > 400 μs (T1), the opposite will occur, and the shift register gets a one.

In this way, a data rate between 2 kbps and 10 kbps (depending on the relative frequencies of ones and zeros) can be maintained as long as the idle period between pulses remains less than 600 μs. Completion of data transfer is signaled by allowing GPIO to remain idle for > TR = 3.5 ms.  This allows R4C2 to time out and a transfer pulse to occur on RCLK, commanding a broadside parallel data transfer from the shift registers to the parallel output bits.

Note that, going back to the original horror story, four BCD digits = 16 bits, two 8-bit shift registers, and 12 ms would be enough logic and time. I think that makes for a pretty good ending for a yarn about a far stretch of a single bit.

Stephen Woodward‘s relationship with EDN’s DI column goes back quite a long way. Over 200 submissions have been accepted since his first contribution back in 1974.  They have included best Design Idea of the year in 1974 and 2001.

Related Content

• Using a single MCU port pin to drive a multi-digit display
• Silly simple supply sequencing
• Short push, long push for sequential operation of multiple power supplies
• How to get the most out of a single timer on an MCU

The post Stretching a bit appeared first on EDN.

In electric vehicle (EV) designs, the shift from 400-V to 800-V battery systems is now a pressing issue. So, the panel discussion on the first day of Automotive Tech Forum 2026 was a good venue for a reality check on the future of 800-V EV architectures.

The panel titled “Powering the Electric Vehicle: From Semiconductors to Systems” explored the latest in battery management system (BMS) designs and what battery modeling tells us about the design challenges as we move toward 800-V systems. And how design building blocks like motor control in EV traction are coping with this transition.

The panelists discussed how 800-V EV architectures could reshape vehicle power distribution. Jerry Shi, sector general manager for EV, HEV, and Powertrain at Texas Instruments, spoke about the emerging 800-V EV design landscape, specifically from a drivetrain standpoint. He also outlined critical design challenges and viable solutions in this design arena.

Carsten Himmele, marketing manager for Automotive at Allegro MicroSystems, cautioned about the industry-wide adoption of 800-V battery systems. “The 400-V battery systems will still dominate mainstream markets due to cost and complexity trade-offs.”

Rohan Samsi, VP of GaN Business Division at Renesas, echoed similar sentiments while envisioning a deeper adoption of 800-V architectures to address range anxiety and efficiency concerns. He acknowledged the challenges such as cost, complexity, and consumer preferences. “The trade-offs between 400-V and 800-V architectures relate to component complexity and service warranty costs.”

So, in the 400-V to 800-V transition, there was a consensus that 800-V systems offer advantages in fast charging and reduced weight. However, for now, panelists expect that 400-V systems will remain dominant in mainstream markets due to their affordability.

Related Content

• How Semiconductors Will Drive EV Growth
• Exploring On-Board EV Systems from 400 V to 800 V
• New design frontiers in BMS hardware and software
• Shifting the EV Bus to 800 V: Benefits and Design Challenges
• GaN enables efficient, cost-effective 800V EV traction inverters

The post EV design: The truth about 400-V to 800-V battery transition appeared first on EDN.

It’s well known that the main job of a pulse width modulator’s filter is to limit the maximum peak-to-peak amplitude of the fPWM Hz-induced ripple. It attenuates this to a specified fraction—Frac of the full-scale PWM output—while passing PWMavg, the average value of the PWM signal.

Wow the engineering world with your unique design: Design Ideas Submission Guide

Although the duty cycle can change instantaneously, the filter’s response to that change takes time to settle. It’s convenient to define the settling time Tfrac to be that after which the transient response remains within ± Frac of PWMavg. (After fully settling, the response variations will be from the ripple only and will remain within ± Frac/2 of PWMavg.) And it’s generally true that the more the ripple is attenuated, the larger Tfrac is. But for a given filter with two or more poles, there is an infinite number of combinations of component values that will limit the maximum ripple to Frac. (Think of the number of poles as being the number of capacitors in an R – C filter.) And yet the value of Tfrac is typically different for each combination. So we have a filter optimization problem: find the component value combination that minimizes Tfrac while satisfying the ripple requirement Frac.

I’ve addressed this issue before in a Design Idea (DI), but the procedure’s complexity was perhaps off-putting and inadequately flexible. I’ve since revisited the problem, finding a somewhat improved and analytically optimal solution. But that improvement alone does not justify a new DI.

So, why this new DI?

What I think does justify this is a spreadsheet that offers greater flexibility in terms of filter requirements and automates all the work for you. Download the files from https://github.com/Christopherrpaul/Customizable-PWM-Filter .

If you use OneDrive or something like it, you must install the files outside the OneDrive folder. (Safely ensconced there, OneDrive doesn’t “see” them and can’t interfere with the spreadsheet’s query of the paths to where certain files are stored locally.)

Open the spreadsheet. In the following, the yellow-highlighted parameters here and on the spreadsheet are inputs to be supplied by the user; the green-highlighted ones are spreadsheet outputs. Tell it your PWM frequency, in Hz, specify the required value of Frac, and press the “Calculate” button.

The Visual Basic Application (VBA)-driven spreadsheet takes that information and determines the values of the filter’s real and complex pole pairs ( the Q and ω0 of the latter ), which give you the optimal, smallest Tfrac, which it also displays.

To produce an implementable filter, it then combines this information with the (default) values of the filter’s capacitors c1, c2, and c3 . (These you can change and again press Calculate.) From all of this, it determines both the exact and the closest standard E96 values for the resistors r1, r2, and r3 needed to complete the filter. The filter itself is the third-order Sallen-Key low-pass depicted in the schematic portion of the spreadsheet screenshot seen in Figure 1.

Figure 1 A screenshot of the spreadsheet that runs the show. See the text.

And since we all like graphs, two have been provided. The one on top shows how ω0 and the real portion of all poles vary with Q. More importantly, it also shows that TFrac generally gets worse (larger) as Q is increased (not surprising, with the concomitant increase in oscillatory amplitudes).

The other graph shows the decay with time of PWMavg minus the absolute value of the transient response, with the voltage displayed on a logarithmic scale. The bumps are evidence of a damped oscillatory behavior.

But as they say in the late-night TV commercials (or at least they used to), “But wait! There’s more!”

How do I know this thing works?

You might ask how you can confirm that this filter will perform as advertised. The answer is easy if you’ve installed LTspice on your computer and you tell the spreadsheet the path starting from the root directory to the LTspice.exe file. Mine’s in C:\Users\chris\AppData\Local\Programs\ADI\LTspice\LTspice.exe.

Don’t worry if you can’t see the entire entry in the Excel cell provided. (NOTE – With the discussions surrounding the ongoing changes in LTspice versions 26.x.y, these files have been developed for use with the stable and still widely used LTspice 17.1.15. This version can still be downloaded and installed: https://ltspice.analog.com/software/LTspice64.exe. I haven’t checked if the files work with the 26.x.y versions.)

Press the “LTspice: Exact…” button. It will automatically launch a simulation using the exact resistor values derived and plot the filter’s response to the two biggest transients: a “full” one from 0 to 100% duty cycle (no PWM ripple) and a “half” one from 0 to 50% duty cycle (maximum possible ripple). See Figure 2 for a sample LTspice run.

Figure 2 An LTspice run using Exact component values for a sample filter.

The responses have been offset to reach their final values at 0 V. Tfrac appears on the plot as a vertical line along with two horizontal lines, which are at ± Frac. You can zoom in to see that the value of Tfrac is indeed correct; it crosses a ± Frac line exactly at the point that the full transition response does. (The full transition always takes a little longer to settle than the half-step transition.)

But alas, alack; this assumes perfect components with 0% tolerances. So the “LTspice Standard…” button launches a simulation of 100 Monte Carlo runs with capacitor and resistor tolerances of 1% and 1% using the E96 resistor values. (You can change all three of these default values and re-run the simulation. In fact, it’s worth considering the overall reduced settling time that can be had with suitably chosen 0.1% resistors added in series with small 1% resistors to more closely approach the exactly calculated values. Better tolerance capacitors would also help, but they tend to be prohibitively expensive.)

As you’ll see, non-zero tolerance variations lead to settling times longer than Tfrac. But by performing an extended number of Monte Carlo runs, you’ll be able to determine the time beyond which even filters made out of real-world components will have settled to Frac.

Filter design constraints

The real portions of all poles in the filter have been constrained to be identical. The reason for this is that these values control the decay rates of the half- and full-step transients, either of which could dictate the overall settling time. Given that the total ripple attenuation is the product of the real parts of both poles, if one were smaller than the other, it would extend the overall settling time beyond that achieved with identical poles. This constraint also simplifies the optimization problem in that there is only one real and one imaginary value of poles to consider, rather than one imaginary and two real values.

Calculated resistor values 

Depending on certain inputs to the spreadsheet, the derived values of the filter resistances might be smaller or larger than you’d like. In that case, the input values of the capacitors could be multiplied by a constant K of your choosing to obtain new resistor values divided by that K.

The spreadsheet’s default capacitor values are in the “Goldilocks” range—large enough that op amp input and PCB capacitances will affect them minimally, but small enough that NPO/COG type capacitors (whose stability with temperature and DC voltages are demanded in filter designs) are not prohibitively expensive. The ratios of one to the other of the default capacitor values have been shown to consistently result in realizable filters. Feel free to experiment with other values and ratios, but be aware that it might not be possible to realize filters with those changes.

Filter drivers

Do not drive the filter from a microprocessor directly. Its non-PWM functions draw currents that lead to small voltage drops across the IC-to-package-pin bonding wires. These induce errors by preventing signals from getting close to the ground and the supply rail. Instead, buffer the microprocessor with dedicated SN74AC04 logic inverters, which will swing to the rails, since they have no other currents to deal with and their outputs are minimally loaded. For a reasonably accurate reference voltage supplying the SN74AC04, consider the REF35.

SN74AC04-induced errors

It’s been pointed out that all digital drivers have different logic high and low resistances. These differences are sources of error that are worst at a 50% duty cycle. The part’s data sheet says that at a 3-V supply, the logic high voltage drop under a 12-mA load over the industrial temperature range could be as high as 560 mV, with a resistance of 45 ohms.

The logic low resistance maximum is a bit better, but there is no spec for the difference. The safe but admittedly ridiculous possibility is that the logic low resistance is 0 ohms, leaving us with a 45-ohm difference. This can be mitigated by paralleling G gates to reduce the drive resistance by that factor to produce a difference of Rdiff = 45/G.

Since no DC current can flow through the filter’s passive components, the fractional full-scale error at 50% is:

.5 · r1 / ( r1 + Rdiff) – .5 = – .5 · Rdiff / ( r1 + Rdiff)

For a b-bit PWM, you’d probably want the error to be less than half of one LSbit or 2-b-1. So you’d require that r1 > Rdiff · 2b.

Consider G = 5. For b = 8, r1 > 2300 ohms. For b = 12, it’s 37 kohms, and for b = 16, 590 kohms. But this brings up a second point: a large b means a relatively small fPWM and therefore a large TFrac. Fortunately, there’s a way around this.

Double up

Summing the contributions of two 8-bit PWMs, one of whose signals’ amplitude is 256 times that of the other, allows both to have an fPWM 256 times larger than that of a single 16-bit PWM. This yields a TFrac reduced by the same factor. Figure 3 shows one way to employ this approach.

Figure 3 Configuration with independent most significant (MSbit) and least significant (LSbit) 8-bit PWMs, the latter contributing 1/256 of the former, to replace a single 16-bit PWM. This arrangement reduces the settling time by a factor of 256.

Op-amp considerations

Figures 1 and 3 lead to the question of which op amp to use. A rail-to-rail input and output unit is warranted. The OPA376 family of singles, duals, and quads is a good answer.

It’s 25 µV at 25°C, ±1 µV/°C from -40 to +85°C, and barely disturbs the accuracy of even a 16-bit PWM. Its input bias current of 10 pA maximum at 25°C, and its typical (no maximum spec) of less than 50 pA at 85°C, introduces errors on par with its offset voltage. Consider the op amp’s output rail-to-rail limitations, however. Either avoid PWM duty cycles at the extremes, or extend the op amp’s supply rails a few tens of millivolts (see its data sheet) beyond those of the PWM.

In approaching your design, you might find the following nomograph in Figure 4 useful.

Figure 4 The above nomograph can aid in selecting the operating point of your design.

Problems, gripes, suggestions, requests, and accolades

The spreadsheet employs VBA numerical iteration routines to find the Q, ω0 pairs and the filter resistors. Although I’ve tested these routines extensively, it’s always possible that one or the other will fail to converge with some combination of input values.

In that case, please let me know by adding a note to the “Comments” section of this DI. This will generate an automatic email alert and will allow the inclusion in our conversation of others who might be interested. Please do not email me unless you have a comment that is truly meant to be private (a marriage proposal?) I encourage feedback of all kinds.

A grudging acknowledgement

I’d be remiss if I did not mention the help I got from a certain widely available AI program in developing this project. This ranged from deriving Inverse Laplace transforms and Newton-Raphson iteration algorithms to VBA coding.

But working with this AI wasn’t all lollipops and rainbows. In the course of the effort, I was reminded of Ronald Reagan’s admonition to “Trust, but verify.” But as things progressed, I dropped the “trust” part.

I found I had to break tasks down into sections, understand each that was provided, test assiduously, and make corrections before proceeding to the next step. Setting a multi-step task was a recipe for disaster. Still, AI is a valuable tool, and I find it even more valuable now that I better understand how to work with it.

I’d be interested in hearing about others’ experiences.

Related Content

• Gold-plated PWM-control of linear and switching regulators
• Brute force mitigation of PWM Vdd and ground “saturation” errors
• A nice, simple, and reasonably accurate PWM-driven 16-bit DAC
• PWM buck regulator interface generalized design equations

 

The post Custom design PWM filters easily appeared first on EDN.