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

So this is circuit main consist of short circuit under and over voltage protection and ideal diode using mosfet Amongst which short circuit and ls ideal diode condition But ov uv condition failed due to my back to back mosfet architecture and false trigger at the gates It failed But for someone who’s fresher with 3month experience i would consider this as a fair try:) submitted by /u/Worldly-Cream-5550 [link] [comments]

Couldn't find any documentation, so I made my own! The cathode line took 1-3V across the thin wires in the display, and the metal grid along with the phosphorous layer both were hooked up to the 12V+ end while the cathode was hooked up to 12V- I eventually plan on driving it with a teensy 4.0 and a bit more logic to drive the 4-bit ULN2803 interface. In case anybody ever has to work with one of these I'm going to leave some of these SEO terms: VFD 6-LT-09 Echo-6 94V-I PWB-AGN 2161317-007 VFD-7-Segment (kHz/MHz) ULN2803 submitted by /u/chknboy [link] [comments]

The "slayer exciter" circuit is the classic introduction to SSTCs. I really wanted a version with just one coil because once you eliminate the loosely coupled resonant transformer, you end up with a greatly simplified design. It basically drives a series resonant circuit through a RF choke, using a coupling capacitor as feedback. I'm not the first to think of that but there was always something or other that I didn't like about other people's designs so this version might be my own :) I encourage you to try it, let me know if you can get the thing to at least light a neon bulb or something. My tiny axial inductors aren't handling the power well 🔥 And btw component values are "for demonstration only", do not assume they're optimal! submitted by /u/Lily_1225 [link] [comments]

Silicon photonics-based chip-to-chip optical connectivity firm Ayar Labs of San Jose, CA, USA — which is pioneering co-packaged optics (CPO) for AI scale-up — has secured an additional $150m in funding, bringing its total primary capital raised in 2026 to $650m. Separately, it discloses that Wiwynn made a strategic investment earlier this year. Wiwynn, a cloud IT and infrastructure provider for data centers, joins a growing group of strategic backers that includes Alchip, AMD, Intel, MediaTek, and NVIDIA...

The Optical Internetworking Forum (OIF) has issued the Implementation Agreement (IA) for 1600ZR Coherent Interfaces, defining an interoperable 1.6T coherent line interface and frame format for single-span, amplified, point-to-point dense wavelength division multiplexing (DWDM) links up to 120km...

In booth #2173 at the European Conference on Optical Communication (ECOC 2026) in Malaga, Spain (21–23 September), the Ethernet Alliance is hosting a live multi-vendor interoperability demonstration at a pivotal moment for high-speed Ethernet, as bandwidth and performance requirements continue to climb and the 1.6 Terabit Ethernet ecosystem gains momentum. IEEE P802.3dj, which includes new specifications for 1.6Tb/s Ethernet, is also advancing through the standards process...

This is part of a project to calibrate an ESD simulator that I purchased and repaired recently. I needed to measure up to 30 kV safety with a standard multimeter. The divider makes up 200 megaohms on top and 1.1 megaohms on the bottom. Multiple 8 kV rated resistors are used in series to achieve the working voltage. With the multimeter's own 10 megaohm input being taken into account, the division ratio is 200:1. I have to be very careful when making these measurements because a loss of ground to the ESD simulator could damage my multimeter. PCB files are on GitHub: https://github.com/umi-eng/open-hardware-esd-calibration/tree/main/voltage-measurement-fixture submitted by /u/liamkinne [link] [comments]

There’s a lot you can potentially do to boost your WAN’s downstream and upload speeds, as well as to minimize its latency. But only if your service provider lets you.

This is my final post in this series. Really. I promise! Like I’ve said before, I’ve learned a lot in the near-year that started last October, when an inadvertent cable cut led to chronic broadband and TV service outages. Four blog posts’ worth, apparently. But I’ll wrap up today. Really. I promise!

At the conclusion of last week’s third post:

• Debugging intermittent Comcast, part 1: Scenario-setting
• Debugging intermittent Comcast, part 2: Remediation details
• Debugging intermittent Comcast, part 3: Retrospective analysis

I’d been seduced by the Sirens’ Song of the Comcast technician, who, after swapping out some hardware, had confidently proclaimed “wait until you see how fast your Internet access will be now!” Unfortunately, although my connection was now rock-solid reliable, it wasn’t seemingly any faster than before. Why, I wondered? Thereby launching myself down the packet-hole into broadband-land (with apologies to Alice and the White Rabbit for the admittedly lame analogy). Recall upfront that I hadn’t yet done the necessary online research to realize that I was already running near the upper end of my location-determined Comcast-offered speed tier options.

Spectral extension and overlap

DOCSIS 3.1, I learned through my research, is theoretically capable of leveraging wire-based frequencies all the way up to 1,218 Mhz (original plans for further spectrum extensions up to 1,794 Mhz are now instead comprehended in subsequent-gen DOCSIS 4.0). In the process, though, it spectrally overlaps with MoCA 2.5 beginning at 1,125 MHz by default, at least (hold that thought for a dedicated-topic post to come, hopefully in the near future).

