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

Ascent Solar Technologies Inc of Thornton, CO, USA — which designs and makes lightweight, flexible copper indium gallium diselenide (CIGS) thin-film photovoltaic (PV) panels that can be integrated into consumer products, off-grid applications and aerospace applications — was co-host of an executive networking event on 20 October in Willow Springs, California, that brought together leaders and innovators from across the commercial space industry to discuss emerging technologies, mission requirements, and opportunities for future collaboration...

AXT Inc of Fremont, CA, USA — which makes gallium arsenide (GaAs), indium phosphide (InP) and germanium (Ge) substrates and raw materials at plants in China — says that its majority-owned China-based wafer manufacturing subsidiary Beijing Tongmei Xtal Technology Co Ltd has entered into definitive agreements for a private equity financing to fund further expansion of its manufacturing capacity for indium phosphide substrates, expansion of its principal business operations, capital expenditures, and general working capital. The financing agreements provide for a private equity investment in Tongmei by certain institutional investors of a minimum of RMB1,912,350,000 (about US$285m) and up to a maximum of RMB3,668,639,053.25 (about US$545m) in ordinary shares of Tongmei...

Particularly in consideration of current (and over-time increasing) semiconductor constraints, this has been a surprisingly busy (albeit pricey) October from a systems-release standpoint.

Nearly two months ago, as is typical for the season, Apple announced new smartphones, watches and earbuds. Several weeks before that, the company had somewhat-typically-for-fall unveiled two new processors and systems containing them. But wait, there’s more. Just two weeks back, and atypically, Apple had rolled out more hardware, this time for the smart home. And this week? Three straight days of even more hardware. Very atypical.

I’ll get to Apple’s most recent news shortly. But it wasn’t the only tech heavyweight to unveil new mobile computing devices—a mix of laptops and tablets—this month.

Microsoft and Nvidia go “Ultra”

Last November, within my yearly “Holiday Shopping Guide for Engineers” (this year’s edition which I’m now reminded I need to begin writing shortly), I suggested (among other things) you consider purchasing, for others and/or yourself, Nvidia’s DGX Spark mini AI workstation.

(it’s the gold-colored device to the right of the laptop, not the laptop itself. Hold that thought).

As background info for today’s discussion, I noted the following back then.

Its application processor, originally referred to as the N1X, is now renamed the GB10. Co-developed by NVIDIA (who contributed the Grace Blackwell GPU subsystem) and MediaTek (who supplied the multi-core CPU cluster and reportedly also handled full SoC integration duties), it was originally intended for—and may eventually still show up in—Arm-based Windows PCs. But repeated development hurdles have (reportedly) delayed the actualization of both SoC and system shipment aspirations, and lingering functional bugs preclude Windows compatibility (therefore explaining the DGX Spark’s Linux O/S foundation).

Those bugs have apparently finally been squashed—or at least sufficiently worked around—because Nvidia and lead mobile systems partner Microsoft publicly released the Surface Laptop Ultra on October 7. The history lesson here is interesting (IMHO, at least) and instructive.

Microsoft has been steadily working on Windows-on-Arm, spanning operating systems, applications suites and hardware to run them on, since June 2012 with the Windows Surface RT, which was powered by the multi-core Arm Cortex-A9-based Nvidia Tegra 3 SoC.

 

From then until now, everything else Arm-related, including my latest Surface Pro 11 “Plus” acquisition (along with several generations of developer-tailored desktop hardware), ran Qualcomm-developed silicon, even if the SoCs were Microsoft-stamped. But Nvidia’s back, baby. And it’ll only cost you $2,599 (baseline, as much as $5,899.99 top-end) to own one. With delivery “later this year” (which, I’m compelled to note, has only two more months left in it as I type this). Gulp.

Two versions of the Nvidia RTX Spark N1X (apparently, in a clarification of the earlier rename mention, both GB10 and N1X are valid monikers, for different system form factors) exist, both with the same NPU core inside:

• 5120-core GPU and 18-core CPU, and
• 6144-core GPU and 20-core CPU

System memory ranges from 24 GB to 128 GBytes in capacity, LPDDR5x DDR unified in all configurations. SSD options start at 512 GBytes (PCIe Gen 4), with 1 and 2 TByte PCIe Gen 5 configurations also offered. And by the way, an RTX Spark-based developer platform, $5,999.99 and up, is also available for pre-order (perhaps a replacement for the canceled Qualcomm one?).

Amazon loves generic Android (again)

Next stop: tablets. I’ve said it before, I’ll say it again today, and I’m unfortunately sure I’ll be saying it more in the future, given where semiconductor building block prices and tariffs are going: when your bill-of-materials costs increase, the best way to “hide” them is to bail on entry-level models and conversely double-down on already-profit-margin-padded high-end product variants. Enter Amazon’s no-longer-Fire, now Alexa-branded, latest-generation tablets.

Plastic cases are gone (except for the kiddie-tailored ones), replaced by thin unibody aluminum chassis, wrapped around higher-quality LCDs, multi-speaker arrays and other integrated goodies. Gone too is access to the Amazon Appstore (which won’t be a surprise to anyone who read my last-October Amazon coverage); Amazon’s back to leveraging the Google Play Store.

More generally, the new tablets run “vanilla” Android instead of the “forked” Fire OS precursor. They come in 8”, 11” and 12” “Pro” flavors, each with multiple storage capacity tiers (along with two DRAM capacity options for the 8” version, interestingly), with prices starting at $299 and ranging up to $679.99, not including cases or the high-end model’s optional pen and keyboard accessories.

Speaking of October Amazon coverage, by the way, the company chose today, at the tail-end of competitor Apple’s three-day announcement cadence, to roll out this year’s collection of Echo speakers (one even complete with a camera? SMH), smart displays and such. I won’t be covering them in this particular piece, so to tide you over until I have time to discuss them, I’ll hand you over to Engadget (or any of the other usual suspects, for that matter) for coverage purposes.

Touch me. Finally.

And speaking of unwise chronological congruity, what did Apple roll out this week? Monday brought a new generation of the iPad mini (the prior generation of which, which I own, was dubbed “cute” by my wife just the other day), no longer with a trailing-edge SoC versus its larger siblings (now with the A20 Pro), and with a slightly larger display (8.5” in diameter this time) that, even more impactfully, switches from LCD to OLED. The front camera is conveniently relocated to the landscape edge, too. And yes, all this goodness is accompanied by price increases. The entry-level 128 GByte Wi-Fi-only variant of my 2024 model was originally $499 but got bumped by Apple up to $599 in June of this year, while this year’s edition is $699 and up. Yup.

 

Yesterday? Thanks for asking. The 14” (but not 16”, interestingly…the same thing happened last year, so I’m guessing the larger one’s “Pro” and “Max” only from here on out) entry-level version of the MacBook Pro now runs the M6 SoC, versus last year’s M5, while the 24” iMac makes a two-gen (and associated two-year between-updates) jump from the M4 to the M6.

Yep, that’s basically it; form factors, etc. remain unchanged. Yawn. Even the MacBook Pro stock image shown above, from Apple’s press release, was boring. And if I was a betting man, I’d lay my odds on the earlier-leaked theory that the next SoC iterations of the higher-end “Pro” and “Max” MacBook Pro variants will await the M7 Apple Silicon generation.

Apple instead “kept its powder dry” for today’s unveiling of its first touchscreen-augmented (and broader PROLED XDR-based) computers, MacBook Pro laptops in both 14” and 16” display and both M5 Pro and Max SoC options.

