Feed aggregator

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

As 5G and 5G-Advanced push uplink efficiency and modulation performance, engineers are revisiting where power amplifier (PA) linearization should happen and how it should be validated. Hardware-in-the-loop testing of AI-based digital post-distortion (DPoD) is now linking today’s 5G measurements with possible 6G receiver architectures.

PA linearity remains one of the hardest tradeoffs when designing wireless communication systems. A user device can operate its PA in the linear region with power backoff to preserve signal quality, but that reduces efficiency and drains battery life. Or it can drive the PA closer to saturation, improving power efficiency while introducing in-band distortion and out-of-band spectral regrowth. In 5G, and increasingly in 5G-Advanced, that compromise is becoming more visible as uplink performance demands rise.

This is one reason why DPoD is attracting attention. Unlike conventional digital pre-distortion, which linearizes the PA at the transmitter, DPoD shifts part of the compensation burden to the receiver. In the cellular uplink, that means the base station attempts to recover a signal that may have been transmitted by a more efficient, more nonlinear user device. The idea is especially relevant for battery-powered equipment at the cell edge, where uplink power efficiency matters most.

Although DPoD is often discussed in the context of 6G, its practical evaluation starts with 5G testing. The key questions are measurable today: How much uplink distortion can a receiver tolerate? Can AI-based receivers recover signals beyond what conventional algorithms can handle? And what test setup is needed to compare the two under realistic conditions?

Why the uplink remains difficult

The peak-to-average power ratio of OFDM signals in the 5G uplink leads to nonlinear distortions when operating the PA of the user equipment (UE) close to saturation. As modulation orders increase, the margin for impairment shrinks further. Higher-order constellations improve spectral efficiency, but they are also more vulnerable to error-vector-magnitude degradation caused by PA compression and phase distortion.

Traditionally, this problem has been managed at the UE with transmitter linearization, calibration, and careful PA operation. But that approach carries costs in complexity, power consumption, and thermal overhead. For smartphones, wearables, and IoT devices, those penalties are not trivial.

That is why receiver-side compensation is being revisited, particularly as 5G-Advanced sharpens focus on uplink performance and 6G research considers more aggressive spectral-efficiency targets.

DPoD does not remove the need for spectral compliance, and it does not make PA nonlinearity harmless. What it does offer is a different system partitioning: Some of the burden of recovering a distorted uplink is shifted from the device to the network receiver.

Why AI-based DPoD matters

Classical post-distortion methods rely on predefined models of nonlinear behavior. Those methods can work well in controlled cases, but real uplink signals are shaped by multiple effects at once: PA nonlinearity, multipath fading, noise, synchronization error, and implementation nonidealities. That makes a purely model-based approach increasingly difficult, especially when thinking beyond current 5G deployments toward 5G-Advanced and 6G.

Figure 1: Nokia and Rohde & Schwarz tested a 6G radio receiver that uses AI to boost uplink distance, enhancing coverage for future 6G networks. (Source: Rohde & Schwarz)

AI-based receivers are attractive because they can learn from representative data rather than relying on a fixed analytical model. One example is Nokia Bell Labs’ HybridDeepRx, a neural-network-based receiver designed for OFDM waveforms affected by channel impairments and transmitter nonlinearity (Figure 2). In the setup discussed here, HybridDeepRx effectively replaces part of the conventional base-station receiver chain.

Figure 2: The HybridDeepRx AI receiver (Source: Nokia Bell Labs)

Its role is not simply to “denoise” the signal. The model jointly addresses channel-related effects and nonlinear distortion, then performs demapping to generate soft information for decoding. A key feature of the architecture is that it alternates between frequency-domain and time-domain processing.

Frequency-domain stages help address channel effects in a way familiar to conventional OFDM receivers, while time-domain stages are well-suited to mitigating PA-induced distortion. This hybrid structure makes it a useful candidate for testing whether AI-based DPoD can outperform conventional uplink receiver processing when the transmitter is deliberately operated in a more nonlinear region.

Hardware-in-the-loop testbed

To evaluate that question credibly, Nokia Bell Labs and Rohde & Schwarz (R&S) used a hardware-in-the-loop testbed built around standard-compliant 5G signal generation and wideband signal analysis. The objective was to compare conventional receiver processing with AI-based reception under controlled but realistic uplink impairment conditions.

