Feed aggregator

pSemi offers the PE566212 and PE566213 2.4-GHz SOI front-end modules (FEMs) for Bluetooth, Zigbee, and Thread applications. Each module integrates a power amplifier, low-noise amplifier, and RF switch in a compact 1.8×1.8×0.63-mm LGA package, simplifying RF design. Applications include smart home devices, wireless audio, wearables, and sensing systems.

The FEMs provide transmit output power up to +20 dBm, a receive noise figure of 1.8 dB at 13 dB of gain, and typical bypass-path loss of 0.8 dB. According to pSemi, the FEMs offer 5 to 10 times the range of a standalone SoC. Based on pSemi’s UltraCMOS+ SOI process, they offer a highly integrated silicon-based alternative to GaAs- and SiGe-based front ends.

The PE566212 supports Bluetooth Basic Data Rate (BDR) and Bluetooth Low Energy (BLE), with 22.5 dB of transmit digital gain control in 1.5-dB steps. The PE566213 adds Bluetooth Enhanced Data Rate (EDR) support at up to +11.5 dBm and offers 15 dB of transmit digital gain control in 1-dB steps. Applications include smart home devices, wireless audio, wearables, and sensing systems.

The front-end modules are available now, along with corresponding evaluation boards.

PE566212 product page 

PE566213 product page

pSemi

The post Integrated FEMs ease 2.4-GHz RF design appeared first on EDN.

A liquid-cooling cold plate, Frore’s LiquidJet Diamond integrates a diamond heat spreader to cool hotspots in high-power-density AI GPUs. Its 3D, short-loop, multistage cooling architecture can be customized to match a GPU’s power map, directing coolant to the hottest areas before cooling the rest of the GPU die, high-bandwidth memory (HBM), and other SoC chiplets.

Compared with conventional skived cold plates, LiquidJet Diamond achieves up to 75% higher heat-transfer efficiency and more than 150% higher maximum power density. Frore also claims 16–22°C lower GPU temperatures and 30–35% higher AI tokens-per-watt efficiency.

Beyond thermal performance and hotspot management, LiquidJet Diamond offers a seamless drop-in upgrade for hyperscale data centers. Frore says its manufacturing process combines semiconductor-fabrication precision with the production capacity needed to meet the quality and volume requirements of AI data center deployments.

LiquidJet Diamond product page 

Frore Systems 

The post Diamond spreader tames AI GPU hotspots appeared first on EDN.

Aetina’s AIE-KT78/68 edge AI systems are powered by NVIDIA Jetson Thor platforms featuring the Blackwell GPU architecture for deterministic industrial control. Targeting collaborative robots (cobots), humanoid robots, and autonomous machines, these compact systems run multimodal AI models locally, reducing reliance on cloud processing and associated latency. Supported workloads include generative AI, large language models (LLMs), vision-language models (VLMs), and vision-language-action models (VLAs).

The AIE-KT78 uses the Jetson T5000 system-on-module, with 128 GB of LPDDR5X memory on a 256-bit interface and up to 2,070 FP4 TFLOPS of AI compute performance. The AIE-KT68 features the Jetson T4000 system-on-module, with 64 GB of LPDDR5X memory on the same interface and up to 1,200 FP4 TFLOPS.

Each system provides QSFP28 connectivity with up to 4×25-Gbps bandwidth, dual 10GbE RJ45 ports, and support for up to eight GMSL2 camera inputs to handle data from cameras, LiDAR, radar, and other sensors. A dedicated 1GbE RJ45 EtherCAT port operates as an independent EtherCAT master, synchronizing motors, joints, sensors, and actuators for deterministic control.

Both edge AI platforms run Linux with the full NVIDIA AI software stack.

AIE-KT78/68 product page 

Aetina

The post Systems reduce latency in edge AI automation appeared first on EDN.

Renesas Electronics has launched its first family of 100-V enhancement-mode (E-mode) discrete GaN power transistors. The company says the RTP100E005G1FL, RTP100E2P6G1FL, RTP100E1P8G1FL-DSC and RTP100E1P2G1FL-DSC low-voltage GaN FETs achieve industry-leading hard- and soft-switching figure-of-merit (FOM). They deliver up to 35% lower hard-switching FOM and up to 63% lower soft-switching FOM than comparable GaN devices.

Offered in FCLGA packages that maintain a silicon-compatible footprint, the GaN FETs let designers migrate from silicon MOSFET layouts without significant PCB rework. The RTP100E005G1FL and RTP100E2P6G1FL have typical on-resistance of 5 mΩ and 2.6 mΩ, respectively. The dual-side-cooled RTP100E1P8G1FL-DSC and RTP100E1P2G1FL-DSC have on-resistance of 1.8 mΩ and 1.2 mΩ, respectively. Depending on application requirements and power-conversion architecture, the transistors can achieve up to 40–70% lower switching losses and up to twice the power density at the system level.

The 100-V family targets high-power-density applications, including AI data centers, humanoid robotics, and factory automation. Package options and a wide range of on-resistance values allow the transistors to address different power levels and applications, including synchronous rectification, multiphase buck conversion, and industrial motor drives.

The new low-voltage GaN power transistors are available now, along with corresponding evaluation boards.

Renesas Electronics 

The post 100-V GaN FETs lower switching FOM appeared first on EDN.

METCASE has redesigned its COMBIMET 19-in. rack-mount enclosures to provide greater rigidity and more usable panel space. The aluminum cases are suitable for networking and communications equipment, industrial computers, sound and studio systems, laboratory instruments, and industrial control applications.

The COMBIMET range now offers 68 standard model, size, and color permutations. Improved tabs create stronger, more reliable connections between enclosure components, while enlarged hidden apertures behind the front and rear panels allow more room for displays, controls, switches, connectors, and ventilation. Standard case heights range from 1U to 6U, with depths of 10.43 in., 14.37 in., and 24.00 in.

Enclosures have removable top, base, and rear panels for easy access to electronics. Both the top and base come with or without vents as standard. Units are available in black or light gray. COMBIMET enclosures can also be customized in size, panel design, color, finish, and graphics to meet specific application requirements.

Sales inquiries can be directed to sales@metcaseusa.com.

COMBIMET product page

METCASE

The post Updated rack enclosures offer flexible design options appeared first on EDN.

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

Driving a portable Bluetooth thermal printer from an ESP32-C3 microcontroller, without going through the vendor’s smartphone app. That is what Bas BotBerg does, and the result is that reports on sensor data end up on thermal paper with no phone involved at all. The method is not the usual Bluetooth log capture on Android: the author queries the device directly and reconstructs its communication protocol.