Now that’s a snazzy stock image…err…video, right? Unsurprisingly, there’s a whole lot of underlying software evolution of both MacOS and key apps such as the Safari browser (beta-examination insights into the latter which were discovered two weeks back) as enablers of the enhanced hardware. And equally unsurprisingly, those hardware enhancements come with an associated price tag increase. Depending on size and configuration, you could pay anywhere from $2,899 to…hold your hat…$14,549 for the privilege of a display that responds to your touch.

You may now pick yourselves up from the floor and climb back in your seats. Although I’m sure Apple’s done no shortage of advance market research, including conversations with potential customers under NDA, I’m admittedly somewhat skeptical about the prospects for long-term high volume success here. I say this although I have absolutely no doubt in the first-generation fiscal-and-other enthusiasm of technology early adopters, and even though I acknowledge (in a nod to my earlier Microsoft Surface case study comments) that Apple’s a late adopter here as compared to Windows-powered touchscreen counterparts (along with its own iPad, for that matter).

Speaking of case studies, let’s take me as an example. Including my current x86-based Surface Pro 7+ (and spare, along with two Pro 8+ successors in the queue) and earlier mentioned Arm-based Pro 11 models, I’ve to date purchased nine (six to-date actively used) touchscreen Windows laptops, if my recollection is correct. But I’ve barely used their touchscreens at all, far from for any meaningful period of time.

Partly, speaking of fiscal blessings, it’s because I’ve in-parallel owned multiple generations of iPads. And to that point, I’m most enthused about the concept when it’s applied to hybrid systems like the Surface Pro that can operate as both a tablet and a laptop, depending on if a physical keyboard is connected at the time. But that’s not the form factor of these new MacBook Pros. And I’d wager that anyone who’ll buy one is capable of buying an iPad (or few), too.

Thoughts, readers? Let me know in the comments!

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

Related Content

• Apple’s processor cadence: A pending stutter-step for improved long-term edge inference?
• The Microsoft-reminiscent iPhone Duo: How much customer holding-and-folding is necessary to keep Apple from folding on the experiment?
• Apple heads Home: Distributed identity validation, and how much does Matter matter?
• Amazon and Google: Can you AI-upgrade the smart home while being frugal?
• The Microsoft Surface Pro 5 succession: Selections, motivations, and initial impressions

The post Amazon, Apple and Microsoft: New mobile computing platforms take off appeared first on EDN.

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

TetraMem has completed tapeout of the MLX300, a 12-nm analog in-memory computing (A-IMC) SoC based on multi-level RRAM technology. The chip was developed using Synopsys EDA software delivered through Synopsys Cloud FlexEDA, extending multi-level RRAM-based AI chip development to advanced FinFET nodes.

The MLX300 tapeout follows TetraMem’s MLX200/MLX200M multi-level RRAM A-IMC SoCs, which completed full-mask tapeout in 2026 on a commercial 22-nm process.

TetraMem’s architecture enables scalable AI accelerator development while improving performance per watt and reducing data movement. The MLX300 uses this architecture in a single-chip accelerator for audio, vision, and smaller language models. It supports up to 64 million INT4 parameters on-chip without external DRAM for model-weight storage. TetraMem says the SoC targets energy efficiency exceeding 50 TOPS/W.

TetraMem

The post Analog in-memory computing advances to 12 nm appeared first on EDN.

ST has launched an automotive sensor platform that combines multi-axis accelerometers and angular-rate sensors in a single package. The platform is designed to extend active and passive safety systems and driver-assistance features across vehicle categories, from premium to mass-market. Applications include crash protection, rollover detection, airbag deployment, vehicle stability control, and radar beam stabilization.

The sensors feature internal diagnostics and support SafeSPI, a serial peripheral interface for automotive safety. ST’s first four offerings following its integration of NXP’s sensors division are:

• NCS1012BAEP: z-axis (yaw) angular-rate sensor and xy low-g accelerometer
• NCS1012CAEP: x-axis (roll) angular-rate sensor and yz low-g accelerometer
• NCS1012EAEP: x-axis (roll) angular-rate sensor and xy medium-g accelerometer
• NCS10135AEP: z-axis (yaw) angular-rate sensor and xyz low-g accelerometer

Angular-rate sensors offer full-scale ranges of ±125 dps, ±250 dps, or ±350 dps, with integrated low-pass filtering (12.5–400-Hz cutoff options) and operation from −40°C to +105°C. Low-g accelerometers cover ±1.50 g to ±34 g, while medium-g versions cover ±15.5 g to ±150 g and feature an independent signal chain to minimize noise. Both acceleration sensor types feature low offset and drift over the automotive temperature range and integrated low-pass filtering.

The combo sensors are now in production in 24-pin QFN packages with wettable flanks.

STMicroelectronics

The post Motion sensor combo ICs target vehicle dynamics appeared first on EDN.

A programmable Hall switch from Melexis, the MLX92342, simplifies remote position detection in automotive systems such as seatbelt buckles. The 2-wire, PCB-less sensor IC provides a valid output and generates a diagnostic safety signal in less than 100 µs. This signal indicates a fault condition, allowing the ECU to distinguish a sensor malfunction from a valid buckle-state reading.

With integrated on-chip diagnostics, the MLX92342 is certified as an ISO 26262 ASIL B SEooC and qualified to AEC-Q100. ESD protection is rated at 8-kV HBM, 15-kV system-level contact discharge, and 25-kV system-level indirect discharge. The device supports magnetic latch, unipolar switch, and omnipolar switch configurations, with a magnetic operating range of 0.5 mT to 200 mT. 

Beyond seatbelt buckle detection, the MLX92342 can be used in window lifters, brake fluid level sensors, active air skirts, locks, valves, and actuators. It is a suitable option for applications using mechanical microswitches, reed switches, or less advanced magnetic switches, adding programmability, diagnostics, and contactless operation.

The MLX92342 is available now. A locked, pre-programmed version, the MLX92341, is also available.

MLX92342 product page 

Melexis

The post Hall switch adds diagnostics for automotive safety appeared first on EDN.

Innodisk offers the GMSL2 camera starter kit, which bundles four 3-Mpixel cameras, a MIPI CSI-2-to-GMSL2 capture card, and accessories. The kit provides a ready-to-use platform for developing and validating multi-camera systems for edge AI vision applications.

GMSL2 is a high-speed serial link for real-time video transmission, supporting forward-channel data rates of up to 6 Gbps. The starter kit includes camera source code for the NVIDIA Jetson Orin Nano Super Developer Kit, the platform used to run the system. The pre-integrated hardware and software reduce the need for component sourcing, complex system-level integration, driver debugging, and tuning.

In addition to the four fixed-focus GMSL2 camera modules and capture card, the kit comes with four 1-meter GMSL2 FAKRA cables, a power adapter, and power cords.  Target edge AI applications include blind spot detection and ADAS for heavy-duty vehicles, as well as object recognition and environmental perception for humanoid robots and autonomous mobile robots.

After initial validation with the starter kit, Innodisk offers customization services ranging from hardware fine-tuning to application deployment in edge environments.

GMSL2 camera starter kit (EKIT-B14-001)

Innodisk

The post Camera kit simplifies multi-camera AI development appeared first on EDN.

The Renesas RX74M and RX74N 32-bit MCUs are the first in the RX family to use a 22-nm process and incorporate embedded MRAM. Based on a 600-MHz RXv3e core, both of these industrial devices achieve more than twice the performance of their 240-MHz predecessors, the RX72M and RX72N.

