Новини світу мікро- та наноелектроніки

The device is Melexis’ first dual-input inductive ASSP sensor, purpose-built for demanding automotive applications like steer-by-wire and torque feedback.

submitted by /u/ScienceDIY [link] [comments]

Intel has pulled back the curtain on Panther Lake, the first client architecture built on its advanced 18A process node.

Life is rife with dichotomies. Good and evil. Black and white. Up and down. Left and right. And, apparently, Ultrahuman and Ringconn ;-). My previous post detailed my experiences, observations, and conclusions from a week or so evaluating the Ultrahuman’s Ring AIR smart ring, following up on last month’s smart ring introductory overview write-up. This one will cover its also-scheduled-for-shipment-cessation-on-October-21 competitor, RingConn’s Gen 2.

What do I mean by dichotomy in this regard? Well, several of the Ultrahuman weak points were, in contrast, RingConn’s strengths. What did I like the most about the Ultrahuman smart ring? It’s the same thing I liked least about RingConn’s alternative device.

Color shortcomings

Let’s dive into the details, starting with that last nitpick bit, since it matches the ordering cadence from last time. Here again are all three smart rings I initially tested, simultaneously located on my left index finger:

The RingConn Gen 2 is at the right, with the Ultrahuman Ring AIR in the middle and Oura’s Gen3 Horizon at left. Color options specifically selected for my evaluations are as follows:

• RingConn Gen 2: Future Silver
• Ultrahuman Ring AIR: Raw Titanium
• Oura Gen3 Horizon: Brushed Titanium

As mentioned last time, the Ultrahuman ring is the closest match to my wedding band on the left-hand ring finger. The Oura Gen3 Horizon is next in the similarity line, although, as you’ll see in near-future detailed coverage of it, the differentiation from my band is more obvious when it’s standalone on the index finger. And the sketchiest match, at least from the standpoint of the wedding band’s body color, is the RingConn Gen 2, although in exchange, it alternatively does a decent job of accentuating the wedding band’s bright edges:

The irony here is that the original RingConn Gen 1 did come in a duller Moonlit Silver color option, which likely would have been a closer match, but for some unknown reason, the company decided not to continue it into the next-generation offering:

Other folks are apparently displeased with the shinier evolutionary trend, too, and have dulled their Gen 2s using abrasive-side kitchen sponges, Dremels, files, and the like. I’m impressed with the results, although I’m admittedly not sure I’ve got the moxie to follow in their footsteps:

Battery life and other bonuses

From this point forward, pretty much everything else came up roses. I’d bought my ring, gently (and briefly) used, off Mercari (no, I never seemingly learn, but this time the outcome was positive) back in mid-June for ~$200 inclusive of tax, shipping, etc., representing a 33.3% (or more) discount off the normal sale price. Initially, the battery charge level only dropped ~5% per day, translating into a whopping nearly three weeks of estimated between-charges operating life (although I never let it completely drain to see if the discharge rate was truly linear or not). Even now, roughly three months later, the drain is still notably less than 10% per day. And it recharges very quickly.

To the best of my recollection, the ring (originally introduced in August 2024) has also received only one firmware update the entire time I’ve owned it, which installed successfully and drama-free. I really do like RingConn’s direct (vs inductive) charging scheme, which reliably mates the ring to the dock (courtesy of magnetic attraction between the two sets of contacts) and preserves existing dock investments if you change ring sizes:

And the high-end Gen 2 comes with an official (from-RingConn versus third-party) battery case, convenient for use when traveling (for long durations, mind you, given the ring’s inherent lengthy between-charges operating life):

Standard charging docks, factory-bundled with the lower-priced Gen 2 Air (which I’ll cover next), can also be purchased separately for both Gen 2 smart ring models.

The lower-priced, apnea-less alternative

The mainstream Gen 2 smart ring I tested normally sell for $299 or more (minus occasional promotional discounts) on Amazon and elsewhere, and comes in three color scheme options:

• (aforementioned) Future Silver
• Matte Black
• Royal Gold

For $100 more ($399 total), there’s also a (fourth) Rose Gold color option.

RingConn also sells a $199 “Air” version of the Gen 2 smart ring. There are, as far as I know, only two differences between it and the more expensive alternative:

• Only two color options this time: Galaxy Silver and Dune Gold, and
• No sleep apnea measurement and analysis capabilities (which may reflect a reduced sensor or other functional allotment, or may just be a software feature lock-out)

The latter point is one for which I have personal interest, so I’ve spent a fair bit of time assessing it. For one thing, the RingConn Gen 2 is the only smart ring I’m aware of on the market that offers this feature. I tested it a bit; here’s the report I got on September 5, for example:

which closely correlated with the data that came directly from my Resmed CPAP machine:

That said, the comparative results for the next night weren’t quite as synonymous, although they were still “in the ballpark”:

What you’re looking for when comparing results, at least at first, is the AHI (Apnea-Hypopnea Index) number, which Resmed’s software alternately refers to as “Events/hr” in its summary screen. Here’s an overview description, from the Sleep Foundation website:

The Apnea-Hypopnea Index (AHI) quantifies the severity of sleep apnea by counting the number of apneas and hypopneas during sleep. Apneas are periods when a person stops breathing and hypopneas are instances where airflow is blocked, causing shallow breathing. Normal AHI is less than 5 events per hour, while severe AHI is more than 30 events per hour. The AHI guides healthcare professionals in their diagnosis and in determining effective treatment.

A key point to note here: I was using my CPAP machine both nights, which is why the AHI was so low in the first place. To that point, a sleep apnea-assessing smart ring is IMHO of limited-to-nonexistent value once you’ve been diagnosed and treatment is in process, since further apnea is suppressed (assuming your treatment regimen is effective, that is). Anyway, the treatment equipment is likely already reporting the data you need to assess effectiveness. Save the $100 in this case. Conversely, though, as an early-warning indication of potential apnea, which you don’t yet realize you’re suffering from? Given the large number of people who are reportedly sleep apnea-afflicted but don’t yet realize it, from study results I’ve seen, as well as how significantly apnea can health-compromise a person, I’m gung-ho on RingConn’s smart ring for that scenario.

Oh, and before going on, here’s the report that RingConn’s app generates after it’s gotten at least three nights’ worth of sleep data point sets to comparatively assess:

Other observations

Much of what follows echoes what I said about the Ultrahuman smart ring in my previous post and/or in last month’s initial overview piece. Nevertheless, for completeness’ sake:

• It (like others) misinterpreted keyboard presses and other finger-and-hand movements as steps, leading to over-measurement results, especially on my dominant right hand.
• While the Bluetooth LE connectivity extends battery life versus a “vanilla” Bluetooth alternative, it also notably reduces the ring-to-phone connection range. Practically speaking, this isn’t a huge deal since the data is viewed on the phone. Picking up the phone (assuming your ring is also on your body) will prompt a speedy close-proximity preparatory sync.
• Unlike Oura (and like Ultrahuman), RingConn provides membership-free full data capture and analysis capabilities. The company also sells optional extended warranties.
• And the app will also automatically sync with other health services, such as Google Fit and, more recently, its Android Health Connect successor. That said, I wonder (but haven’t yet tested to confirm or deny) what happens if, for example, I’m wearing both the ring and my Health Connect-cognizant (either directly or via the Health Sync intermediary) smartwatches from Garmin or Withings. Will the service endpoint be intelligent enough to recognize that it’s receiving concurrent data from two different sources and either discard one data set or reconcile them, rather than just adding them together?

And with that, a few hundred words shorter than its Ultrahuman predecessor (which in this case definitely isn’t a bad thing from a RingConn standpoint), I’m going to wrap up this write-up.

It turns out I’ve got two different Oura posts coming up; I ended up picking up a gently used Ring 4 to supplement its Gen3 Horizon precursor. Plus, two different smart ring teardowns, as well. So, stay tuned for those. And until then, please share your thoughts in the comments!

—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

Related Content

• The Smart Ring: Passing fad, or the next big health-monitoring thing?
• Can a smart ring make me an Ultrahuman being?
• The 2025 CES: Safety, Longevity and Interoperability Remain a Mess
• Smart ring allows wearer to “air-write” messages with a fingertip

The post RingConn: Smart, svelte, and econ(omical) appeared first on EDN.

Infineon Technologies AG of Munich, Germany has launched the CoolSiC MOSFETs 1400V G2 in the TO-247PLUS-4 Reflow package, supporting higher DC-link voltages and enabling improved thermal performance, reduced system size and enhanced reliability...

Japan-based power semiconductor firm ROHM has released a new white paper detailing power solutions for AI data centers based on the 800VDC architecture of NVIDIA of Santa Clara, CA, USA...

submitted by /u/Porphyrin_Wheel [link] [comments]

Edge AI, mired by fragmentation and a lack of broad availability of toolchains, is inching toward open architectures and open-source hardware and software. This shift was apparent at Synaptics Tech Day on 15 October 2025, held at the company’s headquarters in San Jose, California.

In other words, some edge AI processors are moving away from proprietary, closed AI software and tooling toward open software and ecosystems to deliver AI applications at scale. Google’s collaboration with Synaptics embodies this open-source approach to edge processors, aiming to deliver AI intelligence at very low power levels.

Figure 1 Astra SL2610 processors provide multimodal AI compute for smart appliances, home and factory automation equipment, charging infrastructure, retail PoS terminals and scanners, and more. Source: Synaptics

Google, which built a mini-TPU ASIC for edge AI under the Coral brand back in 2017, subsequently built the Coral NPU as a four-way superscalar 32-bit RISC-V CPU. Google is hoping that edge AI silicon suppliers will start using this small, lightweight CPU as a consistent front-end to other execution units on an edge AI processor.

As part of this initiative, Google has open-sourced a compiler and software stack to port models from any ML framework onto the CPU. That allows silicon vendors like Synaptics to create an open-standards-based pipeline from the ML frameworks all the way down to the NPU front-end.

But the question is why RISC-V, especially when Synaptics’ SL2610 processor is built around Arm Cortex-A55, Cortex-M52 with Helium, and Mali GPU technologies. Synaptics managers say that the move to RISC-V is intended to reduce fragmentation in software stacks serving edge AI designs.

