Feed aggregator

The DFRobot_RTU library brings the Modbus RTU protocol to Arduino. With a few commands you can read and write coils, discrete inputs, holding registers, and input registers. The source code is available in the official repository, which includes ready-to-upload examples.

Modbus RTU is a serial protocol widely used in industry. It runs over UART, so on Arduino you only need the TX and RX pins. The library handles the Modbus frame, CRC calculation, and exception codes. This lets the maker focus on the data rather than the protocol details.

Supported commands and registers

The library implements Modbus commands 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x0F, and 0x10. Command 0x01 reads coils, 0x02 reads discrete inputs, 0x03 reads holding registers, and 0x04 reads input registers. Commands 0x05 and 0x06 write a single register, while 0x0F and 0x10 write multiple registers. This covers all the main protocol operations.

Each Modbus device has an address ranging from 0x00 to 0xF7, that is, from 0 to 247. The library uses this address to route requests. It also sets a reception timeout with a default value of 100 ms. If the device does not respond within that time, the library reports the error.

• 0x01: read coils
• 0x02: read discrete inputs
• 0x03: read holding registers
• 0x04: read input registers
• 0x05: write single coil
• 0x06: write single holding register
• 0x0F: write multiple coils
• 0x10: write multiple holding registers

Wiring and configuration

Connecting the sensor to the microcontroller is straightforward. Connect VCC to 5V, GND to GND, RX to the TX pin of the UART, and TX to the RX pin of the UART. Mind the crossover: the sensor’s TX goes to Arduino’s RX and vice versa. Then set the device address in the code and choose the command to use.

The library includes functions to read and write single or multiple registers. It also handles Modbus exception codes, so you can immediately tell if the device rejected the request. To get started, the project repository contains basic examples with the configuration for each command.

To try the library you can use an Arduino Uno R4 Wi-Fi board. The hardware UART is available on pins 0 and 1, or you can use a SoftwareSerial on other pins. The library works with both modes. Additionally, if you want a module with built-in Wi-Fi, the ESP32-C6-Zero is a good choice for IoT projects that speak Modbus.

Before uploading the sketch, check the baud rate. The sensor and Arduino must use the same baud rate, otherwise communication fails. The library does not set the speed, so you configure it in the code. Modbus devices usually use 9600 or 19200 baud.

Once everything is configured, reading a register takes only a few lines of code. You call the read function, passing the device address, the register address, and the number of registers. The library builds the frame, sends it, and waits for the response. Finally, it returns the read data or an error code.

Source: https://github.com/DFRobot/DFRobot_RTU

The post Modbus RTU on Arduino with the DFRobot_RTU Library appeared first on Open Electronics.

Renesas Electronics Corporation, a leading supplier of advanced semiconductor solutions, has expanded its RZ/G series with new 64-bit general-purpose microprocessors (MPUs) aimed at HMI (Human Machine Interface) systems and IoT Edge applications. The RZ/G3L and RZ/G3SE devices are pin-compatible MPUs that support a wide range of industrial and consumer HMI systems, as well as IoT gateways and home gateways, characterised by high demands for processing power and high-speed network connectivity.

The RZ/G3L integrates a GPU (Graphics Processing Unit) for 3D graphics rendering, together with an H.264 video codec. This combination is ideal for applications such as smart retail terminals and medical devices with an HMI interface, which require advanced graphics and video capabilities. The RZ/G3SE, on the other hand, is designed for IoT devices with simpler display requirements, such as electric vehicle (EV) chargers and industrial gateways that provide status indications and configuration screens. Thanks to the pin-level compatibility between the RZ/G3L and RZ/G3SE, developers can reuse the same PCB design across different product variants, simplifying development and reducing time-to-market.

High performance with standby consumption in the order of 1 mW

The new devices deliver high processing performance thanks to a CPU cluster made up of up to four Arm® Cortex®-A55 cores running at up to 1.2 GHz, alongside a Cortex-M33 coprocessor running at 200 MHz. At the same time, the third generation of the RZ/G series adopts a proprietary power management architecture that significantly reduces energy consumption in standby. As a result, the new products can achieve consumption in the order of 1 mW in deep standby mode. The devices can remain in standby while keeping the Linux system in memory and quickly resume operation when needed. These power-saving features are particularly suited to industrial applications and IoT devices that require continuous, always-on connectivity.