Recall, too, that I still had a point of entry (PoE) filter sitting ahead of the cable modem, initially a self-purchased and -installed standalone unit, subsequently integrated within the grounding block supplied by Comcast. In both cases, however, the specified low-pass cutoff frequency was only 1,002 MHz, matching that of the lingering two-way splitter in-between the filter and the cable modem (connection-shared with a CABLEcard receiver, therefore the splitter). And building on the fact that I wasn’t currently running MoCA anyway, I suspected that nobody else in my neighborhood was, either.

Why, then, did all the extra hardware “gifts” the technician had passed on to me at the end of his visit—standalone MoCA filters, two- and three-way splitters, etc.—have 1,002 MHz low-pass cutoffs, too, if DOCSIS 3.1 supposedly stretched to 1,218 Mhz? And what would therefore happen, I wondered, if I were to ditch the outside filter entirely, along with replacing the limited-frequency splitter in the furnace room with a spectrally wider alternative? There’s no better way to find out than to try it and see what happens, right? So that’s what I did.

Here again is the original outside setup:

Here’s my original in-the-furnace-room splitter:

And here are some snapshots of the original dataset, first as a benchmark result from my router.

Followed by a data dump leveraging my cable modem’s convenient second integrated Ethernet port.

Now let’s replace the filter-inclusive grounding block outside with a filter-less one.

And swap out the original furnace room splitter with one that spec’d operation all the way out to 2,450 MHz.

The outcome? Data suggestive of a degraded-performance response to the changes, actually. The benchmark results alternatively might simply reflect test run-to-run variability.

But the higher upstream signal power that the modem is being required to generate in the latter case is, as I first explained in Part 2, suggestive of higher channel noise level that it’s “fighting”.

Perhaps MoCA is operational somewhere in my neighborhood after all? Obviously, I immediately reversed course and returned to the original setup.

Router uniqueness and artificial constraints

The fact that I was “only” getting ~850 Mbps (average, ~890 Mbps peak) download speeds still nagged at me, particularly given that my upload speeds were notably exceeding Comcast’s estimates (43+ Mbps vs. 35 Mbps), and in spite of the fact that I’d best-case only be able to squeeze an additional 50 Mbps or so of downstream bandwidth out of the setup. My cable modem is a somewhat unique Netgear variant, the Nighthawk CM1100, which I’d first mentioned more than seven years back, with more in-depth coverage a year-plus later.

As I mentioned before, the Nighthawk CM1100 “only” implements 1 GbE connectivity, but it integrates two Ethernet ports, thereby (barely) rationalizing NETGEAR marketing’s “multi-gig” product claims.

The intent here is to optionally mate the CM1100 with a more advanced router containing dual Ethernet WAN connections, subsequently leveraging a feature known as “link aggregation”. But, as my research eventually revealed, this particular feature, not to mention the router’s broader 1 GbE (minus protocol overhead) claimed peak performance specs, were for naught “thanks” to Comcast’s unavoidable setting tweaks.

Here’s what Google AI Assistant, aggregating various info bits on the Internet that I’d already come across, spat back at me when I searched on the phrase “Xfinity 1 Gbit plan actually 800 Mbit CM1100”.

The reason your Xfinity 1 Gbps (1,000 Mbps) plan is maxing out at roughly 800 Mbps is because Xfinity explicitly limits the Netgear CM1100 to an 800 Mbps speed tier on their network.

Even though the Netgear CM1100 is a highly capable DOCSIS 3.1 modem with a theoretical multi-gigabit capability, Comcast’s official device compatibility lists cap this specific hardware for plans “Up to 800 Mbps” (previously rated for up to 945 Mbps). When an unapproved or downgraded modem is connected to a higher tier like the 1 Gig plan, Xfinity’s automated provisioning system pushes a default, restricted config file to the modem. This prevents it from pulling your full subscription speed.

Hardware and Network Bottlenecks

Beyond Xfinity’s strict software provisioning profile, your hardware setup likely has several physical bottlenecks preventing you from reaching 1 Gbps:

• Lack of a 2.5 Gbps Port: The CM1100 only features standard 1 Gbps (1,000 Mbps) Ethernet ports. Due to standard network overhead (headers, routing metadata, and packet loss), a single 1 Gbps port will max out at roughly 940 Mbps in a real-world wired environment.
• Link Aggregation Limits: While the CM1100 supports Link Aggregation (bonding its two 1 Gbps ports together to achieve 2 Gbps), Xfinity generally disables or restricts this feature on customer-owned modems. Furthermore, most consumer Wi-Fi routers do not support WAN Link Aggregation.

How to Fix It

If you want to get the full speed you are paying for, you have three primary paths forward:

• Downgrade Your Plan: Call Xfinity and drop your service to the 800 Mbps tier. Your CM1100 is perfectly optimized for this tier, you will save money on your monthly bill, and your real-world internet performance will feel exactly the same.
• Upgrade Your Modem: If you want to keep the 1 Gbps speed (or plan to upgrade to 1.2 Gbps in the future), you must purchase a modern DOCSIS 3.1 or DOCSIS 4.0 modem that features a dedicated 2.5 Gbps Ethernet port (such as the Arris Surfboard S33 or Netgear CM2000). This will allow Xfinity to push a “Next-Gen” provisioning profile to your house.
• Rent an Xfinity Gateway: You can opt to rent an Xfinity XB7 or XB8 gateway. These come equipped with native 2.5 Gbps LAN ports and are completely optimized for Xfinity’s over-provisioned gigabit speeds.