When asked about this, John Weil, head of processing at Synaptics, told EDN that many semiconductor suppliers are employing RISC-V cores, generally as assisting cores, and most people don’t know that they are even there. “In this case, it’s a much more performance-oriented RISC-V core to perform neural processing.”

Synaptics tie-up with Google

In January 2025, Synaptics announced it would integrate Google’s ML core with its Astra open-source software to accelerate the development of context-aware devices. The collaboration aimed to combine AI-native hardware with open-source software to accelerate the development of context-aware devices.

Next, Synaptics introduced the Torq edge AI platform, which combines NPU architectures with open-source compilers to set a new standard in edge AI application development. Torq, leveraging an open-source IREE/MLIR compiler and runtime, has been critical in facilitating the deployment of Google’s RISC-V-based Coral open NPU in the edge AI processor Astra SL2610.

Figure 2 Torq, a combination of AI hardware and software, includes Google’s Coral NPU and Synaptics’ home-grown AI accelerator. Source: Synaptics

At Synaptics Tech Day, the company showcased the Astra SL2610 processor powering several edge AI applications. That included e-bikes, EV charging infrastructure, industrial-grade AI glasses, command-based speech recognition, and smart home automation.

Vikram Gupta, chief products officer at Synaptics, told EDN that when the company wanted to go broad, it decided that this processor would be AI native. “When we met with Google, it instantly resonated with us because they were working on Coral NPU, an open ML accelerator,” he said. “We also wanted to go open source as part of our AI-native processor story.”

Regarding Google’s interest in this collaboration, Gupta said that Google benefits because it has a silicon partner. “Google gets mindshare in the AI race while it’s prominent in the cloud as well as the edge AI.” Moreover, Google could bring multimodal capabilities to this tie-up to enable more context-aware user experiences, said Nina Turner, research director for enabling technologies and semiconductors at IDC.

Another critical goal of this silicon partnership is to confront fragmentation in the edge AI world. “Our take is that the only way to keep up with AI innovation at the edge is to be open,” said Weil of Synaptics. “While some edge AI suppliers want everything in their ecosystem, we are focused on how we knock down walled gardens.”

Regarding collaboration with Google, Weil added, “As an edge AI guy, I need to be working with guys working in the cloud, focused on the next big AI idea.” He further summed up by saying that for Synaptics, the challenge was how to make hardware that keeps up with the speed of AI, open architecture, and open source. “So, we took Google technology and matched it with ours.”

Open and collaborative

At a time when innovations in AI software and algorithms are far outpacing silicon advancements, an AI-native approach to edge IoT processing could be critical in adopting contextual LLMs for audio, voice, text, and video applications at the edge.

The launch of the Astra SL2610 processor, an AI-enabled system-on-chip (SoC) encompassing application processor-level as well as microcontroller-level parts, marks an important step in the availability of scalable, open systems for deploying real-world edge AI. These AI-native chips are expected to help create an ecosystem that will simplify development and unlock powerful new applications in the edge AI realm.

“We believe that the only way to keep up with AI innovation at the edge is to be open and collaborative,” Weil concluded.

Related Content

• It’s All About Edge AI, But Where’s the Revenue?
• How Edge AI Transforms IIoT and Enables Industry 5.0
• Hybrid system resolves edge AI’s on-chip memory conundrum
• Infineon Expands Edge AI Capabilities with Launch of DEEPCRAFT AI Suite
• The Future of the Edge: The Rising Tide for Better AI Performance, Scalability, and Security

The post An edge AI processor’s pivot to the open-source world appeared first on EDN.

submitted by /u/Far-Orchid-1041 [link] [comments]

Learn how the Foster-Seeley discriminator, a classic analog circuit for FM demodulation, achieves its superior linearity.

This is probably pretty common since there are 8 (EIGHT!!!) of these inside a cheap Samsung monitor, still, found it really impressive that this is (1) possible & (2) economically viable. submitted by /u/Bug_Next [link] [comments]

submitted by /u/AutoModerator
[link] [comments]

