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

As 5G-Advanced continues to roll out, bringing AI/ML integration, integrated sensing and communication (ISAC), RedCap, and non-terrestrial network capabilities, support for 3rd Generation Partnership Project (3GPP) Release 19 (R19) is emerging, setting the stage for initial 6G deployment and testing. Qualcomm Technologies, for example, is already incorporating AI/ML into RF modems to control real-time signal conditions, dynamic impedance matching, and predictive power scaling. Its latest X105 5G Modem-RF platform is 3GPP R19-ready.

(Source: Adobe Stock)

Many of the technologies under consideration for 6G are already emerging in 5G-Advanced, giving vendors and operators an opportunity to trial capabilities such as AI-driven network optimization and ISAC before committing to broader 6G rollouts, according to ABI Research.

5G-Advanced rollouts are creating a practical runway toward early 6G deployment and testing. The September/October 2026 digital issue looks at how the industry is progressively validating the technologies needed for initial 6G interoperability and performance.

ABI Research provides an update on the transition from 5G to 6G. Research analyst Michael Moreno reports that 6G will embed AI deeper in the radio access network and core to manage radio resources, optimize performance, and deliver a more intelligent network. While AI already exists in 5G networks, 6G is designed to integrate AI capabilities more deeply into the network architecture, he said.

Although 6G is still being defined through the 3GPP standards process, Moreno said it is clear that AI, distributed computing, and sensing are becoming as integral as new frequencies, lower latency, and data rates.

5G, 5G-Advanced, and 6G networks all raise test challenges, particularly around uplink efficiency and modulation performance. This is why engineers are revisiting where power amplifier (PA) linearization should happen and how it should be validated, according to Andreas Oelemann, program manager of AI for wireless at Rohde & Schwarz: “PA linearity remains one of the hardest tradeoffs when designing wireless communication systems.”

Oeldemann reports that digital post-distortion (DPoD) is gaining some attention because, unlike conventional digital pre-distortion, DPoD shifts part of the compensation burden to the receiver. He discusses a hardware-in-the-loop testbed built around standard-compliant 5G signal generation and wideband signal analysis.

Two critical areas for wireless design are RF and timing devices. Contributing writer Stefano Lovati reports that sub-6-GHz and mmWave signal chains, higher front-end module integration, and gallium nitride PAs are shaping some of key design decisions on the road from 5G to 6G.

He also finds that RF digital front ends are integrating functions that were previously handled by analog parts. In addition, front-end architectures are beginning to include Frequency Range 3, AI, and early 6G interoperability as 5G-Advanced is rolled out.

The underlying timing infrastructure that keeps 5G networks synchronized has become a strategic technology domain, Benjamin Bunyatipanon, digital marketing specialist for Microchip Technology’s frequency and time system business unit, said. He explores why cesium clocks matter and how they fit into 5G timing architectures, with new challenges in synchronization, global navigation satellite system dependence, and critical-infrastructure reliability.

Also in this issue, we cover top 10 5G chips and modules introduced over the past year, targeting a range of applications, including smartphones, wearables, industrial IoT, and connected vehicles. Don’t miss the wireless chip roundup. These devices feature high integration, low power consumption, and advanced security features, driven in part by the need for multiprotocol functionality and edge AI applications.

Cover image: Adobe Stock

The post Getting ready for 6G networks appeared first on EDN.

Aiming to strengthen its supply chains and accelerate semiconductor technologies from concept to reality, the UK has launched Semiconductor Catapult, which provides customers with access to UK semiconductor supply chain integration, design, system test and validation, delivering long-term economic benefit to the UK...

Tри освітні програми РТФ та ФБМІ КПІ ім. Ігоря Сікорського пройшли міжнародну акредитацію KPI4U-2 вт, 09/29/2026 - 17:07

Університетське управління, наука та міжнародна діяльність: КПІ ім. Ігоря Сікорського розвиває співпрацю з Естонією KPI4U-2 вт, 09/29/2026 - 16:43

Openterface KeyMod is a pocket-sized USB bridge that turns a smartphone into a complete control console for computers, servers, kiosks, and embedded systems. The project comes from TechxArtisan and is available in two versions: Mini and Plus. TechxArtisan’s Crowd Supply campaign explains how it all works, and the hardware files are being released.

The device connects to the target machine over USB and presents itself as a composite device. It has an HID interface for keyboard and mouse, plus a USB network bridge called CDC-ECM. The smartphone runs the KeyCmd app, which talks to the KeyMod over BLE 5.3 in the Mini, or over wired USB in the Plus. The Plus version offers higher bandwidth, useful for heavier transfers.

How the network bridge works

The network bridge assigns a fixed IP to the target, 192.168.11.2, and to the host, 192.168.11.1. This creates a private point-to-point network with no configuration needed. That opens a direct channel for SSH terminal sessions, file transfer, and other administration tasks. The BLE connection uses AES-128 encryption and ECDH P-256 key exchange, with support for authenticated pairing. Security is not an afterthought here, but a core part of the design.

The HID modes include keyboard, touchpad, gamepad, presentation, macro, and shortcuts. All of them are controllable from the KeyCmd app. In addition, an experimental AI mode called Agent Mode lets you plan and execute terminal commands, HID input, and macros through an LLM. The local model tested is a 0.6B Qwen, which sent 1,130 characters in under a minute. For those working with embedded systems, this means quick, direct control.

Size and technical specifications

The KeyMod Mini measures 25 × 15 × 5 mm and weighs about 2.4 grams. The Plus is larger, at 44 × 20 × 10 mm, and weighs 8.9 grams. The BLE 5.3 module reaches 2 Mbps in wireless mode, while USB goes up to 10 Mbps. BLE range is about 5 meters under optimal conditions, up to 10 meters at most. The target gets a fixed IP and the network is ready to use within seconds.

At the heart of the device is a CH32 HID controller, alongside a BLE 5.3 Bluetooth module. The project’s open source philosophy invites you to explore and modify the code.

A single dongle turns your smartphone into a full console for IT administration, embedded development, and gaming. The open source philosophy and advanced features, like the network bridge and AI, make it a versatile tool. The firmware will be open source after the funding campaign, and OSHWA certification is planned. Hardware files are being released, so anyone who wants to can study and replicate the project.

The practical applications are many. A network administrator can manage a server remotely over SSH. An embedded developer can control a development board without opening a laptop. A gamer can use the smartphone as a wireless gamepad. The presentation mode also turns the phone into a slide remote. The possibilities grow with Agent Mode, which automates complex command sequences.

Battery life is not a concern, because the KeyMod draws power from the target machine’s USB port. Power consumption is minimal, and the device is always ready to go. The KeyCmd app is available for Android 5.0+ and iOS 17.0+, covering most modern smartphones. For those using a Raspberry Pi 5 as a server or development station, the KeyMod is an ideal companion for quick management. The direct USB connection removes the need for Wi-Fi or extra cables.

In short, the Openterface KeyMod is a project that combines compact hardware, open source software, and advanced features. The experimental AI mode opens up new possibilities for automation. OSHWA certification and the release of hardware files show a real commitment to the community. If you are looking for a practical way to use your smartphone as a work tool, this dongle deserves attention.

Source: https://www.crowdsupply.com/techxartisan/openterface-keymod

The post Openterface KeyMod: turning your smartphone into a control console appeared first on Open Electronics.

The Arkansas Research Institute for Electronics Systems (ARIES) has been launched, with the aim to develop, produce and deploy next-generation power electronics, microelectronics and semiconductors that thrive in the most challenging environments...

There are several ways to boost a relatively low AC or DC voltage by a factor of two or three, each with tradeoffs and constraints.