Unfortunately, as you already saw from the screenshots I shared last time, an “800 Mbps” plan isn’t offered at my particular Comcast service location. I’m also not interested in paying Comcast a monthly rental fee for the “privilege” of using Xfinity Gateway gear I’ll never own free-and-clear.

And regarding the “upgrade your modem” option, I now recall an email I received from the company in late May 2025 with the tantalizing subject line “Replace your equipment to get faster speeds – at no extra cost.” Here’s the body verbiage.

Good news

Bringing customers like you the best in-home WiFi experience is our top priority. That’s why we’re excited to give you faster speeds so your home can continue being everyone’s favorite binge, scroll, share, and stream zone.

Here’s the best part: These faster speeds are included with your current Internet plan at no extra cost.

Next steps

Your current internet equipment can’t deliver these new speeds, so we’ve compiled a list of compatible devices to purchase so that you can take advantage of the fastest speeds available to you. Click below to find a compatible device.

Find compatible devices

Or you can explore our Xfinity Gateway option, which is a modem + WiFi router in one with advanced security designed to deliver the fastest, most reliable coverage on our network.

Take action today so you can start enjoying faster speeds as soon as possible.

Thanks for being with us.

The “no extra cost” angle, perhaps obviously, was specific to the service tier I was paying for. The “replace your equipment” encouragement, on the other hand, was most definitely not “no extra cost”. And nowhere in the email, or the linked website page for that matter, did Comcast happen to mention Google AI Assistant’s tipoff that “when an unapproved or downgraded modem” such as my existing CM1100 “is connected to a higher tier like the 1 Gig plan, Xfinity’s automated provisioning system pushes a default, restricted config file” (known as a bootfile) “to the modem. This prevents it from pulling your full subscription speed”.

The information Google AI’s Assistant is sharing with me seems spot-on, by the way; an over-provisioned “800 Mbit” plan (if it theoretically existed as a service tier option for me) would likely deliver the ~890 Mbps peak download and ~43 Mbps peak upload speeds that I’m now seeing.

I’m more than a little irritated to learn that Comcast’s latest-version provisioning bootfile for CM1100, which downloads every time the modem connects to the network and overrides NETGEAR’s factory-default settings, is disabling my device’s dual-Ethernet facilities. I’m even more irritated to learn that the bootfile now also artificially restricts my modem’s peak speeds, which were previously unhindered.

And don’t get me started on the fact that Comcast wants me to drop several hundred dollars on a brand-new replacement modem with capabilities that the speed tiers available at my location can’t even leverage, discarding my perfectly good existing hardware in the process, just so I can take full advantage of the service I’m paying for.

Thanks but no thanks, Comcast. Thoughts, readers? Sound off in the comments!

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

Related Content

• Debugging intermittent Comcast, part 1: Scenario-setting
• Debugging intermittent Comcast, part 2: Remediation details
• Debugging intermittent Comcast, part 3: Retrospective analysis
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• A quest for faster upstream bandwidth

The post Debugging intermittent Comcast, part 4: Broadband diagnostics appeared first on EDN.

Infineon Technologies and SolarEdge Technologies, have expanded their existing collaboration to include Solid-State Circuit Breaker (SSCB) technology for high-voltage DC distribution in AI and hyperscale data centres. The collaboration addresses a key challenge in adopting 800 VDC architectures: achieving selective protection while maintaining high efficiency requires extremely fast fault isolation.

Expanding the partnership into solid-state protection addresses an important gap in the distribution layer between the Solid State Transformer (SST) and the compute rack, further advancing the end-to-end grid-to-rack concept. SolarEdge is leading the design of the Solid-State Circuit Breaker (SSCB) solution, while Infineon contributes its silicon carbide (SiC) JFET technology as a core component of the protection switch.

Rapidly increasing AI compute density is pushing the data-centre industry toward higher-voltage DC distribution architectures. In this environment, solid-state circuit breakers (SSCBs) address the need for fast and selective fault protection. Unlike AC systems, DC systems do not have a natural current zero, making fault interruption more challenging and potentially resulting in arcing when conventional mechanical breakers are used.

SSCBs overcome this limitation by using power semiconductors to interrupt fault currents in the microsecond regime, without mechanical contacts and the associated arcing. Infineon’s CoolSiC JFET technology combines low conduction losses, fast turn off capability and high robustness, making it suitable for solid-state protection applications. These characteristics can help protect high-value compute hardware from fault-related damage while supporting compact and power-dense DC distribution architectures.

The collaboration builds directly on SolarEdge’s SST platform with Infineon SiC components, first announced in November 2025. The SST is designed to enable direct medium-voltage (13.8-34.5 kV) to 800-1500 VDC conversion at over 99 percent efficiency, collapsing multiple conversion stages into a single solution while reducing physical footprint.

“High-density AI infrastructure at 800 VDC demands uncompromising efficiency and protection”, said Shuki Nir, Chief Executive Officer of SolarEdge. “Solid-state protection will enable operators to achieve both, delivering ultra-fast and dependable fault isolation without sacrificing conversion performance. Infineon’s silicon carbide technology is what makes it practical at scale.”