hi hi again :3 Can't believe it took so long to get them, but I had to fix a few things here and there. Then I made an order during Chinese holidays, and customs, as always, requested a description for my PCBs but didn’t contact me, so I had no idea I had to do anything until the store called me and told me I’d better call DHL right now (please add me to the whitelist <3) Description of the setup. For frequency testing, I was using a signal generator and scope together. Scope input signal point is the electrode test point, and output is the Vout test point. This way, whatever happens with the signal between the signal generator and the electrode itself does not matter. For the heartbeat signals, I had both passive and active electrodes connected in pairs (positive and negative): Bias was on my left leg (just one, passive as before, you do not need any active electrodes there), the first contact point is around the collarbone, the second contact point under my heart on the last rib. Passive electrodes are connected using sticky gel pads, active electrodes only dry contact with and without conductive rubber (1 mm thick, bought it on Adafruit store, if I measure resistance from top to bottom it gives me around 300 Ohm). To connect electrodes, I’ve soldered wire for the ground and 5 V output of my Meower board (link is right at the end). I thought I would add noise to the power rail and it would be bad — no, it’s fine :3 So, electrodes do work: Frequency response almost perfectly matches calculations (you can see it on the schematic pic) It looks like we can go rail to rail; it cuts the signal at 0 and keeps it alive until you hit above 5 V. I haven’t seen any problems with noise or clicks or any other types of noise I could spot in the time domain Dry contact use case with just direct contact gives not amazing but really good results — rattle noise, movements, network noise (50/60 and 100/120 Hz noise) almost nonexistent. The difference is huge. I didn’t even get what was going on at the beginning, thought something was wrong Dry contact with conductive rubber in between gives almost the same results as just direct contact, but I feel like it picks up a bit more electrode movement itself. Maybe I had to use adhesive between metal and rubber itself, but if it sits on your skin and the rubber has good contact with you and the electrode - almost no difference. There is a pic with heartbeat seignals. Green line is active electrodes and orange is passive. you can see there not only 50 and 100 Hz network noise, but also spikes - i was tapping on all cable at ones and the only one which pick up rattling were passive electrodes. So, rattle goes away, network noise goes down by alot even without filtering - looks really good. So - now I can say - if you found this post, electrodes are tested and they do work. Schematic is correct (unless proven otherwise, if so let me know please :3). Conductive rubber works just fine, and I feel like just for normal use for BCI it’s the best way, so there are no contacts with any metal and it’s a bit softer and more comfortable. Thank you so much to everyone who told me I’m stupid and found problems here and there. I can’t believe I made 10 mistakes in 10 components, but I did :3. Though I’ve learned a lot. Anyway, thanks again. You can find active electrodes files here https://github.com/nikki-uwu/Meower/tree/master/hardware submitted by /u/Meow-Corp [link] [comments]

The design features wide bandgap semiconductors in a full-bridge LLC with planar magnetics.

- This chip incorporated 2 chips in one package. The CPU die and the L2 cache die. - The chip also had a superscalar design and a RISC-based processor. - The gold finishes are for bond reliability and corrosion-resistance. Plus, they look cool submitted by /u/SkunkaMunka [link] [comments]

Omnivision expands its automotive portfolio with two new image sensors. The OX05C global shutter (GS) high dynamic range (HDR) sensor is a new addition to the company’s Nyxel near-infrared (NIR) family for in-cabin monitoring cameras, and the OXO8D20 image sensor targets advanced-driver assistance systems (ADAS) and autonomous driving (AD) applications.

The OX05C represents the automotive industry’s first and only 5-megapixel (MP) back-side illuminated (BSI) GS HDR sensor for driver and occupant monitoring systems, according to Omnivision. It delivers extremely clear images of the entire cabin, enabling improved algorithm accuracy even in high-brightness conditions.

OX05C GS HDR image sensor (Source: Omnivision)

The 2.2-µm OX05C features Omnivision’s Nyxel NIR technology, claiming world-class quantum efficiency (QE) at the 940-nm NIR wavelength, improving driver and occupant monitoring systems capabilities in low-light conditions. The on-chip RGB-IR separation eliminates the need for a dedicated image signal processor and backend processing.

The GS HDR OX05C also avoids interference from other IR light sources in the cabin, compared to rolling-shutter HDR sensors, Omnivision said, improving the RGB image quality and enabling more capture scheme and functions in real applications.

Measuring 6.61 × 5.34 mm, the OX05C1S package is 30% smaller than its predecessor, the OX05B (7.94 × 6.34 mm), allowing greater design flexibility when placing cameras in the automotive cabin. OEMs also use the same camera lens when upgrading from the OX05B to the newer OX05C for a design and cost advantage.

In addition, the integrated cybersecurity and the support of simultaneous driver and occupant monitoring with a single camera reduces complexity, cost, and space, Omnivision said.

The sensor comes in Omnivision’s stacked a-CSP package and a reconstructed wafer option for designers that need to customize their own package. The OX05C sensor is available in both color filter array RGB-IR and mono designs. Samples of the OX05C are currently available. Mass production starts in 2026.

In addition to the OX05C, Omnivision introduced the 8-MP  OX08D20 automotive image sensor with TheiaCel technology for exterior automotive cameras. It delivers improvements in low-light ADAS and AD performance and is an upgrade to the OXO810 sensor for exterior cameras.

OX08D20 automotive image sensor (Source: Omnivision)

The OX08D20 features the same benefits of the OX08D10, plus an innovative capture scheme developed in collaboration with Mobileye that reduces the motion blur of nearby objects while driving and improves low-light performance. It also upgrades to 60 frames per second to enable dual-use cameras, and includes updated cybersecurity to match the MIPI CSE 2.0 standard.

The image sensor features low power consumption and is housed in an a-CSP package that is 50% smaller than other exterior sensors in its class. The OX08D20 will be sampling in November 2025 and will enter mass production in the fourth quarter of 2026. 

The post Omnivision expands automotive image sensor portfolio appeared first on EDN.

Littelfuse Inc. extends its K5V Series of illuminated tactile switches with the release of new K5V4 models including the gull-wing and 2.1-mm pin-in-paste (PIP) versions compatible with reflow soldering. These switches target a range of applications, such as data centers, network infrastructure, industrial equipment, and pro audio/video systems.

(Source: Littelfuse Inc.)