Lower-voltage circuitry dominates much of design and associated discussions, with ICs and systems operating from five, three, and one, and even sub-one volt rails. There’s good reason for this: in general, such circuits require less power and have lower dissipation than higher-voltage circuits. Further, these lower-voltage circuits also can operate at higher speeds since the voltage/current swings are smaller, and so the slewing demands (dV/dt, dI/dt) are also reduced.

However, there are many cases when a higher voltage is either preferred or mandatory.  It’s interesting to see the creative ways that have been devised to develop a high voltage from a low-voltage source, often with techniques that are a hundred years old and still in use.

Why would you want to use a higher voltage, since lower operating voltages offer advantages of lower power consumption and higher speeds, among other factors? Among the reasons:

• First, a circuit may operate at a lower voltage, but need a higher voltage in one section to boost signal/noise ratio (SNR); this is common for sensitive front ends in RF and sensor applications.
• Second, when a circuit must deliver power – not voltage – to a load, it’s always more efficient to do so at higher voltages due to reduced losses (internal, switching, IR, and I2R). In these cases, it may be beneficial, even if not mandatory, to use a somewhat higher voltage. In a typical situation, a battery and regulator providing 3 V for the main circuitry may also need to provide a 12-V rail for a sensor.
• But the biggest reason is that requirement is simply unavoidable. There are many real-world applications where the voltage needed is determined by the physics of the situation, and there is no way to “get around” those requirements. For example, many scientific, medical, and test systems require higher voltages (>100 V to >1000 V) to set up specialized components such as vacuum electron devices (VEDs—the now-preferred designation for vacuum tubes) or create electric fields.

There are two very different ways to do increase a low voltage to a higher one: via a transformer, or via some type of switched-capacitor arrangement.

The transformer’s principle is simple and (hopefully) known to everyone reading this blog. An AC voltage on the primary (input) side is stepped up (or down) in proportion to the turns ratio between primary side and secondary (output) side.

For example, if the primary has 10 turns and the secondary has 100 turns – a 1:10 ratio – the voltage on the primary will be stepped up by a factor of ten (Figure 1). Of course, if you need a DC output, that ×10 AC output would need to be rectified and filtered. Use of a transformer to increase or decrease an AC voltage been known for about 150 years and is widely used to step up/down voltages in power-line installations, of course. However, it is often not the best choice for small circuits.

Figure 1 The relationship between primary (left side) and secondary (right side) turns ratio and voltage (and current) step up/step down is simple and a fundamental principle of magnetics. (Image source: Allelco)

However, while the transformer is very good at voltage step-up (or step-down) for larger systems, it is relatively large, costly, and heavy relative to a modest PC board. Further, it is not compatible with IC processes and packaging, and so would have to be mounted as a separate unit. Despite these drawbacks, it is sometimes still the right solution with respect to various tradeoffs.

The alternative is usually a circuit which uses some arrangement of switched capacitors. These clever schemes that have been in use for many years. They are often more practical and IC-compatible, because ICs can provide fast switching of the capacitors. Depending on their size, these capacitors can be in-chip or external; either way, a capacitor is more PC-board “friendly” in many cases than a transformer. These step-up approaches most commonly use a charge pump or a “flying capacitor” topology (where the capacitor is alternately switched or “flys” between input and output sides).

Charge pumps use an electronic switch to control the connection of a supply voltage across a load through a capacitor in a two-step process (Figure 2). in the first step, a capacitor is connected across the DC input supply, charging it to that same voltage. In the second step, the switches are used to reconfigure the circuit so that the capacitor is in series with the supply and the load. Now, the voltage across the load is doubled, as it is the sum of the original supply and the capacitor voltages. The switching action is repeated. Additional regulation is needed to smooth out the pulsed voltage at the output.

Figure 2 In the basic charge pump, the switching capacitor is charged from the input voltage to ground in the first phase, and then connected between the input voltage and output voltage; this “stacking” creates an output voltage which is twice the input voltage. (Image source: Texas Instruments)

An external or secondary clock circuit drives the switching, typically at tens of kilohertz up to several megahertz. A higher frequency minimizes the amount of capacitance required, as less charge needs to be stored and replenished in a shorter cycle. However, higher frequencies can also have higher losses, so there’s a tradeoff.

By adjusting the switching duty cycle, charge pumps can deliver double, triple, half, and scaled (such as ×3/2, ×4/3) ratios. With some rearrangement of the topology, they can also invert or reduce the output voltage (often called buck mode).

Charge pumps can be efficient (80-90%) but only when the components are sized for a specific load current. If the load current changes, the efficiency drops. Also, there are losses in the switching circuity which increase as the switching frequency increases; on the other hand, the output ripple is far less at higher frequencies, so the output filtering is simplified. 

