Feed aggregator

Unfinished circuit board for controlling Nema 17 stepper motors on a robotic arm. submitted by /u/esp_lukaz [link] [comments]

PyBLE is an open-source MicroPython IDE that communicates over Bluetooth LE, letting you code, run, and debug ESP32 boards wirelessly from a tablet or iPad—no cloud, no USB cable, no PC required.

Control a gate or other electronic devices from your smartphone using the Ganimede.E12 board and a dedicated mobile app, with a focus on privacy and security.

Gemma Translator is an open-source multilingual voice interpreter for Raspberry Pi 5 that runs entirely on-device, using Google Gemma 4 and LiteRT, with a retro-terminal UI and no cloud dependency.

Cheaper, faster, and more fun than ordering from china! PS, I didn't put any acetone down the drain. I just needed a solvent resistant surface to clean the mask off. All the acetone went into the atmosphere and my lungs instead. submitted by /u/BlownUpCapacitor [link] [comments]

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

A maker known as PRBS23 has freed the MasterBuilt Gravity 800 Grill controller from proprietary firmware, replacing it with an open source firmware featuring PID temperature control, over-the-air updates, and a real-time web interface.

Build a simple seven-note electronic keyboard using the versatile 555 timer IC. This project explains the astable multivibrator configuration and how to calculate resistor values for musical notes.

Build a no-code ePaper weather dashboard with the Seeed Studio XIAO EE05 and SenseCraft Seeedash. Drag-and-drop widgets, flash firmware, and display temperature, humidity, wind, and more on a 4.26-inch ePaper screen.

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

Build a scriptable USB keyboard using a Teensy board that emulates a standard keyboard and can be controlled over serial from a laptop or a Raspberry Pi, letting you interact with pre-boot menus and BIOS settings without a physical keyboard.

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

Be prepared to respond to “electrical overstress” claims from semiconductor suppliers by citing their own datasheet entries.

During my automotive embedded career, I was heading a product team controlling auxiliary functions of a diesel engine powertrain for passenger vehicles.

As you are likely already aware, a “Check Engine”  lamp illuminates on the driver dashboard in case of any malfunction with the engine or its control system. This activation alerts the driver, so that he or she can get the malfunction rectified before continuing the journey.

In one of our production batches, the vehicle assembly line technician started reporting “erratically and intermittently illuminating check engine lamp” as feedback. All of these vehicles were summarily rejected and blocked from further dispatch.

Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale

Tempers predictably flared all across the vehicle plant as the population of rejected vehicles grew rapidly. Curiously, our electronic control unit (ECU) associated with this function had been performing flawlessly for the last few years. It was a mystery to all of us why such a problem should crop up so suddenly.

When the failure was analyzed in our laboratory, it quickly became clear that the output driver IC pin used for driving the LED was pumping around 4 mA of current through the LED even in the “off” state! The datasheet had guaranteed a maximum leakage current value of around 0.5 mA. The output driver IC was apparently misbehaving, at least as far as the associated driving pin was concerned.

The IC semiconductor supplier’s application engineers were contacted and briefed about the problem. They later responded with a stock diagnosis of “electrical overstress” as the root cause.

“But what can ever ‘overstress’ your driver pin in such a simple circuit?,” we replied in attempting to counter the (lack of) logic behind their answer. “A simple short wire connects the ECU to the dashboard LED connector.”

“It must be electroshock discharge (ESD) events occurring during your electronic assembly, then,” they responded. “Sometimes ESD precautions are violated by the assembly technicians. We have faced such problems from a few customers in the past.”.

We clearly understood by this point that the semiconductor supplier team was trying to wriggle out of the situation without taking any responsibility or otherwise helping us. “How can so called ‘ESD events’ be partial only to a specific pin of your driver chip?,” we responded, in striving to alert them to the flaw in their reasoning. “It should have caused random failures across all units we’ve manufactured to date, and with all of the pins of your driver chip.” However, the supplier team clung to its reasoning, bringing the situation to an impasse.

Every passing day, our plant situation was getting more and more explosive, when I was struck by an idea. I asked our team to note down the alphanumeric production batch codes stamped on all of the culprit chips. To our surprise, all of them were identical! In contrast, the healthy chips all had other production batch codes.