The K5V4 is the first long-travel, single pole/double throw (SPDT) illuminated tactile switch in a reflow-capable SMT package, Littelfuse said, filling a critical gap in the market. They enable direct SMT assembly for the first time, reduce production costs, support higher throughput, and improve end-product quality, while maintaining durability and tactile performance, the company added.

The K5V4 switches are reflow soldering-compatible thanks to the use of a high-temperature polyarylate (PAR) material with a 250°C thermal deformation threshold, eliminating the need for silicone sleeves or special handling. They are  suited for manufacturers transitioning from wave to reflow soldering processes.

Other features include SPDT contact configuration with normally-open and normally-closed options, a sharp tactile response with audible click and 4N operating force, and integrated high-brightness LEDs in a variety of colors and bi-color options.

For greater reliability, these switches provide a compact, dust-resistant design for reliable operation in dense boards, and gold-plated dome contacts for long-term contact performance. They are available in SMT (gull wing) and THT (PIP) versions for design flexibility.

The K5V tactile switches are currently available in tape and reel format, with quantities ranging from 1,000 to 2,000 units. Samples can be requested through authorized Littelfuse distributors.

The post Illuminated tactile switches withstand reflow soldering appeared first on EDN.

Hello r/electronics! I've made a WLED compatible controller for a friend of mine, and I wanted to give something back to the awesome electronics community! My controller supports: 4 high-current open-drain PWM outputs for analog 0-24V LED strips. 4 high-speed differential transmitters for driving 12V addressable LED strips using lengthy wires - the corresponding receivers (which can be soldered in-line with most LED strips) are also linked in the GitHub repo. 4x isolated optocoupler inputs (0-50V) for light switches, pushbuttons, and interfacing with other systems. An onboard USB programmer for easy programming. If you want to make your own, all of the necessary files for production (gerbers, BOM, PnP files) are available in the repository, together with the schematics and a bit more information. Please do read the "Limitations" section before ordering your own copy; if you have any uncertainties, don't hesitate to reach out to me! https://github.com/KuglicsL/LED_control submitted by /u/KuglicsL [link] [comments]

Bipolar stepper motors provide precise position control while operating in an open loop. Industrial automation applications—such as robots and processing and packaging machinery—and consumer products—such as 3D printers and office equipment—effectively take advantage of the stepper’s inherent position retention. This eliminates the need for convoluted sensor technology, processing power requirements, or complex control algorithms.

However, driving a stepper motor in an open-loop methodology requires the motion profile to be errorless. Any glitch in which the stepper’s load abruptly changes results in step loss, which desynchronizes the stepper position from the application’s perceived position. In most cases, this position tracking loss is problematic. For example, in a label printer, step loss could cause the print to be skewed with the label, resulting in skewed label prints.

This article will describe a simple implementation that gives stepper motor the ability to sense its position and actively correct any error that might accrue during actuation.

 

Design assumptions

For this article, we will assume that a bipolar stepper motor with 200 steps per revolution is employed to drive a mechanism that is responsible for opening and closing some sort of flap or valve while servicing a production line. To make motion smooth, we will utilize a bipolar stepper driver with 8 degrees of microstepping, resulting in 1,600 step commands per full rotor revolution.

In order to fully open or close said mechanism, we will need multiple rotor turns; for simplicity, assume we need 10 full turns. In this case, the controller would need to send 16,000 step commands on each direction to successfully actuate the mechanism.

When the current is high enough to overcome any torque variation, the stepper moves accordingly and can fully open and close the control surface. In this scenario, the position is preserved. If steps are lost, however, the controller loses synchronization with the motor, and the actuation becomes compromised.

Newer technologies attempt to provide checks, such as stall detection, by measuring the motor winding’s back electromotive force (BEMF) when the applied revolving magnetic field crosses the zero-current magnitude. Stall detection only tells the application whether the motor is moving; it fails to report how many steps have been effectively lost. In cases like this, it’s worthwhile to explore closing the loop on the rotor position using sensing technology.

Sensor selection

In some cases, using simple limit switches—like magnetic, optical, or mechanical—might suffice to drive the stepper motor until the limits are met. However, there are plenty of cases where the available space does not allow the use of such switches. If a switch cannot be used, it might make sense to populate an optical shaft encoder (relative or absolute) at the motor’s back side shaft, but there is a high cost associated with these solutions.

An affordable solution for this dilemma is a contactless angular position sensor. This type of sensor involves the use of readily available magnetics with precise and accurate semiconductors that employ Hall sensors, which extract the rotor’s position with as much as 15 bits worth of resolution. That means each rotor revolution can be encoded to as much as 215 = 32,768 units, or 0.01 degrees (360/32,768).

For this example, an 11.5-bit resolution was selected, as that will be sufficient to encode the 1,600 microsteps. By using 11.5 bits of resolution, we can obtain 2,896.31 effective angle segments. A Hall-effect based contactless sensor such as the MA732 provides absolute position encoding with 11.5 bits of resolution.

When coupled to a diametrically magnetized round magnet, the sensor is periodically sampled through its serial peripheral interface (SPI) port at 1-ms intervals (Figure 1). When a read command is issued, the sensor responds with a 16-bit word. The application uses the 16 bits worth of information, although the system’s accuracy is driven by the effective 11.5-bit resolution.

