Збирач потоків

I placed order #48116 on 11 February 2026 for a soldering station. As of 19 May 2026, nearly 100 days later, the order has still not shipped. Tracking only shows that a shipping label was created, with no actual carrier movement. Before receiving any response at all, I sent multiple emails to all listed FNIRSI support addresses and also attempted to contact them through their website chat. I received effectively no responses through chat or email for an extended period. The only replies I eventually received came after I mentioned escalating the matter through my bank and making the situation public. Over roughly the following 3 weeks, I received only two short replies stating that the issue was being “escalated to manager”, but there were no further updates, no shipment, no refund, and no meaningful communication afterward. At this point I have neither received the product nor a refund. Based on my experience, I would strongly caution people against ordering directly from FNIRSI unless they are prepared to risk non-delivery and extremely poor customer support. If you want their products, I would recommend purchasing through a platform with strong buyer protection instead. submitted by /u/AdministrativeElk628 [link] [comments]

i think it is so funny how digikey packages their stuff. i ordered a pnp npn transistor pair and one came in the standard antistatic pin cushion the other came in a make shift package id describe as a chunk of plastic cut with four very intentionally placed rubber stoppers. they are trolls and my favorite company submitted by /u/Useful_Major8563 [link] [comments]

What makes a market success? Is there a Swiss-made sensor inside? Or maybe a wrist strap? What happened to the basics: cost-effective reliable functionality? (And yes, get off my lawn, you kids!).

Back in late March, I detailed my experiences setting up TP-Link’s entry-level Tapo H100 smart IoT hub and wirelessly mating it with a Tapo T315 smart temperature and humidity monitor a few rooms over:

along with, for good measure, a Tapo T300 smart water leak sensor downstairs. The Tapo T315 was effective in several respects: proving that the two DREO humidifiers (one of them also “smart”) were functioning effectively, and that whatever humidity sensing technology was being harnessed in conjunction with my furnaces was not functioning effectively and should be ignored going forward.

Display-optional when the data’s already app-visible?

The Kindle-reminiscent 2.7” e-ink display built into the T315 was convenient for at-a-glance monitoring of both humidity and temperature…that said, truth be told, I can count on the fingers of one hand, without using any of them more than once (and maybe even some of them at all) how many times I’ve looked at it since setting it up. To wit, at the end of that late-March writeup, I noted:

I’ve also got a redundant Tapo H100 smart hub and T300 smart water leak sensor, both sitting on the shelf, queued up for teardown, along with a display-less sibling of the T315 hygrometer, the Tapo T310 Smart Temperature and Humidity Sensor.

The Tapo T300 is still sitting on my teardown pile, although I plan to get to it soon (I promise, barring any out-of-my-control delay factors, of course). The Tapo H100 was dissected toward the end of last month. And today, you get the Tapo T310. I’ll as usual start with outer box shots, as usual accompanied by a 0.75″/19.1 mm diameter U.S. penny for size comparison purposes:

Marketing hype? Reality? A bit of both?

The back panel notes that the sensor is “high-accuracy”. The product page further elaborates that it’s “Swiss-made”. What is this, a watch (analogy)?

Snark aside, Google AI Overview informs me that:

Switzerland is a global leader in high-precision humidity sensors, with key manufacturers like Sensirion, Novasina, and IST AG providing advanced capacitive and resistive sensors. These sensors are renowned for high accuracy, long-term stability, and are widely used in HVAC, medical, and industrial applications.

Assuming Gemini’s not hallucinating, I suppose that I could apologize to TP-Link’s marketeers at this point. But I’ll pass :

Open sesame:

Inside, as previously documented on the left-side box panel, is our patient:

along with various mounting, opening and literature bits, plus a wrist strap presumably for sensing-on-the-move purposes, or perhaps just as a fashion statement (???):

Dear friends, we shall never speak of the wrist strap again. Instead, let’s focus our attention on the device itself. Front:

Left side (note to self: must not draw reader attention to the hole for the wrist strap…):