High-performance connectivity to expand system functionality

Featuring high-speed interfaces such as PCIe, Gigabit Ethernet with TSN support and USB, the new MPUs allow developers to add application-specific functionality and advanced connectivity options. The PCIe interface supports connection to 5G communication modules, Wi-Fi 6 modules and even external AI accelerators. Gigabit Ethernet with TSN support enables low-latency, highly reliable communication, essential characteristics in industrial networks where real-time performance is a fundamental requirement.

“The growing sophistication of industrial and IoT devices requires solutions able to balance high performance, low power consumption, advanced connectivity and platform scalability,” said Hari Pendurty, Vice President of the EP Edge AI & Application Processors Business Division at Renesas. “RZ/G3L and RZ/G3SE were developed to help customers meet these constantly evolving requirements and to build product families more efficiently, leveraging a common hardware platform for different applications.”

An ecosystem rich in tools and resources to reduce development time

Thanks to an ecosystem made up of ten solutions, which includes GUI development environments, operating systems, software and SoMs, Renesas simplifies and accelerates application development. The company will continue to invest in expanding the ecosystem, offering an ever wider choice of hardware, software and tools that are already validated and ready to use.

• Graphics application development solutions: LVGL, Embedded Wizard, Slint, Candera, Spyrosoft, Qt Group
• Operating system solutions: Zephyr RTOS, Atmark Techno
• SoM solutions: Embedded Artists, a Virtium Company, Advanet

For information on other partners you can refer to the following link: Renesas Partner Program.

Technical specifications

• Main Arm Cortex A55 CPU available in dual-core or quad-core configurations
• Available in a 400-pin LFBGA package (14 × 14 mm) and a 368-pin LFBGA package (17 × 17 mm)
• ECC (Error Checking and Correction) protection on both integrated memory and the external DDR interface
• Advanced security features, including Renesas Secure IP, Secure Boot, Arm TrustZone and tamper detection
• Wide operating temperature range from -40°C to +125°C
• Verified Linux Package (VLP) compliant with the Civil Infrastructure Platform (CIP), for Long-Term Support (LTS).

Winning Combinations

Renesas has combined the new MPUs with numerous compatible devices from its product portfolio to offer a wide range of complete solutions. These include the Mode3 AC EV Charger Wallbox solution with high-level PLC communication, based on the RZ/G3L, and the AI-Enabled Smart Home Security Hub based on the RZ/G3SE, which enables advanced monitoring capabilities thanks to integration with cameras, microphones and sensors, as well as cloud connectivity. For further Winning Combinations you can visit the Renesas website: renesas.com/win

Availability

The RZ/G3L and RZ/G3SE devices are available today. An evaluation kit consisting of an SMARC v2.1 module board and a carrier board is also available for both products.

The post Renesas launches 64-bit RZ/G3L and RZ/G3SE MPUs for HMI and IoT Edge appeared first on Open Electronics.

This project builds a basic electronic door lock with the Arduino UNO R4 WiFi. A touch sensor detects contact, a relay controls a solenoid lock, and an OLED display shows the system status. The principle is simple: touch the sensor, the door unlocks for 5 seconds, then locks itself again. It is a starting point for customizable smart locking systems.

The central board is the Arduino UNO R4 WiFi, which manages the whole flow. The touch sensor sends a signal to the board, which activates the relay to power the lock. The 128×64 pixel OLED display shows the startup, locked, and unlocked screens. The system uses a relay module to separate the control circuit from the power circuit, so the solenoid lock operates safely.

The circuit and components of the lock

Assembly requires few components: the Arduino board, the touch sensor, the OLED display, the relay module, and a solenoid lock. Everything connects on a breadboard with jumper wires. The relay is essential because the lock runs at 12 VDC, while the Arduino operates at 5 V. Without the relay, the lock’s current would damage the board.

