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

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

PaperFlux is a small connected object that once a week prints a summary of the user’s GitHub activity on thermal paper: stars, followers, commits from the last seven days, languages and main repositories. The board downloads a black-and-white PNG image generated by a server over HTTPS and sends it to a 58 mm thermal printer. The project is by Alban Petit and covers the period from October 2024 to September 2026. It is a complete example of a connected object that brings together custom electronics design, embedded firmware, a production web service and mechanical modelling.

The board measures 33.55 × 50.05 mm and has four M2 mounting holes. The total PCB thickness is 1.58 mm, with an ENIG finish. The routing counts a little over 300 segments on the front side, around thirty on the back and about a hundred vias. The heart is an Espressif ESP32-C3-MINI-1, flanked by a Diodes AP33772S controller in a WQFN-24 package with 0.5 mm pitch and I²C address 0x52.

USB-C PD power and the 3.3 V rail

The board is connected to a USB-C Power Delivery charger and negotiates a voltage of 9 V, with 5 V as fallback, which powers both the electronics and the printer. The AP33772S controller talks to the charger on the CC1 and CC2 lines, where the pull-down resistors R4 and R5 are 5.1 kΩ. It also measures current through the R6 shunt of 5 mΩ and monitors temperature via the NTC1 thermistor.

Once the voltage is established, the AP33772S closes the two MOSFETs Q1 and Q2, both DMN3009SFG. The ESP32-C3 is powered through the AP33772S switch: if a protection trips and cuts the output, the microcontroller shuts down together with the printer. The AP63203 converter produces a 3.3 V rail with current up to 2 A, using a Würth WE-MAPI 3015 inductor of 3.9 µH. The connector is a JAE DX07S016JA1R1500. A TI TPD4E02B04 also comes into play for line protection and, on the I²C bus, a TI PCA9306 level shifter.

The ESP32-C3 firmware and PNG streaming to the print head

The firmware connects to Wi-Fi, synchronises the clock via NTP and checks every minute whether it is time to print a receipt; by default the receipt is due once a week. When the time comes, the board calls the web service endpoint. The server collects the GitHub statistics, lays out an HTML template in a headless Chromium and converts the screenshot into a black-and-white PNG exactly as wide as the print head. The PNG generated by the server is 384 px wide and in 1-bit format.

The firmware decodes the PNG on the fly and sends it to the printer line by line. The DP-EH400/2 thermal printer has a print width of 384 dots and a TTL interface, with a UART connection at 9600 baud. The project uses KiCad for the schematic and layout, PlatformIO with Arduino on ESP32-C3 for the firmware, and on the server side Ruby 3.3 with Sinatra, Ferrum, ImageMagick, Kamal, Docker and GitHub Actions. Mechanical modelling is done in FreeCAD.

• Espressif ESP32-C3-MINI-1, the microcontroller with Wi-Fi
• Diodes AP33772S, the USB-C Power Delivery controller with I²C address 0x52
• 2 × DMN3009SFG, the MOSFETs that close the output
• Diodes AP63203, the converter that produces the 3.3 V rail up to 2 A
• Würth WE-MAPI 3015 of 3.9 µH, the converter inductor
• TI PCA9306, the I²C level shifter
• TI TPD4E02B04, the line protection
• JAE DX07S016JA1R1500, the USB-C connector

Anyone who wants to rebuild the project will find the full account of the work, from the KiCad schematic to the web service, on the maker’s site. The text contains precise numbers: the 33.55 × 50.05 mm board, the 5 mΩ shunt, the 384 px PNG, the UART at 9600 baud. These are all figures that matter to anyone who has to replicate the same chain, from the USB-C connector to the thermal print head.

For assembly you need a USB-C PD charger capable of negotiating 9 V, a USB-C to USB-C data cable and a thermal printer compatible with the DP-EH400/2 format. For those starting from scratch with the ESP32-C3, a mini ESP32-C3 module is the simplest starting point to try the firmware before soldering the final board.