The interesting part is the underlying choice. Instead of relying on the manufacturer’s app, the project uses an application that lists the printer’s Bluetooth Low Energy services and characteristics. That way the work shifts away from the encrypted traffic of a closed app and towards the services the device exposes, which stay visible and queryable.

Identifying the writable services and sending the first payloads

The next step is to separate the services marked as writable from all the others. On those, the author starts sending data and observes how the printer responds. It is a process of trial and error, but every response narrows the field. The discovery phase is therefore done in Python with the Bleak library, which makes it possible to iterate and adapt the code in seconds.

• Query the device and read the list of Bluetooth Low Energy services.
• Isolate the characteristics marked as writable.
• Send test payloads and observe how the printer reacts.
• Adapt the Python code with the Bleak library at every attempt.
• Map commands and endpoints once you understand what triggers them.

The first milestone comes when the printer’s motor starts and feeds the paper. That movement confirms that the command identified is the right one and that the approach is the correct one. From there the work becomes more orderly: payloads are noted down, the endpoints to send them to are noted down, and the protocol map takes shape.

Moving the payloads into the C++ firmware on the ESP32-C3

Once the data to send and the endpoints to send it to have been mapped in Python, the same payloads move into the C++ code on the ESP32-C3. The microcontroller then becomes the printer’s only counterpart. The Adafruit GFX library is also used to produce icons and to format the output more easily, so the report is not just raw text but has a readable structure.

For anyone who wants to rebuild the project, the starting board is compact and has the radio built in: the ESP32-C3 module in SuperMini format covers both the Bluetooth Low Energy side and sensor control. The rest of the work is in the firmware, not the hardware.

Anyone who has already taken apart a portable thermal printer knows that the critical point is not the mechanics. The critical point is the protocol, and that is exactly what the project tackles. The method used is an alternative to Bluetooth log capture on Android, and in some ways more direct: you talk to the device instead of spying on an app. Bas BotBerg’s project page on Hackaday.io collects the work done on this Bluetooth thermal printer.

The case is a good reference for anyone who needs to control, from a microcontroller, peripherals that the manufacturer makes accessible only through proprietary applications. The sequence is always the same: list the services, find the writable ones, send data, observe the responses, map the payloads. The device changes, not the method.

Source: https://hackaday.io/contests

Related products

• Mini ESP32-C3 module

The post Driving a Bluetooth Thermal Printer with the ESP32-C3 appeared first on Open Electronics.

VisIC Technologies Ltd of Ness Ziona, Israel — a fabless supplier of power conversion devices based on gallium nitride (GaN) transistors — and mobility technology company AVL are advancing their collaboration with the integration of VisIC’s D3GaN power module technology into AVL’s vehicle demonstrator...

This silly simple circuit cancels out potentially serious digital potentiometer zero- and full-scale errors.

Everybody (well, most everybody) knows that digipots tend to be more accurate when used as variable voltage dividers (i.e., in potentiometer mode) and not so much when used as variable resistors (in rheostat mode). In pot mode, many error-promoting effects like resistance element tolerances and temperature coefficients cancel out (well, mostly). But even when pots are used as actual pots, some small non-idealities might still sneak by. One (okay, two) of these are zero- and full-scale ratio errors.

Figure 1 shows a simple Dpot output buffer that should work fine when the error terms are small.

Figure 1 Dpot U1 runs in straightforward voltage-division potentiometer mode with unity-gain buffer A1 providing isolation from output loading. So everything should be nicely ideal with Vsigout = Vsigin(Rwa/Rba).

Unfortunately, sometimes the errors are not so small. For example, if U1 were an 8-bit (1/256) resolution MAX5451, then typical values for full-scale and zero-scale errors are listed in its datasheet as 8lsb = 3.1%, which makes the actual achieved accuracy look more like only 5 bits instead of the claimed 8.

Vsigout = Vsigin((Rwa/Rba)(1 – Fullscale) + (Rwb/Rba)(Zeroscale))
Fullscale = Zeroscale = 0.031 (typical)
Vsigout = Vsigin(Rwa/Rba) +/-3%

In any precision-critical application, those 3% offsets are likely to be unacceptable. Fortunately, Figure 2 suggests how a simple 3-resistor error-nulling fix is possible.

Figure 2 If R1 = R2 x (scale error) then the errors disappear and Vsigout = Vsigin(Rwa/Rba).

Here’s how it works. Note that, for best performance, R2 and R3 should equal each other to ~0.1% and R1 should be adjusted equal to R1 = ScaleErrorPercentage x R2. An easy way to accomplish this is as follows:

1. Adjust U1 to its maximum UP setting. Then Rwa = Rba.
2. Set SigIn = V+ – 100mV or so. The exact voltage isn’t critical; we’re just insuring that A1 won’t saturate.
3. Connect a sensitive voltmeter between SigIn and SigOut.
4. Adjust R1 to null the meter reading and force Vsigout = Vsigin.

Done.

In some applications, error cancellation might be good enough with R1 equal to a fixed value calculated from the datasheet figures, instead of needing post-assembly calibration. 31 kΩ, for example, would align with the MAX5451’s data.

Which might niftily null some non-negligible production costs.

Stephen Woodward‘s relationship with EDN’s DI column goes back quite a long way. Over 200 submissions have been accepted since his first contribution back in 1974.  They have included best Design Idea of the year in 1974 and 2001.

Related Content

• DPOT push up/down
• Finger-friendly DPOT pushbuttons do ups, downs, and dittos
• Double DPOT programming: Parallel gang-up, singleton, or none
• Digital potentiometer simulates log taper to accurately set gain
• Push to increase, decrease a digital potentiometer
• Synthesize precision bipolar Dpot rheostats

The post Nifty nulling of non-negligible dpot “scale” errors appeared first on EDN.

🚀 Збудуй свою МРІЮ — зроби перший крок у світ інженерії! kpi ср, 10/14/2026 - 14:58

Specialty analog foundry Tower Semiconductor Ltd of Migdal Haemek, Israel and high-performance semiconductor, Internet of Things (IoT) system and cloud connectivity service provider Semtech Corp of Camarillo, CA, USA have agreed to expand their 20-year partnership. Semtech will invest in securing dedicated silicon germanium (SiGe) capacity at Tower in support of its strong design wins and demand for AI data-center optical interconnect components...