“Today’s data infrastructures have become more vulnerable to electrical faults, thereby driving the demand for smarter, faster and more robust power distribution systems,” said Andreas Weisl, Executive Vice President and Chief Sales Officer of Industrial & Infrastructure at Infineon. “By combining our advanced silicon carbide JFET technology with SolarEdge’s expertise in final power distribution, we are addressing these demands to ensure fast, safe and reliable operations in AI data centers.”

Building on more than 15 years of leadership in DC-coupled power electronics, SolarEdge is developing an 800 VDC powertrain for AI factories, a DC-native chain that carries power from the medium-voltage grid connection through conversion, distribution and protection to the compute rack. Infineon’s broad portfolio of silicon, silicon carbide and gallium nitride solutions provides that foundation, supporting the decarbonisation of AI infrastructure through lower losses, reduced environmental impact, and improved total cost of ownership.

The post Infineon and SolarEdge Expand Collaboration for Solid-State Protection in 800 VDC AI Data Centres appeared first on ELE Times.

This development board combines a 3.97-inch touch e-paper display with LoRa and NFC connectivity, all on an ESP32-S3R8 platform. The result is a compact, battery-powered device designed for those building portable IoT objects. The board also integrates a PDM microphone, buzzer, 6-axis IMU, and RTC, so it covers many use cases without needing external hardware.

At its core is the ESP32-S3R8 module with 8 MB of PSRAM and 16 MB of flash. The monochrome e-paper display has a resolution of 800×480 pixels and supports 4 gray levels. The SSD1677 driver manages it, while the FT6336G controller handles capacitive touch. The standout feature is the refresh speed: it goes from 4.71 seconds in quality mode to just 0.07 seconds in fastest mode. This makes it usable even for interfaces that require frequent updates.

Connectivity and integrated sensors

LoRa connectivity is handled by the Stamp LoRa-1262 module with a Semtech SX1262 chip, operating between 868 MHz and 923 MHz. This enables long-distance communication with low power consumption, ideal for remote sensors or mesh networks. NFC communication is managed by the ST25R3916 chip, which supports ISO14443A, ISO14443B, FeliCa, and ISO15693. The board with integrated display can therefore read NFC tags, communicate with smartphones, or function as a badge.

The BMI270 6-axis inertial sensor detects movement and orientation, while the RX8130CE RTC keeps time even when the board is powered off. The PDM microphone and buzzer complete the set: you can add voice commands or acoustic feedback. The board also includes a 1150 mAh battery, rechargeable via USB-C port. Everything fits in a 101 x 61 x 7.95 mm format and weighs only 74.7 grams.

Software and development tools

The board is compatible with Arduino IDE, UiFlow 2, and ESP-IDF. You can develop quickly with Arduino or take advantage of ESP-IDF’s advanced features. The project board is ready to use: just connect it via USB-C and start programming. For projects that require more computing power, you can pair it with additional ESP32 modules.

For those who want to experiment with displays and sensors, the ESP32 module with TFT touch display is a cheaper but less complete alternative. If you are only interested in LoRa connectivity, the RTX 433 MHz Long Range LoRa module can be integrated into custom projects. The choice depends on your needs: this board offers everything in a single package.

The combination of touch e-paper display, LoRa, and NFC in a compact board is rare. The fast display refresh makes it suitable for dynamic interfaces, while the built-in battery makes it portable. Here are the key points:

• E-paper display 800×480 with 4 gray levels and refresh up to 0.07 s
• LoRa with SX1262 for long-distance communication
• NFC with ST25R3916 for tag reading and communication
• BMI270 IMU, RX8130CE RTC, PDM microphone, and buzzer
• 1150 mAh battery and USB-C port for charging
• Support for Arduino IDE, UiFlow 2, and ESP-IDF

Furthermore, the low power consumption of the e-paper display extends battery life, making the board suitable for devices that must run for days. Finally, the generous PSRAM and flash allow handling complex applications without memory issues. If you are looking for a complete platform for portable IoT, this board is a solid choice.

Source: https://github.com/m5stack/M5PaperMono-UserDemo

The post ESP32-S3 board with touch e-paper display, LoRa, and NFC appeared first on Open Electronics.

This development board combines a 3.97-inch touch e-paper display with LoRa and NFC connectivity, all on an ESP32-S3R8 platform. The result is a compact, battery-powered device designed for those building portable IoT objects. The board also integrates a PDM microphone, buzzer, 6-axis IMU, and RTC, so it covers many use cases without needing external hardware.

At its core is the ESP32-S3R8 module with 8 MB of PSRAM and 16 MB of flash. The monochrome e-paper display has a resolution of 800×480 pixels and supports 4 gray levels. The SSD1677 driver manages it, while the FT6336G controller handles capacitive touch. The standout feature is the refresh speed: it goes from 4.71 seconds in quality mode to just 0.07 seconds in fastest mode. This makes it usable even for interfaces that require frequent updates.

Connectivity and integrated sensors