Each MCU features 1 MB of code MRAM, 256 KB of zero-wait-state TCM (tightly coupled memory) RAM, and 1.5 MB of SRAM for real-time processing. Unlike embedded flash, MRAM can be written without a prior erase operation, allowing faster code and data updates and reducing programming time.

The RX74M is designed for industrial automation equipment, including AC drives, industrial robots, and PLCs. The RX74N targets smart meters, power conditioners, and HVAC systems. Both integrate Gigabit Ethernet and CAN FD, while the RX74M adds a TSN-capable Ethernet switch and an EtherCAT slave controller for industrial networking.

The RX74M and RX74N are available now, along with corresponding evaluation boards.

RX74M product page 

RX74N product page 

Renesas Electronics 

The post Industrial MCUs pair 600-MHz cores with MRAM appeared first on EDN.

Designing compact and efficient power factor correction (PFC) stages for low-power to mid-power applications often requires operating in critical conduction mode (CrM) or discontinuous conduction mode (DCM). These modes offer improved efficiency and simplified control at light loads, but require careful design to ensure correct valley detection and mode transitions across the entire input range and load range.

CrM/DCM boost PFC topology is a highly recommended solution for applications up to 200 W. This topology remains a compelling choice for the 200 W to 400 W range, particularly when cost effectiveness and light-load performance are primary design constraints. However, it’s important to select the most suitable mode depending on the power level and system constraints.

Figure 1 The PFC boost stage operates in CrM under worst-case conditions and falls back to DCM at lighter loads. Source: Monolithic Power Systems

This article presents a step-by-step methodology for designing a boost PFC stage that operates in CrM under worst-case conditions and falls back to discontinuous conduction mode at lighter loads, as shown in Figure 1.

The inductor is selected to achieve critical conduction at the minimum input voltage (VIN) and a full load, ensuring proper zero-current switching. Key aspects such as variable frequency behavior, inductance, and peak current calculation are addressed in this article through a formula-driven approach.

Step 1: Define the operating parameters

An effective power design should include a clear set of specifications and consider the worst-case scenario. The operating parameters for a universal input PFC converter are the minimum AC RMS input voltage and maximum output power (POUT_MAX).

Table 1 shows the power converter specifications for a practical example, which will be applied to the following calculations in this article.

Table 1 These power converter specifications are applied to calculations in this article. Source: Monolithic Power Systems

Based on Table 1, the minimum switching frequency (fSW) is at the peak of the low AC line and at POUT_MAX. Figure 2 shows that the inductor current dependent on time (iL (t)) follows the AC input voltage and its average value (IL_AVG) in CrM.

Figure 2 The inductor current dependent on time follows the AC input voltage and its average value in CrM. Source: Monolithic Power Systems

The worst-case conditions can be determined using the power converter specifications from Table 1.

The maximum input power (PIN_MAX) can be calculated with Equation (1):

If POUT_MAX is 150 W and η is 0.94 under the worst-case conditions, then PIN_MAX is 159.57 W.

The minimum peak AC voltage (VIN_PK_MIN) can be calculated with Equation (2):

If VAC_MIN is 85 V, then VIN_PK_MIN is 120.21 V.

Step 2: Calculate the inductance

The single most important component in this design is the boost inductor (L). Figure 3 shows an example of a power inductor for the PFC boost stage.

Figure 3 Here is an example of a power inductor for the PFC boost stage. Source: Monolithic Power Systems

The boost inductance determines the energy storage per cycle and mode. The converter must be in CrM at the minimum AC input voltage under full loads. This ensures that the inductor has sufficient energy storage capability for all other operating conditions.

The required inductance (L) for CrM can be calculated with Equation (3):

Where VIN_PK_MIN is the peak input voltage at the minimum AC input voltage, VOUT is the DC output voltage, PIN_MAX is the input power at full load, and fSW_MIN is the target minimum switching frequency.

The inductance based on Equation (3) and the power converter specifications provided in Table 1 is 450 µH, as shown below.

At the highest current demand (low line peak at full loads), a 450-µH inductor ensures that the current returns to 0 A by the end of a 70-kHz cycle. For any other current demand levels, the cycle completes faster, causing the part to operate in discontinuous conduction mode.

Step 3: Calculate the maximum component stress

With a fixed inductance, the absolute maximum peak current tolerated by the MOSFET and diode at the peak of the low AC line voltage can be calculated. In CrM, the inductor current waveform is a triangle starting from 0 A, where the peak current (ISW_PK) is exactly twice the average input current. The average current at the peak of the sinusoid (IIN_PK_AVG) can be calculated with Equation (4):

The absolute peak switch current (ISW_PK_MAX) can be calculated with Equation (5):

The calculation for the practical example is shown below.

This means that the MOSFET (Q1) and boost diode (D1) must be rated to handle a repetitive peak current of at least 5.31 A. The RMS current rating is lower, but this peak value determines the component’s survivability.

Step 4: Analyze variable frequency operation

A defining characteristic of a CrM/DCM PFC is its variable switching frequency (fSW), which changes dynamically throughout each half-cycle of the AC line and is the lowest at the peak of the AC voltage (where the most power is processed) and highest near the zero-crossings.

The instantaneous fsw (t) can be calculated with Equation (6):

Where vin (t) is the instantaneous input voltage, and p (t) is the instantaneous input power.

vin (t) can be calculated with Equation (7):

p (t) can be calculated with Equation (8):

Figure 4 shows fSW across a half-line cycle, which has a characteristic U shape.

Figure 4 Switching frequency (fSW) across a half-line cycle has a characteristic U shape. Source: Monolithic Power Systems

The designed minimum 70 kHz switching frequency (fSW_MIN) is lowest at the peak of the sinusoid, while the frequency rises dramatically near the zero-crossing. The controller IC must have a maximum frequency clamp to prevent excessively high-frequency operation, which would lead to high switching losses. A typical clamp is about 250 kHz.

Step 5: Understanding the control loop and zero-current detection (ZCD)

Compared to a fixed-frequency CCM design, a CrM/DCM PFC uses on-time control and zero-current detection (ZCD). The voltage loop sets the on-time command to regulate the output voltage (VOUT), while the ZCD signal and the controller’s internal timing logic determine when the next switching cycle can begin. As a result, fSW depends on the on time (tON), the inductor demagnetization time, and any additional delay introduced by the controller.

On-time control

The main control loop adjusts the MOSFET’s tON. A longer tON results in a higher peak current and more power delivered to the output. The controller’s error amplifier (EA) compares VOUT to a reference voltage and sets the required tON to keep VOUT in regulation. The tON behavior across the AC line cycle depends on the control method implemented between constant-on-time (COT) control and variable-on-time (VOT) control.

• Constant-on-time (COT): In this standard approach, the controller maintains a fixed tON throughout a single mains half-cycle. The peak current (IPK) can be calculated with Equation (9).

The current naturally follows the sinusoidal shape of VIN, providing inherent power factor correction. The voltage loop updates this constant value slowly across several cycles to regulate the output load.

• Variable-on-time (VOT): To further minimize total harmonic distortion (THD), advanced controllers may modulate tON within the half-cycle. For example, intentionally extending tON near the VIN zero-crossings can compensate for dead zones and crossover distortion, resulting in a purer sinusoidal input current.

Zero-current detection (ZCD)

Rather than use a fixed-frequency clock to start a new cycle, the controller waits for a signal from the ZCD circuit, indicating that the inductor current (IL) has dropped to 0 A. An auxiliary winding is added to the boost inductor. When IL decays and reaches 0 A, the voltage on the main winding collapses, inducing a voltage swing in the auxiliary winding. This voltage swing is detected by the ZCD pin on the PFC controller, which immediately initiates the next MOSFET turn-on event.