Back, showcasing the translucent aqua bit of plastic intended for the owner to yank out in order to power up and otherwise activate the device:

Right side:

Top, revealing the ventilation and sensing vent (and another view of another wrist strap hole…arrggh…):

And bottom:

Mobile-adjacent in multiple ways

That cellphone SIM card bracket-reminiscent hole is our pathway inside. As you might have noticed from one of the earlier pictures, TP-Link generously included a SIM card bracket removal-reminiscent tool. I instead went “old school” via a nearby paper clip:

Mission accomplished, so far at least:

Next to depart is the battery, a not-terribly-common (therefore nice of TP-Link to bundle with the device from the get-go) CR2450:

And our last step before diving inside is to dispense (temporarily) with the aqua translucent plastic strip. I’m aspiring for this teardown to be non-destructive, so I’ll strive to hold onto it for reinstallation (followed by the battery) afterwards. I could, of course, keep the battery out of the compartment until I’m ready to activate, gift, donate or otherwise deal with it, but I’m more likely to lose the battery, so…

Another simple-therefore-low-cost consumer device

And here we go…

That wasn’t bad at all, and it might even still work after I reassemble it (he says, realizing that he’s just jinxed himself in doing so)!

Now to pop out the PCB:

Starting with the PCB backside, the battery terminals are already a known entity. Aside from the embedded antenna supporting TP-Link’s 900 MHz ISM band wireless proprietary protocol for bidirectional communication with the Tapo H100 smart IoT hub, there’s not much else notable to see (unless you’re into mode switches, such as the toward-the-bottom one labeled SW1, that is). Look back at the earlier pre-case-opening image of the exposed battery compartment and you’ll notice both the switch’s user-accessible hole and a larger manufacturer-tailored opening for test point TP12. And at the time, I guessed that the device at the top edge, PCB-labeled U5, was the temperature sensor (hold that thought).

Highly integrated

Things get more interesting, as they often do with teardowns like these, when you flip the PCB over (and no, I’m not referencing the comparative abundance of test points on this side):

Toward the top (vertically), and toward the center (horizontally) is the system’s “brains”, Cmsemicon’s BAT32G135GE 64 MHz (max) Arm Cortex-M0-based application processor. Below it are, at left, a Hefei Jingweite Electronics (JWT) 26 MHz crystal oscillator, along with an IC labeled as follows to its right:

300A
N997
423

The one (and only) semiconductor-related result emerging from a Google search on that particular three-phrase sequence was a link to the beefy user guide (PDF) for Texas Instruments’ MSP430 embedded controllers. I was initially skeptical re the relevance of that result, but I decided to press on to the product line overview page, where I saw included there the CC1 series, based on the Arm Cortex-M3, which supports “Sub-1 GHz dual-band” wireless. So…mebbe? If so (and regardless, actually), note that the PCB-embedded antenna is interestingly visible on this side of the PCB, too. Maybe so it reliably works in various orientations when the device is leashed to the owner’s wrist…oops…

An identity crisis

Below it, the conceptual teardown image I shared with you earlier had informed me, was the “Swiss-made” humidity sensor, strangely labeled D1 on the PCB and also strangely surrounded by foam (for protective reasons, I initially presumed, since its package was lid-less):

(I’m loving the 5x macro telephoto lens on the Google Pixel 10 smartphone I just got, which I’ll have more to share about in future writeups!)

How the ambient humidity could get through that foam to the sensor, though, was beyond me. Then I noticed the front-side hole in the case, at the same location as D1, and figured that was how. But then I looked at this stock image:

and realized thee things:

• That hole in front was for an LED to shine though, actually
• D1 was that LED, not a humidity sensor, and
• The “temperature” sensor I’d previously noted on the PCB backside? I was half-right. It’s from Sensiron. And it does double-duty, sensing both temperature and humidity. Thereby even more completely explaining the topside vent proximity.