The BH1750 sensor converts light intensity into a digital value and makes it available on the I2C bus. Its measurement range goes from 1 to 65,535 lux. On the GY-302 breakout the sensor comes ready to use with Arduino, ESP32 and other boards. AdriRobot tried it with an Arduino UNO and writes about it on his blog.

What the BH1750 sensor measures

The lux is the unit of measurement for illuminance: it corresponds to one lumen per square metre. It therefore describes the light falling on a surface, evaluated as the human eye perceives it. For reference, light reflected by a full Moon is about 1 lx, a bright office is about 400 lx, and sunlight ranges between 32,000 and 100,000 lx.

Measurement modes and resolution

The BH1750 works in six modes, divided into two groups: continuous measurement and single measurement. In continuous mode the sensor detects light without stopping. In single mode it takes one measurement and then shuts down, so it must be reconfigured before the next reading. The library used in the article does this automatically.

Each mode offers three levels of precision:

• low resolution: 4 lx precision and 16 ms measurement time;
• high resolution: 1 lx and 120 ms;
• high resolution 2: 0.5 lx and 120 ms.

By default the library selects continuous high resolution. In low and high resolution modes the maximum value is 54,612.5 lx, while in high resolution 2 it stops at 27,306.25 lx. In practice the sensor returns a 16-bit integer, which the library converts into lux by dividing it by 1.2. A result of -1 means no valid data arrived, while -2 signals an unconfigured device.

You can also change the time interval in which the sensor counts light, through the MTreg register. The value ranges from 32 to 254 and the default is 69.

The GY-302 module: power, pinout and address

On the GY-302 the sensor is joined by a 3.3 V LDO regulator, marked 662K, and its capacitors. The module therefore accepts Arduino’s 5 V on the VCC pin. The regulator supplies up to 250 mA and withstands a maximum of 6.5 V at its input. On the SCL and SDA lines there are also two 4.7 kΩ pull-up resistors. The breakout is sold as a light intensity sensor.

The connector has five pins: VCC, GND, SCL, SDA and ADDR. The last one is used to choose the I2C address and comes into play when several BH1750 sensors share the same bus. With ADDR at a low level the address is 0x23, with ADDR high it becomes 0x5C. On the module tested the pin is tied to ground through a 4.7 kΩ resistor, so the sensor responds at 0x23.

• measurement range: from 1 to 65,535 lux;
• supply voltage: from 3 to 5 V;
• operating temperature: from -40 to +85 °C;
• dimensions: 18.5 × 13.9 × 2.5 mm, connectors excluded.

Connecting it to an Arduino UNO and an OLED display

For the first test you only need an Arduino UNO board, the GY-302 module and a few male-to-female jumper wires. VCC and GND go to the power supply, while SDA and SCL connect to Arduino’s I2C pins. Before uploading the sketch it is worth running the IDE’s i2c_scanner example: if the wiring is correct, the serial monitor reports a device at address 0x23.

The reading uses Christopher Laws’ BH1750 library, which is installed from the Library Manager together with the Wire library, already included in the IDE. The sketch reads the value every second and also writes it to the serial monitor.

The project is then completed with a 0.96-inch OLED display, 128×64 pixels, SSD1306 driver and I2C interface. The display responds at address 0x3C, so it shares the same bus as the sensor. The Adafruit SSD1306 and Adafruit GFX libraries are needed, and the lux meter shows the lux directly on the screen.

Anyone who wants to see the BH1750 at work in a larger project can read the ESP32 weather station with a live web dashboard, which pairs it with a DHT22 and a BMP280.

Source: the original AdriRobot article also contains the complete schematic, the sketches and the test video.

Related products

• Light intensity sensor
• OLED Display I2C 0.96” – VCC/GND/SCL/SDA

The post BH1750 Sensor: Measuring Lux with Arduino and the GY-302 appeared first on Open Electronics.

Two identical frames face each other. You throw an object into the first one and it appears to come out of the second instantly, with no video trickery. It is the linked-portal illusion from Portal, rebuilt in hardware by James’ Programming. The system relies on a flywheel launcher that fires a replica of the object out of the second portal as soon as the first one detects an incoming throw.

The heart of the project is an Arduino Uno R4 in the WiFi version, which coordinates sensors, actuators and LEDs. Approaching objects are detected by time-of-flight distance sensors. The actual launch is handled by a flywheel launcher, the same principle used in the flywheel launchers of modern toy guns.

Two ToF sensors instead of sixteen

The history of the tests is the most interesting part of the story. The first attempts used 16 ToF sensors, a number that promised full coverage of the space in front of the portal. The result, however, was too slow: the read time of all those sensors left no margin to trigger the flywheel in time. The final version relies on just two ToF sensors, chosen for reliable passage detection.

The problem is not only electronic. A flywheel launcher has a mechanical delay between the command and the object coming out, so the system has to pre-trigger the launch while the object is still flying towards the first portal. The ToF sensors track the approaching trajectory and give the firmware time to work out the right moment to send out the replica.

• Arduino Uno R4 for system control
• Time-of-flight distance sensors for tracking
• Flywheel launcher to fire the replica
• Addressable LED rings for the portal glow
• Servo for the alignment mechanism
• 3D-printed frames on a custom aluminium chassis

Servo-assisted alignment and measured limits

To repeat the cycle without human intervention, the object has to be put back in its starting position. A servo-assisted alignment mechanism recentres and repositions the objects after every throw. The addressable LED rings, mounted on the frames, reproduce the typical glow of the portals in the game and provide the visual signal that the system is active.

The project took about nine months to complete. The most honest figure, though, comes from testing: the detection and self-alignment systems only worked about one time in twenty. That is the real limit of a system that has to guess trajectory, flight time and mechanical delay within a fraction of a second. Anyone wanting to rebuild it must allow for this variability, not just the electronics.

The details of the project, from the sensor tests to the launch mechanism, can be found on James’ Programming’s site. If you want to understand how the flywheel delay is compensated for with ToF sensors, that is the place to start.

For anyone wanting to replicate the sensing side, a ToF laser distance sensor based on the VL53L3CX is the same type of component used to track approaching objects. The rest is mechanical engineering: frames, chassis and flywheel have to be designed and printed with patience.

Source: https://circuitdigest.com/news/maker-builds-a-linked-portal-illusion-using-arduino-uno-r4-flywheel-launcher-and-tof-distance-sensors

Related products