The OLED display connects via I2C, using the SSD1306 and Adafruit_GFX libraries. The 128×64 pixel resolution is enough to show the system status with clear characters. The touch sensor connects to a digital pin: when it detects a touch, it sends a high signal to the Arduino. The response is immediate, and the relay trips right away.

The firmware and unlock time

The code is written in the Arduino IDE and uses the SSD1306, Adafruit_GFX, and Adafruit_SSD1306 libraries. The sketch reads the touch sensor state and, when it detects a touch, activates the relay. The display shows the unlock screen for 5 seconds, then the system locks the door again. The unlock time is fixed at 5 seconds, but it can be changed in the code.

The operation is cyclic: startup, waiting, unlock, relock. The OLED display updates the status in real time, so you always know whether the door is locked or unlocked. The project demonstrates the principle of a basic electronic lock, and the maker’s website collects the details for replicating it. It is a simple but complete system.

For assembly you also need a universal acrylic support to keep the Arduino and breadboard tidy. 15 cm male-to-female jumper wires help connect the modules without soldering. The project can be expanded with a numeric keypad, an RFID reader, or a Wi-Fi module for remote control.

In short, this project is an excellent base for anyone who wants to understand how an electronic lock works. The components are few, the code is essential, and the result is functional. With the Arduino UNO R4 WiFi you also have the option to add connectivity in the future, turning the prototype into a real smart lock.

Source: https://srituhobby.com/how-to-make-a-solenoid-door-lock-system-using-a-touch-sensor/

The post Electronic door lock with Arduino UNO R4 WiFi and touch sensor appeared first on Open Electronics.

This is my project that I’ve been working on for the last two weeks. It’s called Kira04 AIRNODE. I currently 3D print in my small bedroom, and I have three printers running simultaneously, sometimes almost 24/7. I started getting worried about the VOCs they release, as well as the amount of heat they generate, so I came up with this project. Kira04 AIRNODE is basically a bundle of sensor modules that connects directly to the ventilation system I installed in my window. It helps me monitor and keep the temperature, humidity, and VOC levels in check while my printers are running. And yes, I know the wiring and soldering are pretty horrible 😅. There are wires everywhere right now. I actually tried making a custom PCB for it using my CNC mill a few times, but unfortunately both attempts failed pretty tragically 😂. At that point, I just wanted to get the project working, so I decided to finish it quickly with the current wiring. I’d love to hear any feedback or suggestions you have for improving it. I’m also trying to decide what to do with the project next: Should I open-source Kira04 AIRNODE, or do you think this could potentially become an actual product? submitted by /u/Next-Ad-5652 [link] [comments]

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

When you connect multiple sensors to a microcontroller, sooner or later you run into an I2C address conflict. Two devices using the same address cannot share the bus, and finding a valid combination by hand is tedious. Ztronics has solved the problem with a free, open-source web tool that searches I2C addresses and checks whether multiple devices can coexist on the same bus without conflicts.

The tool is designed for Arduino, ESP32, Raspberry Pi, and other embedded systems. You can search for a device by name, type, manufacturer, or hexadecimal address, then select the ones you want to connect. The tool compares the available addresses of each device and checks whether it is possible to assign a unique address to every component.

The backtracking algorithm and conflict solutions

If a conflict exists, the tool looks for a valid alternative configuration using a backtracking algorithm. This method tries different address combinations until it finds a solution that assigns a unique address to each device. In particular, it works well with sensors that have multiple configurable addresses, such as the MPU6050 which uses 0x68 or 0x69, or the BMA400 which uses 0x14 or 0x15.

When the conflict cannot be resolved, the tool suggests practical solutions. You can change a device’s address, use another I2C bus, switch to software I2C, or add an I2C multiplexer such as the TCA9548A. The I2C bus uses only two communication lines, SDA and SCL, so conflicts are the only real obstacle to connecting many sensors.

• MPU6050: addresses 0x68 or 0x69
• DS3231: address 0x68
• BMA400: addresses 0x14 or 0x15
• SSD1306: addresses 0x3C or 0x3D