LoRa connectivity is handled by the Stamp LoRa-1262 module with a Semtech SX1262 chip, operating between 868 MHz and 923 MHz. This enables long-distance communication with low power consumption, ideal for remote sensors or mesh networks. NFC communication is managed by the ST25R3916 chip, which supports ISO14443A, ISO14443B, FeliCa, and ISO15693. The board with integrated display can therefore read NFC tags, communicate with smartphones, or function as a badge.

The BMI270 6-axis inertial sensor detects movement and orientation, while the RX8130CE RTC keeps time even when the board is powered off. The PDM microphone and buzzer complete the set: you can add voice commands or acoustic feedback. The board also includes a 1150 mAh battery, rechargeable via USB-C port. Everything fits in a 101 x 61 x 7.95 mm format and weighs only 74.7 grams.

Software and development tools

The board is compatible with Arduino IDE, UiFlow 2, and ESP-IDF. You can develop quickly with Arduino or take advantage of ESP-IDF’s advanced features. The project board is ready to use: just connect it via USB-C and start programming. For projects that require more computing power, you can pair it with additional ESP32 modules.

For those who want to experiment with displays and sensors, the ESP32 module with TFT touch display is a cheaper but less complete alternative. If you are only interested in LoRa connectivity, the RTX 433 MHz Long Range LoRa module can be integrated into custom projects. The choice depends on your needs: this board offers everything in a single package.

The combination of touch e-paper display, LoRa, and NFC in a compact board is rare. The fast display refresh makes it suitable for dynamic interfaces, while the built-in battery makes it portable. Here are the key points:

• E-paper display 800×480 with 4 gray levels and refresh up to 0.07 s
• LoRa with SX1262 for long-distance communication
• NFC with ST25R3916 for tag reading and communication
• BMI270 IMU, RX8130CE RTC, PDM microphone, and buzzer
• 1150 mAh battery and USB-C port for charging
• Support for Arduino IDE, UiFlow 2, and ESP-IDF

Furthermore, the low power consumption of the e-paper display extends battery life, making the board suitable for devices that must run for days. Finally, the generous PSRAM and flash allow handling complex applications without memory issues. If you are looking for a complete platform for portable IoT, this board is a solid choice.

Source: https://github.com/m5stack/M5PaperMono-UserDemo

The post ESP32-S3 board with touch e-paper display, LoRa, and NFC appeared first on Open Electronics.

NUBURU Inc of Centennial, CO, USA (a dual-use defense & security integrated platform company) says that, following notification from NYSE Regulation, trading in its common stock is scheduled to resume on NYSE American on 14 September under the ticker symbol ‘BURU’. The stock is currently quoted on the OTC Pink Market under the temporary post-split symbol ‘BURUD’...

This year, the emphasis of Electronica, Bengaluru, is on a presentation of new inspection systems. Making its presence felt, GOPEL electronic will present an array of new products at the exhibition. The Multi Line AXI X-ray inspection platform marks a new generation of inspection systems for electronic assemblies that brings a new dimension of quality to electronics manufacturing.

Advanced Technology on Display by GOPEL Electronic

Multi Line AXI combines advanced technological innovations with flexible application options and multifunction capabilities, while also offering simple and rapid adaptability to inspection tasks. This innovative AXI marks a new benchmark in X-ray inspection while supporting manufacturers in maintaining consistent quality in electronics production.

The all-purpose Multi Line is ready for all inspection tasks throughout the entire manufacturing process which includes SPI (Solder Paste Inspection), SMD (Surface-Mount Device) and THT (Through-Hole Technology) processes. Due to the modularity of the Multi Line platform, camera modules can be configured according to specific requirements and are available for other process applications through rearrangement, if ever required.

Fast test program generation, bilateral inspection and the use of a common operating platform are characteristics of devices from the Multi Line AOI platform, which ensure high quality of production at high-mix/low volume production, prototyping, and small batch sizes. The Vario Line systems combine high-speed inspection with high defect-detection performance, setting new standards in precision and efficiency through intelligent 2D/3D inspection and variable 360-degree inspection in 1-degree increments.

Testing and Programming Prowess

In the field of electrical testing and programming, GOPEL electronic’s in-system programming and boundary scan products will take centre stage: For example, the FlashFOX universal programmer supports the dynamic transfer of programming data—the programmer always retrieves the latest content to be programmed from the central server. In addition to the 8-channel version, the new FlashFOX 2 can also implement complex power supply configurations for the microcontrollers or flash devices to be programmed, thanks to four integrated independent power supplies.

The turnkey BARCUDA tester is a complete solution for testing and programming PCBAs. The stand-alone unit utilises the proven technologies of GOPEL Electronics’s Embedded JTAG Solutions, but can also be expanded to meet the functional test requirements of electronics manufacturing. The BARCUDA JTAG production tester tests and programs PCBAs with or without JTAG/boundary scan without the need for time-consuming configuration of a specialized in-house test system.

The JULIET unlimited JTAG tester is a professional, flexible JTAG/boundary scan tester that combines the entire system electronics and DUT adaptation into a single, complete unit. A total of six different models cover all production applications from simple test execution to a complete repair station with graphical fault visualisation making the system ideal for rapid prototyping and low-volume production runs.

The post GOPEL Electronic to Showcase New AOI, BScan and X-ray Inspection Systems at Electronica 2026 appeared first on ELE Times.