• Arduino UNO R4 WiFi Set with USB-A / USB-C Cable
• ToF Laser Distance Sensor with VL53L3CX

The post Linked Portals: Portal’s Illusion Becomes Real Hardware appeared first on Open Electronics.

Two complementary market footprints have teamed up to make battery and charging infrastructure more intelligent for EV fleets across India. Datakrew and Gaadin Technologies have signed a Memorandum of Understanding (MoU) to collaborate on integrated EV fleet, battery and charging solutions for customers across their respective markets. The collaboration will combine Datakrew’s EV battery and vehicle intelligence with GaadinAI’s EV charging infrastructure management platform.

The strategy intends to create a more connected operating view for fleet operators, charge point operators and mobility businesses across Asia Pacific, the Middle East, Africa and other markets. Under the collaboration, each company will be able to bring the other’s capabilities into relevant customer opportunities, while also working together where customers require a more integrated view across the vehicle, battery and charging infrastructure.

Connecting the Vehicle and the Charger

As electric fleets scale, vehicle operations and charging operations are increasingly becoming part of the same operating system. Yet in many fleets today, vehicle and battery data sits in one platform while charger, session and energy data sits in another. Operators can see what happened on either side, but often lack the context needed to understand how the two are affecting each other.

That separation matters because charging behaviour influences battery ageing, while battery condition influences vehicle availability, safety, performance and long-term asset economics. Looking at both sides together creates a stronger basis for operational decisions than treating the vehicle and the charging network as independent systems.

The MoU brings together Datakrew’s capabilities in EV battery intelligence, IoT-enabled vehicle data acquisition and AI-driven fleet analytics with GaadinAI’s EV charging management and energy management capabilities. The shared objective is to give customers a more complete operating picture: how a vehicle is being used, how its battery is behaving at cell and pack level, how it is being charged, and how those factors interact over time.

Commenting on the collaboration, Dr. Sumanta Bose, Founder and CEO of Datakrew Pte. Ltd., said, “The vehicle and the charger are often managed as separate systems, but for an EV fleet they are part of the same operating reality. Battery condition is shaped by how the vehicle is driven and how it is charged, while charging decisions are more useful when they are informed by what is happening inside the battery. GaadinAI brings strong EV charging management and energy optimisation with additional market reach, while Datakrew brings the vehicle and battery intelligence layer. Bringing those two views together creates something much more useful for operators than either view in isolation.”

Understanding the Scope of the Collaboration

Under the MoU, Datakrew and Gaadin intend to combine their respective capabilities into integrated offerings spanning EV fleet operations, battery intelligence and EV charging and energy management.

Datakrew will contribute its EV battery and vehicle intelligence capabilities, including state of charge and state of health monitoring, cell-level voltage, current and temperature behaviour, thermal and pack anomaly detection, analysis of the effect of driving patterns and duty cycles on battery condition, and broader vehicle and fleet analytics. These capabilities are delivered through Datakrew’s OXRED platform, with vehicle data acquired through its ITUS Max device family and related integrations.

GaadinAI will contribute its EV charging management and energy management capabilities, including charge point operations across multiple charger vendors, session and energy management, charging network monitoring, and the operational and deployment experience it has built across its markets.

The two companies also intend to make relevant platform interfaces available for integration. This ensures that vehicle-side and charge-side information can be presented to customers as a connected operating view rather than as separate datasets that need to be reconciled manually. Where appropriate, both sides will also support customer engagements with technical and commercial resources from their respective teams.

Commenting on the collaboration, Sanjeev Tripathi, Founder and CEO, Gaadin, said, “As EV fleets scale, the constraint is no longer only charger availability. It is how intelligently those chargers are operated, how energy is managed, and how charging behaviour affects battery life. This collaboration is designed to address that full stack.”

Datakrew and Gaadin: Moving From Deployment to Operations

The EV industry is entering a different phase of maturity. For much of the past decade, the immediate challenge was deployment: procuring vehicles, installing chargers and putting the necessary infrastructure in place. As fleets become larger and more established, the focus is shifting toward operating those assets efficiently over many years.

That shift changes the role of data. During deployment, vehicle systems and charging systems could be managed separately because they were often solving different immediate problems. During long-term operation, however, many of the questions converge. Fleet uptime, charging strategy, battery life, energy cost, maintenance planning and residual value are closely connected, and decisions in one area increasingly influence outcomes in another.

This creates a natural role for collaboration between specialised technology providers. Battery intelligence and charging infrastructure management are both technically deep disciplines, and customers benefit when strong platforms in each area can work together without requiring one provider to replicate the other’s technology. Open interfaces and practical interoperability allow operators to retain flexibility while gaining a more complete view of their electric assets.

The Datakrew–Gaadin collaboration is built around that principle. Each company will continue to focus on its own area of expertise, while making it easier for customers to connect the vehicle, battery and charging layers where there is a clear operational benefit.

What it Means for the Customers

For customers, the value of the collaboration is expected to be operational rather than simply technical. Instead of managing fleet and charging information as separate exports or dashboards, operators can work toward a connected view in which charging sessions, vehicles, batteries and duty cycles can be interpreted together.

That creates the potential for charging decisions to be informed by battery condition rather than by energy demand alone. Over time, operators may be able to make more deliberate decisions about which vehicles are charged, how frequently they are charged, how deeply they are charged and how charging behaviour should vary based on battery condition, route requirements and fleet availability.

The combined view can also help with fault isolation. An unusual charging event can originate from the charger, the vehicle, the battery or the interaction between them. When information from both sides is available together, engineering and operations teams have more context to identify the likely source of a problem and respond appropriately.

The partnership intends to reduce the integration burden on customers. Operators already working with either company may be able to access complementary capability through an existing technology relationship rather than independently sourcing systems and then commissioning a separate integration between them.

Importantly, the collaboration does not require either company to become a full-stack provider. Both platforms remain distinct, giving customers the ability to combine specialised capabilities while retaining flexibility across mixed vehicle fleets and multi-vendor charging environments.

From Complementary Capabilities to a Joint Offering

Datakrew has focused on what happens in the vehicle and inside the battery, while GaadinAI has focused on what happens across the charging network. The areas are closely connected in day-to-day EV operations, but they require different technical capabilities and operating experience. By working together, Datakrew can bring battery and vehicle intelligence into charging-led customer conversations and into markets where Gaadin already has operational presence and relationships.