Final design

By calculating the required boost inductance and current on the semiconductor devices, a PFC boost converter design can be completed using the MP44020, a multi-mode CrM/DCM PFC controller. Table 2 shows the key design results for a 150-W application.

Table 2 Design results are shown for a 150-W application. Source: Monolithic Power Systems

The MP44020 CrM/DCM controller provides simple and high-performance active PFC using minimal external components. To enhance system performance across all load conditions, fSW is reduced at light loads via dead time (DT) extension technology, which improves efficiency and helps achieve very low standby power consumption. MP44020 also achieves lower THD by implementing VOT control, a significant advantage over conventional COT methods.

Protections include over-voltage protection (OVP), over-current limit (OCL), brown-in (BI) and brown-out (BO), VCC voltage (VCC), under-voltage lockout (UVLO), and over-temperature protection (OTP).

Due to MP44020’s high integration, the PFC stage requires only a few external components to function effectively. Figure 5 shows the PFC boost converter schematic using the MP44020 CrM/DCM controller.

Figure 5 The PFC boost converter using the MP44020 requires only a few external components to function effectively. Source: Monolithic Power Systems

Adhere to CrM design principles

Implementing an active PFC boost converter is a critical first stage for modern AC/DC power supplies. This ensures compliance with harmonic current standards and maximizes power quality. In particular, CrM topology offers a cost-effective solution for applications up to 400 W.

By adhering to the design principles for CrM, such as selecting the appropriate boost inductor and managing the variable fSW, engineers can design efficient and reliable PFC circuits. Moreover, a modern controller significantly simplifies this task. Its variable-on-time (VOT) control scheme ensures low THD in addition to integrated protections and efficiency-boosting features for light-load conditions that achieve a robust and high-performance design.

Rafael Collado is a design engineering supervisor at Monolithic Power Systems (MPS).

Related Content

• Power Factor Correction (PFC) Modules
• Back to Basics: Power Factor Correction
• How to design a high-boost-ratio boost converter
• Advantages of interleaved boost converters for PFC
• Feasibility and Accuracy Analysis of Input Power Estimation for Boost PFC Converters with Additional Sensors

The post An equation-driven guide to designing a CrM/DCM boost PFC appeared first on EDN.

🎥 КПІшники пишуть Радіодиктант національної єдності KPI4U-2 ср, 10/28/2026 - 17:41

A real-time environmental monitoring system on the STM32 Blue Pill, using STM32Cube HAL and FreeRTOS. Four quantities are under control: temperature, humidity, ambient light and motion. The data ends up on an SSD1306 OLED display, the pages are scrolled with a rotary encoder, and a buzzer warns when the temperature leaves the configured range. Behind the scenes there are five FreeRTOS tasks exchanging data through queues and an event group, plus 13 unit tests that run on a PC without touching the hardware.

The interesting part is not the sensor itself, but how the firmware is organised. The application logic stays separate from the hardware, so it can be tested with Unity before even connecting a board. On top of that, cppcheck performs static analysis on the code. The test result speaks for itself: 13 tests total, 13 passed, 0 failed.

Five FreeRTOS tasks, priorities and queues

SensorTask reads the DHT22 and the photoresistor roughly every 2000 ms via vTaskDelayUntil(), then sends the values to DisplayTask and AlarmTask through a FreeRTOS queue. MotionTask, on the other hand, watches the PIR sensor and signals motion with an event group. StateTask consumes that event and decides the state of the system.

InputTask handles the rotary encoder and sends the selected page to DisplayTask with a dedicated queue. DisplayTask owns the SSD1306 display and shows four pages: Temperature, Humidity, Light and Motion. AlarmTask receives the temperature data from the queue and drives the buzzer according to the evaluateTemperature() function. The configured normal temperature range goes from 18 °C to 30 °C.

The state machine has two conditions: ACTIVE and INACTIVE. If no motion is detected for about 15 seconds the system switches to INACTIVE, and motion detected by the PIR automatically brings it back to ACTIVE. As a result, the behaviour changes without any manual intervention.

What you need to rebuild it and how to test it

The component list is short: a board with an STM32F103C8T6 microcontroller, the board with the STM32F103C8T6 microcontroller, then a DHT22 for temperature and humidity, an LDR photoresistor, a PIR sensor, a rotary encoder, an SSD1306 OLED display and a buzzer. The DHT22 is the module with DHT22 temperature and humidity sensor with a single-wire serial interface, easy to connect.

• STM32 Blue Pill with STM32F103C8T6
• DHT22 sensor for temperature and humidity
• LDR photoresistor for ambient light
• PIR sensor for motion
• Rotary encoder for changing page
• SSD1306 OLED display
• Buzzer for the temperature alarm

The development environment is PlatformIO inside Visual Studio Code, with Git and GitHub for versioning. The simulation runs on Wokwi, so the logic can be tried without building anything. The 13 unit tests break down like this: 5 for the temperature alarm logic, 4 for the display navigation, 4 for the system state logic. All 13 pass, none fail. The complete code, with the tests and the configuration, is in the Rie07 repository on GitHub.

For anyone who wants to get started, the advice is to follow the order of the tasks: first SensorTask and DisplayTask, then AlarmTask, and finally MotionTask and StateTask. That way you see something on the display right away and add the rest one piece at a time. In particular, keeping the alarm logic in a separate function such as evaluateTemperature() makes testing immediate.

Source: https://github.com/Rie07/bca182-freertos-multisensor

Related products

• Board with STM32F103C8T6 Microcontroller
• Module with DHT22 Temperature and Humidity Sensor

The post Environmental Monitoring with STM32 and FreeRTOS: A Testable Multitasking System appeared first on Open Electronics.

🎥 Від магістратури в Японії — до реформ в Україні kpi ср, 10/28/2026 - 15:53

submitted by /u/1Davide
[link] [comments]

КПІ ім. Ігоря Сікорського, Житомирська політехніка та Університет Кренфілда: об’єднуємо зусилля задля відновлення українських земель! KPI4U-2 ср, 10/28/2026 - 14:22

A simple circuit adds a relevant status-reporting bit to the device’s existing already-sizeable capabilities suite.

As described in its datasheet (PDF), the DRV103 is a (mostly) complete, robust, versatile, and efficient solution for solenoid and other power driver applications. However, there’s one trick missing from its sleeve. It lacks the ability to detect and report open-load faults in which the driven load has come adrift or is missing its connection to the power source, or the coil winding has come open or has otherwise lost continuity.

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

The 103 falls out of its shrink wrap with built-in over-current and over-temperature detection and protection already in place. The logic-level OK-status flag output goes to zero when an energize command is issued and such an error occurs. So, this variety of mishap and mayhem is already adequately covered. No need for rework there.

But obviously, if the driver attempts to energize the load when the load’s connections are broken, nothing useful will happen. And, in an unmodified 103, neither before nor after the failed attempt will any diagnostic error indication be sent to the controller, which will therefore happily but erroneously assume its orders are continuing to be obeyed. This might not be so good, particularly if the application is critical. And at the end of the day, aren’t they all?

Figure 1 shows a (reasonably) simple modification to address this shortcoming.

Figure 1 The absence of V+ at OUT when Input = 0 causes “wired-or” Status OK bit to be pulled low by Q2, indicating the open-load error condition. A connected GPI pin should be configured for passive pullup.

Here’s how it works.