Source: https://albanpetit.com/post/paperflux/

Related products

• Mini ESP32-C3 module

The post PaperFlux: the thermal receipt printer that prints your GitHub activity appeared first on Open Electronics.

Infineon Technologies AG is setting up Europe’s first high-volume manufacturing facility for gallium nitride (GaN) power semiconductors using 300-millimetre wafers. The company plans to invest around €1.1 billion in its existing cleanroom facilities at its Villach site in Austria by 2034, using and upgrading the current infrastructure to expand production capacity more efficiently and at a lower cost. Manufacturing is expected to begin by the end of 2027. The investment aims to meet growing demand for energy-efficient power chips used in AI data centres, energy infrastructure, electric vehicles, robotics and consumer electronics. GaN semiconductors can improve power-conversion efficiency, reduce energy losses and enable smaller, more compact electronic systems.

Infineon is a leading developer of gallium nitride (GaN) power semiconductors. Two years ago, the company achieved a major technological milestone by successfully processing GaN wafers measuring 300 millimetres in diameter. These larger wafers can produce around 2.3 times more chips per wafer than conventional 200-millimetre wafers, making manufacturing more efficient and cost-effective. Infineon is now moving this technology into high-volume production to supply customers with next-generation power semiconductors.

“This substantial investment shows our clear commitment to strengthening the European semiconductor ecosystem and Europe’s technological sovereignty. By establishing high-volume manufacturing on 300-millimeter wafers, we will be the first company in the world to bring gallium nitride power electronics into volume production,” says Jochen Hanebeck, CEO of Infineon Technologies AG. “In doing so, we are paving the way for the widespread use of gallium nitride in a wide range of key applications in areas such as artificial intelligence, energy infrastructure, e-mobility and robotics. This new, state-of-the-art manufacturing facility translates innovation leadership into direct customer benefits.”

Christian Stocker, Federal Chancellor of the Republic of Austria: “With Infineon’s billion-euro investment, we are witnessing one of the largest single investments in the history of Austria’s high-tech industry. This is not only a strong commitment to Austria as a business location but also helps ensure that the future of the semiconductor industry will not be shaped solely in Asia or the United States, but also in Austria and Europe. Villach will thus become home to a globally unique production facility for one of the key technologies that will shape the future. This will strengthen our international competitiveness and secure jobs and value creation in Austria. After all, Austria may not be a country with unlimited natural resources, but it is a country with an unlimited wealth of talent. Our cutting-edge research sets international standards, and companies such as Infineon demonstrate every day how innovation made in Austria works. These are precisely the strengths we want to build on with our industrial strategy so that, by 2035, Austria will once again rank among the world’s top ten industrial nations.”

Wolfgang Hattmannsdorfer, Austrian Federal Minister for Economic Affairs: “Chips are as important to tomorrow’s economy as oil was to yesterday’s. Europe currently accounts for only around 10 percent of global chip production. For me, the conclusion is clear: We must also manufacture this key technology in Europe. Austria is already a leader in energy-efficient chips. Relative to our population, we rank first in the EU in business R&D spending in the semiconductor sector. With our industrial strategy, we intend to build on this lead and not only research new technologies but also manufacture them on an industrial scale. This benefits the entire economy: Statistically, every job in the chip industry can provide six additional jobs across the broader economy. That is why we intend to support Infineon’s new chip production with up to 319 million euros – subject to clear funding criteria for the location. This will ensure that public funds strengthen value creation and jobs in Austria over the long term.”

The investment in this first-of-a-kind technology is being supported under the European Chips Act. The European Commission approved €319 million in state aid. The formal funding commitment by the Austrian Federal Ministry for Economic Affairs, Energy and Tourism is expected within the stipulated time limits. By approving the funding from the Federal Ministry for Economic Affairs, Energy and Tourism, the European Commission is not only enabling the expansion of manufacturing capacities in Europe but is also generating positive spillover effects in related sectors – for example, through cross-border collaboration with universities and research institutions and improved access to innovative technologies and products for start-ups and small and medium-sized enterprises.