Gaadin, in turn, can extend the depth of its charging proposition by helping customers understand the condition and behaviour of the vehicle and battery at the other end of the charging session. The commercial model is intended to remain practical. Each company can introduce the other into relevant customer opportunities, and both can pursue joint opportunities where a customer has a clear need spanning the vehicle, battery and charging layers.

The post Driving the Future: Inside Datakrew and Gaadin’s Partnership to Reshape EV Fleets appeared first on ELE Times.

Вітаємо команду ІСЗЗІ КПІ ім. Ігоря Сікорського з високим результатом kpi ср, 10/14/2026 - 10:04

The working principle of an electric vehicle (EV) relies on electrical energy stored in a large battery pack. An electric motor converts this electrical energy into mechanical energy, delivering power to the drivetrain to rotate the wheels and create motion. The exterior of an electric vehicle looks very similar to that of a car running on fuel but the powertrain installed inside an electric vehicle works very differently compared to the combustion engine in a fuel-powered car.

A major difference between a fuel-car and an electric vehicle is that an EV can generate power while applying brakes or slowing down, converting kinetic energy into electrical energy; a fuel-powered car does not support this method.

The complete working mechanism of an EV involves coordination between several systems: the battery pack, battery management system (BMS), power electronics, inverter, electric motor, transmission, thermal-management system and vehicle control system. These systems communicate with each other to control the flow of electricity from the battery to the wheels and recover energy when the vehicle slows down.

Battery Pack Stores Electrical Energy

It is the primary energy storage device containing thousands of individual battery cells arranged into modules and assembled into a large battery pack. It uses lithium-ion battery technology because of its small size, lightweight, high energy density, and low self-discharge rate. The battery stores energy in chemical form and releases it as electricity when the vehicle requires it.

The Battery-Management System Controls the Battery

The Battery Management System is responsible for monitoring and controlling the battery pack. Its monitoring parameters include state of charge (SoC) and State of Health (SoH), which helps the BMS monitor, protect, and optimize the battery pack. To perform its functionalities, it uses a combination of hardware and software components such as cell monitoring ICs, cell balancing circuits, stack communication, and CAN bus.

Power Electronics Control the Flow of Electricity

Power electronics perform switching operations by rapidly switching high-power solid-state semiconductor devices (MOSFETs, IGBTs, and thyristors) to control the flow of electric current. This method can reduce energy losses in the form of heat compared with traditional approaches that rely on resistors before advanced semiconductor switching.

Other core functionalities of power electronics include pulse width modulation to control the voltage or power delivered to the load, energy storage and filtering to manage high-power flow between the battery, electric motor, and accessories, and feedback control loops that adjust the switching frequency or duty cycle in real time to maintain stable power delivery and prevent fluctuations.

The Inverter Converts Battery Power for the Motor

The energy transferred from battery to electric motor is via inverter. It is an important link between a battery and motor that converts DC current from the battery into AC current for running the traction motor.

When the driver presses the accelerator, the vehicle’s control system determines the required power for the demanding acceleration. The inverter then converts DC current from the battery into a controlled AC waveform for the motor. When the vehicle is accelerating, the flow of energy from the battery to the wheels is shown in the given flow chart.

Battery ➔ Inverter ➔ Electric Motor➔ Transmission ➔ Wheels

The Electric Motor Converts Electricity into Motion

The conversion of chemical energy stored in a battery to mechanical energy via the inverter takes place in three phases and it also controls the frequency and voltage of the produced output alternating current (AC). The inverter uses high speed electronic switches (such as MOSFETs or IGBTs) to perform pulse width modulation (PWM). The technique shapes the electricity into AC cycles.

The produced AC cycles are then divided into three separate AC currents sent to the motor’s windings in a carefully timed sequence via the inverter. By adjusting the frequency of the AC power, the inverter dynamically controls the motor’s speed. By adjusting the voltage/amplitude, it changes the motor’s power and torque.

Transmission Transfers Torque to the Wheels

Once the rotational power is produced by an inverter, the drivetrain transfers that power to wheels by converting electrical energy into mechanical rotation. Electric motors spin at a very high RPM (revolutions per minute). Most EVs use a single-speed gearbox to drop this RPM to a lower, safer speed while multiplying the torque force. The resultant force is passed to a physical part, known as a differential, which allows the wheels on the same axle to rotate at different speeds while turning and the same speed to both wheels when driving in a straight line.

The Wheels Convert Motor Torque into Vehicle Motion

The last step is to convert the motor drive torque into work. The reduction gear and differential send the torque to the wheels. Force is created from the relationship between the rotating tires and the ground surface, which causes the vehicle to move. The vehicle’s control system constantly provides data such as wheel speed, accelerator position, steering angle and vehicle speed. This data can be used to control motor torque to achieve the best movement while driving an electric vehicle. These features make modern electric vehicles more advanced not only in terms of battery size but also in controlling torque because of integrated software, sensors, power electronics, and mechanical components that work together.

Regenerative Braking Recovers Energy

As already discussed at the beginning of this article, electric vehicles generate power while applying brakes or slowing down the vehicle. This feature is not available in a fuel-powered car. The amount of energy generated while applying brakes depends on the vehicle’s kinetic energy, which is then converted into electrical energy and stored as chemical energy in the battery.

Given below is the flow chart describing the flow of energy generated from applying brakes to storing energy in the battery:

Wheels ➔ Electric ➔ Motor ➔ Inverter ➔ Battery

The inverter transforms the created power into a form compatible with the battery, and the BMS decides whether the converted energy is accepted and how much is accepted.

Thermal Management Keeps the System Within Safe Temperatures

Temperature of vehicle components plays a crucial role in the proper operation of overall vehicle performance. The temperature of the electric motor should be maintained between 90°C and 95°C. This is the ideal temperature range for an electric vehicle to perform operations. Temperature above 100°C represents the risk state, which can cause battery damage or catch fire.

To avoid these major problems, vehicles come with installed thermal management systems which use liquid cooling and heating circuits to maintain an optimum temperature. Not only high temperatures, but also extremely low temperatures can affect battery and efficiency of an electric vehicle. The vehicle depends on onboard thermal management systems, active battery heaters, and specialised cabin-warming tech to deal with extremely cold weather conditions.

Conclusion

The operation of the electric vehicle depends on a precise sequence of energy conversions. Electrical energy stored inside the battery is regulated by the BMS; conversion and transfer of energy to the traction motor is through power electronics. An electric motor produces torque and transfers it to wheels through a reduction gearbox and differential. The primary purpose of the gearbox and differential is to turn high-speed motor power into smooth and controlled motion at the wheels.