The device database and browser-based operation

The entire tool runs in the browser, with no backend, account, or API. The device database is in JSON and the logic is in JavaScript, with HTML5 and CSS3 for the interface. This means you can use it offline once the page is loaded, and your data never leaves your computer.

The Ztronics repository contains all the source code, so you can examine it, modify it, or add new devices to the database. Moreover, the modular structure makes it easy to integrate the tool into other projects or use it as a reference for your own tools. The Ztronics repository collects the complete code and instructions for using it.

For those working with ESP32 or Arduino, this tool eliminates a recurring problem. Instead of manually checking the datasheets of each sensor, you can verify in seconds whether a combination works. Additionally, the suggestions on multiplexers and alternative buses help you design more robust schematics from the start.

Source: https://github.com/webzf/i2c-address-compatibility-checker

The post Find I2C addresses without conflicts with this web tool appeared first on Open Electronics.

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

South Korean company INFAC Corporation has introduced an innovative 800V electric vehicle battery pack design that integrates a high-power, isolated and regulated 800V-to-48V DC-DC converter. The new design improves vehicle performance and energy efficiency and extends range thanks to the reduction in high-voltage cables and connectors.

Instead of treating the DC-DC conversion stage as a separate, distributed subsystem, INFAC designed the power to be stepped down at the source for SELV distribution throughout the vehicle. This simplified approach enables cleaner, more flexible and more modular 48V zonal architectures across various EV platforms, without relocating battery cells or reducing vehicle range.

Reimagining what is possible between battery packs and DC-DC converters

INFAC recognised that traditional approaches to power delivery were not aligned with the industry’s goals for weight reduction, cost optimisation and design simplicity.

High-voltage DC-DC converters are typically mounted outside the high-voltage (800V or 400V) battery assembly system (BAS), requiring additional safety and thermal management systems. EV motor and inverter systems require hundreds of kilowatts of power and need high-voltage cabling, dedicated mounts and enclosures. Other powertrain subsystems and body and chassis electronics require 3.5 to 12 kW and can easily be powered from a 48V SELV zonal distribution network.

Figure 1: The Vicor DC-DC converters (BCM and PRM) fit inside the 800V battery pack. This saves space and weight in the vehicle design and takes advantage of the battery’s cooling system to handle thermal challenges. This innovative approach eliminates the cost and weight of an additional cooling system for a remote DC-DC converter. The DC-DC module is compact enough to be integrated without relocating the battery cells. The high-density Vicor BCM6135, combined with the PRM3735 regulator, met the strict space constraints, allowing INFAC to realise the new battery pack design.

Physically separating the high-voltage source and the DC-DC conversion system needlessly duplicates the power distribution and management systems, wasting space, weight and cost and doubling the liquid cooling systems required.

The innovation: moving DC-DC conversion inside the battery pack

INFAC’s key insight was that the battery pack already incorporates a robust liquid cooling system for managing thermal loads. By integrating the high-voltage DC-DC converter inside the battery and leveraging the existing infrastructure, INFAC eliminated the separate cooling system that traditionally sits outside the battery pack for the DC-DC converter. This departs from traditional “silver-box” design approaches, positioning the battery pack as a central, intelligent energy hub rather than a passive energy source.

Figure 2: To be positioned inside the car’s battery pack, the system’s form factor had to be extremely small. The INFAC system measures 215 x 45 x 82 mm (L x W x H). The volume is 793 cm3 and it weighs about 1.5 kg.

The change was achieved using Vicor’s high-density BCM6135 DC-DC converters and PRM3735 regulators, which provide high-voltage-to-48V conversion and regulation and enable a high-power, fully isolated and regulated bus for the zonal architecture. Previously, housing the DC-DC conversion function inside the battery pack was impractical, since dimensional constraints forced designers to deal with power management issues, electrical isolation, safety requirements and the packaging ruggedness of the power modules.

Benefits of DC-DC conversion integrated into the battery

By placing the DC-DC converter inside the battery pack, INFAC achieved a series of benefits that increased system-level performance:

• By leveraging the battery’s liquid cooling network, the power module eliminates redundant cooling circuits and reduces thermal interfaces.
• The length and thickness of high-voltage cables are significantly reduced, simplifying high-voltage wiring routing and layout.
• Fewer brackets, enclosures and cooling components reduce bill-of-materials (BOM) cost and weight.
• Minimising connections and cooling paths reduces leakage points and electrical failure risks.
• Fewer external interfaces translate into faster, more consistent production processes.

Vicor’s high-density modular power architecture delivers the efficiency, scalability and compact form factor needed to make battery-integrated 48V distribution practical on a large scale. In doing so, it positions the battery pack as the central hub for energy management and distribution in next-generation electric vehicles and allows INFAC to align its EV battery pack designs with the industry’s broader transition to 48V zonal power architectures.

The post INFAC integrates Vicor DC-DC conversion into the 800V EV battery pack appeared first on Open Electronics.

An inexpensive robot kit with Arduino UNO Rev3, obstacle-avoidance sensors, and line-following capability becomes a face-tracking robot. The trick is in the control board: just replace the UNO Rev3 with an Arduino UNO Q, which has the same headers and mounts an STM32U585 microcontroller alongside a Linux microprocessor. Iulia Feroli’s project shows how local artificial intelligence can be added to a low-cost robot without touching the mechanics.

The robot starts from the Elegoo kit, with its motor shield and sensors for obstacle avoidance and line following. The UNO Q slots in place of the original board, and the shield moves over without any modification. Thanks to the STM32 microcontroller and the Linux microprocessor, the new board runs machine learning models locally, with no cloud connection. A standard USB webcam is connected to the UNO Q to provide vision.

Video stream and face tracking

The webcam video stream is processed with the face tracking Brick from Arduino App Lab. The code converts the face position in the frame into movement commands for the robot. The robot rotates to center the face and moves toward it, always staying in front of the person. The result is a responsive face tracker that requires no external servers or Wi-Fi connections.

Iulia Feroli’s project is documented in a video showing the robot in action, with an explanation of the assembly and the code. Swapping the board is the core of the intervention: the UNO Q maintains electrical and mechanical compatibility with the UNO Rev3 but adds the computing power needed for AI. In addition, the face tracking Brick in Arduino App Lab simplifies managing the machine learning model, making the code accessible even to those without neural network experience.

What you need to rebuild the project

To replicate the robot you need only a few components, all easily available. The list includes the Elegoo kit, a USB webcam, and the control board. Here are the main steps:

• Remove the Arduino UNO Rev3 from the Elegoo kit and keep the motor shield.
• Mount the Arduino UNO Q in its place, checking that the headers align.
• Connect the USB webcam to the UNO Q port.
• Upload the sketch with the face tracking Brick from Arduino App Lab.
• Power the robot and test it in front of a face.

The UNO Q is the heart of the system: it combines the simplicity of the STM32U585 microcontroller with the power of the Linux processor. This combination allows local machine learning models, such as face tracking, to run without additional hardware. The board is also available in a 4GB version with a full accessory kit, which includes everything needed to get started.

The original Elegoo kit, with its Arduino UNO Rev3 board, remains an excellent base for other projects. However, for this face tracker, the UNO Q is the right choice: it offers the necessary computing power and maintains compatibility with the shield. The overall cost stays low, and the result is a smart robot that impresses with its responsiveness.

Source: https://youtu.be/FIu14vCvGfs?si=8SSW0K6O7J6Y07tz

The post Face-tracking robot with Arduino UNO Q appeared first on Open Electronics.

opened up a broken controller to see if I could use the D-PAD in one of my project. Totally separate from the main board with 6 pin inputs. It‘s beautiful. submitted by /u/Late-Ninja-5531 [link] [comments]

7 years ago I designed a single board computer PCB. That was for a retrogaming console. It included a A20 SoC, ram, battery management system, Ethernet, HDMI, emmc, wifi and so on. I did everything on my own. Those were some good times. I loved rooting that PCB. submitted by /u/PaddleStroke [link] [comments]