At this point, I could have just concluded that TP-Link’s marketing department has no clue how to draw conceptual images. But then I remembered TP-Link’s propensity for frequent hardware redesigns. And, giving the company the benefit of the doubt, I hit up the FCC certification page (2AXJ4T310) to have a look at the internal photos:

No such luck. The LED and humidity-and-temperature sensor seem to have always been in their current locations. TP-Link’s marketing department has no clue how to draw conceptual images.

With that, I’ll wrap up this writeup and turn it over to my readers for their thoughts in the comments. I’ll keep the device disassembled for a while after this writeup is published, in case you have any further questions, but eventually I’ll give reassembly-and-resurrection a shot.

—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.

Related Content

• The Tapo Hub: TP-Link joins the low-bandwidth, long-range RF club
• TP-Link’s Tapo H100: Smart sensing unencumbered
• Tapo or Kasa: Which TP-Link ecosystem best suits ya?
• The Blink Sync Module 2: Faster response and local storage, too
• TP-Link’s Kasa EP10: If at first it doesn’t connect, buy, buy again

The post Smart hygrometers: Still largely useful even without integrated visual monitors appeared first on EDN.

Викладач-науковець і випускник НН ІПСА - новий Chief AI Officer у WINWIN AI Center of Excellence при Мінцифрі kpi пн, 05/18/2026 - 11:19

Вітаємо декана ФЕЛ з присвоєнням почесного звання «Заслужений працівник освіти України» kpi пн, 05/18/2026 - 11:13

Центр космічного зв’язку і радіоастрономії відкрито на Радіотехнічному факультеті kpi пн, 05/18/2026 - 10:58

Resistor networks are a great way to improve the gain accuracy and gain temperature drift of your system compared to designs using discrete resistors. One common motivation for improving gain accuracy and drift is that the initial system accuracy is good enough to skip calibration altogether. A common drawback of resistor networks is that there are a limited number of gain or attenuation options available, unlike discrete designs that can accommodate an essentially unlimited number of gain and attenuations.

This article shows how it’s possible to achieve 340 different gains and attenuations from just 10 resistor network ratios.

Take the case of RES11A, a resistor network that contains two resistor-divider networks (RG/RIN) in each package. The device is available in 10 product variants for different resistor ratios, with each variant identified by a suffix. For example, RES11A90 is the 9-to-1 ratio variant (see Figure 1).

You can use it to set gain on an operational amplifier or as an attenuator. The tolerance and drift of the resistors in the divider track closely, yielding significantly better attenuation accuracy and lower temperature drift than discrete resistors at a comparable price. RES11A, for example, has a worst-case tolerance of ±0.05% and temperature drift of ±2ppm/°C.

Figure 1 The above diagram highlights the functional blocks of the RES11A90 resistor network. Source: Texas Instruments

Swapping the input and output provides two different attenuations

The RES11A resistor network has 10 different resistor ratios, so you might think that you can only get 10 different attenuation values for this device. Keep in mind, however, that it’s not possible to swap the input and output of the attenuator, so each network can achieve at least two different attenuations.

Figure 2 shows how RES11A90 operates first as a 0.1 V/V and then a 0.9 V/V attenuator by simply reversing the connections. Thus, you can get at least 20 different attenuations from the 10 unique networks.

Figure 2 Swapping inputs and outputs on RES11A90 yields two different attenuations. Source: Texas Instruments

Combining both halves unlocks even more options

Generally, only one of the resistor pairs is active at a time when using RES11A as either an attenuator or a single-ended amplifier feedback network. But you can place the unused pair in series or parallel with either RIN or RG. Since all the resistors in the network were deposited in the same wafer processing step, they all have good ratio matching and drift matching.

Thus, the ratio, and drift accuracy of the combined divider will typically be the same as the individual dividers, although the worst-case ratio accuracy widens to ±0.1% with a ratio drift of ±4ppm/°C. Figure 3 illustrates how placing RG2 in parallel with RG1 achieves an attenuation of 0.818 V/V.

Figure 3 Using both halves of RES11A90 helps achieve a unique attenuation. Source: Texas Instruments