“Competitiveness and technological sovereignty emerge where excellent research is translated into industrial value creation. This is precisely where our flagship project comes in: From Austria, we are bringing innovation into industrial application, strengthening our technological leadership and securing highly skilled jobs. Microelectronics is a key industry with enormous leverage for the economy and society. The entire Austrian semiconductor ecosystem benefits – from research organizations and universities to industrial partners. We are thus sustainably strengthening Europe’s competitiveness and strategic autonomy in microelectronics,” emphasizes Sabine Herlitschka, CEO of Infineon Technologies Austria AG.

The investment strengthens Villach’s role as a global competence center for power electronics and new semiconductor materials. Infineon Austria currently employs around 5,800 people, approximately 4,800 of them at the Villach1 site. Together with universities, research institutions, start-ups and industry partners, Infineon forms the core of an internationally recognized microelectronics ecosystem in southern Austria. The establishment of the new 300-millimeter GaN manufacturing facility will also create positive synergies with the power electronics research and development activities located in Villach.

Gallium nitride is an advanced semiconductor material that can switch and convert electricity much more efficiently. This enables smaller, more powerful and more energy-efficient electronic systems with lower energy loss and reduced heat generation. Analysts expect the market for GaN power semiconductors to grow to approximately USD 3.5 billion by 2031, representing annual growth of around 35 percent between 2025 and 2031.2

The post Infineon to Build Europe’s First High-Volume 300mm GaN Power Semiconductor Manufacturing Facility appeared first on ELE Times.