Figure 1 The Hall-effect sensor is connected to the MCU through the SPI ports. Source: Monolithic Power Systems

Power stage selection

Driving bipolar steppers require two full H-bridges. The two main implementations to drive bipolar stepper motors are using a dual H-bridge power stage with a microcontroller unit (MCU) to generate sine/cosine wave pairs or using a fully integrated step indexer engine with microstepping support. Using an MCU and dual H-bridge combination provides more flexibility in terms of how to regulate the sine wave currents, but it also increases complexity.

For this article, a fully integrated step indexer with as much as 16 degrees of microstepping was selected (Figure 2). The integrated step indexer in this article is MP6602, which provides up to 4 A of current drive and is capable of driving NEMA 17 and NEMA 23 bipolar stepper motors. Meanwhile, the MCU drives all control signals, communicates with the indexer through the SPI port, and samples the fault information.

Figure 2 The step indexer is connected to an MCU to drive the bipolar stepper motor. Source: Monolithic Power Systems

Final implementation

For a closed-loop stepper implementation, the sensor and power stage should be controlled by an off-the-shelf ARM Cortex M4F MCU. The MCU communicates with both devices through a single SPI port with two chip selects. An internal timer generates the steps. The board measures 1.35”x1.35” and is small enough to fit behind a NEMA17 stepper motor (Figure 3). This allows the reference design to be used in a larger motor frame size such as the NEMA 23.

Figure 3 The PCB’s bottom side has the MA732 angle sensor. Source: Monolithic Power Systems

Figure 4 shows the motor assembly, in which Figure 4a (above) shows the motor assembly with a diametrically magnetized round magnet facing MA732 sensor, and Figure 4b (below) shows the final solution.

Figure 4 Assemble the motor such that the housing is invisible. Source: Monolithic Power Systems

Absolute position and sensor overflow

Although the contactless magnetic based sensor is an absolute position encoder, this is only true on a per-revolution basis. That is, throughout the rotor’s angular travel through each revolution, the sensor provides a 16-bit number that the MCU reads, which essentially allows the firmware to learn the rotor’s absolute position at any given time.

As the motor revolves, however, each new revolution is indistinguishable from the previous revolution. We can add angular position readings into a much larger number, which can be expressed as a variable that takes all the angle readings to obtain the entire position as an absolute value (called Rotor_Angle_Absolute). This variable is a 32-bit signed integer.

If the motor moves forward, increment the variable, and vice versa. Assuming 16-bit readings, 1,600 microsteps per revolution, and a 1,000-rpm step rate, it would take 22.37 hours for the variable to overflow. The MCU must ensure that the sensor readings are added correctly, even as the rotor goes through its overflow region. This absolute position correction must be executed whether the motor is rotating clockwise or counterclockwise; in other words, the sensor position is incrementing or decrementing.

Figure 5 shows how the angle position changes over time.

Figure 5 The angle position changes over time as the motor revolves. Source: Monolithic Power Systems

Figure 5 shows that the angular displacement (MA732_Angle_Delta, denoted as AD in figure) is computed at periodic intervals (1ms). During each sample, the previous read is stored within MA732_Angle_Prev (denoted as Prev Angle in figure), the new sample is stored at MA732_Angle_New (denoted as New Angle in figure). MA732_Angle_Delta can be calculated with Equation 1:

The result of Equation 1 is added to MA732_Angle_Absolute. If the rotor moved clockwise (forward), the displacement is positive; if the motor moves counterclockwise (reverse), the displacement is negative.

A special consideration must be made during angle sensor overflows. If the sensor moves forward past the maximum of 0xFFFF (denoted as OvF+AD in Figure 5), or if the sensor decrements its position past 0x0000 (denoted as OvF-AD in Figure 5), the previous equation can no longer be used. In both scenarios, the FW logic chooses one of the following equations, depending on which case we are servicing.

If the angle displacement overflows when counting up and exceeds the maximum (OvF+AD), then MA732_Angle_Delta can be calculated with Equation 2:

If the angle displacement overflows when counting down and falls below the minimum (OvF-AD), then MA732_Angle_Delta can be calculated with Equation 3:

Stepper motor: New frontiers

Using an off-the-shelf MCU, we can interface the stepper motor driver and Hall-sensor based sensor via an SPI port. The firmware can then continuously interrogate the position sensor and extrapolate the motor rotor position at all times. By comparing this position to a commanded position, the motor can be commutated to reach the commanded position in a timely fashion.

If an external force causes the motor to lose steps, the sensor information tracks how many steps were lost, which then allows the MCU to close the loop on position and successfully bring the stepper motor to the commanded position.

Although stepper motors are mostly used in open-loop applications, there are plenty of advantages in closing the loop on position. By employing cost-effective, Hall-sensing technologies, and an easy-to-use index-based stepper drivers, the application can now add servo-like properties to their stepper-based applications.

Jose Quinones is senior application engineer at Monolithic Power Systems (MPS).

Related Content