10 resistor network ratios, 34 configurations each

Different series and parallel combinations of both halves yield 34 different attenuations. Since there are 10 different variants of the network, the total attenuations possible with RES11A is 340 (34 × 10 = 340). Even accounting for duplicates, there are many unique attenuations. Figure 4 shows all 34 possible configurations.

Figure 4 Here are 34 possible attenuator configurations for the RES11A resistor network. Source: Texas Instruments

Manually sorting through so many options to determine which attenuator configuration meets your requirements isn’t practical. TI’s free Analog Engineer’s Calculator software tool identifies the best RES11A configuration to achieve your target attenuation or gain. Figure 5 illustrates how the calculator can find the resistor configuration for a target attenuation of 0.818 V/V.

Figure 5 The tool determines the RES11A configuration to achieve a 0.818 V/V attenuation. Source: Texas Instruments

Gain applications and compatible devices

While this article focuses on attenuation, RES11A also works well for setting gain on a single-ended or differential amplifier. In the case of a single-ended amplifier, combining both network divider halves results in many different gain values. Figure 6 shows the RES11A gain tool in the Analog Engineer’s Calculator to find different attenuations and gains.

Figure 6 This is how the tool finds gain of 3.5 V/V.

The tool also supports the RES21A and RES31A resistor networks, which share the same ratios as RES11A but scale overall resistance by a factor of 10 and 100, respectively. Thus, you can address your gain or attenuation requirement for RES11A and just substitute RES21A or RES31A if you require a higher overall resistance.

Ten ratio variants. Thirty-four configurations each. Three hundred forty reasons to leave the discrete resistor drawer closed.

Art Kay is applications engineer at Texas Instruments.

 

 

Related Content

• Analog Devices Design Tools: ADIsimRF
• Why I’m fine with my calculator’s tiny decimal point
• Choosing and using resistive power splitters and dividers
• Splitting voltage with purpose: A guide to precision voltage dividers

The post How many attenuations can you get from 10 resistor networks? appeared first on EDN.

Пішов з життя Юрій Петрович Зайченко kpi нд, 05/17/2026 - 18:47

I built a scientific calculator from scratch: custom PCB, custom FPGA firmware, and a CPU I designed myself in Verilog. The physical build: a custom main board and keypad PCBs designed in EasyEDA and manufactured by JLCPCB, an Altera Cyclone II FPGA as the brain, an LCD display, battery with charging circuit, and two ROM-flashing connectors on the sides to update the firmware. Under the hood it runs a nibble-oriented CPU I designed specifically for BCD arithmetic: the way decimal calculators should work internally. I then wrote ~4K of machine code implementing the full set of scientific functions: trig, logarithms, complex numbers, statistics, all verified to 14 significant digits against a dedicated test suite. The full stack: Custom CPU in Verilog: Harvard architecture, 12-bit ISA, 8 registers, hardware fault detection Hand-written microcode assembler in Python Verilator + Qt simulation framework for development and debugging Custom PCB (EasyEDA / JLCPCB), battery, charging circuit, 3D printed case The finished device is sitting on my desk. Live WebAssembly demo (runs the actual Verilog + microcode in your browser): https://baltazarstudios.com/files/calculator-d/Calculator.html Write-up: https://baltazarstudios.com Source: https://github.com/gdevic/FPGA-Calculator Hackaday: https://hackaday.com/2026/05/13/build-the-cpu-then-build-the-calculator/ Happy to answer questions about the PCB design, the FPGA setup, or anything else. submitted by /u/gdevic [link] [comments]

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

Una vez que lo pegues, ya tienes todo listo. ¡Dale al botón de Post (Publicar) y habrás terminado el proceso! 🚀⚡ submitted by /u/ServorElectronica [link] [comments]

Безпека, стійкість, інформаційні технології та екологічний моніторинг Інформація КП пт, 05/15/2026 - 21:00

submitted by /u/Upbeat-Permission-22 [link] [comments]

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

A scenic view, once so charming, has been irretrievably ruined. Will it happen again?