We wrote an inquiry mail to the semiconductor company, asking them to decode the alphanumeric production batch code stamped on the culprit chips. Their answer was predictable: “It means: This chip was manufactured in country X and plant location Y, with month/year code as mm/yy.” Apparently, all of the culprit chips were manufactured at a specific plant location, where a production quality lapse was presumably leading to the disaster we were facing.

What was the way ahead? We pre-filtered out all of the culprit chips based on their production batch code, preventing them from being assembled on our boards. We also filtered them out of our supply chain by directing our distributors not to supply such chips to us. These steps solved the problem for once and all!

The lessons and insights behind this case are as follows:

• Be thorough with your circuit analysis. This means, among other things, completely understanding all datasheet entries for all key components.
• Prepare yourself to respond to “electrical overstress” responses from semiconductor suppliers by citing their own data sheet entries that support your design decisions.
• “Electrical overstress” can occur due to numerous possible causes, such as ESD, over voltage, over-current, excessive power dissipation etc. Your prior circuit analysis during design verification should rule out these possibilities. Encourage semiconductor supplier engineers to sign off your circuit analysis. This will reduce their chances of later claiming “electrical overstress” as a diagnosis.
• Be mindful of correlating production batch codes with culprit chips. During another of my experiences, this one more recent, I encountered randomly misbehaving CPU chips in one of the ECU failures I was analyzing. I was amazed to learn that all of these culprit CPUs also contained the same production batch codes. No semiconductor supplier will openly admit to quality issues in its own manufacturing plants, even if they’ll all hopefully take corrective action internally.
• Always keep in mind that a random root cause, such as ESD mishandling, cannot cause a consistent failure such the exact same pin misbehaving every single time.

Fortunately, we hit upon the corrective solution to the seemingly intractable field issue quite early, which otherwise would have led to a substantive loss of business for our vehicles and company.

Vishwas Vaidya is a graduate of the Indian Institute of Technology in Delhi, India. Currently, he is self-employed as an engineering consultant and industry faculty member in the field of embedded systems for global automotive clients and high-repute academic institutions. Vishwas’ articles and research reports have appeared in many worldwide engineering publications.

Related Content

• Vehicle emissions: Issues and workarounds for various monitoring conditions
• Stress analysis
• Semiconductor Reliability and Quality Assurance–Failure Mode, Mechanism and Analysis (FMMEA)
• Design for reliability: You have the tools

The post Overstressed over an erratically flickering check-engine lamp appeared first on EDN.

Discover the ePaper smart journal, an open-source electronic notebook built with a Raspberry Pi Zero 2 W, a Waveshare ePaper display, and an M5Stack CardKB keyboard. It offers the simplicity of paper with the power of a computer, perfect for capturing ideas without distractions.

Autonomous systems are making the transition from controlled pilot operations to large-scale deployment across transportation and industrial environments. Additionally, AI training facilities are scaling up to host thousands of AI agents operating concurrently to execute various tasks and build extensive training sets for AI models.

As these systems scale, most of the attention has focused on advances in compute, model performance, and system intelligence. One equally critical but often overlooked constraint is the network infrastructure, which will be required to transport massive amounts of data.

That challenge becomes apparent in environments where many untethered systems operate in close proximity. For example, in a robotaxi depot or factory floor, large numbers of mobile, autonomous systems generate and transfer data at the same time.

Here, the limiting factor is not simply bandwidth, but the network’s ability to sustain multiple high-throughput data streams within a confined physical area—effectively a problem of data density.

Figure 1 Wireless environments such as robotaxi depot hosting many untethered systems in proximity can’t sustain multiple high-throughput data streams within a confined physical area. Source: Peraso

Edge AI and the 10K challenge

In the early 2000’s, we faced what was called the “1000x challenge” as the data communications industry considered how to upgrade fixed and wireless networks to support high-speed access to human customers. As edge AI evolves, data demand is scaling in localized areas by at least another order of magnitude, presenting the 10,000x challenge.