• Stepper Motor Controller
• Stepper Motors: Care & Feeding
• Stepper Motor Controller Eliminates Need for Tuning
• Standard Step-Motor Driver Interface Limits Performance
• Why microstepping in stepper motors isn’t as good as you think

The post No more missed steps: Unlocking precision with closed-loop stepper control appeared first on EDN.

WDT in safety standards

With the prevalence of microcontrollers (MCUs) as processing units in safety-related systems (SRS) comes the need for diagnostic measures that will ensure safe operation. IEC 61508-2 specifies self-test supported by hardware (one channel) as one of the recommended diagnostic techniques for processing units. This measure uses special hardware that increases speed and extends the scope of the failure detection, for instance, a watchdog timer (WDT) IC that cyclically monitors the output of a certain bit pattern from the MCU.

The basic functional safety (FS) standard IEC 61508-2 Annex A Table A.10 recommends several diagnostic techniques and measures to control hardware failures in the program sequences of digital devices. Such techniques include a watchdog with a separate time base with or without a time window, as well as a combination of temporal and logical monitoring of program sequences. While each of these has corresponding maximum claimable diagnostic coverage, all these techniques employ WDTs.

This article will show how to implement these diagnostic functions using WDTs. Furthermore, the article will provide insights into the differences of program sequence monitoring diagnostic measures in terms of operation and diagnostic coverage when implemented with ADI’s high-performance supervisory circuits with watchdog function.

Low diagnostic coverage

Part 2 of IEC 61508 describes simple watchdogs as external timing elements with a separate time base. Such devices allow the detection of program sequence failures in a computer device, such as MCUs, within a specified interval. This is done by having a mechanism that allows either:

1. The MCU is to issue a signal to reset the watchdog before it reaches the timeout
2. The watchdog timeout period to be reached so that the watchdog can issue a reset signal to the MCU

Step #1 occurs when the program sequence is running smoothly, while step #2 happens when it is not.

Figure 1a shows an example of the watchdog implementation with a separate time base but without a time window through the MAX6814. Notably, MCUs usually have an internal WDT, but it cannot be solely relied on to detect a fault if it is part of the defective MCU, which will be an issue considering common cause failures (CCF).

To address such CCF concerns, a separate WDT is used to ensure the MCU is placed in reset [1, 2]. Through a flowchart, Figure 1b illustrates the behavior of the WDT as embedded in the MCU’s program execution. Before the flow starts, it’s important to set the watchdog timeout period or the WDT’s maximum reset interval. When such a period or interval is defined, the WDT will run upon execution of the program. The MCU must be able to send a signal to the MAX6814’s WDI pin before it reaches timeout, as the device will issue a reset signal to the MCU if the timeout period is reached. When the MCU resets, the system will be placed into a safe state.

Figure 1 Simple watchdog operation showing (a) an example of the watchdog implementation with a separate time base but without a time window and (b) the behavior of the WDT as embedded in the MCU’s program execution. Source: Analog Devices

Such a WDT’s timeout period will capture program sequence issues; for example, a program sequence gets stuck in a loop, or an interrupt service routine does not return in time. For instance, only 5 of the 10 subroutines meant to be run on every loop of the software are executed.

However, the WDT’s timeout period will not cover other issues concerning program sequence issues—whether execution of the program took longer or shorter than expected, or if the sequence of the program sections is correctly executed. This can be solved by the next type of WDTs.

Medium diagnostic coverage

Since the existence of a separate time window allows for the detection of both excessive delays and premature execution, windowed WDTs prohibit the MCU from responding longer or shorter than the WDT’s open window. This is also referred to as a valid window specification. As compared to simple watchdogs, it guarantees that all subroutines are executed by the program in a timely manner; otherwise, it will assert the MCU into reset [3].

Figure 2 shows an example implementation of program sequence monitoring using the MAX6753. It comes with a windowed watchdog with external-capacitor-configurable watchdog periods.

Figure 2 Sample implementation of a windowed watchdog operation with external-capacitor-configurable watchdog periods.

Figure 3, on the other hand, shows another implementation using the MAX42500, whose watchdog time settings can be configured through I2C—effectively reducing the number of external components. This allows for the capability to increase fault coverage through a packet error checking (PEC) byte as shown in Figure 4. The PEC byte increases diagnostic coverage against I2C communication-related failures such as bus errors, stuck-bus conditions, timing problems, and improper configuration.

Figure 3 Another implementation: windowed watchdog through I2C, reducing the number of external components compared to Figure 2. Source: Analog Devices

Figure 4 PEC byte coverage to I2C interface failures, such as bus errors, stuck-bus conditions, timing problems, and improper configuration. Source: Analog Devices

 While watchdogs with a separate time base and time window offer higher diagnostic coverage compared to simple WDTs, they still cannot capture issues concerning whether the software’s subroutines have been executed in the correct sequence. This is what the next type of diagnostic technique addresses.

High diagnostic coverage

Diagnostic techniques involving the combination of temporal and logical monitoring provide high diagnostic coverage to program sequences according to IEC 61508-2. One implementation of this technique involves a windowed watchdog and a capability to check whether the program sequence has been executed in the correct order.