Four astronauts have just circled the Moon and returned safely back to Earth. This (Artemis II, if you’ve been living under a rock for the last month-plus) is quite an achievement, and my saying so is admittedly quite an understatement. But I am disturbed by a thought regarding future lunar plans, and not just those of the United States but of other nations as well.

I have read of the near-future possibility of setting up permanent facilities on the lunar surface. Any such installations will experience day and night cycles, which we see from here as lunar phases. When enveloped in darkness, these lunar facilities will therefore undoubtedly also require artificial light sources. My concern is that these light sources will be visible from Earth. We will no longer have today’s lunar darkness. Our view of the Moon will be permanently despoiled.

Such despoilage has happened before. Consider the following two views of Diamond Point on Oahu in the Hawaiian Islands (Figure 1). The upper image is a screen shot from a movie starring Annette Funicello that dates from 1965 (I think I have that right), while the lower view was taken only a few decades later, in 2020:

Figure 1 These views of Diamond Point were taken in 1965 (upper) and 2020 (lower)

The once beautiful view of the natural landscape is now blocked by buildings and piers. The scenic view that was once so charming has been ruined. And sadly, that loss is irretrievable, at least within our lifetimes.

It looks like we are about to do the same thing to our Moon.

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

Related Content

• 1st manned Apollo mission launches, October 11, 1968
• Apollo 11 launches, July 16, 1969
• Apollo 11 makes 1st manned landing on the Moon, July 20, 1969
• Apollo 17 lands on moon, December 11, 1972

The post Despoilage appeared first on EDN.

Food Ninja turned reflow oven! My first board in 15 years went great other than my bad designs! Attempt at building a 6 channel sonar, dint go so great..... worked in air but not in water. submitted by /u/TunaRado [link] [comments]

Automotive silicon design is entering a phase where functional safety, cybersecurity and artificial intelligence (AI) can no longer be treated as separate concerns. In connected, software-defined vehicles, safety outcomes depend not only on protection against random hardware faults, but also on resilience to malicious interference and software vulnerabilities. As a result, many of the decisions that determine system safety are now made at the silicon architecture level.

When ISO 26262 was first published in 2011, it marked a major step forward in structuring functional safety for automotive electronics. But the vehicles being designed today are fundamentally different. Autonomous driving, electrification, AI-based perception, vehicle-to-everything (V2X) connectivity, and centralized compute architectures were not primary considerations at the time.

The core objective remains unchanged: to avoid hazards to people. However, the way this objective is achieved is now deeply tied to how safety is architected into semiconductor devices.

Functional safety is no longer just a system-level concern; it’s a design-time challenge for ASIC and SoC engineers. For many safety-critical functions, whether ISO 26262 targets can be met depends on decisions made in the earliest stages of silicon architecture.

A growing and converging standards landscape

The industry has responded to new challenges by expanding the safety and security framework. ISO 26262:2018 addresses functional safety in road vehicles, while ISO 21448 (SOTIF) considers hazards arising from insufficient or incorrect system behavior. ISO/PAS 8800:2024 begins to address the safety implications of AI-based systems.

Alongside these, ISO/SAE 21434 introduces requirements for automotive cybersecurity, and platform-level schemes such as PSA Certified, while not automotive-specific, are shaping expectations for secure-by-design silicon, roots of trust, and independently evaluated security assurance.

In practice, these frameworks cannot be applied in isolation. Safety and cybersecurity requirements must be interpreted together and traced into silicon architecture, verification strategies, and ultimately the safety case. This convergence increases complexity, but it also reflects the reality of modern automotive systems: safety now depends on both fault tolerance and system integrity.

Figure 1 Functional safety is now a silicon architecture problem that must be addressed alongside cybersecurity and AI from the earliest stages of design. Source: EnSilica

Safety is implemented in silicon