Unlike human-oriented connected devices, which send human-digestible amounts of traffic, these systems continuously produce large datasets as part of normal operation. Cameras, LiDAR, radar, and other sensors capture detailed information about the physical world, often accumulating terabytes of data over short periods of time.

At the same time, the models that power these systems continue to grow. It’s common for operating models to reach several gigabytes and need regular updates to reflect new data and performance improvements. This creates a steady cycle of uploading raw data and downloading updated intelligence.

The effect is a network demand model, which is very different from human-driven demand. Traffic is less sporadic and is heavily upload-biased as systems dump their accumulated experience data. With numerous systems operating in a defined area, demand is constantly high in volume.

Data density becomes the limiting factor

When many autonomous systems operate in close proximity, a supporting wireless network is needed not only to provide high link speeds, but to do so consistently for every client system in the operating space. The defining factors for the network are not only link speed but also data density.

The constraint shows up clearly in places like autonomous vehicle depots, robotics-heavy factories, and AI training facilities. These environments concentrate large numbers of systems into relatively small areas. Each one generates data during operation, uploads it for processing, and receives updated models in return. When many systems follow this cycle at the same time, demand becomes highly synchronized.

Where wireless approaches fall short

If all autonomous systems were stationary, then more cables, fiber, switches, and routers could be installed to provide each device with its own multi-gigabit connection to the network. Mobile systems require wireless connectivity, and the analogy is that more access points or distribution nodes are required to increase data density.

This is where real physical constraints enter the picture: a fixed amount of frequency spectrum and bounds on the amount of data, which can be transported within that frequency space. That translates into very high-density data service that requires reuse of the allocated frequency over a small physical area.

The frequency reuse capability of any wireless technology is determined by how well neighboring access points and clients can isolate their signal from neighboring systems using the same frequency. In other words, a frequency reuse metric is defined by the ability of each terminal to focus its transmission energy, defined as antenna directivity, and the tolerance of each receiver to interference created by its neighbors, which is defined as a signal-to-noise-and-interference-ratio (SNIR) threshold.

Wi-Fi technologies in the sub-7 GHz spectrum, such as multiple-input and multiple-output (MIMO) and 4096 QAM modulation, have done an amazing job at increasing the capacity of each channel, pushing capacity close to the Shannon bound. However, this capacity comes with constraints. Maximum throughput requires very high SNIR use of wide channels, which are in short supply within the allocated spectrum. Moreover, designers must maintain high space-time diversity in order to support multiple MIMO streams.

Furthermore, the realization of high antenna directivity in a phased array configuration, which allows beam steering, is determined by the number and spacing of antenna elements. These factors scale with the carrier frequency, so antenna arrays for higher frequencies are proportionally smaller than antenna arrays for lower frequencies.

Wi-Fi systems generally have one antenna element for each spatial stream. Top-tier Wi-Fi systems can support 16 spatial streams, but rather than setting the antenna spacing at a distance of ʎ/2 for optimal beamforming, antenna spacing is optimized to provide the spatial diversity needed for MIMO operation.

Given a wavelength of 5 cm for a 6-GHz carrier, a square array of 16 elements would typically be 15 cm (1ʎ spacing) to 45 cm (3ʎ spacing) per side. These larger dimensions increase beamwidth and reduce spatial directivity. Additionally, each antenna element will be on the order of 0.5 to 1 ʎ (2.5 to 5 mm).

Since the ability of sub-7 GHz Wi-Fi to scale for high data-density is limited by the carrier frequency and subsequent antenna dimensions, we are led to consider millimeter wave frequencies, which can reduce the antenna element and array sizes by an order of magnitude. Two frequency bands for consideration are 28 GHz, as supported by 3GPP FR2 standards, and 60 GHz, as supported by 5G FR2-2 (or U) and “WiGig” IEEE 802.11ad/ay.

Figure 2 The 60-GHz technology ensures zero interference while operating many wireless networks in the same space simultaneously. Source: Peraso

5G mmWave technology can provide high throughput and high directivity, but some practical limitations impact its suitability for many edge AI applications. First, when considering the 28-GHz band, which represents the primary deployment of 5G mmWave equipment, it’s important to understand that it is a licensed band and is often heavily subdivided. Operation in this band for private networks will be complicated by the need to lease spectrum from the primary holder.