КПІшники долучилися до освітньо-інноваційного проєкту PolyTECH Project 2026 KPI4U-2 пт, 09/25/2026 - 23:08

Єдність у дії: доступні культурні простори як основа розвитку громад KPI4U-2 пт, 09/25/2026 - 22:44

Перше знайомство нового складу «Формула Студент КПІ» відбулося! KPI4U-2 пт, 09/25/2026 - 18:11

Traditionally, every generation of cellular technology has been mostly about moving data faster. However, 6G is shaping up to be a different kind of upgrade. The industry’s focus is shifting from how fast a network can move data to what new services and experiences it can deliver, with artificial intelligence enabling this shift.

6G is being designed to embed AI deeper into the radio access network (RAN) and core, enabling the network to predict demand peaks before congestion sets in and manage radio resources in real time. That same intelligence could also help the network make use of its own infrastructure and wireless signals to provide data and gather information about the physical environment.

AI already exists in 5G networks, but 6G is designed to integrate these capabilities more deeply into the network architecture. 6G is still being defined through the 3rd Generation Partnership Project (3GPP) standards process, and many of these technologies are in the trial stage. Still, the direction is becoming clear as AI, distributed computing, and sensing are becoming as integral as new frequencies, lower latency, and data rates.

6G standardization & 3GPP

3GPP started to study 6G in Release 19, which was completed in December 2025. Release 20 evaluates foundational items for 6G, including studies of AI, sensing, and new architecture of the 6G network, and it is expected to be completed by 2027. Release 21 is now open for contributions and will be the first normative 6G specifications, pending finalization of its scope and timeline, and is expected to build on top of Release 20 studies and be completed by 2030.

Commercial 6G systems are still expected around 2030, although pre-commercial deployments and field trials will appear earlier. Many of the technologies being considered for 6G are already being introduced through 5G-Advanced, giving vendors and operators a chance to test capabilities such as AI-driven network optimization and integrated sensing and communication (ISAC) before committing to larger 6G deployments.

At the same time, 6G development is not limited to consumer networks. Governments and defense departments are also exploring potential use cases, particularly where communications, computing, sensing, and real-time decision-making need to work together. The U.S. Department of Defense is exploring 6G technologies and prototypes for military applications, adding another potential source of demand for early 6G systems.

The U.S. government’s Mission 6G 28 initiative is another example of this push toward early testing. The initiative is encouraging industry-led demonstrations of technologies, including AI-driven networking and integrated sensing, ahead of the 2028 Los Angeles Olympic Games. These demonstrations use pre-standard technology, providing an early look at which concepts can move from research into real-world environments.

Vendors are also developing tools to support these early trials, giving operators and research and development teams a way to test new capabilities before the standards are finalized.

3GPP’s timeline for Release 21 (Source: 3rd Generation Partnership Project)

The standards process provides the industry with key milestones to watch. Release 20 is expected to conclude in 2027, followed by the development of the normative 6G specification in Release 21 and the final protocol freeze in March 2029. After that, the focus shifts to operators and equipment manufacturers to turn those specifications into reliable systems.

AI-RAN

One of the clearest examples of AI moving into the network is in the RAN, which includes the base stations and antennas that connect devices to the cellular network. Traditionally, RAN equipment has been built around proprietary hardware and custom silicon designed for telco-specific functions with long upgrade cycles. AI is starting to challenge that model, but the industry is not taking one single approach.

Ericsson is taking a more evolutionary approach. The company is embedding AI capabilities into the RAN infrastructure that operators already have, with the goal of improving performance without a costly, large-scale hardware replacement. Early trial results point to real gains in efficiency and throughput, particularly around scheduling and radio resource management.

Nokia and Nvidia are pushing something more transformative. Their AI-RAN uses graphics processing unit (GPU)-based computing alongside traditional telco workloads, turning the RAN into a more flexible compute platform.

Nvidia backed this vision with a $1 billion investment in Nokia, and the two companies already have live trials running with T-Mobile. Putting more GPUs into the RAN brings additional computing capacity but also higher power consumption, cooling requirements, and infrastructure costs. Operators will ultimately have to decide whether the revenue from running AI workloads at the edge is enough to justify those costs.