When Input is pulled low by the controller, typically a µC general-purpose (GP) output bit, Q3 turns off, releasing Q1’s collector. Since Input being low also turns the DRV104 internal transistors off, the driver’s OUT pin will now float high or low depending on whether (or not) an intact connection to V+ is established through a properly connected load. This will turn Q1 on (or off), and Q2’s base along with it.

If a good V+ connection exists, Q1 will now turn on, turning Q2 off, releasing Status OK and causing a connected GP input bit to go true, sharing the good news with the controller.

Otherwise not.

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

• 8 to 48 volt PWM relay/solenoid driver finds fault, pinches power
• Booster circuit enables reliable solenoid operation
• The overcurrent limiting transistor fails before anything else!
• Three discretes suffice to interface PWM to switching regulators
• Automotive low side output switch architecture suitable for 8 to 48 volt buses and beyond

The post Adding open-load fault detection to the DRV103 PWM driver appeared first on EDN.

Let’s explore the many application angles of one of the most widely used WiFi modules, through a prototyping board that can host and manage sensors and actuators, all testable with firmware we wrote specifically for the purpose. First instalment.

Modules based on the Espressif ESP32 SoC are highly regarded by designers of applications connected over a WiFi wireless interface, and that is why we have seen them in use for years, and use them ourselves in various projects. Precisely because of their importance and the strong demand from developers and experimenters, we decided to build a demoboard that makes it possible to create firmware both to test a wide range of sensors and to learn how to program the ESP32 and build connected applications, first and foremost in the Internet of Things space.

The board we will use has at its core a wireless module based on the ESP32, and also provides a whole set of headers (connectors) for plugging in various breakout boards and modules that act as its peripherals, namely pressure, ultraviolet, air quality, lightning and gesture sensors plus an NFC-compatible RFID reader. Completing the board is a user interface made up of an OLED display, a set of buttons and LEDs, all configurable to achieve a specific interfacing mode.

Let’s see right away what it is, analysing the board in detail before moving on to the description of the corresponding circuit diagram.

The board

Our demoboard is based on the Board with ESP32 (code YB555), fitted with a MicroUSB connector that is used for programming but can also supply power to the whole demoboard, provided the current required does not exceed a certain value that the ESP32 board can deliver. Alternatively, 12V can be supplied to the PWR power plug, and then it is the demoboard’s regulator U2 (code MP1584ENDCDC) that produces the 5V for the rest of the circuit. In Fig. 1 you will find the pin-out of the ESP32 module in question.

The following modules can be hosted on our demoboard:

• Air quality sensor code SGP30CO2 (U3)
• Lightning sensor code FT1324M (U4)
• Gesture sensor code APDS9960BOUT (U5)
• UVB sensor code GYLM8511 (U6)
• Pressure sensor code BMP280 (U7)
• NFC/RFID reader code PN532 (U8)
• 0.96″ OLED display code OLED096C or code OLEDGVSCSD (OLED1)
• 5V relay (RL1)
• Red LED (LD1)
• Green LED (LD2)
• 5 buttons (P1, P2, P3, P4, P5)
• BreadBoard
• Provision for connecting 3.3V SPI devices (SPI)
• Provision for connecting other 3.3V I²C devices (I²C)

Additional connectors and external peripherals

Beyond what is already provided above, other devices can be connected by making use of the free pins of the ESP32 board. The pins with no connection are D1/TX0, D2, D3/RX0, D34, plus the SPI pins that are not used for connection to any breakout board.

As for the connectors intended for connecting breakout boards and sensors external to the board, we have provided these elements:

• Liquid turbidity (clarity) sensor code TORBISENS (CNU9)
• PIR sensor code PIRMOD / code MINIPIRMOD (CNU10)
• Servo motor, for example code SERVO206 (CNU11)

All the codes given in brackets refer to products for quicker identification. In any case, let’s take a look at the board’s circuit diagram, shown in full on the page next to this one.

Circuit diagram

The circuit, as you can see, is centred on the ESP32 board, designated U1, which receives its main power through the Vin pin; its internal regulator provides a stabilised 3.3V that powers the interface boards that can be fitted to the demoboard and run on that voltage, that is, all those that can be hosted on-board except U6.

The Vin contact of U1 is powered with the 5V that the main power supply derives from the input voltage applied to the PWR DC power jack; the input voltage is first filtered by capacitors C1 and C2 and then stepped down to 5V by regulator U2, which is an MP1584ENDCDC DC/DC step-down module, capable of delivering 3A of current at a stabilised 5V: enough to run all the breakout board modules supported by our demo board.

The 5V output (suitably filtered by C3, C4 and C11 to knock down the switching residue of the switching module) powers the modules that run at that voltage (the UVB module) and the connectors for the servo (CNU11), PIR (CNU10) and external turbidity sensor (CNU9), as well as the relay coil, which is switched by the NPN transistor T1 under the command of the ESP32 module’s D32 I/O line. From RL1 (whose coil has been fitted with an antiparallel diode to protect the collector junction of T1 when it turns off) we make the three changeover contacts available, so as to handle various types of load and various operating conditions; the relay is an actuator peripheral that can be associated, for example, with the sensors detecting that certain thresholds have been exceeded, or with the reading functions of the RFID/NFC module.

OLED display and I²C communication

The display on the board is a small OLED that can be interfaced over the I²C bus, used several times in our projects for its versatility, its low cost and the availability of dedicated Arduino libraries for driving it. It is the OLED096C: a module with a 128×64 pixel blue OLED (Organic Light Emitting Diode) display, I²C interface, SSD1306 graphics controller, viewing angle of about 180°, Arduino compatible.

The library provided for the graphics controller has a modular structure and some modules can be excluded from compilation to reduce the use of Flash memory space. It requires very little RAM and supports, besides I²C bus communication, SPI as well: in the first case it runs a software implementation (Wire library, AVR Twi, Linux i2c-dev) and in the second a 4-wire SPI implementation (Arduino SPI library, AVR Spi, AVR USI module).

The controller allows you to create primitive graphics functions (lines, rectangles, pixels, bitmaps) and text printing (using characters of different sizes; you can use GLCD Font Creator to create new characters).

The display is managed by module U1, through the I²C bus shared with other on-board units such as modules U3 (air quality sensor), U4 (lightning detector), U5 (gesture detector), U7 (pressure sensor), U8 (RFID/NFC module), and brought outside through the connector labelled I2C, to interface the demoboard with external units. In the circuit diagram you can see that OLED1 is powered through two three-way jumpers that must be set one complementarily to the other; the purpose is to allow the various versions available on the market to be fitted, since they may have the + and – power pins (1 and 2) swapped; so if pin 1 is positive, you close jumper J1 on +3V3 and J2 on GND, while if it is negative, you do the opposite (J1 on GND and J2 on +3V3).

SPI bus, LEDs and buttons

Our ESP32 module also implements a 4-wire SPI bus (MISO, MOSI, SCK and CS), useful for interfacing the demoboard with SPI devices (in this case the connector of the same name is used) and various sensors; on that point it should be said that although the on-board sensor U4 supports bidirectional SPI/I²C bus communication, we preferred to interface it to U1 over the I²C bus already described, which uses the ESP32’s D21/SDA and D22/SCL lines. The complete SPI bus, on the other hand, uses the ESP32’s I/O lines D13 (MOSI), D12 (MISO), D14 (SCK) and D15 (CS-Chip Select), and on the relevant connector we also bring out GND and the +3.3 volt supply.