Infineon Technologies AG of Munich, Germany and smart energy firm SolarEdge Technologies Inc of Milpitas, CA, USA have extended their collaboration to advance solid-state circuit breaker (SSCB) technology for high-voltage DC distribution in AI and hyperscale data centers. The collaboration addresses a key challenge in the adoption of 800VDC architecture: Safe operation of increasingly power-dense infrastructure requires very fast fault-isolation to achieve selectivity while maintaining high efficiency...

​Arrow Electronics has made global remote access available to customers through its Digital Test Drive platform for evaluating NXP Semiconductors’ Ara240 discrete neural processing unit (DNPU). This gives engineers early access to run, test, or evaluate real-world performance for advanced AI models and technologies for computer vision, generative AI & multimodal systems before purchasing.

This trend comes as AI is being more heavily deployed in industrial, robotics, and intelligent vision applications, and developers now look forward to implementing more advanced AI applications close to the generation of data. Operating AI locally at the edge brings advantages such as limited latency, enhanced data privacy, and restricted reliance on cloud-hosted computation, as for those with real-time requirements.

To enable customers to discover and examine this functionality. Arrow has also included NXP’s Ara240 solutions on its Digital Test Drive, a digital test platform offered by Arrow on the web. Arrow’s Digital Test Drive, a ‘digital test platform,’ is a remote hardware test and development platform hosted in the cloud. It allows users to test real hardware, remote devices without actually owning and having a target device on their desk.

Engineers can test live systems with NXP i.MX applications processor and the Ara240 DNPU over remote systems that let engineers explore real world AI applications like computer vision, LMM inference and vision language AI without having to rely on specifications or benchmarks. From these systems, engineers can better test their intended use case for their particular project before investing hardware money and system architecture.

“Developers need practical ways to understand how advanced AI technologies will perform in real applications,” said Justin Mortimer, senior director, product marketing, Secure Connected Edge, NXP Semiconductors. “By providing access to NXP’s Ara240 DNPUs through Digital Test Drive, Arrow enables engineering teams to evaluate real-world edge AI performance faster and make informed design decisions.”

“At Arrow, we are committed to helping customers accelerate their AI journey by removing barriers between innovation and deployment,” said Shelby Schnurrenberger, vice president of supplier management, global semiconductor, Arrow Electronics. “By integrating NXP’s Ara240 AI accelerator into our Digital Test Drive platform, engineers can evaluate advanced edge AI workloads immediately, gaining hands-on experience with the technology before making hardware investments.”​

​“Together with NXP, we are enabling customers to move faster from concept to production and unlock new opportunities in intelligent edge applications. Digital Test Drive extends global access to NXP’s AI portfolio, allowing engineers to validate performance, explore use cases, and shorten development cycles from anywhere in the world. This collaboration reinforces our shared commitment to making edge AI more accessible, scalable, and practical for customers across industrial, robotics, machine vision, and emerging intelligent systems.” Schnurrenberger stated.

The post Arrow Electronics Provides Remote Assessment of NXP’s Ara240 Edge AI Accelerator appeared first on ELE Times.

ST is introducing an initiative to provide Rust drivers for many of our sensors, opening a new avenue for those looking to adopt this programming language in their embedded systems development. Obviously, we will continue to ship and maintain our C-based ecosystem.

However, we are also aware of the growing popularity of the Rust programming language, the benefits it offers for many projects, and that building a robust, platform-agnostic alternative in another programming language takes significant time and investment. It’s for those reasons that we have started porting drivers piecemeal and are now advertising our presence on crates.io and showcasing projects like Embassy STM32, which provides a hardware abstraction layer in Rust for our MCUs.

Reason One: Safety

One of the most popular aspects of Rust is its inherent code safety compared to other languages, including C and C++. In essence, that means the Rust compiler will forbid certain operations that could jeopardise memory safety. Being memory-safe means that the Rust compiler will block any memory access if it hasn’t been explicitly allocated or has already been deallocated. This is a significant departure from C and C++, where developers have much more freedom in memory management. However, it also means that bad code can lead to issues such as buffer overflows, memory leaks, and “use-after-free” or dangling pointers. All of these can result in data corruption or even security vulnerabilities.

The reason Rust is safer is that it implements Resource acquisition is initialisation (RAII), a technique that automatically and immediately allocates resources when an object is created and releases them when the object is deleted. The compiler allocates these resources to an owner and can then transfer ownership or allow another owner to borrow it if needed. As a result, Rust handles resource management and does not need a garbage collector to manage memory allocations, unlike C++, another language that implements RAII but still requires developers to manage memory themselves. In practice, the absence of a garbage collector reduces overhead, but it also makes Rust code much less lenient.

While this blog post can’t begin to scratch the surface of all the ways Rust differs from C and C++ (we won’t even go into type safety), the point above illustrates an important reason why developers are moving to Rust and why ST has already tried to provide alternatives to its sensor drivers. The Rust learning curve is high. Writing safe code that compiles is challenging because there are so many guardrails to ensure code safety. However, it also means that once the code compiles, developers have far greater assurance of safety and security. And for developers new to Rust, having open-source drivers like the ones ST provides means they can study our implementations and learn from our experience.

Reason Two: Practicality, Portability, and Performance (sort of)