In today’s vehicles, many critical safety mechanisms are implemented directly in hardware. Fault detection, redundancy schemes, error correction, watchdogs, and safe-state control are embedded within ASICs and SoCs. Typical techniques include lockstep CPU architectures for execution monitoring, ECC-protected memories to detect and correct bit errors, and dedicated safety islands that supervise system health and enforce safe-state transitions.

These mechanisms are responsible for ensuring that faults are either corrected or managed in a way that prevents hazardous behavior. Increasingly, they must also be robust against unintended interactions and deliberate manipulation, not just random faults.

This creates a fundamental shift. Functional safety is no longer something that can be added at the system level; it must be designed into silicon architecture from the outset. Decisions around redundancy affect area and cost. Diagnostic features influence power consumption and performance. Detection latency must be balanced against system constraints. These trade-offs are often made before the full system context is completely defined.

At the same time, safety mechanisms are only effective if the system enforcing them remains trustworthy. Ensuring that trust is now a core architectural concern.

Cybersecurity as a determinant of safety

Cybersecurity is no longer adjacent to functional safety—it’s a determinant of it. A system that meets ASIL targets for random faults may still be unsafe if it can be compromised through software, interfaces, or update mechanisms. In connected vehicles, a maliciously induced fault can have the same or greater impact than a hardware failure.

At the silicon level, this translates into requirements for hardware roots of trust, secure boot, run-time integrity checking, and domain isolation. These mechanisms ensure that only authenticated software can control safety-critical functions and that faults or compromises in non-critical domains cannot propagate into safety paths.

From a design perspective, this expands the traditional fault model. In addition to random hardware failures, engineers must now consider adversarial conditions such as fault injection attacks, privilege escalation, and corrupted firmware. Safety architectures must be capable of detecting, containing, and responding to both types of failure.

The limits of the V-model in silicon development

ISO 26262 promotes the V-model as a structured development approach, moving from requirements to implementation and back through verification. While this provides a useful framework, it does not always reflect how safety-critical ASICs are developed in practice.

Silicon design requires early decisions that cut across the V-model structure. Process technology selection, architectural partitioning, testability, and diagnostic coverage must all be considered at a very early stage. These decisions directly influence safety mechanisms and compliance with ASIL requirements.

In reality, ASIC development is highly iterative, moving between architecture, implementation constraints, and verification. The goal is not strict adherence to a linear process, but maintaining traceability, safety intent, and configuration control throughout the design cycle.

Traditional safety analysis is under pressure

Safety analysis methods such as failure modes and effects analysis (FMEA) and fault tree analysis (FTA) remain foundational. However, their application at the ASIC level is becoming increasingly challenging.

Modern automotive SoCs integrate CPUs, AI accelerators, high-speed interfaces, and complex interconnect structures on a single device. Applying traditional analysis techniques at this scale is difficult, often requiring abstraction that introduces uncertainty.

As complexity increases, the question is no longer whether analysis has been performed, but whether it’s sufficient to capture all relevant failure modes, particularly when both accidental faults and adversarial conditions must be considered.

Toward simulation-driven safety verification

To address these challenges, the industry is moving toward more dynamic, simulation-driven approaches. Fault simulation, long used in semiconductor tests, is increasingly applied in a functional safety context.

Instead of simply identifying faults, the focus shifts to system response. When a fault is injected, engineers must determine whether it is detected, whether it is corrected, and whether the system transitions to a safe state within the required time.

This approach integrates safety analysis with design verification and provides more concrete evidence that safety mechanisms operate correctly under realistic conditions. Increasingly, safety metrics such as single-point fault metric (SPFM) and latent fault metric (LFM) can increasingly be supported by fault-injection and simulation-based evidence, alongside analytical safety analysis.

Figure 2 The fault injection verification flow demonstrates how the design contains, detects, and correct faults. Source: EnSilica

AI moves the challenge further into silicon

AI introduces both new risks and new opportunities for functional safety. On the hardware side, AI workloads are implemented in dedicated accelerators within automotive SoCs, further shifting safety responsibility into silicon.