Besides the connectors and modules described so far, the demoboard carries two multifunction LEDs driven by the D25 and D26 lines of module U1 (in USB communication they indicate the switching of the data channel) and manageable by firmware according to the desired application; to complete the circuit we have provided five normally open single-pole buttons that can be used, for example, to set values or thresholds, or to navigate on-screen menus; not by chance, the keys have these functions associated with them:

• P1 = OK
• P2 = UP
• P3 = DOWN
• P4 = LEFT
• P5 = RIGHT

And their arrangement on the printed circuit board somewhat echoes that of a classic joypad. If you intend to use the buttons for other functions, you are free to do so (by modifying the example firmware that will be proposed from time to time among the examples) and rename them according to your needs.

To complete the demoboard we added a small 170-contact breadboard in the centre, which can be used either to wire up breakout boards using Arduino jumpers and the SIL contacts or connectors of the on-board modules, or to connect active and passive components to specific parts of the circuit, for building small circuits of your own.

Building it in practice

Good, at this point we have described the demo board, so we can move on to the construction side: building the demoboard starts with the double-sided printed circuit board on which all the necessary components will sit. To make the project more accessible to makers, these are all THT, that is through-hole or traditional mounting, if you prefer. So once you have the printed circuit board, you can build the board with a minimum of equipment: just an electronics soldering iron, some solder wire and a pair of side cutters to trim the leftover component leads.

Once the board for photo-etching is ready (that is, after you have obtained it from the PCB manufacturing service, starting from the two copper-side traces available for download), you can move on to the actual assembly.

Start by placing and soldering the lowest-profile components, so resistors, LEDs, non-polarised capacitors, pin strips and female strips for the connections and for the modules that will be hosted on board, then the LEDs, the buttons and the electrolytic capacitors, and finally the power jack. Then fit the breadboard, which is simply glued in the position shown by the assembly drawing, using double-sided tape because it has no pins or leads. For polarised components (semiconductors and electrolytics) you must scrupulously respect the insertion direction shown in the assembly drawing you will find in these pages.

Don’t forget to pay attention to the polarity of the OLED display’s power contacts and to set the corresponding jumpers J1 and J2 accordingly (as already explained a few paragraphs back) so that power is applied with the correct polarity.

To power the board you need to use a supply source (not necessarily stabilised) that delivers a DC voltage of 8 to 12 volts and a current of at least 1A (in reality the current depends on how many modules you fit and which ones).

Remember that although the photos in these pages show the demoboard fully populated, you don’t actually need to fit all the modules, only the ones you will be working with at any given time; it goes without saying that two must always be present: the DC/DC (U2) and of course U1, that is the module containing the ESP32 SoC.

Component list:

• C1, C4, C6, C8, C10, C11: 100 nF ceramic
• C2, C3, C5, C7, C9: 100 µF 16 VL electrolytic
• D1: 1N4148
• LD1: 5 mm red LED
• LD2: 5 mm green LED
• P1, P2, P3, P4, P5: Microswitch
• R1, R2: 330 ohm
• R5: 6.8 kohm
• R6: 3.3 kohm
• R3: 4.7 kohm
• R4: 10 kohm
• RL1: 5V relay, 1 changeover
• T1: BC547
• U1: ESP32-WROOM-32 breakout
• U2: 5V/3A step-down module
• U3: SGP30 air quality module
• U4: AS3935 lightning sensor
• U5: PDS-9960 gesture module
• U6: UVB sensor module
• U7: pressure sensor module
• U8: NFC/RFID module
• OLED1: 0.96″ OLED display

Miscellaneous:

• 2-way male pin strip, 2.54 mm pitch (4 pcs.)
• 3-way male pin strip, 2.54 mm pitch (5 pcs.)
• 4-way male pin strip, 2.54 mm pitch (1 pc.)
• 6-way male pin strip, 2.54 mm pitch (3 pcs.)
• 7-way male pin strip, 2.54 mm pitch (1 pc.)
• 15-way male pin strip, 2.54 mm pitch (2 pcs.)
• 2-way female pin strip, 2.54 mm pitch (4 pcs.)
• 4-way female pin strip, 2.54 mm pitch (2 pcs.)
• 5-way female pin strip, 2.54 mm pitch (1 pc.)
• 6-way female pin strip, 2.54 mm pitch (2 pcs.)
• 7-way female pin strip, 2.54 mm pitch (1 pc.)
• 15-way female pin strip, 2.54 mm pitch (2 pcs.)
• 4-way female pin strip, 2.54 mm pitch, 90° (1 pc.)
• Jumper (2 pcs.)
• 3-way terminal block, 5 mm pitch
• 170-contact breadboard
• Power plug
• S1632 printed circuit board (140×110 mm)

Arduino IDE setup

Once you have completed your demoboard at the hardware level, you can focus on the software side, which covers creating the applications and programming the ESP32 module.

First of all you will need to install the ESP32 board so that it can then be programmed from the IDE. To do this, open the IDE, then from the “File > Preferences” menu enter the string https://dl.espressif.com/dl/package_esp32_index.json in the Additional Boards Manager URLs box (Fig. 2).

Having done that, from the “Tools > Board” menu you must issue the “Boards Manager” command and select your ESP32 board, that is type ESP32 in the text box at the top and proceed with installing the ESP32 by Espressif Systems board package (Fig. 3).

Now, again from the “Tools > Board > Boards Manager” menu, choose the “DOIT ESP32 DEVKIT V1” board as shown in Fig. 4.

Everything is ready for programming, so from this point on you can write the code needed to manage the breakout board you are interested in. On that note we have already made available a set of example sketches for each breakout, so you will always have a starting point that certainly simplifies developing custom code. The folders with the sketches available for download are the ones shown in the screenshot in Fig. 5. In each individual example’s folder you will find the library paired with it, where the code requires one. Also, in every folder there will be an “info.txt” file that briefly explains the purpose of the example.

For almost all the examples you will need to have the 0.96″ OLED display module fitted; on that note, remember that on board you can use either OLED displays with the GND/VCC/SCL/SDA pinout, or those with a VCC/GND/SCL/SDA pinout, simply by configuring the two jumpers J1 (for pin 1) and J2 (for pin 2) so that GND rather than VCC is brought to pin 1 or 2 of the display, depending on the display installed.

First application: water sensor

This application example consists of reading the “turbidity” value of water using the specific sensor that can be connected to strip CN9.

This connector can also be used to read a voltage of up to 5V, since there is a divider at the input that lowers the voltage to a maximum of 3.3V; this reduction is necessary because the corresponding ESP32 input tolerates a normal voltage of 3.3V and a maximum of 5V, beyond which the ESP32 module is damaged.

The sensor used is the 9145-TORBISENS (Fig. 6) and it consists of the actual sensing element, to be partially immersed in the water whose clarity or turbidity you want to detect, and a signal conditioning and interface board, which will provide a digital or analogue signal and which you must connect to connector CNU9.

The sensor is able to detect particles suspended in water (or another liquid, as long as it is not chemically aggressive or a solvent) by measuring light transmission and the dispersion rate, which changes with the total amount of total suspended solids (TSS) in the water. As the TSS (Total Suspended Solids) increases, the liquid’s turbidity level rises. It has an analogue and a digital output.

When using this sensor, it is worth remembering that only the transparent plastic part with the two “prongs” should be immersed, because the upper part of the probe (the one where the cable connects) is not watertight. The temperature of the liquids in which the sensor can be immersed must be between +5°C and +90°C: bear this in mind when using it.