This consideration would not apply to 5G systems designed for the 60-GHz unlicensed band, but in reality, very little hardware has been developed supporting 60 GHz, as few operators want to deal with unlicensed band operation when they have heavily invested in swaths of protected spectrum.

A second consideration for any 3GPP-based equipment is cost. Designed to meet the needs of major network operators, a small cell, indoor node may cost $10 to $15k, and an outdoor RU can easily double the cost. Compared with the economy of WiGig-based 60 GHz, 3GPP-based solutions cannot actively address the edge AI scaling challenge.

WiGig meets high-density edge AI challenge

From inception, IEEE 802.11ad and subsequent 802.11ay standards, commonly known as WiGig, were designed to provide high data density. Leveraging up to 14 GHz of contiguous spectrum with a carrier wavelength of about 5 mm, small high directivity antennas at the access points and client terminals realize multi-gigabit throughput per channel with high isolation from neighboring connections. Furthermore, with no interference from common Wi-Fi, 60-GHz networks can be implemented with high confidence in the availability of clear channels.

In contrast to sub-7 GHz Wi-Fi, WiGig’s data capacity is not dependent on multi-stream MIMO, thus antenna elements can be spaced at ʎ/2 (about 2.5 mm) in order to provide optimal shaping of the antenna beam. With such a small wavelength, the number of antenna elements can also be reasonably scaled up to tailor the beamwidth for the required frequency reuse and resulting data density.

A new breed of integrated 60-GHz products demonstrates proven solutions to the data-density challenge. Providing RF and baseband ICs with compact PCB integrated antennas, these modules make it possible to develop and deploy systems where data density, reliable performance, and cost all matter.

From connectivity to data movement

As data density increases, we should not overlook the fact that it places greater demands not only on the wireless infrastructure, but also on the backend network resources and backhaul. That’s because datasets acquired by autonomous systems must be transported to the AI training engines, which will continuously evolve in terms of operating models and new models provided to the systems in the field.

Net capacity demand needs to be addressed throughout the network, which opens the opportunity for innovations in decentralized AI learning systems. That, in turn, places more learning resources close to the network edge. As this capability evolves, we envision a level of high integration between the wireless network and the local controller, which will ensure reliable data transfer for all domain clients.

Edge AI systems are increasing both the volume of data and the concentration of that data within physical environments. So, as deployments scale, performance will depend on how well networks handle these conditions.

Here, data density provides a useful way to think about the problem. It focuses attention on the limits that appear when many systems operate together, rather than looking at devices one at a time.

Wireless technologies that support high levels of spatial reuse and efficient short-range communication are well positioned to meet these demands. As edge AI continues to expand, those characteristics will matter more than incremental gains in peak speed alone.

Michael Hamilton is VP of business development at Peraso Inc.

Related Content

• Top 10 edge AI chips
• Designing edge AI for industrial applications
• Edge AI powers the next wave of industrial intelligence
• Why Connectivity Has Become an Edge AI Design Decision
• Edge AI Is Forcing a Rethink of Predictive Maintenance Architecture

The post Data density: The constraint reshaping wireless for edge AI appeared first on EDN.

Освітня конференція «Освітній хаб: точки доступу» kpi пт, 09/04/2026 - 12:26

Specialty semiconductor and performance materials producer 5N Plus Inc (5N+) of Montréal, Québec, Canada has been selected by the US Department of War to receive a US$7.3m award to establish domestic production of gallium arsenide components for US defence applications. This follows presentation of the firm’s proposal at the inaugural Defense Industrial Base Accelerator (DIBX) Pitch Competition in Philadelphia (25-27 August)...

A four-video series explores the analog-to-digital and digital-to-analog converters on the Arduino UNO R4, from basic concepts to building a practical electronic voice changer with just a few passive components and a dynamic microphone.

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

element14 Community has launched a new design challenge focused on smart home and healthcare projects, inviting engineers, makers, and tech enthusiasts to build innovative prototypes that improve everyday living and personal well-being.