At the same time, many operations are performed by an electric vehicle along with the working state of an engine such as thermal management for maintaining the suitable temperature, software platforms to control powertrain by coordinating with electronic control units (ECUs), power electronics, and BMS. An electric vehicle replaces a combustion engine with tightly integrated electronics, electrochemical, and propulsion systems.

The post How an Electric Vehicle Works: From Battery Packs to Wheels appeared first on ELE Times.

From rule-based workflows to AI-generated content and autonomous decision-making, businesses are entering a new era of intelligent automation.

The Next Stage of Enterprise Automation

Artificial Intelligence Companies are reinventing how they use products, data, and the enterprise. Automation has been a real workload saver for businesses for years and has played a role by automating rule-based manual and rule-based workflows. Then Generative AI arrived with its game-changing capability of content generation- text, images, code, technical documentation. Now we have Agentic AI, which, in addition to generating content, can plan actions, leverage digital assistants, and complete multi-step workflows with very little human guidance.

These three types of technology, Agentic AI, Generative AI, and Traditional Automation, are important for any enterprise running pilots or already investing in digital transformation. They may seem similar but will likely solve different pain points and require different deployment strategies.

Computer scientist and Coursera founder Andrew Ng has said that it’s ‘the new electricity’ because, as widely touted as the technology is, AI is going to change everything, ‘not one thing at a time’. From helping (creating content) to doing (acting), AI and automation are leading a fourth industrial revolution in manufacturing, medicine, finance, security, and IT.

What Is Traditional Automation?

Traditional automation automates instructions, rules, scripts, and flows, automating work that repeats with little human intervention. Examples include: Robotic Process Automation (RPA), batch system jobs, manufacturing controllers, enterprise business rules-based software. These systems work effectively if you know the input conditions, the environment, and the desired output, and you know the relationship between all three. For example, a manufacturing system that controls the plant to follow a control algorithm; a monitoring and alarm system where the alarm sounds when the temperature rises above a specified level; or an ERP system that automatically creates an invoice when the order fulfils certain conditions.

The primary advantages of traditional automation include reliability, stability, speed, and cost-efficiency for repetitive predictable operations. However, conventional and rule-based automation can lack robustness when data is partial, when instructions need to change, or when an unanticipated situation isn’t covered by previous rules. This doesn’t render traditional automation inaccessible, though. There are still uses for conventional automation in situations requiring deterministic behaviour, accurate timing, and consistent reactions—safety-sensitive industrial machinery still needs designed controller hardware. There are still uses for conventional automation in situations where you need deterministic behaviour, accurate timing, and consistent reactions- safety-sensitive industrial machinery still needs designed controller hardware.

What Is Generative AI?

The outputs of generative AI models are created based on the data and format you input into the model. Copywriting, summarisation, coding, translation, and visual design are all use cases for Large Language Models (LLMs), image generation models, and multimodal AI. Unlike classic automation, which relies on structured data, generative AI understands natural language input and can be used by marketers for writing campaigns, software developers for code snippets and summarising technical documentation, and product teams to create ideas for new product designs.

Enterprises are applying Generative AI in their automation use cases. These use cases include customer service, managing the knowledge base, research, and software engineering. Generative AI is useful for providing employees easier ways to search extensive document repositories and to translate complex technical content into understandable content.

However, the technology is imperfect. Models may generate incorrect statements, invented references, or misinterpret instructions. Their results can require review by a human subject matter expert- particularly in technical, financial, legal, and safety- critical contexts. Moreover, generative AI doesn’t just generate content; it lacks the power or capability to actually perform the action. A model might prepare a maintenance report, but it can’t change an asset-management system or make an engineering assignment on its own.

What Is Agentic AI?

An agentic AI can goal-seek (when given instructions), reason out (by planning and executing steps to accomplish a goal), use tooling (e.g., APIs and tools), get feedback, and alter behaviour if the context changes. We see agentic AI as being powered by an LLM (or, in our focus case, a Generative AI) for reasoning and language tasks, while utilising APIs, enterprise data, memory, rules, etc. Agentic AI systems are taught by enterprise chat to explore how they can use generative models for input interpretation, problem solving, and action planning.

Think of a particular IT support function. A classic automation would trigger an alert whenever a server fails. A Generative AI assistant may review the alert and suggest a short list of the most probable root causes. An Agentic AI system that has been configured correctly would gather diagnostic information, review peer-approved troubleshooting instructions, recommend actions, and carry out peer-approved remediation.

Agentic capabilities also enable coordination of multi-agent AI. A retrieval agent might surface results, while one or more subsequent specialised agents carry out processing, and yet other sketches out an execution plan. Multi-agent support might facilitate a variety of advanced workflows, but supporting such collaboration introduces additional problems-especially in coordination, monitoring, permission, and accountability. Agentic skills do not mean that humans lose control.

Agentic AI vs Generative AI vs Traditional Automation: Understanding the Differences

The biggest contrast between Agentic AI, Generative AI, and Traditional Automation is how each approaches a given task. The traditional Automation approach is to follow a set process. This is most effective for repetitive tasks where the data inputs and outputs are known—examples include AP automation, predefined reporting, and assembly line control.

Generative AI generates text or other output from a prompt. It is helpful for writing documents, summarising, generating code, and knowledge work. Agentic AI combines reasoning, planning, and use of tools to achieve a long-term goal via a series of steps. It can gather information, decide between alternatives, connect to multiple interacting applications, and determine when a goal has been reached.

For instance, with traditional automation, the ticket would be assigned based on parameters, and with Generative AI, it could be summarised and potentially even responded to. Generative AI could even be used by an agent to create a draft resolution. An Agentic AI could retrieve the customer order history, compare that to the refund policy, generate a suggested outcome, and activate a supported process step. And it’s not always a case of choosing just one: all three can be used together in the same automation.

Real-World Applications Across Industries Manufacturing and Industrial Operations

At the manufacturing stage, Traditional Automation sets the pace for manufacturing, conveyor planning, and repetitive assembly. Generative AI may help engineers when they read logs, write manuals, or guide troubleshooting of failed equipment. Agentic AI can support authorised workflows: Collect sensor data, generate a service ticket, check availability of spare parts, and coordinate dispatching a technician. In the industrial use case, keep the AI agents as close as possible to the traditional control system: Request safety interlocks and high-impact actions only after engineering control approval has been obtained.

Healthcare and Financial Services