Another reason developers are adopting Rust for their embedded projects is the way it handles interfaces and bus operations. Unlike C, which traditionally uses a pointer-based bus abstraction, Rust uses “Traits”, which define interfaces as types and then provide a flexible abstraction over them. Through ecosystem standards such as embedded-HAL, interfaces for buses like I2C and SPI can be implemented consistently across platforms, helping developers gain expertise. In fact, our code already uses APIs aligned with our original C drivers to ease the learning curve, and we adopted consistent naming to smooth the transition to our Rust alternative.

One misconception we often encounter is that Rust is inherently “faster” than C or C++. The truth is far more nuanced. Depending on the application, Rust may be slower than, on par with, or faster than C. However, in many instances, Rust forces teams to rewrite their application, which naturally leads to refactoring, dropping legacy code, or creating new, optimised processes. The absence of a garbage collector in Rust, or its modern compiler enhancements, certainly helps, but embedded system developers should not rush in thinking it will magically provide significant runtime improvements. However, it will offer significantly safer, often more flexible code, which is why we are providing Rust alternatives for our C sensor drivers.

Reason Three: The Rust Community

The discussions in our GitHub repository for this project show a thriving community, which is an important factor for many developers. It’s not just key industry players like Meta, Google, or Microsoft that have publicly pledged to adopt the new programming language. Many smaller teams are investing in the new language because acquiring fluency takes time, and falling behind could lead to significant technical debt that would benefit a competitor. We know that adoption is still in the early phase. This is why we are providing Rust sensor drivers now. ST wants to support those who want to be first in this transition, which seems to be shaping the future of embedded systems development.

The best way to get started is to install Rust using rustup, then, as developers build their project, grab one of our packages on Crates. Our GitHub Page also walks users through the download and integration process. We offer examples in Cargo to help teams get results faster. And while the drivers themselves allow engineers to be MCU-agnostic, the examples we use are written for STM32 microcontrollers and primarily use the NUCLEO-F401RE development board. Current Rust drivers focus on I2C and SPI interfaces, as these are by far the most commonly used, but additional support, including I3C, is underway, and we will update this blog post as we release major updates.

The post Rust MEMS Drivers: 3 Reasons to Try and Adopt Our New Sensor Drivers Written in Rust appeared first on ELE Times.

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

The ThinkNode M9 from Elecrow is a fully autonomous LoRa mesh communication terminal. You don’t need a smartphone to write messages: the physical QWERTY keyboard and color TFT display are enough. The MeshCore firmware manages the mesh network between devices, so messages travel from node to node without any infrastructure. It’s designed for emergencies, hiking, and outdoor activities where cell coverage is unavailable.

At the heart of the device is an ESP32-S3R8 with a 240 MHz processor, 512KB SRAM, 8MB PSRAM, and 16MB of flash. The Semtech LR1110 LoRa module handles radio transmission in the EU868 and US915 bands. The built-in GPS supports GPS, GLONASS, Galileo, and BeiDou. A 2,300 mAh Li-Po battery powers everything, with an estimated standby time of 2-3 days.

How the LoRa mesh terminal works

The MeshCore firmware coordinates mesh communication between terminals. Each message can be forwarded by other nodes until it reaches its destination. The 37-key QWERTY keyboard sends key press events via I2C. The firmware polls the keyboard in the main loop, so response is immediate. The 2.4-inch TFT display with 320×240 resolution shows the user interface, including messages, network status, and GPS position.

The LR1110 module also includes advanced geolocation features, but the external GPS remains the primary reference for position. Wi-Fi and Bluetooth add connectivity for initial configuration and debugging. The firmware can be updated via USB-C, which also serves for battery charging. The device measures 126 x 67 x 10.3 mm and weighs 123 grams, so it fits in a pocket without any trouble.

The build is solid and compact. Operating temperature ranges from -10°C to 60°C, while storage goes down to -20°C. The price of $74.90 makes it accessible for anyone wanting to experiment with mesh messaging without spending ham-radio money. For those who want to approach the LoRa world starting from a single board, a TTGO LoRa 868 MHz with ESP32 and OLED display does the same job as the ThinkNode: same European band, same microcontroller, onboard display.

Software and customization

The MeshCore firmware is open source and can be compiled with ESP-IDF. Those who prefer simpler environments can use Arduino IDE or MicroPython. The display is managed with LVGL, a lightweight graphics library suitable for small screens. The documentation includes instructions for modifying the interface and adding custom functions.

The QWERTY keyboard is the strong point compared to other LoRa terminals. Many devices require a smartphone to type, but here everything happens on the board. Additionally, multi-constellation GPS support makes positioning reliable even in remote areas. The firmware automatically handles mesh routing, so the user doesn’t need to configure anything complex.

• Off-grid text messaging without a smartphone
• Multi-constellation GPS for accurate positioning
• EU868 and US915 bands selectable via firmware
• Wi-Fi and Bluetooth for configuration and debug
• Rechargeable Li-Po battery with 2-3 days of autonomy

Why choose a standalone LoRa terminal

In emergency situations, cellular networks can fail. A LoRa mesh terminal creates an alternative network among participants. Range depends on the environment: in open field you exceed one kilometer, in the city it decreases but the mesh extends coverage. The ThinkNode M9 is designed for this scenario, with robustness suited to outdoor use.