Once the sensing part has been introduced into the water, the sensor provides the corresponding value in a time of the order of 500 ms. If the output is set to analogue, it provides a voltage from 0 to 4.5 V inversely proportional to the liquid’s turbidity; if instead it is set to digital, the turbidity threshold can be adjusted using the dedicated trimmer on the interface board (0=turbid; 1=clear).

The sketch we suggest you upload to use the water turbidity sensor is the one shown in Listing 1.

Listing 1

/**************************************************************************

This is an example for our Monochrome OLEDs based on SSD1306 drivers

This example is for a 128×64 pixel display using I2C to communicate

3 pins are required to interface (two I2C and one reset).

Adafruit invests time and resources providing this open

source code, please support Adafruit and open-source

hardware by purchasing products from Adafruit!

Written by Limor Fried/Ladyada for Adafruit Industries,

with contributions from the open source community.

BSD license, check license.txt for more information

All text above, and the splash screen below must be

included in any redistribution.

**************************************************************************/

#include <SPI.h>

#include <Wire.h>

#include <Adafruit_GFX.h>

#include <Adafruit_SSD1306.h>

#define SCREEN_WIDTH 128 // OLED display width, in pixels

#define SCREEN_HEIGHT 64 // OLED display height, in pixels

// Declaration for an SSD1306 display connected to I2C (SDA, SCL pins)

// The pins for I2C are defined by the Wire-library.

// On an arduino UNO: A4(SDA), A5(SCL)

// On an arduino MEGA 2560: 20(SDA), 21(SCL)

// On an arduino LEONARDO: 2(SDA), 3(SCL), …

#define OLED_RESET -1 // Reset pin # (or -1 if sharing Arduino reset pin)

#define SCREEN_ADDRESS 0x3C ///< See datasheet for Address; 0x3D for 128×64, 0x3C for 128×32

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);

#define NUMFLAKES 10 // Number of snowflakes in the animation example

#define LOGO_HEIGHT 16

#define LOGO_WIDTH 16

const int Sens = 33;

void setup()

{

Serial.begin(9600);

// SSD1306_SWITCHCAPVCC = generate display voltage from 3.3V internally

if(!display.begin(SSD1306_SWITCHCAPVCC, SCREEN_ADDRESS)) {

Serial.println(F(“SSD1306 allocation failed”));

for(;;); // Don’t proceed, loop forever

}

// Show initial display buffer contents on the screen —

// the library initializes this with an Adafruit splash screen.

display.display();

delay(2000); // Pause for 2 seconds

// Clear the buffer

display.clearDisplay();

display.setTextSize(2); // Draw 2X-scale text

display.setTextColor(SSD1306_WHITE);

display.setCursor(5, 0);

display.print(“** Test **”);

display.setCursor(20, 30);

display.print(“ Analog “);

// Show the display buffer on the screen. You MUST call display() after

// drawing commands to make them visible on screen!

display.display();

delay(2000);

// display.display() is NOT necessary after every single drawing command,

// unless that’s what you want…rather, you can batch up a bunch of

// drawing operations and then update the screen all at once by calling

// display.display(). These examples demonstrate both approaches…

/*

// Invert and restore display, pausing in-between

display.invertDisplay(true);

delay(1000);

display.invertDisplay(false);

delay(1000);

*/

pinMode(Sens,INPUT);

}

void loop()

{

int val_adc = 0;

float val_tens;

String txt_msg;

val_adc=analogRead(Sens);

val_tens = float(500)/float(4096);

val_tens = float(val_tens) * float(val_adc);

val_tens = float(val_tens) / float(100);

txt_msg=””;

txt_msg = String(val_tens,4) + “V”;

Serial.println(txt_msg);

OLED_Message(“5V max for CNU9-OUT”,txt_msg);

delay(500);

}

void OLED_Message(String text_display1, String text_display2)

{

int lunghezza = 0;

display.clearDisplay();

display.setTextSize(1); // Draw 2X-scale text

display.setTextColor(SSD1306_WHITE);

display.setCursor(0, 20);

lunghezza = text_display1.length();

lunghezza=21-lunghezza;

lunghezza=lunghezza/2;

for (int i=0;i<lunghezza;i=i+1)

{

display.print(“ “);

}

display.print(text_display1);

display.setCursor(0, 40);

lunghezza = text_display2.length();

lunghezza=21-lunghezza;

lunghezza=lunghezza/2;

for (int i=0;i<lunghezza;i=i+1)

{

display.print(“ “);

}

display.print(text_display2);

display.display();

} As for the connection between the sensor, the supplied interface board and the demoboard, the wiring diagram shown in Fig. 7 applies; in the image, the wire colours are red for +5V, black for ground (GND) and blue for the signal.

Conclusions

Well, with this first example of use we end our overview of the ESP32 demoboard; in the next instalment we will present new sketches and new applications involving both the on-board sensors and modules and modules that can be connected externally through the side connectors.

The demoboard presented in these pages was created to develop and prototype “connected” applications that exploit the WiFi wireless interface to publish or transfer data relating to the sensors and readers present on board or connected externally through the connections it provides; the same parameters can be partly managed and displayed, as a monitor, by the on-board OLED display.

The rich set of sensors makes the board an ideal candidate for the development and prototyping of applications in the IoT field, precisely because of its function as a bridge between sensor data and the Internet or a local wireless connection. With a few extra lines of code it is also possible to perform a minimum of Edge Computing so as to aggregate data from several sensors and save bandwidth in transmission to the Network.

Related products

• Analog Water Turbidity Sensor

The post ESP32 Demoboard: a Prototyping Board for Sensors and Actuators (Part 1) appeared first on Open Electronics.

As spacecraft and satellites become more autonomous and rely on software to perform complex tasks, they need faster and more reliable onboard computing systems. These systems must also withstand harsh space conditions while maintaining security and dependable performance. Microchip Technology has announced several key developments in its PIC64-HPSC high-performance space computing series. The 64-bit multicore RISC-V platform is designed to support spacecraft, satellites and other critical space missions that require advanced processing capabilities.

Early radiation tests on Microchip’s radiation-hardened PIC64-HPSC1000-RH processor have shown that it can withstand a total ionising dose of up to 200 krad(Si). It also passed single-event latch-up (SEL) testing at a particle energy level of 78.2 MeV·cm²/mg under specified operating conditions. During testing, the system controller continued to operate reliably, with no uncorrected errors or external resets required in the tests completed so far. These results indicate progress towards making the processor suitable for radiation-intensive space missions, including those involving low Earth orbit, the Moon and Mars.

“Our vision for PIC64-HPSC was to develop a modern, high-performance computing platform capable of enabling the next generation of civil, commercial, scientific and defense space systems,” said Kevin So, vice president of Microchip’s communications business unit. “The combination of operational silicon, radiation-characterization results and customer evaluation activity demonstrates continued execution against that vision and marks an important step in the maturation of the platform.”

Through the PIC64-HPSC Early Access Program, participating customers have been evaluating silicon and development kits, and beginning application development with supporting software, tools, technical resources and direct engineering assistance from Microchip. A growing ecosystem of board partners is also developing PIC64-HPSC-based VPX and VNX+ computing platforms, providing additional paths for system developers to integrate the processor into future space systems. The Early Access Program can help space-system developers reduce program risk and advance application development.

Initial silicon performance measurements are in line with program objectives, providing a foundation for increasingly compute-intensive workloads such as onboard autonomy, high-performance payload processing, Earth observation and intelligence, secure communications, spacecraft control, scientific exploration and edge AI. By processing more sensor and mission data onboard, future spacecraft can reduce dependence on communications bandwidth, shorten decision-making latency and respond more rapidly to changing mission conditions. The importance of advanced onboard processing is also reflected in NASA’s FY26 Civil Space Shortfall Prioritization, which ranked advanced onboard computing for space operations as the third-highest civil space technology shortfall.