Figure 3 shows the overall setup. An R&S SMW200A vector signal generator creates the 5G uplink waveform and applies a PA model, followed by wireless channel emulation. This is important because it allows a controlled introduction of nonlinear PA distortion without changing physical hardware from test to test. Researchers can vary amplifier operating point and distortion level repeatably, which is essential for comparing conventional and AI-based receiver behavior.

Figure 3: Hardware-in-the-loop AI receiver testbed using the R&S SMW200A vector signal generator, FSWX signal and spectrum analyzer, and VSE vector signal explorer to compare conventional 5G uplink reception with Nokia Bell Labs’ HybridDeepRx (Source: Rohde & Schwarz)

On the receive side, an FSWX signal and spectrum analyzer captures the impaired uplink waveform. The FSWX provides the bandwidth and dynamic range needed for this kind of work. The captured signal is then processed in the R&S VSE vector signal explorer software, which serves as the central analysis environment.

VSE plays several roles in the setup: It performs the standard demodulation steps needed for signal analysis; supports KPI extraction such as BLER, BER, throughput and ACLR; and, crucially, can load user-defined AI models in ONNX format. In this case, Nokia Bell Labs’ HybridDeepRx receiver is imported into the measurement flow and executed using GPU-accelerated inference. That creates a direct bridge between AI model development and RF test instrumentation: The same captured waveform can be processed through a conventional algorithm chain or the neural-network-based receiver.

This is where HybridDeepRx becomes central to the measurement concept. Rather than evaluating an abstract AI model offline, the setup places the model directly inside a realistic signal-analysis flow. That allows the comparison of receiver approaches using the same waveform, same impairment conditions, and same measured KPIs such as block error rate and throughput. For engineers, this is much more convincing than a purely simulated benchmark.

The value of the testbed is not limited to proving that an AI receiver can run in the loop. It also helps clarify how much distortion can be tolerated before conventional processing breaks down and whether an AI-based receiver extends that operating region.

Because the R&S SMW200A can impose both wireless-channel effects and controlled PA nonlinearity, the setup can explore a range of realistic uplink cases, from mildly impaired links to strongly compressed transmission. This makes it possible to study a key architectural question for future systems: If the receiver becomes more intelligent, can the UE be allowed to transmit less linearly and therefore more efficiently?

That question matters because receiver-side compensation may improve bit recovery, but it does not remove the physical consequences of PA compression. The value of a hardware-in-the-loop setup is that it keeps the evaluation grounded in measurable signal behavior and system-level KPIs rather than algorithm claims alone.

From 5G measurement to 6G architecture

This makes AI-based DPoD a good example of how 5G testing is feeding future wireless architecture. The waveforms, KPIs, and measurement discipline are rooted in today’s 5G and 5G-Advanced work. But the system question being explored points toward 6G: whether some of the uplink linearization burden can move from power-limited devices to compute-rich infrastructure.

That possibility is attractive because the uplink is where device constraints are least forgiving. If future base stations can recover more heavily distorted signals, UEs may be able to operate with simpler or more efficient transmitters in difficult link conditions. For cell-edge users, that could translate into better power efficiency without an equivalent penalty in coverage or throughput.

The concept is still emerging, and many challenges remain, including generalization across devices, channels, and deployment conditions. But the combination of a realistic 5G waveform source, controlled PA and channel emulation, wideband signal capture, and in-tool AI inference provides a practical way to study the idea now.

AI-based post-distortion is not just a theoretical 6G topic; it is already a 5G test problem. And as this work shows, progress depends on hardware-backed comparison between established receiver methods and AI-based alternatives, using tools that let both live in the same measurement flow.

About the author

Andreas Oeldemann is program manager of AI for wireless at Rohde & Schwarz, headquartered in Munich. As part of the corporate R&D team, his work focuses on how novel T&M solutions will enable the validation and deployment of physical- and MAC-layer AI/ML methods of 5G-Advanced and 6G communication systems. In this role, he investigates future customer requirements for testing AI/ML implementations in the air interface, develops early proof-of-concept T&M solutions, and drives collaborations with industry partners and academic institutions to advance 6G R&D. He holds an M.Sc. in electrical engineering from the Technical University of Munich.

The post From 5G uplink testing to 6G research: AI DPoD in the lab appeared first on EDN.

Перше знайомство нового складу «Формула Студент КПІ» відбулося! 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]