Designers must consider how these accelerators behave under fault conditions and how their outputs are monitored and validated. On the system side, AI raises fundamental challenges around verification. Unlike deterministic logic, AI systems exhibit probabilistic behavior influenced by data and operating conditions.

AI also reinforces the convergence between safety and security. Ensuring the integrity of inputs, models and execution becomes critical, as corrupted data or manipulated models can lead directly to hazardous behavior.

Memory safety and system integrity

One emerging approach to improving robustness is the use of hardware-enforced memory safety. Capability-based architectures, such as CHERI, provide fine-grained control over memory access, reducing the likelihood that software defects or exploitable vulnerabilities propagate into safety-critical behavior.

By mitigating broad classes of memory-corruption vulnerabilities at the hardware level, these techniques contribute to both system integrity and functional safety, particularly in complex software-defined environments.

Designing for long-term security

Automotive systems are expected to operate reliably over long lifetimes, often exceeding a decade. This introduces additional challenges for cybersecurity.

Cryptographic mechanisms that are secure today may not remain so over the lifetime of the vehicle. As a result, there is growing interest in cryptographic agility and support for post-quantum cryptography (PQC), particularly for secure boot, firmware updates, and vehicle communications.

These considerations further reinforce the need to treat security as a foundational aspect of silicon design, rather than a feature added later in the development process.

However, the automotive industry does not need to abandon existing safety standards; instead, it must adapt how they are applied in the context of semiconductor design. Take, for instance, functional safety, which is no longer just a system integration challenge. It’s a silicon architecture problem that must be addressed alongside cybersecurity and AI from the earliest stages of design.

At the silicon level, the distinction between safety and security is becoming increasingly artificial. Safety mechanisms must operate correctly in the presence of both accidental faults and malicious interference. This requires a unified architectural approach, where safety, security and system integrity are designed, verified, and validated together.

As vehicles become more intelligent, connected and autonomous, the role of custom silicon in delivering safe operation will only grow. The standards still matter, but increasingly, it’s silicon that determines whether those standards can be met in practice.

Enrique Martinez-Asensio is functional safety manager at EnSilica. He has more than 35 years of experience in the semiconductor industry, having worked on mixed-signal IC design and technical support and management in several semiconductor companies.

Related Content

• Automotive Cybersecurity: Attacks Keeps Growing
• Enabling functional safety in automotive processors
• Approaches to functional safety in automotive design
• Automotive processor IP complies with ISO 21434 cybersecurity
• ISO/SAE 21434: Software certification for automotive cybersecurity

The post Automotive silicon in the era of AI, functional safety, and cybersecurity appeared first on EDN.

STMicroelectronics, a global semiconductor leader serving customers across the spectrum of electronics applications, introduces a new generation of ultralow-power global-shutter image sensors. That delivers high-quality, always-on vision to compact devices operating on batteries or harvested energy. The VD55G4 (monochrome) and VD65G4 (RGB colour) sensors, part of the ST BrightSense portfolio, are now available to early adopters. Also, enabling customers to start designing their next generation of smart, ultralow-power vision devices today.

The new sensors serve applications including wearables, AR/VR and XR headsets, smart home appliances and medical devices. They deliver rich visual context and AI-ready data under tight constraints on power, size, and cost. The sensors combine an ultralow-power detect-and-wake architecture with a very small global-shutter optical format and interfaces that optimise low-power microcontrollers and cost-effective systems-on-chips (SoCs).

“Always‑on vision is becoming essential for the next generation of personal electronics, from smart glasses and AR/VR headsets to intelligent home appliances and medical devices. With VD55G4 and VD65G4, we are bringing this capability to smaller, lighter products that must run for a longer period on a tiny battery. These new sensors help our customers create more intuitive and responsive experiences, extend battery life, and bring embedded vision and edge AI into everyday devices,” said Alexandre Balmefrezol, Executive Vice President and General Manager of the Imaging Sub-Group at STMicroelectronics.

From wearables and AR/VR to smart appliances