If operators mostly want better network performance, adding AI to existing RAN infrastructure may be enough. However, the case for GPU-based AI-RAN becomes stronger if operators see an opportunity to turn that additional compute into a new business around distributed AI workloads.

The 6G core

AI is also starting to reshape the network core, the part of the network responsible for routing traffic, managing connections, and allocating resources. In May 2026, 3GPP advanced two competing approaches for integrating AI into the 6G core, with both now being studied in parallel.

The first, Solution Variant #18.1, puts AI directly into the core through new, agent-based network functions. These functions could interpret an intent from a user or application and orchestrate existing network functions to carry it out.

The second, Solution Variant #18.3, keeps AI separate from the core. A dedicated AI domain would interact with existing network functions through a translator function, allowing AI to optimize and orchestrate the network without fundamentally changing the core itself.

Two approaches for integrating AI into the 6G core (Source: ABI Research)

Variant #18.1 is being pushed primarily by Chinese vendors and operators, including Huawei, ZTE, and the major Chinese carriers, while Variant #18.3 has support from Western vendors and operators including Nokia, Ericsson, AT&T, T-Mobile, Qualcomm, and Google. SK Telecom is notably involved in both, reflecting the fact that the industry has not settled on a single path.

For now, 3GPP is keeping both options open. Where AI ends up sitting in the core will shape network architecture and vendor influence for years.

Integrated sensing and communication

As AI makes the network more capable of making decisions and managing itself, sensing can give it more information about the physical environment around it. ISAC uses its existing wireless signals for both communication and sensing, allowing cellular infrastructure to detect and track objects without dedicated sensing equipment.

Recent trials are starting to show what it could look like in practice. For example, in July 2026, AT&T and Ericsson used existing 5G infrastructure outside the AT&T Stadium in Texas to detect, locate, and track multiple drones flying between 300 and 400 feet. The system used existing massive multiple-input/multiple-output radios, signal processing, and AI-enabled sensing rather than a separate radar system.

The demonstration is a useful proof point, but it is not yet a replacement for dedicated radar. It’s more likely a near-term role as an additional layer of sensing, particularly in places where cellular infrastructure is already widely deployed. Drone detection, perimeter security, industrial sites, ports, and logistics facilities are the likely first use cases.

The bigger test will be whether ISAC can move beyond controlled trials and demonstrate performance across different environments, weather conditions, distances, and object types. If ISAC can handle those conditions, it could give AI-driven networks another important input, allowing them to make decisions based on what is happening in the physical environment and inside the network.

What to watch

The next few years will show whether 6G can deliver on the larger idea that it is less about a faster connection and more about the network becoming an intelligence platform. The clearest checkpoints are on the standards calendar: Release 20 studies conclude in 2027, the architecture is due to be finalized in 2028, and the first normative 6G specs freeze in March 2029. This will determine the technical standards, but what operators do in practice comes down to whether AI, distributed computing, and sensing can create enough value to justify the cost and complexity of putting them deeper into the network.

This is what truly differentiates 6G from previous generations. The network is becoming part of the computing infrastructure and can process AI workloads closer to the source, make decisions about how network resources are used, and gather information about the physical environment. That moves 6G beyond the traditional role of connecting devices and toward a more intelligent network.

This is a follow-up to ABI Research’s 5G & 6G: Adoption, Technologies and Use Cases.

The post 5G to 6G: AI moves into the network appeared first on EDN.

Now I appreciate that the hardware industry didn't have an "open source" culture around it before AI or else we would be doomed. submitted by /u/AmbassadorBorn8285 [link] [comments]

A Steam Controller, Valve’s gamepad, now runs Zork, the famous text adventure from 1980. Owen Feldman has written an Intel 8080 emulator in Rust that runs directly on the controller’s microcontroller. The emulator boots CP/M, the operating system of that era, and the Z-machine, the virtual machine that interprets Infocom games. The result is a fully playable game, with the computer connected via USB acting as a terminal.

The Arm Cortex-M4 and the 8080 emulator