In healthcare, Generative AI in the healthcare could generate summarise of clinical documentation, and help with administrative correspondence. Agentic AI might lead scheduling, obtaining approved records, and similar tasks. Clinical decision-making would require appropriate professional governance.

In Financial Services, traditional automation handled transactional processing, whereas Generative AI can create summaries of financial documents and even assist with customer engagement. Agent AI can help with fraud investigation by gathering evidence and escalating concerns. Payments and changes to accounts should have controls and audit trails.

Cybersecurity and IT Operations

Typical security automation generates alerts by configured indicators. Agentic AI may help security analytics by summarising incidents, investigation reports and producing plain language explanations of technical results. Agentic AI for cyber security may gather approved data sources, prioritise alerts, collect evidence, and carry out approved actions.

However, with greater access comes greater risk. A badly trained agent could alter data, disclose sensitive details, or make a mistake and take the wrong action. This is why organisations need least-privilege access, observability into actions and decision points, and the ability to pause and revert those decisions.

Challenges and the Road Ahead

Digital automation processes are different. You are switching from high-volume test automation to a completely new process, and there are a few factors to consider before you decide. Data quality, integration cost, human resilience, security, and performance. Conventional automation is reliable but less flexible. Generative AI is flexible but unpredictable. Agentic AI is flexible but unpredictable. Agentic AI is more powerful operationally but comes with new, more complex risks, as the system can query applications.

Microsoft CEO Satya Nadella has been talking about an emerging agentic world- where AI agents operate in the jobs of humans, teams, and enterprises. This vision’s next step is to utilise enterprise systems to orchestrate work between teams and individuals and not simply in response to the work they submit. Pragmatic advice: automate the routine work that is deterministic; Generative AI for work that involves language and content generation; and Agentic AI for case orchestration that is multi-step, multi-function, multi-stakeholder, multi-outcome where the complexity merits more nuance. Minimise human oversight as the scale of potential consequences of an action increases.

Conclusion

Looking at Agentic AI vs Generative AI vs Traditional Automation, we see three flexible dimensions for enterprise tech: Traditional automation provides predictable execution, Generative AI allows machines to produce and consume new data, and Agentic AI gives machines the ability to orchestrate a series of actions to achieve an explicit goal.

Hence, for businesses, the goal shouldn’t be to replace each process with the latest AI, but rather to choose the right capability for each use case, artfully connect the systems, and retain the right level of human oversight. An enterprise that leverages both deterministic automation and Generative AI with well-governed AI agents will be more agile, productive, and responsible.

The post Agentic AI vs Generative AI vs Traditional Automation: How Intelligent Systems Are Transforming Enterprise Operations appeared first on ELE Times.

Керівник виробничої компанії Артем Ющук: "Чекаємо студентів, які вміють створювати" Інформація КП ср, 10/14/2026 - 08:00

Apple branding is front and center in the company’s resurrected smart home “push”. Although broader ecosystem compatibility is also feasible, you’d never know it from the messaging.

Within my 2024 CES coverage, I devoted a section to the industry-developed Matter smart home interoperability standard, which had originated in December 2019, as well as to the associated Thread wireless protocol. I was not encouraged by the then-current industry-adoption status, nor with the implementation robustness of what few implementations did exist, although I clung to a sliver of sooner-or-later “hope springs eternal” optimism.

The Matter smart home communication standard, built on the foundation of the Thread (based on Zigbee) wireless protocol, had no shortage of associated press releases and product demos in Las Vegas this week. But to date, its implementation has been underwhelming (leading to a scathing but spot-on recent diatribe from The Verge, among other pieces), both in comparison to its backers’ rosy projections and its true potential.

Not that any of this was a surprise to me, alas. Consider that the fundamental premise of Matter and Thread was to unite the now-fragmented smart home device ecosystem. If you’re an up-and-coming startup in the space, you love industry standards, because they lower your market-entry barriers versus larger, more established competitors. Conversely, if you’re one of those larger, more established suppliers, you love barriers to entry for your competitors.

Therefore the lukewarm-at-best (and more frequently, nonexistent or flat-out broken) embrace of Matter and Thread by legacy smart home technology and product suppliers. Suffice it to say that I’m skeptical about Matter and Thread’s long-term prospects, albeit only cautiously so. I just don’t know what it might take to break the logjam that understandably prevents competitors from working together, in spite of the reality that a rising tide often does end up lifting all boats…or if you prefer, it’s often better to get a slice of a large pie versus the entirety of a much smaller pie.

I’ve also appropriately scattered Matter and Thread mentions within a series of follow-up pieces, most notably my subsequent CES 2025 summary.

A year later, is the situation better? Not really, candidly. For a more in-depth supplier-sourced perspective, I encourage you to read Aalyia’s coverage of her time spent last week in Silicon Labs’ product suite, including an interview with Daniel Cooley, CTO of the company. Cooley is spot-on when he notes that “it is not unusual for standards adoption to progress slower than desired.” I’ve seen this same scenario play out plenty of times in the past, and Matter and Thread (assuming they eventually achieve widespread success) won’t be the last. I’m reminded, for example, of a quote attributed to Bill Gates, that “We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next 10.”

Cooley is also spot-on when he notes that Matter and Thread don’t necessarily need to go together; the Matter connectivity standard can alternatively use Ethernet (either wireless, aka Wi-Fi, or wired) for transport, along with Bluetooth Low Energy for initial device setup purposes. And granted, there has been at least some progress with both Matter (in particular) and Thread over the past year.

Version 1.4 of the Matter specification, announced last November, promises (quoting from Ars Technica’s coverage) “more device types, improvements for working across ecosystems [editor note: a concept called “Enhanced Multi-Admin”], and tools for managing battery backups, solar panels, and heat pumps”, for example. And at CES, the Connectivity Standards Alliance (CSA), which runs Matter, announced that Apple, Google, and Samsung will accept its certification results for their various “Works With” programs, too. That said, Amazon is notably absent from the CSA’s fast-track certification list

As I write these words in October 2026, we’re nearing two years since Matter 1.4’s release. The spec is now at the v1.6 level, with further enhancements including belated support for cameras and other sensors, along with energy management systems; you can read all the details at the associated Wikipedia entry. And speaking of Silicon Labs, for additional background info I’ll commend to your attention a still-relevant EDN article series published in early 2023 and authored by Rob Alexander, the company’s Principal Product Manager for Matter:

• How can device makers streamline Matter certification
• Why Matter matters
• How to connect existing smart home devices to Matter

That all said, industry adoption still seems like it’s stuck in first gear, that is assuming it’s (arguably) moving forward at all. And specific to Apple, whose re-engagement with the smart home market went public earlier today, Matter seems to be little more than a convenient alternative means of achieving baseline access to Apple’s otherwise proprietary HomeKit ecosystem without need to pony up for a paid license, as was timely exemplified by yesterday’s TP-Link smart plug teardown. Indicative of this seeming irrelevance, Matter and Thread are mentioned only in passing in Apple’s press release covering partnerships with other companies.

Enter the brand-new HomeView

If I had to bet, I’d wager that the HomeView smart home hub has been stuck in the ready-for-production queue for a while now, awaiting a sufficiently robust AI-enhanced successor to the legacy Siri assistant service. The outcome product’s industrial design hearkens back to both Amazon’s latest-generation Echo Show series, released a year ago, and to Apple’s own 2002-2004 era iMac G4 computer.

Shown here is the product variant with a down-firing woofer and two passive radiators built into the base; a wall-mountable version with only the two 7” full-range drivers in the display is also available. Both cost $299, run an app-restricted operating system also branded HomeView, functionally reminiscent of the Apple Watch UI and with an intriguing derivative-of-CarPlay angle, and are based on the Apple Silicon A18 SoC; the DRAM size wasn’t announced (although in the iPhone SoC variant, it’s 8 GBytes). And there’s zero mention of Matter or Thread anywhere in the press release this time, although on-site media inquiries revealed that HomeView can in fact act as both a Matter controller and bridge, along with as a Thread border router.

The above conceptual usage promo video is admittedly compelling (IMHO, at least); I’ll cover shortly the privacy ramifications and implementation of the multi-user scenario shown in it.

Evolutionary advancements also garner announcements

The HomePod mini smart speaker was originally introduced in October 2020, with more colors added to the product line mix a year later (and a teardown by yours truly ~1.5 years after that), so a redesign was arguably overdue. We didn’t get much today, but it was at least something. The SoC inside is now the S10, versus the prior S5, both originally intended for various Apple Watch generations and this time Apple Intelligence-capable.

Then there’s the Apple TV 4K, the newest generation of which candidly and bafflingly seems to have been cut off at the knees by its creator on day one. Its SoC upgrade from the A15 Bionic in the 2022 version of the device to the A18 affords it AI capabilities…but Apple’s also bringing Siri AI to both the 2022 and 2021 versions of the device (presumably predominantly cloud processing-based in these older, latter cases), so if you already own one, you’re good. The newest version embeds a three-microphone array that lets you shout at it from afar…but the remote controls included with legacy Apple TV 4K versions already embed a microphone.

And speaking of remote controls, the newest Apple TV 4K’s version embeds a speaker so you can prompt it to emit a locating sound if it’s stuck between the cushions of your sofa…but that same remote control can also be purchased separately for $59 for use with legacy Apple TV 4K versions. And did I mention that the newest Apple TV 4K costs $299, both a $50 uptick from the current price of its equivalent-capacity predecessor (which itself saw a $100 price increase from the original $149 earlier this year) and twice the price of Google’s TV Streamer 4K (which itself is notably pricier than equivalents from Roku, Walmart, and the like)? The only other notable benefit that the newest Apple TV 4K affords is integrated stereo and surround sound support, but actualizing this particular aspiration necessitates one or two matched pairs of only second-generation HomePods and/or HomePod minis.

Privacy-assuring redundancy

Wrapping up, the aspect of today’s announcements that I actually found most interesting was what Apple referred to at the end of the HomeView press release as “Private and Secure by Design” and I alluded to by the “Distributed identity validation” mention in this piece’s title.

If you haven’t yet seen the conceptual usage promo video I embedded earlier, please go back and watch it before continuing. Two things you’ll likely note straightaway are that:

• The HomeView device dynamically recognizes each user audibly by voice and/or visibly by face, and
• The HomeView device responded by dynamically tailoring its UI to each user’s preferences as well as more generally by replying using that user’s dataset.

Voice and face recognition are admittedly getting more responsive and reliable all the time, but they’re still not perfect. The latter’s not even an option with the camera-less HomePod mini v2 and 2026 iteration of the Apple TV 4K. And when you’re dealing with a user’s personal information—emails and text messages, calendar and contacts data, music and image libraries, etc.—you need to be absolutely sure of who you believe you’re interacting with, no matter that you’re presumably interacting with someone who lives in the home where the device is located.

That’s why personalized AI is only available on today’s announced devices for users who:

• Have registered Apple accounts, and
• Have unlocked FaceID-capable iPhones (translation: not the latest iPhone Duo, for example) and iPads logged into those accounts and either connected to the same Wi-Fi network as the HomeView, HomePod mini v2 and/or 2026-version Apple TV 4K, or recently on Wi-Fi but currently logged in via cellular (I’m assuming this latter exception handles cases where someone’s iPad or iPhone briefly drops Wi-Fi).

It also, of course, conveniently excludes Android smartphone and tablet owners and the like. Ahem.

That’s “all” I’ve got for you today. Rumors suggest that Apple’s got another event scheduled for two weeks from today. We’ll see; if so, I’ll see you back here then. For now, as always, I welcome your thoughts in the comments!

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

Related Content

• Apple’s question for the developer: Are you up for an AI do-over?
• The 2025 WWDC: From Intel, Apple’s Nearly Free, and the New Interfaces Are…More Shiny?
• The 2024 WWDC: AI stands for Apple Intelligence, you see…
• Apple’s processor cadence: A pending stutter-step for improved long-term edge inference?

The post Apple heads Home: Distributed identity validation, and how much does Matter matter? appeared first on EDN.

Lumentum Holdings Inc of San Jose, CA, USA (which designs and makes optical and photonic products for optical networks and lasers), Astera Labs Inc (which provides rack-scale AI infrastructure through purpose-built connectivity solutions) and Corning Inc are giving a joint demonstration of PCIe-over-optics connectivity for AI rack-scale architectures in Astera Labs’ booth #B34 at the 2026 Open Compute Project (OCP) Global Summit at the San Jose McEnery Convention Center (12–15 October). The rack-level demonstration combines an Astera Labs Scorpio Smart Fabric Switch with Lumentum’s 1060nm vertical-cavity surface-emitting laser (VCSEL)-based optical interconnect platform and Corning multi-mode fiber connectivity...