PIC64-HPSC is designed as a scalable computing foundation for a broad range of next-generation space systems. Its 64-bit multicore RISC-V architecture supports the industry’s move toward more open and scalable models for onboard autonomy, software-defined spacecraft, distributed processing, deterministic communications and heterogeneous computing.

PIC64-HPSC originated from NASA and JPL’s assessment of future spaceflight computing requirements and awarded the HPSC contract to Microchip in 2022. Today, operational silicon, customer evaluations and early radiation-characterization achievements reflect the program’s progress to date.

The HPSC program helped establish the foundation for Microchip’s 64-bit computing portfolio, which the company has since expanded its portfolio of PIC64 MPUs addressing performance requirements across a broad range of markets.

The post Microchip Achieves Key Milestones in PIC64-HPSC Spaceflight Computing Development appeared first on ELE Times.

Beyond Physical Perimeters: Transitioning to Attack Surface Management

With the rapid emergence of Software-Defined Vehicles (SDVs) and Advanced Driver Assistance Systems (ADAS), modern automobiles have evolved into distributed computing platforms—effectively data centres on wheels. This transformation requires a fundamental shift in how the industry conceptualises automotive security.

Traditional security models relied on physical perimeters, drawing a boundary around assets and protecting them within a contained enclosure. Much like cloud computing disrupted enterprise physical perimeters, automotive software renders physical containment obsolete. Security engineering must instead adopt an Attack Surface Management model.

Rather than attempting to enclose the vehicle within a physical parameter, Attack Surface Management evaluates every external connection point through which an attack vector could enter:

• OEM Cloud Connections: Over-the-air (OTA) update channels and telemetry pipelines.
• Mobile Applications: User management apps interacting with vehicle functions via APIs.
• Charging Infrastructure: Physical and digital interfaces at EV charging stations.
• Third-Party APIs: External software services pulling or transmitting vehicle telemetry.
• In-Vehicle Infotainment (IVI) & Connectivity: Local wireless protocols including Bluetooth and Wi-Fi.

Recent real-world incidents highlight the dangers of flawed perimeter assumptions. These include remote disabling of commercial auto-rickshaws via unauthenticated, open wireless interfaces. Secure vehicular architecture requires continuous validation: verifying whether the sender of an instruction is authorised and determining whether the receiving Electronic Control Unit (ECU) should execute the request.

Cybersecurity as a Brand Differentiator and Hygiene Metric

In enterprise IT, a cybersecurity breach typically results in data loss, service downtime, or administrative inconvenience. In the automotive domain, a breach triggers a cyber-physical event, directly impacting physical safety and human lives.

Security researchers have repeatedly demonstrated remote exploits capable of manipulating navigation systems, spoofing GPS coordinates, or executing unauthorised API calls across thousands of connected vehicles globally. Significantly, many of these vulnerabilities stem not from flaws in the primary vehicular control systems, but from exploits within integrated third-party software APIs accessed over the internet.

As consumers become increasingly tech-savvy, cybersecurity has shifted from an invisible technical specification to a foundational brand hygiene issue. Regardless of a vehicle’s luxury features, performance metrics, or post-purchase service offerings, unmitigated cybersecurity vulnerabilities threaten brand trust. Furthermore, as Over-The-Air (OTA) software updates become standard, managing update integrity is critical to preventing vehicle bricking or operational failures on the road.

Implementing Zero Trust Architecture (ZTA) and Machine-to-Machine Authentication

As autonomous and connected vehicles advance, managing Machine-to-Machine (M2M) and Vehicle-to-Vehicle (V2V) identity authentication requires implementing Zero Trust Architecture (ZTA).

Zero Trust operates under the explicit assumption that a network breach has already occurred (“trust no one”). Within a vehicle’s internal bus and external communication channels, ZTA eliminates implicit trust and enforces strict authentication protocols:

• Machine-to-Machine Identity: Every interaction between onboard ECUs, adjacent vehicles, and external road infrastructure requires explicit identity verification and authorisation.
• Fine-Tuned Role-Based Access Control (RBAC): ZTA enforces strict boundaries between informational data and physical control systems. For example, while a vehicle may accept V2V telemetry regarding downstream traffic congestion, that external data stream must never be granted execution rights to alter onboard steering or braking systems directly.

Implementing Zero Trust across vehicular systems requires embedding continuous validation across every architectural layer—from physical hardware root-of-trust to software execution.

Post-Quantum Encryption, VSOCs, and the “Cyber Crumple Zone”

To protect passengers, pedestrians, and data privacy against long-term threat vectors, original equipment manufacturers (OEMs) must implement proactive defense strategies:

Post-Quantum Cryptography (PQC)

With the eventual realisation of quantum computing, legacy encryption algorithms risk widespread decryption. OEMs must begin transitioning toward Post-Quantum Cryptography standards (such as NIST-approved PQC frameworks) to ensure long-term data protection.

Hardware Security Modules (HSM)

Relying solely on software-based trust keys creates structural vulnerabilities. Physical Hardware Security Modules (HSMs) must serve as the immutable, hardware-backed Root of Trust (RoT) for all cryptographic operations within the vehicle.

Vehicle Security Operations Centres (VSOC)

Continuous monitoring through specialised Vehicle Security Operations Centres (VSOCs) allows OEMs to detect telemetry anomalies across fleet deployments in real time. It also helps initiate defensive countermeasures before vulnerabilities can be exploited at scale.

The “Cyber Crumple Zone” Analog

Traditional automotive engineering uses physical crumple zones to absorb impact energy during a collision, preventing physical force from penetrating the passenger cabin. Automotive software architectures require an analogous Cyber Crumple Zone. By enforcing strict hardware and software compartmentalisation, a cyber breach within a non-critical subsystem (such as the IVI or a third-party app interface) is strictly contained. This prevents lateral movement into critical vehicle dynamics, steering, or braking controls.

Mitigating Security Debt, Ensuring Data Privacy, and Framework Alignment

Connected vehicles store extensive personal data, including frequent locations, navigation histories, and home automation credentials (such as automated garage door keys). As privacy regulations like India’s Digital Personal Data Protection (DPDP) Act come into force, OEMs must treat vehicle telemetry under strict data privacy frameworks.

Managing Automotive Security Debt

The automotive development lifecycle spans 5 to 10 years, followed by an operational vehicle lifespan of another decade or more. This long timeline introduces significant security debt—where aging onboard hardware and software architectures remain in service long after modern threat vectors have evolved.

To mitigate security debt, OEMs must adopt a risk-based management approach:

• Establishing continuous validation pipelines that extend beyond initial lab certifications to monitor long-term operational resilience on the road.
• Managing technology updates lifecycles to patch legacy systems as vulnerabilities surface over time.
• Aligning internal risk frameworks with established automotive cybersecurity standards (such as AIS 189/190 and ISACA risk maturity models).

By combining Attack Surface Management, Zero Trust principles, hardware-backed root-of-trust, and compartmentalised cyber crumple zones, the automotive industry can build software-defined vehicles that remain secure throughout their operational lifespans.

The post “We’re Redefining Vehicular Security in Software Defined Vehicles” — R.V. Raghu, Director, Versatilist Consulting India appeared first on ELE Times.

Наталія Семінська: "Без відновлення людського капіталу неможливе повноцінне відновлення країни" Інформація КП ср, 10/28/2026 - 11:00