VD55G4 and VD65G4 bring always‑on vision to products that must stay small, light, and extremely power-efficient. Building on the ST BrightSense family, they add a colour option, faster response for interactive use cases, and simple connectivity to low‑power microcontrollers, making it easier to add vision to space‑ and cost‑constrained designs.

In wearables, the sensors enable all‑day, always‑aware features such as glance detection, presence sensing, and contextual alerts, while fitting into very compact designs and working directly with microcontroller‑based platforms. For AR/VR and XR headsets, they combine low power and high‑quality capture to support accurate tracking and spatial awareness, helping extend battery life without compromising comfort.

In smart home appliances, IoT devices, and medical products, the sensors allow more intelligence to run locally on the device itself, reducing cloud dependence and standby power. Their tiny size and energy efficiency also make them well-suited to solar‑ or energy‑harvesting‑powered vision nodes.

Ultralow‑power design consumes up to 10x less power

VD55G4 and VD65G4 consume up to 10 times less power than conventional global‑shutter sensors. It watches for changes in a scene and wakes up the main processor only when needed, shifting from continuous streaming to event‑driven operation. This enables all‑day, always‑on experiences, longer battery life, and practical vision systems powered by small batteries or energy harvesting. The small footprint with integrated image processing simplifies design and reduces system cost, while supporting responsive AI‑ready vision features in a wide range of edge devices.

Growing design ecosystem

The VD55G4 (monochrome) and VD65G4 (RGB colour) image sensors generate 300 mm wafers using a 3D‑stacked 65 nm / 40 nm architecture, in-house process and manufacturing in ST Crolles plant.

ST is also offering the full companion ecosystem with multiple tools and resources, including:

• Development boards for platforms such as STM32 and Raspberry Pi
• Turnkey camera modules
• Evaluation software, platform drivers
• A software development kit to accelerate embedded vision projects

The post STMicroelectronics Launches Next-Generation Ultralow-Power Image Sensors appeared first on ELE Times.

For years, devices like the RbPi have been described as “credit-card sized”. And of course the message is rather the footprint, but at some point I became obsessed with taking that idea one step further: What would it take to build something that is literally sized like a credit card? I've got a slight feeling that you really don't seem to like questions here, but I hope this rhetorical one is okay :P That question slowly escalated into months of experiments to find solutions for things where default methods won't work. I can't use large, rigid components, connectors, and find a way to make my own custom flexPCB. And after months of tinkering, I made the first prototype. Fragile, but it works within the goal of not exceeding 1 millimeter. Somehow, news pages have picked this up and described it as "revolutionary" which is a bit far fetched, but I feel flattered 🤭 To be fair, 'computer' might be a little overstatement, but it's technically perfectly within the definition of one. If you should have suitable words for it that sounds cool, feel free to suggest ^^ The prototype includes: ESP32-C3FH4 w/ WiFi & BLE NFC read/write 1.54" 200*200 E-Paper display ultra-thin LiPo battery including charging circuit and power path management accelerometer Finding small/thin enough components wasn't really the main challenge, mechanical stability was. Solder and general material fatigue, pressure distribution (particularly focused pressure) and other strain related issues were the real problem. This doesn't even include battery protection and some other things to solve. At this scale, the project turned into a weird mix of electrical, mechanical and chemical engineering. A few things that became clear over time: preventing strain is much easier than surviving strain tiny real-world tolerances start dominating the entire design near the physical limit many “thin enough” components stop being thin enough once assembly is considered FPC connectors are basically obsolete, forcing me to get creative and solder each single wire for each 0.5mm pitch pad one by one. The prototype is fully self-powered and running from its internal battery. I documented a large part of the engineering process, including the process of etching my own flexPCB, on my GitHub repo. And yes, it's not like this thickness is a necessity, going just 0.5mm thicker would probably have saved me months of engineering. This entire project was probably motivated way too much by the 'disbelief' factor 😄 I am curious on your thoughts on this! :) submitted by /u/krauseler [link] [comments]

Зустріч із випускниками університету — народними депутатами kpi чт, 05/14/2026 - 17:36