The heart of the project is the Steam Controller’s main microcontroller, an Arm Cortex-M4. According to Feldman, this chip is orders of magnitude more powerful than the entire Apple IIc, the computer on which many people played Zork in the 1980s. The Intel 8080 emulator was written from scratch in Rust, a language known for safety and performance. The emulator, together with the Z-machine and Zork, is installed on the controller using the firmware update tool included in the Steam package for Linux.

The game needs no graphical resources: Zork is text only. However, the controller has neither a screen nor a keyboard. Feldman therefore wrote a small server application that runs on the connected computer. This application displays the game text and sends commands to the engine over USB. In practice, the PC becomes a serial terminal, while the gamepad does all the computational work.

The failure and repair with a Raspberry Pi Pico

During the process, Feldman damaged his Steam Controller. The original firmware was compromised and the gamepad no longer responded. To repair it, he used a Raspberry Pi Pico soldered to the debug pins on the board. With the Pico he restored the original firmware, bringing the controller back to life. This step shows how useful it is to have a spare microcontroller for low-level debugging.

The project is documented in Owen Feldman’s video, where he shows the development process and the repair. It is a perfect example of how modern consumer hardware can be pushed beyond its limits. A gaming pad, designed for input and vibration, becomes a complete computer capable of running an operating system and a retro gaming classic.

• The gamepad’s Arm Cortex-M4 microcontroller runs the Intel 8080 emulator.
• CP/M and the Z-machine run inside the emulator, with no external hardware.
• The PC connected via USB acts as a terminal for text and commands.
• A Raspberry Pi Pico made it possible to restore the firmware after a failure.

For those who want to replicate the project, you need a Steam Controller, a computer with Steam for Linux, and a bit of patience. The most delicate part is flashing the firmware: a mistake can render the gamepad unusable, as happened to Feldman. Having a Raspberry Pi Pico available for debugging is a smart precaution. In addition, those who want to experiment with microcontrollers may find the Pico Primer kit with sensors and tutorials useful, although for this project only the bare Pico is needed.

Source: https://youtu.be/M5XUR8Fnjf4?si=IhDVd-LKypGjz5rw

The post Zork on a Steam Controller: when the gamepad becomes a mainframe appeared first on Open Electronics.

You don’t have to be Superman (or even just use phone booths as changing stations) to find this author’s recent research results disturbing.

I was recently looking for some information about neon lamps when I came across a series of websites with content which, courtesy of my blissful naïveté, I found rather jarring. I merged a collection of screen shots into one image for your ease of perusal (Figure 1).

Figure 1 Warning: this collection of screen shots may be angst-inducing.

Looking further into the “radioactive additive” matter, I found a paper about that Krypton stuff (PDF). And looking further yet, I came across two more screen shots, which IMHO are very much deserving of your attention (Figures 2 and 3).

Figure 2 This screenshot’s information covers Krypton 85 itself.

Figure 3 And this screenshot discusses Kr-85’s uses and cancer risks.

Having been jolted into newfound awareness of the presence of radioactive material where I would never have expected it (due, again, to my own naïveté, of course.), I am reminded of how exposure to lead has been recently recognized as having no minimum exposure level that can be considered safe for anyone. Leaded gasoline, for example, is now out of use.

Mercury exposure is another example. And X-ray exposure effects are of similar concern, albeit minimally accepted only as necessary for medical diagnostics purposes.

My sense is that the same “no minimum acceptable exposure” rule should also apply to radiation exposure from electronics components, with regard to the possibilities of “cancer induction”. And right now, for lack of such, one should handle Krypton 85-bearing items with some care and, if accidentally broken, with extreme care. Although what precise steps would be called for, I do not know.

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

Related Content

• Radon sensor embeds sizeable alpha particle detector
• Radon: Level detection, risk determination, and as-needed mitigation
• My Geiger counter doesn’t count (sob sob)

The post Neon lamps and Krypton 85 appeared first on EDN.

📰 Газета "Київський політехнік" № 31-32 за 2026 (.pdf) Інформація КП пт, 09/25/2026 - 14:54

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