An example can be visualized when the circuit in Figure 2 is combined with the sequence in Figure 5, where the MCU has each of its program routines employing a unique combination of characters and digits. Such unique combinations are then placed in an array each time a routine is executed. After the last routine, the MCU will only kick, or send a reset signal to, the watchdog if all words are correctly set in the array.

Figure 5 Checking the correct logic of the sequence through markers. Source: Analog Devices

Highest diagnostic coverage

In some systems, more diagnostic coverage may be required to capture failures of the MCU, which may mean simply that sending back a pulse in a windowed time is not enough. With this, it may be beneficial to require the MCU to perform a complex task, such as calculating, to ensure that it’s fully operational. This is where the MAX42500’s challenge/response watchdog can come into play.

In this watchdog mode, there’s a key-value register in the IC that must be read as the starting point of the challenge message. The MCU must use this message to calculate the appropriate response to send back to the watchdog IC, ensuring the watchdog is kicked within the valid window. This type of challenge/response watchdog operates similarly to a simple windowed one, except that the key register is updated rather than the watchdog being refreshed with a rising edge. This is shown in Figure 6. Notably, for the MAX42500’s WDT, the watchdog input is implemented using the I2C, while the watchdog output is the output reset pin.

Figure 6 A challenge/response windowed watchdog example where the MCU reads the challenge message in the IC and calculates an appropriate response to be sent back to the watchdog IC to allow it to be kicked within the valid window. Source: Analog Devices

The MAX42500 contains a linear-feedback shift key (LFSK) register with a polynomial of x8 + x6 + x5 + x4 + 1 that will shift all bits upward towards the most significant bit (MSB) and insert the calculated bit as the new least significant bit (LSB). With this, the MCU must compute the response in this manner and return it to the register of the MAX42500 through I2C. Notably, such a polynomial is identified as primitive and at the same time, a maximal length feedback polynomial for 8 bits. This ensures that all bit value combinations (1 to 255) are generated by the polynomial, and the order of the numbers is indeed pseudo-random [4][5].

Such a challenge/response can offer more coverage than the combination of temporal and logical program sequence monitoring, as it shows that the MCU can still do actual calculations. This is as opposed to an MCU just implementing decision-making routines, such as only checking whether the array of words is correct before issuing a signal to reset the watchdog.

Diagnostic coverage claims

The basic functional safety standard has maximum claimable diagnostic coverage for each diagnostic measure recommended per block in an SRS. Table 1 corresponds to the program sequence according to IEC 61508, which utilizes WDTs.  

Diagnostic Technique/Measure	Maximum DC Considered Achievable
Watchdog with a separate time base without a time window	Low
Watchdog with a separate time base and time window	Medium
Combination of temporal and logical monitoring of program sequences	High

Table 1 Watchdog program sequence according to IEC 61508-2 Annex A Table A.10.

Furthermore, with the existence of different implementations that may not be covered in the standard, a claimed diagnostic coverage can only be validated through fault insertion testing.

Diagnostic measures using WDTs

This article enumerates three types of diagnostic measures that use WDTs as recommended by IEC 61508-2 to address failures in program sequence. The first type of watchdog, which has a separate time base but without a time window, can be implemented using a simple watchdog. This diagnostic measure can only claim low diagnostic coverage.

On the other hand, the second type of watchdog, which has both a separate time base and a separate time window, can be implemented by a windowed watchdog. This measure can claim a medium diagnostic coverage.

To improve diagnostic coverage to high, one can employ logical monitoring aside from the usual temporal monitoring using watchdogs. A challenge/response windowed watchdog architecture can further increase diagnostic coverage against program sequence failures with its capability to check an MCU’s computational ability.

Bryan Angelo Borres is a TÜV-certified functional safety engineer who focuses on industrial functional safety. As a senior power applications engineer, he helps component designers and system integrators design functionally safe power products that comply to industrial functional safety standards such as the IEC 61508. Bryan is a member of the IEC National Committee of the Philippines to IEC TC65/SC65A and IEEE Functional Safety Standards Committee. He also has a postgraduate diplomat in power electronics and more than seven years of extensive experience in designing efficient and robust power electronics systems.

Christopher Macatangay is a senior product applications engineer supporting the industrial power product line. Since joining Analog Devices in 2015, he has played a key role in enabling customer success through technical support, system validation, and application development for analog and mixed-signal products. Christopher spent six years prior to ADI as a test development engineer at a power supply company, where he focused on the design and implementation of automated test solutions for high-reliability products.

References

1. “IEC 61508 All Parts, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related ” International Electrotechnical Commission, 2010.
2. “Top Misunderstandings About Functional Safety.” TÜV SÜD,
3. “Basics of Windowed Watchdog Operation.” Analog Devices, Inc. December
4. “Pseudo Random Number Generation Using Linear Feedback Shift Registers.” Maxim, June 2010.
5. Mohammed Abdul Samad AL-khatib and Auqib Hamid Lone “Acoustic Lightweight Pseudo Random Number Generator based on Cryptographically Secure LFSR.” International Journal of Computer Network and Information Security, Vol. 2, February

 Related Content

• Watchdog versus the truck
• Need a watchdog for improved system fault tolerance?
• WDT assumes varied roles

The post Program sequence monitoring using watchdog timers appeared first on EDN.