The physical keyboard avoids the typing errors of touchscreens, especially with gloves. The color display at 200 cd/m² is readable even in sunlight. For those who want to build a similar device from scratch, you’ll need a 2.8-inch TFT touch display and a UBLOX NEO-6M GPS module; the QWERTY keyboard, however, remains the hard part to source. The ThinkNode M9 remains a complete, ready-to-use product.

The project board on GitHub includes schematics, firmware, and assembly instructions. The community around MeshCore is active and releases regular updates. Support for ESP-IDF and Arduino IDE makes the device suitable for both beginners and experts. Finally, the competitive price and compact size make it an ideal companion for those who live outdoors.

Source: https://github.com/meshcore-dev/MeshCore/pull/2942

Related products

• TTGO LoRa32 SX1276 with ESP32 and SSD1306 OLED
• LCD TOUCH SCREEN 2.8 "SPI

The post ThinkNode M9: LoRa mesh terminal without a smartphone appeared first on Open Electronics.

The ThinkNode M9 from Elecrow is a fully autonomous LoRa mesh communication terminal. You don’t need a smartphone to write messages: the physical QWERTY keyboard and color TFT display are enough. The MeshCore firmware manages the mesh network between devices, so messages travel from node to node without any infrastructure. It’s designed for emergencies, hiking, and outdoor activities where cell coverage is unavailable.

At the heart of the device is an ESP32-S3R8 with a 240 MHz processor, 512KB SRAM, 8MB PSRAM, and 16MB of flash. The Semtech LR1110 LoRa module handles radio transmission in the EU868 and US915 bands. The built-in GPS supports GPS, GLONASS, Galileo, and BeiDou. A 2,300 mAh Li-Po battery powers everything, with an estimated standby time of 2-3 days.

How the LoRa mesh terminal works

The MeshCore firmware coordinates mesh communication between terminals. Each message can be forwarded by other nodes until it reaches its destination. The 37-key QWERTY keyboard sends key press events via I2C. The firmware polls the keyboard in the main loop, so response is immediate. The 2.4-inch TFT display with 320×240 resolution shows the user interface, including messages, network status, and GPS position.

The LR1110 module also includes advanced geolocation features, but the external GPS remains the primary reference for position. Wi-Fi and Bluetooth add connectivity for initial configuration and debugging. The firmware can be updated via USB-C, which also serves for battery charging. The device measures 126 x 67 x 10.3 mm and weighs 123 grams, so it fits in a pocket without any trouble.

The build is solid and compact. Operating temperature ranges from -10°C to 60°C, while storage goes down to -20°C. The price of $74.90 makes it accessible for anyone wanting to experiment with mesh messaging without spending ham-radio money. For those who want to approach the LoRa world starting from a single board, a TTGO LoRa 868 MHz with ESP32 and OLED display does the same job as the ThinkNode: same European band, same microcontroller, onboard display.

Software and customization

The MeshCore firmware is open source and can be compiled with ESP-IDF. Those who prefer simpler environments can use Arduino IDE or MicroPython. The display is managed with LVGL, a lightweight graphics library suitable for small screens. The documentation includes instructions for modifying the interface and adding custom functions.

The QWERTY keyboard is the strong point compared to other LoRa terminals. Many devices require a smartphone to type, but here everything happens on the board. Additionally, multi-constellation GPS support makes positioning reliable even in remote areas. The firmware automatically handles mesh routing, so the user doesn’t need to configure anything complex.

• Off-grid text messaging without a smartphone
• Multi-constellation GPS for accurate positioning
• EU868 and US915 bands selectable via firmware
• Wi-Fi and Bluetooth for configuration and debug
• Rechargeable Li-Po battery with 2-3 days of autonomy

Why choose a standalone LoRa terminal

In emergency situations, cellular networks can fail. A LoRa mesh terminal creates an alternative network among participants. Range depends on the environment: in open field you exceed one kilometer, in the city it decreases but the mesh extends coverage. The ThinkNode M9 is designed for this scenario, with robustness suited to outdoor use.

The physical keyboard avoids the typing errors of touchscreens, especially with gloves. The color display at 200 cd/m² is readable even in sunlight. For those who want to build a similar device from scratch, you’ll need a 2.8-inch TFT touch display and a UBLOX NEO-6M GPS module; the QWERTY keyboard, however, remains the hard part to source. The ThinkNode M9 remains a complete, ready-to-use product.

The project board on GitHub includes schematics, firmware, and assembly instructions. The community around MeshCore is active and releases regular updates. Support for ESP-IDF and Arduino IDE makes the device suitable for both beginners and experts. Finally, the competitive price and compact size make it an ideal companion for those who live outdoors.

Source: https://github.com/meshcore-dev/MeshCore/pull/2942

Related products

• TTGO LoRa32 SX1276 with ESP32 and SSD1306 OLED
• LCD TOUCH SCREEN 2.8 "SPI

The post ThinkNode M9: LoRa mesh terminal without a smartphone appeared first on Open Electronics.

Understanding the brain requires tools that can follow neural activity across many scales: from millisecond electrical spikes in individual neurons to brain-wide circuit dynamics that change over months, years, and even a lifetime.