havent touched electronics in forever (ended up doing consumer product rnd (mostly material science) for 8 years and wanted to get back to this im sharing something iv been working on and im sure its nothing compared to the complexity of things people make in this sub there was a concern in my family business -- counting fertilizer bags going into a truck essentially bags are weighed before loading so i managed to pull the signal out of the RS232 port of the weighing machine and using a micro controller count the bags and upload it onto the cloud i was able to add additional features as well (check if the bag is over weighed and sound a siren etc) right now its module based but it works -- hoping version 2 will have next to no modules and 100 percent components the final goal is to bring about IOT into the whole factory submitted by /u/95farfly [link] [comments]

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

Any engineer with hands-on experience is familiar with cables which are shielded with a woven, all-metal braid, seen in Figure 1. Braided shielding has been used for decades. It is widely available, has modest cost, and it works—at least up to a point.

Figure 1 This schematic of a cable using conventional braided shielding illustrates the RF barrier it provides; the illustration shows multiple basic-wire conductors, but the same concept is used with coaxial cables and twisted-pair cabling. Source: Stecker Express

The braid serves two complementary EMI functions in most cases. It attenuates emissions of electromagnetic energy from the cable, and, at the same time, it prevents interfering energy from reaching the cable. It’s used for cables carrying DC all the way to gigahertz signals. Shielding is used with coaxial cable, twisted pairs, multiconductor cable assemblies, and more.

Engineers have a love/hate relationship with cables that use a tightly woven conductive braid for shielding. On one side, it’s an essential passive component for maintaining signal integrity, and how can you put a price on that, especially when there seems to be no viable alternative. On the other side, it adds bulk, weight, cost, and routing challenges to the end-product.

Shielded cable also has termination challenges. Every hands-on engineer can tell “horror stories” of trying to cleanly terminate the shield to the connector, especially if it’s being done by hand without the right tools or jigs. Those tiny cut shards of braid that “fall” when trimming it can easily short the cable, and nearby circuit board, and cause general troubleshooting havoc.

The shielded-cable dilemma increases in today’s world of complex cabling in small spaces, with design emphasis on cable size, weight, and performance. Cables with conventional braided shields—almost always made of copper, but sometimes other metals such as aluminum are used—are relatively heavy and bulky.

Furthermore, the relative proportion of their overall weight and bulk increases compared to core cable size as the core that is being shielded shrinks down. That creates a dilemma for designers as gigahertz cables go down to millimeter-levels diameter, and the weight and bulk of the shielding soon become a significant design issue.

There’s even another insidious concern: performance. As frequencies reach in the multi-gigahertz range, the shielding performance of the braid decreases. The tiny voids in the woven braid become “open windows” to the short-wavelength RF energy. These shielded cables also restrict movement, can be difficult to handle and install, and their “shape memory” makes routing and rerouting more difficult.

Tighter weaves improve the situation somewhat, but at a cost in materials, flex, weight, and other factors.

Some cables use a solid foil as a first-layer shield, which is then covered with a braided shield. This improves RF shielding to nearly 100%, but further increases cost and weight and adds to termination complexity.

What can be done?

New shielding technologies and approaches are needed as cable applications shift. A vendor-authored article I saw highlighted the ARACON shielding system from Micro-Coax, a division of Amphenol. It’s based on a very different approach to creating the RF cage around the signal-carrying conductors.

Instead of woven metal braid, it uses lightweight, ultrathin, and extremely strong DuPont Kevlar fibers to create a textile-like material that then is coated with either nickel or silver (for solderability). It forms a composite shielding braid that is up to 80% lighter than copper, while still providing strong EMI/RFI protection, lightning protection, and mechanical robustness.

The conducting coating adheres to the fabric-like fibers to form a “wrapper” against electromagnetic energy. The result is a thin braid-equivalent that slips onto the cable core like a thin, open-ended, super-flexible sock. It can be used with coaxial cable, twisted pair, and even wire bundles, shown in Figure 2.

Figure 2 The ARACON shielding system uses a thin but super-tough fabric sock that slips over the conductor or wire bundle to be shielded. Source: Micro-Coax

To get a sense of the bulk differences, the density of aramid fibers is only 1.44 grams per cubic centimeter (g/cc), compared to copper at 8.9 g/cc. Even with the addition of the metal coatings, the density of fibers ranges from 3 g/cc to 5 g/cc. At the same time, the tensile strength of the aramid core, at 350 kilopounds per square inch (Ksi) is 3 to 10 times higher than that of traditional or high-strength copper cores (35 Ksi to 95 Ksi).

Its other attributes are flexibility and longevity. It has been tested to withstand over 50,000 flex cycles over a 180-degree arc; installs easily, as it cuts like fabric with standard tools; and it offers corrosion resistance (important in many real-world settings). Termination techniques are similar to those for wire-braided shields.

It meets or exceeds the many stringent mil/aero and space-related electrical, mechanical, and outgassing performance standards for shielding (it’s a long list), but with far less bulk and weight. Micro-Coax says it can be braided and fabricated by wire/cable vendors using standard metal-wire equipment and it supports crimping or banding, as well as soldering (if it’s silver plated).

The high surface-to-volume ratio of ARACON fibers contributes to effective RF EMI shielding, exceeding the performance of conventional shielding, as seen in Figure 3.

Figure 3 Despite its reduced bulk and weight, the Aracon approach offers approximately 20 dB greater attenuation compared to conventional copper braid (here, industry standard AA59569). Source: Micro-Coax

There’s a lot that is attractive about this shielding approach, which is not just a lab development but has been in use for over 10 years. It has been proven “in the field” in aircraft, space vehicles, and more.

While I couldn’t get comparative pricing—and direct one-to-one comparisons are difficult—I suspect it’s more costly than conventional metal-braided shielding. But I can see where the extra cost is justified in applications where lower weight and bulk, along with performance and flexibility, are more critical priorities than cost.

It feels weird to say “we’ve been a team all these years, but things have changed” to braided shielding. Still, sometimes we must acknowledge reality and move on in a somewhat different direction to meet new design demands and constraints. Perhaps that’s what will happen with the availability of this alternative to braided shielding.

Have you ever found the realities of standard braided shielding to be inadequate for your project, or that it imposed too many burdens? Did you look for alternative cable-shielding solutions? Was your search successful?

Bill Schweber is a degreed senior EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features. Prior to becoming an author and editor, he spent his entire hands-on career on the analog side by working on power supplies, sensors, signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing.

Related Content

• Sophisticated Cables: Not Just for RF
• Litz Wire & Other Component Cleverness
• Cable self-heating: The other side of IR drop
• Cable Assemblies: Ignore Them and Be Sorry
• Read this and give electric insulation a second thought
• Transmission line design: Why not 75 ohms instead of 50 ohms?

The post A viable alternative to braided shielded cable appeared first on EDN.

SemiQ Inc of Lake Forest, CA, USA — which designs, develops and manufactures custom silicon carbide (SiC) power semiconductors and 150mm SiC epitaxial wafers for high-voltage applications — has announced the availability of its fourth-generation QSiC silicon carbide power devices, launching a family of 1200V and 750V SiC bare dies and MOSFETs...

Efficient Power Conversion Corp (EPC) of El Segundo, CA, USA — which makes enhancement-mode gallium nitride on silicon (eGaN) power field-effect transistors (FETs) and integrated circuits for power management applications — has announced the availability of the EPC91124 and EPC91125, two new 100V three-phase brushless DC (BLDC) motor drive evaluation boards designed to simplify the development of next-generation high-performance motion-control systems...

We put on a massive Haunted Circus every year for Halloween, so I built an ESP32-based controller to manage the increasingly insane amount of games, props, and custom lighting audio that makes it all happen. It can: Use up to 4 motion sensors and other GPIO based devices. I find Ultrasonic Sensors actually work pretty darn well in a haunt. Trigger up to 4 of pretty much any typical Spirit Halloween, Home Depot, etc prop that has a step pad or try me button. Play custom audio, including a beefy amp and lineout for powered speakers Sync jaw motion with overridden of props (with an extra MOSFET hooked up) Has two higher powered and very protected 5V PWM connectors specifically to make it easy to connect programmable RGB LED strings, servos, etc. Has a wireless interface via a hub, so I can monitor everything plus adjust motion range/sensitivity, volume, and other per-prop settings. It's fun to monitor activations from my phone. Can be powered with 5.9V-12V barrel jack adapters. And has a fused pass thru VOut so you can plug in the controller and one prop through the same adapter, very common use case to spiffy up a prop with custom audio, lights, etc. All of this is programmable via ESP32-S3-WROOM-1-N16R8 Having the extra storage is key for all the audio (and there's an even bigger module, but it was out stock at the manufacturer) The fortune teller in the second photo is a great example of the controller being used to its fullest. The attendant presses a remote control button to start the sequence. This wakes her up, and she does her movements while playing custom audio synced with her jaw synced to it. Plus extra props on the table go off. Plus it sets off a relay to create a lightning effect. Plus it tells a Pi to display a number in the crystal ball via a pepper's ghost effect. I had built a much simpler controller last year, and while I love that thing, I really wanted to push myself to actually have proper power regulation (instead of a USB brick), power protection, my own built-in amp instead of DFPlayer, etc. And it needed to get done in time for Halloween, so I put my mind to figuring out how to get AI to help the process. Over two months I ended up using GPT Sol 5.6 and later GPT Astra via Codex going pretty much every step of the PCB design process: Speccing out the functionality Initial design and component selection Sourcing datasheets, footprints, and 3D files Interpreting datasheets (so many datasheets) Iterating on and validating the design Building schematics in KiCad Some help with component placement (I did most of it, in hindsight I probably didn't need to) And the craziest thing, 99.9% of this PCB was routed by GPT Astra. There was a lot involved in getting it to work well enough, particularly anything in visual layout. The general process was to have AI attempt to do the work, figure out where it's struggling and critique it, iterate, and once we had a good workflow, have AI build a skill so it can do the rest of the step on its own. This was critical to getting good results, including having schematics and routing not look like a dog's breakfast. submitted by /u/bacontreatz [link] [comments]