These pumps are widely available and used as standalone voltage-boost ICs, or as part of buck-boost regulator ICs. They are also often embedded within an IC to provide the higher voltages needed by some (not all) internal functions or external I/O (such as enabling a 3-V RS-232/423 interface IC to provide a 5-V or even 12-V drive. The capacitors are usually external to the IC.

The switched capacitor is just one of several related capacitor-based variations which use electronic switches to transfer charge between an input-side capacitor and an output-side capacitor. The charge pump is not the only option: there’s also the “flying capacitor” (Figure 3).

Figure 3 A capacitor can be switched from a voltage input to output capacitor and load, and the resulting charge transfer can provide voltage boosting as well. (Image source: Analog Devices)

The flying-capacitor principle is this: as the charge q in a circuit is unchanged (let’s assume that there is no load, for now) then the input-side charge q = C1 × V1. Then, if this charge is switched to another capacitor on the output side, q flows to that capacitor but is unchanged, and thus the voltage on the second capacitor changes, as q now equals C2 × V2. If the output-side capacitor is smaller than the input-side one, the output-side voltage will be higher than the input-side voltage.

This almost sounds like something for nothing, but it is not. As charge is “drained” from the output side by the load, the capacitor’s voltage will decrease. To correct this, the input-to-output action must be repeated at a high-enough rate to replenish the lost charge.

Incidentally, the flying-capacitor scheme was used many years ago to provide galvanic isolation between a sensor and a circuit. The sensor for be on the “input” side, while the circuit would be on the output side. The voltage across the sensor would be captured and then transferred to the system circuitry without any ohmic path between the two sides. This scheme has largely been made obsolete by modern isolation schemes using transformer, capacitive, optical, and even RF coupling.

In theory, the transformer or switched-capacitor schemes can be used for transforming, say, 10 or 100 V to thousands of volts. However,  in practice, they cannot be used without major adjustments, as the high-voltage world has some unique issues.

However, as voltages go beyond about 60 V, issues of safety and regulatory mandates become a concern. As these voltages reach into the hundreds and thousands of volts, there are additional unavoidable and non-intuitive issues of material characteristics and electrical phenomena that show that design and construction for these voltage levels is a very different world.

Part 2 of this blog will look at how clever schemes based primarily on diodes and capacitors are used to develop those much-higher voltages using voltage multipliers.

References:

• Flyback converter, Wikipedia
• Cockcroft-Walton voltage multipliers, Wenzel Associates (via TechLib)
• Charge Pumps: The Forgotten Converter, Texas Instruments
• Switched Capacitor Voltage Converters, Analog Devices

—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 and signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing, and he also developed significant mechanical-engineering insight while designing control electronics for large materials-testing systems.

Related Content

• High-Voltage Design: Living Long and Still Prospering
• Pulsed high-power systems are redefining weapons
• Learning to like high-voltage op-amp ICs
• Rich voltage, poor voltage: My incandescent tale

The post Creating higher voltages, part 1: Voltage boosters appeared first on EDN.

Infineon Technologies AG of Munich, Germany is to deliver silicon carbide (SiC) power devices to US-based intelligent power management company Eaton Corp for use in its medium-voltage solid-state transformer (MVSST) 2.0 platform designed for deployment across the Asia-Pacific (APAC). The collaboration helps to increase the efficiency and reliability of the power conversion required to connect AI data centers to the electricity grid. It targets 800V direct current (VDC) data-center power distribution architectures...

We emulate the TDG series remote controls using the GSM Shield.

It was not long ago that we presented our GSM shield for GSM/GPRS modules from SIMCom, QUECTEL, FIBOCOM and others, designed to be embedded in Arduino-based projects that involve cellular connectivity; now the time has come for the first practical application, which in this specific case means replicating the operation of the TDG133 bidirectional GSM remote control, published back in issue no. 148 of July 2010, which lets you manage two relay outputs and two voltage-level inputs. For the occasion we developed a set of commands useful for setting the basic functions both by sending SMS and by sending commands through the serial monitor of the Arduino IDE. Both the electronics and the firmware development are based on the Arduino Mega 2560 or Fishino Mega 2560 board. This is for reasons of available Flash and SRAM memory for the application, but above all for the availability of free I/O pins for developing the project.

The platform on which we will develop our application is the Arduino Mega 2560, widely supported by the GSM shield, since it is the only one able to provide the set of I/Os needed to manage the input and output signals; specifically, the application proposed here requires:

• two I/Os to manage the digital outputs, at least in the basic application, though the project supports up to eight digital outputs and therefore considers the use of eight I/O lines;
• two I/Os to manage the digital inputs, which can be configured to work as active high, active low or on change; in reality up to eight input lines are made available;
• as for the indicator LEDs, those already present on the GSM demo board are used.

For the operating logic we refer to the TDG133 remote control, whose functions we will replicate as far as the available hardware allows. Let us recall that the TDG133 is a bidirectional remote control module that lets you check remotely the state of two relay outputs, in bistable or monostable mode, by sending suitable SMS messages completed with a password. It also lets you acquire the state of two optoisolated inputs.

The commands can come from telephone numbers stored in a list of a maximum of eight numbers, to which the device sends SMS messages and voice calls when it considers the digital inputs to be triggered, based on the settings made during configuration. The TDG133 remote control can also work as a gate opener, a mode to which up to 200 telephone numbers can be associated.

Hardware block diagram

Once we have established what the TDG133 did, we also know what our project has to do, since it must emulate that system using Arduino or compatible hardware. The block diagram in Fig. 1 gives an idea of the electronics our GSM Shield-based remote control is made of.

Like the TDG133, this remote control also provides two digital inputs and two relay outputs. In our application we make available up to eight digital inputs, which can be active high or low, and eight digital outputs useful for driving up to a maximum of eight relays; in reality this availability is hardware, because the current firmware of the Arduino Mega 2560 only allows two digital inputs and two digital outputs to be managed, and anyone who wants to use all 8 lines will have to work on the code.

The block diagram highlights the logic with which the application was developed.

• The Shield Telecontrollo board, highlighted with a green square, is mounted on the GSM Shield, which in turn is plugged into the Arduino Mega 2560.
• The Shield Telecontrollo provides up to eight digital inputs and, by means of board-to-board jumpers, it is possible to select whether the input is active at logic high, in which case the pull-down must be inserted, or active at logic low, in which case the pull-up must be inserted. The event can be generated by bringing the desired input to GND or to +5Vdc. To do this you can use the usual laboratory jumper wires such as code “7300-JUMPER50”.
• The Shield Telecontrollo provides up to eight digital outputs with which the boards with two, four or eight relays can be controlled; these boards all mount relays with a +5V coil voltage. In this case we refer to the products “2846-RELAY2CH”, “2846-RELAY4CH” and “2846-RELAY8CH”. Jumper wires must also be used to connect the relay boards.
• Power to the Shield Telecontrollo can come either from the Arduino Mega 2560 via a USB type B cable, or from the micro-USB socket of the GSM Shield, via a micro-USB cable.
• The connection via USB type B cable also allows the Arduino Mega 2560 board to be programmed, as well as sending the configuration commands through the serial monitor of the Arduino IDE. Through the monitor you can also receive information on the state of the events intercepted during operation, SMS sending and receiving, etc.
• If you want to monitor the AT commands sent by the Arduino Mega 2560 to the GSM module, you can use the usual USB/TTL converter (code FT782) connected to the special connector present on the GSM Shield. The FT782 electronics also allow 5Vdc power to be brought to the GSM Shield.

Circuit diagram

The circuit diagram of the GSM Shield has already been published in issue no. 231, so here we will only describe the circuit of the Shield Telecontrollo, whose circuit diagram is shown in these pages; it is something very simple that takes the connections of port PA0÷7 of the Arduino Mega 2560 and, via on-board jumpers, distributes them for managing the digital output lines used to drive the relays. It also takes the signals of port PL0÷7 of the Mega 2560 for managing the digital input lines. These lines are all on the 36-pin connector (18 pins x 2 rows) of the Arduino Mega 2560, to which the six LEDs mounted on the Shield Telecontrollo and intended for general purposes are also connected (Port PC0÷7).

As for the digital inputs, it is possible to set whether they must be active with a high or low logic level. The operating mode is selected via jumpers (J1÷8), and in particular if the jumper is inserted in position 1-2 the 10 kohm pull-up resistor is inserted and therefore the input is active low, while if the jumper is in position 2-3 the 10K pull-down resistor is inserted and therefore the input is active high.

For each input a contact point has been provided on connector CN5, to be used, via jumper wires, to activate the corresponding input, that is +5V if active high or GND if active low. We have therefore provided two more connectors of 8 poles each, labelled CN1 and CN2, to which we have brought the +5Vdc and GND lines respectively. In this way, for each of the eight inputs there is a corresponding +5Vdc or GND point to be used for simulating the change of state on the input.

As for the outputs, these have simply been brought to connector CN4 together with the +5V and GND lines needed to power the auxiliary relay boards to be used for this application.

To complete the demo board we have also brought out the free lines present on the many other connectors of the Arduino Mega 2560, so as to give the end user the possibility of using the function associated with them. All the lines already occupied for managing the GSM board are not brought out.

In order to make the demo board more versatile we have also provided a section on the PCB that acts as a prototyping development area where users can mount components of their choice to develop their own applications. The pitch between one pad and the next is the usual 2.54mm. This area provides over 315 single pads free of potential, plus a smaller set of pads to which the +3V3, +5V and GND lines have been brought.

Practical construction

For the project you need to prepare the Shield Telecontrollo, that is, make the relevant printed circuit board starting from the copper-side traces available for download together with the project files. During the assembly of the few components present, it is advisable to start with the 0603 SMD resistors and then move on to the 3-pole jumper connectors, followed by connectors CN1, CN2, CN4 and CN5. Finally, mount and solder the board interfacing connectors, namely CN3, CN6, CN8, CN10, CN12, CN14 and CN15.

With these, the assembly of the prototype board is complete; all that remains is to mount it on top of our GSM board and move on to implementing the sketch to be loaded into the ATmega 2560 microcontroller of the Arduino Mega 2560.

Assembly plan

Component list:

• R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16: 10 kohm (0603)
• CN8, CN10, CN12, CN14, CN15: 8-way Arduino strip (5 pcs.)
• CN6: 10-way Arduino strip (1 pc.)
• CN3: 2×18-way Arduino strip (1 pc.)
• CN1, CN2, CN5: 8-way male strip (3 pcs.)
• CN7: 10-way female strip (1 pc.)
• CN9, CN11, CN13, CN16: 8-way female strip (4 pcs.)
• CN4: 10-way male strip (1 pc.)
• J1, J2, J3, J4, J5, J6, J7, J8: 3-way male strip (8 pcs.)
• Miscellaneous: jumpers (8 pcs.), printed circuit board, the sketch

The architecture our application is based on makes use of the EEPROM built into the ATmega 2560 to store a set of parameters, including the SMS messages to be sent in the event of an alarm, and of the SIM memory, inserted in the GSM module, to store the phone numbers authorised to manage the remote control system.

We made this distinction because, although it is quite large, the EEPROM of the ATmega 2560 is not big enough to store all 208 phone numbers that the remote control can handle. We therefore decided to use the memory provided by the SIM to store the phone numbers in the phonebook, together with their description, just as you do on ordinary mobile phones. This approach also gives us the opportunity to show how to use the library functions created for handling the AT commands needed to read, write or delete the phonebook.

Two sketches in a single file

With that brief introduction out of the way, we can start describing how the sketch containing the remote control management code is structured. First of all, note that the code actually contains not one but two sketches, which obviously do not run at the same time. This is possible thanks to a compiler directive that lets us choose whether to use the code that programs the factory parameters into the EEPROM of the ATmega 2560 or whether to activate the remote control management code. The directive that lets us select which sketch to run is the following:

#define WRITE_DEFAULT_DATA_EEPROM

This directive is found at the top of the file “GSM_TDG133.ino”. When this directive is commented out, the remote control code is compiled and executed; otherwise, the code that programs the default parameters into the EEPROM memory is compiled and executed. The parameter programming code does not reset the phonebook on the SIM inserted in the GSM module. Deleting any phone numbers present in the phonebook is done by sending specific command strings, which are interpreted and handled by the remote control code, which in turn sends the appropriate AT commands to delete one or all of the contacts on the SIM.

The EEPROM map

The code that handles programming the factory parameters into the EEPROM is found in the file “_SetupEeprom.ino”, where at the top we find, in table form, the map of the EEPROM memory showing where the data is stored and how much space it takes up.

This map is designed to handle the text of the two input alarms (Input 1 and 2) and their related management parameters, as well as enabling/disabling SMS sending to the first eight numbers in the phonebook. Let’s look at the map in Fig. 2. As you can see, there is room left to add new text messages in case you decide to expand the input section from two to eight inputs in total.

The programming flow-chart

Fig. 3 shows the flow chart of the EEPROM programming sketch, with the steps described below in sequence:

• Using dedicated library functions, the starting addresses in EEPROM are obtained for handling the PIN, PUK, etc. codes used by our GSM module library; looking at the EEPROM map table, you can see that these codes are at the top.
• This is followed by another library function to enable the serial port used for debugging. That is, the serial port that lets you, through the Arduino IDE serial monitor, receive a series of information from the running sketch and possibly send command strings to the sketch.
• Before setting the default values, a function is executed that resets the contents of the EEPROM memory, that is, it sets to 0x00 all memory locations that hold a value other than zero.
• The setting of the factory parameters then begins with writing the PIN, PUK, etc. codes.
• This is followed by the function that stores the system password (default value “12345”).
• This is followed by saving the flags.
• Finally, the strings used for sending SMS messages are stored.
• The system waits two seconds and then performs a full read-back of the whole EEPROM to verify that its contents match the factory values just programmed; first the default parameters are printed on the serial monitor in string format with a short description of the contents, followed by a read-back of the EEPROM and its printing on the serial monitor in hexadecimal + ASCII format.

The contents of the EEPROM

As you can see in Fig. 2, at the top of the EEPROM contents are the PIN, PUK, etc. codes needed by our GSM library, followed by the system password (EEPROM starting address: 0x0050). Finally, the strings to be used for sending SMS messages are shown. Below the data shown, the entire contents of the EEPROM memory are then reported, from address 0x0000 up to address 0x0FFF. Now, if the directive:

#define WRITE_DEFAULT_DATA_EEPROM

is commented out, the main sketch containing the remote control code is compiled and executed, and we will now analyse it.

Initialisation: void setup()

Let’s go back to the flow diagram in Fig. 3 and study it starting from the “void setup()” function, which is used to initialise the GSM library and to pre-load into memory a series of parameters stored in EEPROM. So during initialisation:

• using dedicated library functions, the starting addresses in EEPROM are obtained for handling the PIN, PUK codes used by our library;
• timer 5 is configured, used by the sketch to handle time variables such as the timers used for debouncing the digital inputs, timeouts for handling waiting times, etc. (the time base used for the timer is 2 ms);
• the digital inputs used to implement the sketch are configured;
• the digital outputs used to implement the sketch are configured, as well as the digital outputs used by the GSM library to handle the LEDs connected to it;
• the test routine on the LEDs present on the GSM Shield is executed;
• the interrupts used by the GSM library for its correct operation are set;
• the UART interface used for debugging via the Arduino IDE Serial Monitor is enabled and configured;
• the UART interface used for sending AT commands to the GSM module is enabled and configured;
• the GSM module is powered on and the state machine needed for its correct management is started.

This is followed by reading from EEPROM the parameters used in the sketch, such as:

• system password; default value “12345”;
• system flags, including enabling alarm notification SMS messages and related voice calls;
• inhibition times for the digital inputs;
• observation times for the digital inputs;
• maximum number of SMS messages to send in the event of an input alarm;
• phone number to which ECHO SMS messages are sent;
• gate opener function timeout.

Also during initialisation, the initial state of the alarm digital inputs is set, along with the setting of all the state machines used to manage the sketch and its related functions. Once initialisation is complete, the system enters main and the contents of the “void loop()” function are executed endlessly.

The main loop: void loop()

The following are therefore executed:

• reading the state of the alarm digital inputs and their debouncing;
• handling the functions associated with the alarm digital inputs;
• handling the digital outputs used to control the relays;
• handling the state machines related to the GSM library, both during the GSM module initialisation phase and during normal operation for sending the AT commands needed for the sketch to work.

All the functions and state machines that manage every feature offered by the remote control system follow:

• commands for configuring the remote control system sent through the serial monitor;
• commands for configuring the remote control system sent by SMS;
• sending SMS messages according to the event that was logged;
• placing a voice call according to the event that was logged;
• handling the ECHO function, if enabled;
• handling the gate-open functions;
• handling the LEDs according to the event that was logged.

Managing the GSM state machine

In detail, let us examine how the function “void ProcessStateMachineGsm(void)” works. At the top of the function we have the code, already used in the past, for managing the GSM library and its features, which, through an “if – else” conditional construct, determines whether it is running the initialization of the GSM module or whether it is up and running and therefore ready to process the AT commands sent by the sketch to the GSM module. So, looking at the block diagram, if initialization is running, all the code downstream of the conditional block will not be executed.

Once initialization is complete, the process can then move forward and process the library functions for handling the AT commands needed by the sketch, plus all the other functions needed to build the application under examination. Below is the code that distinguishes the initialization process from the steady-state process:

Gsm.ExecuteUartState(); if (Gsm.GsmFlag.Bit.GsmInitInProgress == 1) { Gsm.InitGsmSendCmd(); Gsm.InitGsmWaitAnswer(); } else { Gsm.UartContinuouslyRead(); Gsm.ProcessUnsolicitedCode(); Gsm.GsmAnswerStateProcess(); **** User code used to develop the sketch **** }

As you can see, the “if – else” construct contains a series of library function calls, one of which is always called because it sits outside the “if – else” construct, namely “Gsm.ExecuteUartState();”, which handles the state machine of the serial communication between the Arduino Mega 2560 and the GSM module mounted on the board. The other functions depend on the value taken by the flag “Gsm.GsmFlag.Bit.GsmInitInProgress”. Part of the user code, depending on what has to be done, can be placed inside the “else” section. Usually you put there all those functions that need to send an AT command to the GSM module and therefore must necessarily be executed once the system has reached steady state and not before.

Registering the first phone number

Let us continue with the analysis of the flow chart; once initialization has been passed, we find ourselves having to handle a series of possible situations, including the first incoming voice call for registering the first phone number in the list. On startup, the sketch scans the SIM phonebook looking for a valid phone number in the first memory location. If it finds nothing, for five minutes it waits for an incoming voice call, from any number, which will be registered in the phone book as “ADMIN”.

It is not mandatory, but it is always good practice to register a phone number in the phone book paired with a descriptive text, because when you receive SMS messages or incoming voice calls the GSM module will automatically return a text string starting with “+CLIP” to tell us whether the phone number is present in the phone book or not. If the string, in addition to the phone number, also contains the paired description, we have confirmation that this number is registered. With this information it then becomes easy to establish which memory location the number is in, to understand whether it is one of the first eight or whether it is instead one of the phone numbers with gate-open function only. Receiving an “Unsolicited Result Code” from the GSM module depends on the type of configuration that our library adopts during module initialization, otherwise such information would not be received (AT+CRC and AT+CLIP commands).

The yellow LEDs LD6 and LD7 blink alternately while waiting for the first incoming voice call. If the five minutes expire before a voice call arrives, the system enters steady state and, to configure the phone numbers in the phone book, you will use dedicated string commands to be sent either by SMS or through the serial monitor.

Generic and specific AT commands

Once the test on the need to wait for the first phone number has been passed, the system finds itself processing functions whose purpose is to send AT commands to the GSM module under certain conditions. Let us see which ones: the general-purpose AT commands sent continuously to the GSM module with a one-second pause between one command and the next. These AT commands are meant to acquire a series of pieces of information from the GSM module, which are useful to the system for its operation. The flow can be interrupted when events occur, such as an alarm or something else, that require other, higher-priority AT commands to be sent. The generic AT commands used are:

• AT+CREG → GSM network registration information;
• AT+CSQ → GSM signal quality information;
• AT+CPAS → GSM module status information (used to know whether it is busy or not);
• AT+COPS → telephone operator information;
• AT+CPMS → incoming/outgoing SMS storage preferences;
• AT+GMI → information on the GSM module manufacturer;
• AT+GMM → GSM module model information;
• AT+GMR → information on the FW revision loaded in the GSM module;
• AT+GSN → IMEI code;

There are also specific AT commands sent following the sending of command strings. For example:

• AT+CPBR → AT command for reading a memory cell of the phone book;
• AT+CPBF → AT command for searching for a phone number in the phone book;
• AT+CPBW → AT command for writing/deleting a phone number in the phone book;
• AT+CMGD → AT command for deleting an SMS from the SIM memory.

The sketch’s notification functions

Next comes the portion of code for handling the command strings needed to configure the remote control system, sent both from the serial monitor and by SMS. The sendable strings (which we will present shortly) are the same regardless of whether they are sent through the serial monitor or by SMS. After that we have a series of conditional blocks in order to check whether particular functions made available by the sketch should be executed if properly configured and enabled. In particular we have:

• sending, if enabled, of the SMS at system power-up (power return); this feature must be enabled by a dedicated command string and the SMS content can be the default one in EEPROM or a string programmed by the user through a dedicated string command;
• sending, if enabled, of the start-up SMS; this feature must be enabled by a dedicated command string; the content can be the default one stored in EEPROM or a different string programmed by the user through a dedicated string command;
• sending of alarm SMS messages according to the state of the digital inputs; the content of the SMS to be sent can be configured by users through a dedicated string command; alarm SMS messages can be sent only to the first eight numbers in the phone book, provided the number has been enabled to receive such an SMS (besides sending an alarm SMS to the first eight numbers in the phone book, the system, if enabled, can also place a voice call to those numbers if they are enabled);
• sending of a report SMS containing the state of the inputs and outputs (this feature must be programmed);
• – enable/disable the function with a dedicated command string;
• – set how often the report SMS must be sent;
• – the message is sent only to the first number in the phone book;
• sending of ECHO SMS. If this function is enabled, all received SMS messages that have no relation to the command strings used by the remote control system will be sent to a previously selected number in the phone book;
• sending of reply SMS messages to command strings sent by SMS;
• finally, the functions for processing incoming SMS messages and any incoming voice calls follow.

How the sketch files are organized

What has just been described is the backbone of the sketch we have built, which, as usual, is split into several files, described below.

• GSM_TDG133 → main file containing all the variable and constant declarations, compiler directives, string commands stored in the microcontroller Flash memory together with their unique numeric codes, the text strings used for printing to the serial monitor, and so on, as well as the functions “void setup()” and “void loop()”.
• AT_CmdFunction → file containing the code that handles the generic AT commands used in the sketch and manages the functions of the GSM library;
• DigitalInput → file containing the code for handling the digital inputs;
• DigitalOutput → file with the code for handling the digital outputs (relays);
• OutComingSmsVoc → file with the code for handling outgoing SMS messages and voice calls;
• ProcessStringCmd → file containing the code that decodes the string commands received from the serial monitor or via SMS;
• SerialStringCmd → file with the code for handling the strings received from the serial monitor or via SMS;
• TimerInt → file containing the code for handling TIMER 5, used for the time variables the sketch needs;
• _SetupEeprom → file containing the code that handles programming the factory configuration of the EEPROM.

Splitting the code across several files also keeps it tidier and lets it be divided into well-defined sections.

Conclusions

Well, that is all for now; in the next and final instalment we will look more closely at the programming aspects, explain how to use the commands and their syntax, and finish by describing the indications given by the LEDs on the GSM Shield.

Related products

• GSM/GPRS SIM900 Shield for Arduino
• Pack of 50 Female-to-Female Jumper Wires – Assorted Colours
• 2-Relay Module 5 Vdc 10A (assembled)

The post GSM remote control: the GSM Shield for SIMCom and Quectel modules (part 1) appeared first on Open Electronics.

Gallium nitride (GaN) and silicon carbide (SiC) power semiconductor firm Navitas Semiconductor Corp of Torrance, CA, USA has been awarded the ALATTIS (Accelerated, Large-Area, 10kV SiC IGBT) program to develop next-generation 10kV silicon carbide (SiC) power semiconductor technology...

Firehat is an open-source HAT that brings native IEEE 1394 FireWire to boards such as the Raspberry Pi 5 and the Radxa ROCK 2F. It adds an i.LINK/DV port to modern SBCs, eliminating the need for older computers. The board uses the VIA VT6315N controller and connects through the 40-pin GPIO header and the PCIe FFC connector. In this way, Firehat becomes a bridge between the DV world and digital storage.

The project solves a real problem: MiniDV and HDV camcorders use FireWire, but modern computers no longer have that port. Firehat fills the gap with a compact, open-source solution. The board measures 56 x 70 x 12 mm and weighs just 25 grams. It costs $79, a reasonable price for anyone who needs to digitize precious tapes.

How Firehat works

Firehat uses two separate connections on the SBC. The 40-pin GPIO header provides power and handles the OLED, buttons, LEDs, and buzzer. The PCIe FFC connection, on the other hand, carries FireWire data between the VIA VT6315N controller and the board. On Linux, Firehat appears as a standard PCIe FireWire controller, using the kernel’s FireWire stack.

DV capture is handled with open-source tools such as dvgrab and dvcont, or with the Equip-1 software stack for a standalone recorder interface. FireWire device control allows you to play, stop, rewind, and trigger captures via software. In addition, libavc1394 support enables reliable communication with camcorders.

For those who want to build the project themselves, you need an SBC with a PCIe FFC connector. The board with the Raspberry Pi 5 is the most common choice, but the Radxa ROCK 2F also works well. Firehat also includes a 1.3-inch OLED display and SK6812 RGB LEDs for status. Everything mounts in a compact case with accessible connectors.

Why digitize with FireWire

MiniDV, Digital8, DVCAM, DVCPRO, and HDV camcorders record to tape. Without FireWire, recovering those videos is a nightmare. Firehat lets you capture the digital DV stream directly to local storage without any quality loss. The DV stream is already digital, so no analog conversion is needed.

The project is designed for makers and archivists. Thanks to Linux support, captures can be automated with scripts. For example, you can rewind the tape, start recording, and stop at the end, all from the command line. Additionally, a 128×64 OLED display shows capture status in real time.

Firehat is not just an adapter; it is a true FireWire controller. The VIA VT6315N chip handles the IEEE 1394 protocol at the hardware level, while the software takes care of the rest. The 30 cm PCIe FFC connection ensures flexibility in mounting. The result is a stable and fast board, suitable even for long capture sessions.

What you need to get started

To use Firehat you need only a few items. Here is the essential list:

• An SBC with a PCIe FFC connector, such as the Raspberry Pi 5 or Radxa ROCK 2F
• Firehat with VIA VT6315N controller and OLED display
• A FireWire camcorder with DV or HDV tape
• Linux with FireWire stack and dvgrab, dvcont, or Equip-1 tools

Assembly is simple: connect Firehat to the GPIO and the PCIe FFC, then boot the SBC. On Linux, the controller is recognized automatically. Finally, run dvgrab to start capturing. No hardware modification to the camcorder is required.

Firehat is available for $79 and the design is open-source, so you can also study the project. An SPI 256×64 OLED display can be added for richer interfaces, but the included 1.3-inch one is enough for most uses. The board is robust and well documented.

In conclusion, Firehat is the modern solution for those with legacy camcorders who want to save their footage. It combines open-source hardware, Linux software, and an accessible price. For anyone working with video archives, it is an indispensable tool.

Source: https://github.com/computerequipmentgroup/firehat

The post Firehat: Bringing FireWire to the Raspberry Pi 5 appeared first on Open Electronics.

As automotive, AI/data centre, networking and industrial systems rapidly transition to 48V power architectures to improve efficiency and support higher power demands, designers require more than visibility into instantaneous voltage and current conditions. They also need systems that can track energy consumption over time and respond to changing power conditions. To address these requirements, Microchip Technology has introduced the PAC1761 and PAC1861 families of 65V energy-aware digital power monitors. The devices combine accumulated energy-measurement capabilities with 65V measurement headroom and transient spike protection to support efficient and resilient 48V power architectures.

The move to 48V power architectures requires digital power monitors to provide additional operating margin, including up to 65V measurement capability and 75V spike protection to ensure transient survivability. The PAC1761 and PAC1861 devices add intelligence to these capabilities, enabling real-time responses to energy-usage dynamics based on accumulated power measurement data.

“The industry conversation is shifting from measuring power at a single point in time to understanding and responding to energy behavior across an entire system and its lifecycle,” said Keith Pazul, vice president of Microchip’s mixed-signal linear business unit. “The PAC1761 and PAC1861 families are designed to help customers build better performing and more reliable 48V systems that can measure instantaneous conditions and understand energy consumption and availability over time. These scalable, low-power solutions reduce monitoring overhead and include pin-compatible package options that improve source flexibility while reducing design risk.”

Microchip’s digital power monitoring devices feature programmable alerts for voltage, current and power excursions, step-limit detection to identify sudden load changes, and configurable accumulated-energy thresholds that enable proactive system management based on both instantaneous and long-term power behavior.

Target applications include automotive, AI/data center, networking, industrial, server, telecom/Power over Ethernet (PoE) and 48V power distribution systems. The 12-bit PAC1761 and 16-bit PAC1861 options are available in VDFN-8 (similar to SOT23-8), VDFN-10 and MSOP-10 packages including automotive-orderable variants. Pin-compatible options can reduce redesign risk, shorten qualification cycles and give customers flexibility to move between devices as requirements, availability, cost or performance change.

Development Tools

Development support includes evaluation board EV12R33A, a Python Command Line Interface (CLI) with library, Linux driver and generic C library with multiple MCU code examples.

The post Microchip Launches 65V Digital Power Monitors for Smarter 48V Power Systems appeared first on ELE Times.

Modern RTL verification flows generate more evidence than engineers can always review with equal priority. Simulation, assertions, coverage, and formal analysis each expose different classes of behavior, but a large design can produce hundreds or thousands of properties.

This article describes an AI-assisted workflow that uses machine learning to prioritize those properties while leaving proof and counterexample generation to the formal engine. The approach is intended to complement, not replace, established SystemVerilog, Universal Verification Methodology (UVM), simulation, and formal verification practices.

The problem: too many properties, too little verification time

Verification teams face a practical allocation problem. A complex subsystem may include control-state logic, FIFO interfaces, arbitration, multiple clock domains, configuration registers, error handling, and protocol checks. Each area can generate assertions, and each assertion can have a different verification cost and value. Some properties prove quickly. Others expose difficult corner cases or consume substantial solver resources.

Simulation remains essential because it exercises realistic scenarios, software interactions, coverage goals, and system-level behavior. Formal verification offers a different capability: it can prove or disprove a specified property over the modeled state space under explicit assumptions. Formal methods therefore complement simulation rather than simply compete with it.

The remaining question is operational: when a verification environment contains a large property set, which properties should receive attention first? Engineers normally answer this using design knowledge, coverage, previous failures, proof history, and experience. As designs grow, an automated way to organize that evidence becomes attractive.

AI as a prioritization layer

Machine learning has become an active research area in electronic design automation, including hardware design and verification. For formal verification, the most useful role may be narrower than asking AI to determine whether a design is correct. AI can instead act as a prioritization layer in front of the formal engine.

The model can assign a priority to each property using features such as RTL hierarchy, number of referenced signals, control and data dependencies, state-machine complexity, clock relationships, previous proof duration, coverage gaps, prior failures, and related assertions. The output is a recommendation about verification order, not a proof result.

A five-stage workflow

The workflow can be organized in five stages: RTL and property analysis, feature extraction, AI-based property ranking, formal execution, and feedback.

Figure 1 Here is a broad view of the five-stage AI-assisted formal verification workflow. Source: Author

1. RTL and property analysis: Collect the RTL, assertions, hierarchy, interfaces, assumptions, and available verification metadata.
2. Feature extraction: Convert verification information into features that describe structural complexity, dependencies, coverage, history, and proof behavior.
3. AI-based ranking: Use one or more machine-learning models to estimate which properties may provide useful verification information earlier.
4. Formal execution: Run selected properties in the formal engine, which produces the authoritative proof result or counterexample.
5. Feedback: Feed proof results, counterexamples, and verification history back into the prioritization process.

Why use more than one model?

A single machine-learning model may not capture every relationship in a verification dataset. A hybrid system can compare recommendations from multiple models and look for agreement. If several models independently place a property near the top of the queue, the system can treat that agreement as a scheduling signal.

This does not make the prediction a formal result. The distinction is important. Machine learning estimates where verification effort may be useful; formal verification establishes whether the selected property holds under the specified assumptions.

Figure 2 In this illustrative AI-assisted property prioritization, scores are conceptual and are not measured results from a specific project. Source: Author

Counterexamples can become verification feedback

A formal counterexample contains more information than a pass/fail label. It can expose a state transition, control path, boundary condition, protocol sequence, or assumption associated with failure. A verification workflow can use those observations to identify related properties that deserve attention.

For example, consider a hypothetical subsystem with a FIFO, arbitration logic, and two clock domains. Suppose a clock-domain property receives high priority because it involves multiple clocks, has limited simulation coverage, and is related to previous failures. If formal analysis produces a counterexample, the system can increase the priority of other properties that share the affected control or clock-domain path.

This is a feedback mechanism, not autonomous verification. The engineer still determines whether the property is correctly formulated, whether assumptions are valid, and whether the resulting evidence is sufficient.

Working with UVM and simulation

The AI layer does not require a new verification environment. Existing SystemVerilog and UVM infrastructure already produces useful information, including test results, functional coverage, assertion status, regression history, and debug information.

Figure 3 UVM and simulation data have been integrated with AI analysis, formal verification, and engineer review. Source: Author

Simulation can provide scenario coverage and failure information. UVM can provide structured testbench and regression data. The AI layer can organize these signals and recommend formal priorities. The formal engine can then produce proofs or counterexamples. This division lets each part of the flow retain its established role.

• Review low-confidence or strongly disagreeing model recommendations manually.
• Keep AI priority, formal status, and signoff status as separate fields.
• Record the features and model version that produced each recommendation.
• Make sure that critical properties are protected by explicit rules.

In a continuous-integration environment, the loop can run after an RTL change: identify affected properties, update their features, generate priorities, execute selected formal jobs, collect results, and store the new evidence. The next run can then use that history. The result is a practical feedback loop that fits around existing verification infrastructure instead of requiring a separate verification methodology.

The scheduler should also enforce engineering rules outside the model. A property marked as mandatory for signoff should remain in the verification plan even if the model assigns it a low priority. Likewise, the system can reserve resources for regression baselines while using AI to order the remaining work. This makes the AI layer a scheduling aid rather than an uncontrolled gatekeeper.

For example, a property record might contain the number of referenced signals, hierarchy depth, number of state elements involved, clock-domain count, previous proof time, previous failure frequency, coverage status, and whether the property belongs to a critical interface or reset sequence. These features are useful because engineers can inspect them and relate them to the underlying design rather than relying on an opaque score.

The approach can be introduced without replacing the existing verification tool chain. A lightweight orchestration script can collect RTL and assertion metadata, regression results, coverage summaries, formal proof history, and counterexample information. The collected information can be normalized into one record per property. Each record can then be passed to a trained model or a small ensemble of models that returns a priority recommendation.

Turning the concept into an engineering workflow

Below is an illustrative property prioritization example.

Table 1 In this illustrative prioritization example, the entries demonstrate the method and are not experimental measurements. Source: Author

The main benefit is not that AI makes formal verification mathematically stronger. The benefit is that it can help organize verification work. A team can use prioritization to focus compute time on properties associated with complex control, weak coverage, previous failures, or other signals that indicate potential value.

The same idea can help with regression management. If a new RTL revision changes a particular control path, the system can identify related properties and move them upward in the queue. If a property repeatedly consumes large amounts of solver time without producing useful evidence, engineers can inspect its formulation and decide whether to refine it, decompose it, or change its assumptions.

What AI should not decide

AI-based prioritization introduces a new failure mode if engineers treat a low score as permission to ignore a critical property. The system should therefore preserve explicit criticality rules. Safety-critical, security-sensitive, interface, reset, and other signoff properties may require execution regardless of their predicted rank.

The workflow should also remain explainable. Engineers should be able to see which features influenced a ranking and distinguish between a property that was not selected, a property that timed out, and a property that was formally proven. These states carry very different meanings.

From verification execution to verification management

As IC designs become larger, verification teams need more than additional tests. They need ways to organize the evidence produced by tests, assertions, coverage, formal analysis, and debug. AI can provide one layer of that organization.

The practical model is therefore a division of responsibility. Simulation explores scenarios. UVM structures the verification environment. AI analyzes evidence and recommends priorities. Formal verification supplies rigorous proofs and counterexamples. Engineers interpret the results and make signoff decisions.

AI-assisted formal verification is most useful when it remains an assistant to established verification methods. Using machine learning to prioritize properties can help teams direct limited compute and engineering resources toward potentially informative checks, while formal verification remains the authority for proof and counterexample generation.

The approach does not require replacing SystemVerilog, UVM, simulation, or existing formal tools. It adds a layer that connects the evidence those systems already produce. With appropriate safeguards, that layer can turn verification history and counterexamples into feedback for the next analysis cycle.

Praveen Kumar Vagala is a semiconductor design verification professional and independent researcher with extensive experience in the semiconductor industry.

Related Content

• Introduction to Formal Verification
• Is Formal Verification Artificial Intelligence?
• Formal verification: where to use it and why
• Specifications: The hidden bargain for formal verification
• Formal Verification Moves Firmly into the Design Environment

The post Rethinking RTL flows with AI-driven hybrid formal verification appeared first on EDN.

Battery-swapping technology allows electric heavy trucks to replace a drained battery placed between the frame rails with a fully charged one at a charging station in just 5 to 10 minutes. Unlike conventional plug-in EV trucks, battery-swapping vehicles are designed with modular and removable battery packs along with the mechanical, electrical and communication interfaces required for rapid battery exchange.

Automated swapping equipment can then remove the depleted pack and install a charged one. Current heavy-duty EV examples in India demonstrate the growing adoption of this approach, with some systems completing a battery swap in less than five to seven minutes.

This battery-swapping technology is gaining attention in India’s EV transportation sector as manufacturers look for a better option to reduce electric vehicle charging downtime. It also provides an advantage of lower upfront costs because the battery is owned by a battery-swapping operator, allowing the customer to pay for battery use through a subscription.

This technology is now moving beyond the deployment phase towards a wider infrastructure network. In July 2026, Energy In Motion (EIM) and Hindustan Petroleum Corporation Limited (HPCL) announced plans to develop fast-charging and battery swapping stations for heavy EV trucks at specific HPCL petrol pumps or service stations. The partnership company (EIM) will establish swap-and-charge hubs along freight corridors including Mumbai-Pune, Delhi-Jaipur and Chennai-Bengaluru over the next 18 to 24 months.

The implementation of battery-swapping at a wider scale demonstrates that India is adopting modern technologies to provide faster and efficient charging solutions to the EV industry. The adoption of this technology at a very large scale will depend on several factors such as battery standardisation, station availability, interoperability, fleet economics, and the development of reliable freight-corridor infrastructure.

The post Battery Swapping for E-Trucks Gains Momentum: India Builds Heavy-Duty EV Infrastructure appeared first on ELE Times.

​The demand for electric vehicles is continuously rising in India. Government and charging companies are making continuous efforts to make charging easy for consumers by expanding charging infrastructure and improving charging efficiency. But increasing the number of chargers alone is not sufficient to provide a reliable charging experience.

A new report from the Institute for Energy Economics and Financial Analysis (IEEFA) found that charger reliability, interoperability, charging cost, home-charging challenges and delays in grid connection are rising problems affecting EV charging in India. The report was published on September 16, 2026.

In the early stages of EV adoption, vehicle range was a major focus for manufacturers and consumers. As EV sales and charging infrastructure continue to expand, attention is increasingly turning​to the reliability and accessibility of charging infrastructure. A charging station is useful only when it is operational and available when an EV user needs it.

Network interoperability is another growing concern, as different charging networks may require separate apps, accounts or payment systems, making it less convenient for users to access and pay for charging across different locations. IEEFA has identified charger reliability and interoperability among charging networks as key factors that need to be addressed to improve India’s EV charging experience.

As India’s charging network continues to grow, the next stage of development will therefore depend not only on deploying more chargers but also on improving their reliability, interoperability, affordability and integration with the electricity grid.

The post EV Charging in India: Reliability and Interoperability Emerge as Key Challenges appeared first on ELE Times.

As manufactures and battery material companies are searching for increasing energy density and improve charging performance in electric vehicles, silicon-based anode technology that replace traditional graphite parts with silicon-based materials is gaining momentum in the electric vehicle (EV) battery industry. The advantage of adopting these technologies is that it holds significantly more lithium ions (up to 10 times more lithium per gram than standard graphite) to boost energy storage of an anode without increasing its size.

Although, this technology suffers from big challenges such as silicon undergo tremendous expansion once it absorbs lithium during charging. This expansion can destroy the anode and cause capacity loss over repeated charging cycles. Researchers have come up with the solution of using silicon-carbon composites to overcome this problem. By combining silicon with carbon based materials can accommodate the expansion to preserve the anode stability.

The technology has new completed its testing phase and is new ready to be implement toward large-scale manufacturing. Group14 Technologies, an American battery technology company, in March 2026 announced that its South Korea battery- material plant for silicon batteries has started production of its SCC55 material at the scale needed for EV batteries. The plant can produce up to 2,000 tonnes of silicon battery material per year, which should amount to about 10 GWh of energy-storage capacity annually once production reaches its planned level.

Australia is another major supporting commercialisation of this silicon-adopting material for energy storage. The Australian Renewable Energy Agency (ARENA) announced an award of $45 million to silicon battery technologies to build a commercial scale facility for advanced silicon-carbon battery material.

These developments put silicon-carbon anodes closer to commercialisation. If the manufacturers can overcome the issues of cost, cycle life, expansion and manufacturing scale, then the technology could contribute to higher battery energy density in future EV batteries, while allowing for faster charging.

The post Silicon-Carbon Anodes Move Toward EV-Scale Production for Higher Energy Density appeared first on ELE Times.

With the rise in the implementation of software technologies in Electric vehicles, the transition towards Software-Defined Vehicles (SDVs) is changing how electric vehicles are designed. Technologies in software-defined vehicles such as advanced automotive semiconductors, edge artificial intelligence (AI) and centralised computing are becoming key concepts in designing future transportation vehicles.

During electronica India 2026 held at Bangalore International Exhibition Centre (BIEC), Renesas Electronics showcased technologies related to SDVs, edge AI, EV charging and intelligent mobility. These technologies highlight the growing role of semiconductor-based computing in designing next-generation vehicles. At the event, Renesas demonstrated its newly designed 3nm multi-domain automotive SoC, the R-Car Gen 5 platform, highlighting features such as advanced driver assistance systems (ADAS), digital cockpit technologies and connected-vehicle solutions providing personalised functions and voice interfaces.

The platform combines high-performance automotive computing with AI capabilities and supports software-defined vehicle architectures. Edge Intelligence was another area of interest, where AI processing is being executed with the help of the vehicle’s sensors and systems instead of depending on cloud interface. Renesas demonstrated applications that support AI vision, autonomous and assisted driving for the driver, and embedded intelligence.

Edge AI can result in faster local responses compared to cloud connectivity and reduce the amount of sensor data that needs to be transmitted to external system. As EV architectures shift towards software-defined systems, the use of advanced automotive system-on-chip (SoC) platforms, edge AI, power semiconductors, and software platform will increasingly play an important role in vehicle computing, charging, connectivity, and smart mobility.

The post Software-Defined Vehicles and Edge AI Reshape Next-Generation EV Architecture appeared first on ELE Times.

SEMICON India 2026, the fifth edition of India’s flagship semiconductor conference, concluded on September 19 at Yashobhoomi, New Delhi, highlighting the country’s growing capabilities across the global semiconductor value chain. Held from September 17 to 19 under the theme “Silicon to Systems: Building the Ecosystem,” the three-day event brought together semiconductor companies, policymakers, investors, academia and start-ups.

The event featured more than 600 exhibitors, including around 300 international participants, with representatives from 52 countries and more than 150 speakers. Six country pavilions representing Japan, South Korea, Malaysia, the Netherlands, Singapore and Sweden, along with 12 state pavilions, showcased capabilities across different areas of the semiconductor ecosystem. The event recorded 51,656 registrations and around 40,000 cumulative footfall.

Prime Minister Narendra Modi inaugurated SEMICON India 2026 highlighting India’s progression from policy discussions and project planning to commercial semiconductor production. During the inauguration, the Prime Minister virtually inaugurated commercial production lines at CDIL Semiconductor in Mohali for discrete semiconductor devices and Suchi Semicon in Surat for semiconductor packaging. The two facilities added to India’s operational commercial semiconductor units under the Semicon 1.0 programme.

As a major outcome of SEMICON India 2026, a total of 56 MoUs, announcements and strategic initiatives were announced across areas including semiconductor design, fabrication, advanced packaging, equipment, materials, power electronics, AI, R&D, startups and talent development.

The post SEMICON India 2026 Concludes at Yashobhoomi, Showcasing India’s Growing Semiconductor Ecosystem appeared first on ELE Times.

Due to massive pool of specialised VLSI (Very Large Scale Integration) engineers, large number of Global Capability Centre (GCCs) presence and ongoing government support, India currently accounts for nearly 20% of the world’s semiconductor design workforce. This number highlights the India’s increasing role in global chip design and research. The statement of accounting 20% global workforce in semiconductor design was made by S. Krishnan, the MeitY Secretary on the side-lines of SEMICON India 2026 in New Delhi.

The government is prioritising the development of semiconductor design talent, said S. Krishnan. He said an ongoing programme is focused on training around 85,000 semiconductor design engineers, while skill-development efforts are also being expanded across the semiconductor value chain, with a strong focus on supporting semiconductor manufacturing in India.

The semiconductor design workforce will play an important in strengthening India’s position in the global semiconductor ecosystem. According to government data, India holds 7% of the world’s semiconductor-related Global Capability Centres (GCSs) along with Indian engineers continue to contributing to chip design, fabrication, verification and testing activities.

The government is taking action to move beyond design and improve semiconductor ecosystem by covering fabrication, advanced packaging, assembly and testing, semiconductor equipment and materials, research and development (R&D), and talent development. The recent organised event Semicon 2.0 has an outlay of ₹1,27,500 crore and is structured around six pillars which include design, machine, materials, advanced packaging, additional fabs, research, and talent.

There are different schemes supported by the government body encouraging semiconductor design which include Design Linked Incentive (DLI) Scheme and the Chips to Startup (C2S) Programme. The focus of these programmes is to train around 85,000 semiconductor design engineers. The initiatives are also aimed at strengthening India’s domestic chip-design capabilities and building a stronger semiconductor design ecosystem.

The post India Accounts for 20% of Global Semiconductor Design Workforce, Says MeitY appeared first on ELE Times.

India continues to focus on raising domestic value addition and further deepening domestic manufacturing in electronics industry. Moving beyond large-scale assembly towards deeper manufacturing and stronger local supply chains, S. Krishnan, the Secretary of the Ministry of Electronics and Information Technology (MeitY) made the statement that India is targeting 35-40% domestic value addition in mobile-phone manufacturing, up from the current level of about 22-23%. To achieve this number, different government schemes are giving support such as India Semiconductor Mission (ISM), mobile manufacturing, the Production Linked Incentive (PLI) for electronics hardware and the Electronics Component Manufacturing Scheme (ECMS).

The Electronics Component and Manufacturing Scheme (ECMS) is expected to play a major role by focusing on deep component-level manufacturing rather than basic assembly. Key areas include printed circuit boards, passive components, electrochemical components, subassemblies, camera module, optical transceivers, and critical equipment.

The government aims to wider the development of India’s semiconductor ecosystem by expanding capabilities across components, semiconductor manufacturing and other parts of electronics value chain. ECMS is designed to integrate Indian manufactures with global value chains and ISM supports semiconductor design, fabrication, advanced packaging, equipment and materials.

The 40% target in domestic manufacturing does not means that forty percent of the electronic devices to be made in India. It means if a device is selling in India, then its forty percent value must be manufactured within the country. This target reflect India’s deepen participation in global value chains by moving beyond final assembly, creating a deeper supplier ecosystem, reduce dependence on imported components, and moving towards complete manufacturing location. This will allow Indian factories to source more inputs locally while maintaining competitive cost, quality and scale.

The post India Targets 40% Domestic Value Addition in Electronics Manufacturing appeared first on ELE Times.