Feed aggregator
PVA TePla and Fraunhofer IISB establish Joint Lab for aluminium nitride substrates
Solid state airflow sensor with linear 4-20mA output
A self-heated Darlington transistor pair makes a simple, sensitive, and sturdy airflow sensor. But first an annoying non-linearity needs unbending.
If you take a self-heated transistor in a TO-92 package and force it to hold a constant temperature differential above ambient, the power input required to keep it stuck to setpoint will be determined by its thermal impedance ZT relative to the air, as given by:
ZT = ZJ + 1/(SC + KT √AF )
where:
ZJ = junction-to-case thermal impedance = 44°C/W
SC = still-air case-to-ambient conductivity = 6.4 mW/°C
KT = “King’s Law” thermal diffusion constant = 0.75 mW/°C√fpm
AF = air flow in ft/min
Wow the engineering world with your unique design: Design Ideas Submission Guide
The AF term suggests the arrangement might be handy for air flow measurement, because of the way it makes ZT, and therefore power input for a given differential, a function of air speed. Figure 1 shows the resulting power vs AF relation a differential (Dt) = 31oC. Do note, however, the annoying non-linearity.
Figure 1 This graph shows the power dissipated vs air speed of a TO-92 held at a constant 31oC above ambient Pw = 31/ZT.
Figure 2 shows a practical thermostat circuit to achieve and maintain this delta-T while outputting a signal predictably related to Pw. It utilizes a Darlington sensor transistor pair (Q1 and Q2) to compensate for ambient temperature and convert the resulting nonlinear Pw curve into a linearized airflow readout. Its current mode output is compatible with the long cable runs often seen in airflow measurement applications.
Figure 2 This linearized Darlington anemometer circuit supports a 4-20mA current mode output. Adjust R10 to calibrate 4mA (zero fpm), R11 to calibrate 20mA (250fpm).
Here’s how it works.
Q1 serves as the self-heated sensor modeled in the Figure 1 math, with Q2 providing ambient temperature compensation. Opamp A2 runs a feedback loop that forces the Vbe differential between Q1 and Q2 (and thus the temperature differential between Q1 and ambient) to hold a constant 31oC. It does this (with the help of Darlington current gain) by forcing Q1’s current draw (I) through R3 to drive Q1’s power dissipation (Pw) to follow the fig.1 curve of heat-vs-air flow. The resulting voltage developed (IR3) is the basis of the air speed measurement.
Okay so far. But how does compensation for Figure 1’s nonlinearity happen? Well, happily the function of Q1’s Pw vs collector current I isn’t linear either. In fact Pw = 5vI – I2R3. That quadratic I2 term is the key. It creates the lovely linearizing curve shown in Figure 3.
Figure 3 This graph details Q1 power dissipation vs collector current. Pw = 5vI – I2R3.
The 2nd-order curvature of Figure 3 compensates for the bend in Figure 1. Although the match isn’t perfect, when converted to the 4-20mA by opamp A1, the realized output is a calibrated readout of air speed that differs from ideal by less than +/- 5% from 0 to 250fpm, as shown in Figure 4.
Figure 4 This graph’s data relates anemometer output vs airspeed: FPM = 15.6(Iout – 4mA) +/-10FPM.
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
- Self-heated Darlington transistor pair comprises new air flow sensor
- Linearized portable anemometer with thermostated Darlington pair
- Nonlinearities of Darlington airflow sensor and VFC compensate each other
- Improve thermal airflow sensor PSRR with just two resistors
- A groovy apparatus for calibrating miniature high sensitivity anemometers
The post Solid state airflow sensor with linear 4-20mA output appeared first on EDN.
Who needs a timing light? I turned an old one into a simple self-powered LED timing light.
 | I reused the housing of an old timing light and built a new LED timing light from scratch. It works for checking ignition timing and adjusting ignition advance on many motorcycles and even carbureted cars with a distributor. The circuit, build process, and testing are covered in the full video. If anyone is interested, the link is in the comments. [link] [comments] |
Infineon supplying CoolSiC MOSFETs 1200V and gate drivers to ADVANTICS
Understanding all costs involved in analog ASIC development
The costs of designing and producing an analog ASIC chip can be grouped into three main parts: human capital, software tools, and prototype fabrication. While all three are equally critical to success, it’s important to note that design tools and wafer foundries are ubiquitous. All semiconductor companies have equal access to them, and it’s rare that a problem with the performance of an analog ASIC comes from the tools used or the wafer foundry that produced it.
Human capital: The ultimate differentiator
If you’re considering an analog ASIC, specification development, circuit design, and physical layout are the most critical steps. These are the true differentiators between the “doers” and “pretenders” (for more on this, read my article “For a Successful Analog ASIC, First Weed Out the Pretenders”).
They require the highest level of analog design skills. I’m referring to teams of craftsmen that have done hundreds of complex precision analog chips that meet requirements others said were impossible. These individuals typically have 30 to 40+ years of experience and can command salaries exceeding $350K per year. They are scarce, they are expensive, and they are worth every penny.
If you remember one thing from the paper mentioned above, let it be this: human capital is the ultimate differentiator.
The feasibility study: De-risking the design
It all starts with a feasibility study conducted by the engineers who will be designing the chip. Figure 1 below shows the steps involved.
Figure 1 The feasibility study must be conducted by the engineers designing the chip. Source: Javelin ASIC Devices
The feasibility study is a risk aversion step intended to identify and quantify risks and establish a plan to mitigate them for a successful result. Additionally, it allows the design team to quantify the time required to do the design and assess a fixed cost to complete it.
Done properly, it can take up to two months to complete the study; more if significant invention is involved, less if the chip is an amalgamation of off-the-shelf existing silicon. These costs range from $20K to $70K and are always credited to the full development if a contract is executed. Since some simulation is required, costly software tools are involved early on.
Figure 2 Human capital and software tools unite in the design phase. Source: Javelin ASIC Devices
Design phase: From specification to architecture
Several things occur during the design phase. The preliminary specification becomes a working document and grows from a 4–6-page product definition paper to an in-depth datasheet that may well exceed 50 pages, becoming more detailed with minimum and maximum limits, definitions of registers, power requirements, and more.
The thoroughness of the datasheet is a measure of the craftmanship of the design team. The datasheet drives the wafer fabrication process selection that matches the requirements for voltage, current, noise, precision, cost, and more to the most optimal foundry and a specific process.
The architecture of the ASIC is defined in functional blocks and teams with decades of experience with those blocks (charge pumps, 24-bit and higher A/D converters, precision low-drift Vrefs, and chopper-stabilized amplifiers) are created and assigned. Whenever possible, programmability using registers is added to tighten Gaussian distributions and maximize yields.
Collaboration, reviews, and designer governance
Weekly calls with the customer’s engineers are scheduled to report on status progress and offer design alternatives that may improve performance, reduce chip size (cost), avoid environmental impacts (electrical noise and temperature variations), add functionality, and more. At the completion of each major block, a design review should be scheduled with the customer’s engineering team that dives deep into a transistor-level explanation of how each aspect of the block works. It includes schematics, simulation result targets compared against specification requirements, and an overview of any external components required.
Software design tools are acquired for the duration of the project. Quarterly calls with customer corporate management are established to review schedules and cash flows. Digital teams are assembled to manage logic, memory, and register requirements.
Test strategy: Third-party vs. custom systems
In parallel with the design of the ASIC itself is the design of the test system. Sometimes evaluating a precision analog ASIC can be as challenging as the chip itself. There are two schools of thought. One is to generate a test specification to be supplied to a third-party test house that fits the capabilities of their array of commercially available test systems.
These companies will review the specifications and recommend which brand of tester is best suited. They will charge a one-time fee for the development of any unique hardware and software program needed to interface your ASIC to their tester. Getting everything up and running can easily cost between $100K and $200K.
An alternative that Javelin uses is to develop a custom test system, specifically tailored for the ASIC. We build two identical systems—one for the wafer probe and one for the final test of the packaged chip. They can be collocated in any test house and interface with the required handlers, or they can be stand-alone.
We prefer this approach because it assures perfect correlation between the wafer probe and final testing. And surprisingly, it’s less expensive. This approach offers complete flexibility in moving testing from one location to another without incurring duplicated tooling costs.
Custom ASIC economics vs. commodity products
When a commodity analog semiconductor company develops a standard product intended to be sold to thousands of disparate customers, they absorb all development costs and amortize it into their unit pricing, hoping their marketing department has identified sufficient sales potential to recover the costs and still show a profit in the long term.
However, when a custom ASIC is involved, the story changes slightly. There is only one customer, and it’s responsible for paying for the complete development. In exchange, it gets exclusivity to the chip.
Exclusivity is important because the justification for paying development costs often includes integrating proprietary IP or creating new inventions to achieve performance advantages over competitors using off-the-shelf components. Other advantages include a significantly smaller size, lower power consumption, protection from product obsolescence, and much more.
Software tools: Powerful but expensive
Although the development costs associated with creating the new IC also include wafer fabrication and package assembly, I want to stay focused on human capital and software tools for a moment. There’s more to it than meets the eye. For those not familiar with chip development costs, the numbers can be intimidating.
While the semiconductor industry often focuses on the multi-billion-dollar capital expenditures of leading-edge digital nodes, the economics of analog IC development follow a distinctly different trajectory. Development does not involve huge capital equipment investments. The investment comes in the form of human capital and tool rental.
Over the past few decades, the tools for supporting analog chip design have improved dramatically, driven in part by the growth in analog applications in automobiles, consumer products, and sensor calibration and signal conditioning, in which precision and accuracy, along with quality and reliability, are of paramount importance. A few of the most popular tools used by analog designers include Cadence Virtuoso and Spectre, Synopsys Primetime, and Mentor Graphics Calibre.
Regardless of whom you select to do your analog ASIC, they will likely use these same tools, as they are available to everyone. However, they are expensive and these costs need to be accounted for. Prices aren’t published and NDAs prevent users from disclosing them, but estimates for a single, fully featured seat for analog/mixed-signal design (layout and simulation) range from $150k-$300k per year. A seat is typically one “open window” for one user, so you can see how the dollars add up quickly.
Prototype fabrication and mask costs
Most silicon fabricators offer multi-product wafers (MPW) for some or all of their processes. These are highly valuable tools for seeing silicon samples at a low cost. They afford the ability to locate and remove any errors prior to production.
On popular processes, they are run monthly, but on others they are run less so, maybe two, three, or six times a year. If you miss the window with an available tape-out, it could be a long wait. MPWs are not required, but when available, they are an important step in evaluating early silicon and debugging test systems well ahead of production.
Whether engaging an MPW or not, the final significant tooling expense is the production mask set. Prices vary from wafer fab to wafer fab and are dependent on the number of masks required to make the ASIC. Figure on spending $75K to $150K.
Figure 3 Test and assembly operations are a critical part of ASIC fabrication costs. Source: Javelin ASIC Devices
Experience matters: Mitigating risk in ASIC development
If an off-the-shelf new chip design runs into a problem, the semiconductor company has the option to simply delay introduction while their engineers sort things out. That is not an option for your ASIC. You are counting on it to be available on a specific date to support the launch of your new or next-generation product.
Don’t be fooled by companies claiming they have been in business for 20 or 30 years. That means very little. What’s important is the experience of the folks doing the work. How long has each engineer been designing analog ASICs?
Everyone makes mistakes, but mistakes are part of learning. You need teams that have made the mistakes decades ago and learned from them. Don’t let your project become a learning experience for novices. You deserve to see the resumes of the people responsible for your ASIC. Ask to see them and insist on speaking with the engineers themselves.
Which brings up another point: you deserve to have direct access to any engineer working on your ASIC. Don’t accept some project manager or marketing manager acting as a gate keeper to be the focal point for all communications between you and your supplier. They add no technical value and insert delays in communications, which more often than not are time critical.
Bob Frostholm is co-founder and CMO of Javelin ASIC Devices.
Related Content
- Analog ASICs Made Simple
- 7 Steps to a Successful Analog ASIC
- Demystifying Analog and Mixed-Signal ASICs
- 7 myths of analog and mixed-signal ASIC design
- A 12-point overview of the advantages of custom analog ASICs
The post Understanding all costs involved in analog ASIC development appeared first on EDN.
Wolfspeed files patent infringement lawsuit in US against Navitas
CXL Type 3: Tooling and boot path from power-on to usable memory
Part 1 of this min-series established why CXL Type 3 memory expanders matter for capacity-bound workloads and where expander memory sits in the latency–capacity pyramid relative to local DRAM. It also explained what must align across the stack before memory becomes usable—CPU and BIOS enablement, kernel CXL support, device firmware, RAS paths, and the NUMA topology that Linux exposes through cxl_pci. Next, it delved into why many CXL problems surface, such as placement or bandwidth imbalance rather than obvious enumeration failures.
This part builds on that foundation with the tools and timeline you need day-to-day to navigate system bring-up. You will learn which user-space utilities reveal what the OS actually sees on the CXL fabric, how to differentiate between “device present” to “memory consumable,” and how to walk the boot sequence from slot power and DRAM training through DVSEC discovery, CEDT read, CDAT delivery, ACPI handoff, and finally driver bind-framing each stage as a validation checkpoint with recognizable failure signatures.
Let’s get to work.
Kernel drivers establish whether a CXL Type 3 device is present, configured, and represented as memory, but validation engineers spend much of their time during bring-up reconciling what firmware advertised, what the driver registered, and how user-visible policy (NUMA placement, DAX/region modes, namespace layout) matches the intended deployment. That reconciliation is difficult from dmesg and kernel logs alone. Practical programs rely on a small set of user-space utilities that expose sysfs and kernel abstractions in forms suitable for automation and field triage.
Essential user-space tooling
cxl/libcxl (often shipped with ndctl sources as “CXL tools”)
The cxl command-line interface and libcxl library walk the CXL sysfs hierarchy—ports, endpoints, memdevs, and decoders—and print structured output, commonly JSON. This is the closest thing to a standard “show me what the OS thinks on the CXL fabric” tool; serial numbers, capacity hints, which PCI function hosts a memdev, and whether decode topology looks sane before debugging performance or NUMA. It’s usually the first stop after dmesg when firmware and driver disagree about what should be visible.
ndctl
ndctl provides user-space administration for the LIBNVDIMM/regions/namespaces model that Linux also uses for some persistent-memory-class bring-up paths. Depending on kernel and platform integration, CXL-attached memory may surface as a separate NUMA node or through PMEM-style abstractions. ndctl lists regions, creates or destroys namespaces, and clarifies whether capacity is in a state software can consume, not merely whether a PCI device exists.
daxctl
daxctl manages direct-access (DAX) devices and related system-RAM or devdax configuration knobs exposed by the kernel. Some deployments expose memory through DAX-oriented paths, especially when treating capacity like PMEM/DAX rather than only anonymous DRAM. daxctl helps verify mode, online/offline behavior, and whether the system matches workload expectations. Misconfiguration here often looks like “memory is there but unusable, wrong interface, or wrong policy.”
numactl and numastat
numactl controls NUMA placement policy; numastat reports per-node memory statistics. Expander memory frequently lands as a separate NUMA node or as far memory relative to a socket. These tools prove placement hypotheses during bring-up, bind threads and allocations, measure local versus remote behavior, and catch cases where OS defaults silently place hot pages on CXL. Many “CXL is slow” bugs are NUMA policy bugs, not link bugs.
acpica-tools
This suite provides a useful utility, acpidump, which extracts ACPI tables from the kernel and dumps the raw values of the specified ACPI table. While a user should not need this during regular bring-up, it can be very useful in sticky situations when the DDR memory enumerates but does not show up either as a NUMA node or as a PMEM device. In such cases, it might be useful to dump certain acpi tables and parse raw values via a debug script.
lspci and setpci (pciutils)
Since CXL Type 3 memory expanders attach over a PCIe/CXL link, pciutils belongs in every bring-up kit alongside CXL-specific tools. lspci lists PCI functions on the bus, reports vendor and device IDs, class codes, negotiated link speed and width, and—when invoked with verbose flags—the extended capability chains that expose CXL and DVSEC registers. It’s often the fastest way to confirm that the endpoint is visible at the transport layer, that link training reached the expected generation and lane count, and that the kernel bound the intended driver (for example cxl_pci).
setpci reads and writes configuration-space dwords for targeted experiments during debug—checking capability offsets, toggling test bits where platform policy allows, or verifying that firmware left key control fields in the expected state. Used together, lspci answers “what does the bus see?” (peek) and setpci supports “can we inspect or adjust a specific config field?” (poke) before diverting attention to higher-level CXL utilities or firmware logs.
Topology and observability helpers
lstopo/hwloc produce human-readable CPU–memory topology maps—useful to confirm how the OS labels CXL memory relative to sockets. lspci/setpci (pciutils) confirm the PCI/CXL function at the bus level when debugging binding (cxl_pci versus overrides) and link issues. A verbose lspci dump reveals device capabilities that Part 3 decodes in detail.
Another, currently open-source, tool for viewing the PCIe hierarchy is pcicrawler, which shows the PCIe topology similar to lspci but in a nicer format.
From power-on to usable memory
The end-to-end path for a CXL Type 3 memory expander runs from first application of host and slot power to the point the operating system can issue CXL.mem accesses to host-managed device memory (HDM). Exact timing and responsibility splits vary by CPU, root complex, memory expander ASIC, and BIOS, but the dependencies recur. In other words, power and clocks before reset release; DDR readiness before credible capacity reporting; configuration-space discovery before decode programming; and table exchange before stable OS topology.
Boot sequence is shown for a system with CXL memory expander. Source: Author
- Power, clocks, and ASIC bring-up
The sequence begins when host platform and slot power are applied. The expander ASIC must reach an internally consistent state: regulators settle, oscillators stabilize, PLLs lock, and on-chip reset completes so an embedded control processor can execute first-stage firmware. The host must provide a stable PCIe reference clock and manage PERST# deassertion per PCIe/CXL electrical requirements, so the endpoint is not expected to train before clocks and power are valid. During this phase, the device is not yet advertising complete HDM metadata.
- On-device DRAM: controller release, training, and SPD
The ASIC releases reset to the DDR controller and run DRAM initialization and training for attached DIMMs. Firmware discovers configuration and capacity through serial presence detect (SPD) reads. In parallel, the ASIC initializes high-speed SerDes and the PCIe/CXL controller. There is a critical interval where HDM must not be treated as authoritative.
Firmware clears or gates HDM metadata until DRAM discovery completes—conceptually mem_info_valid = 0. Only after capacity and layout are known does firmware program HDM-related fields in PCIe extended configuration space via CXL-designated vendor-specific extended capability (DVSEC) structures and assert mem_info_valid = 1.
- PCIe link training, DVSEC, and HDM registration
As link training toward the host begins, firmware populates HDM capability structures through DVSEC containers—HDM instance count, per-region sizing, and validity flags. Setting “memory info valid” is the device’s contract that subsequent host reads from HDM descriptors consistent with trained DRAM.
- PCIe/CXL link up and configuration-space discovery
When the physical link reaches DL_Up at negotiated width and speed, the host enumerates the endpoint as a PCI function, parsing capability lists to discover CXL entries, DVSEC registers, and HDM decoders.
- Decode programming and mem_enable
Platform firmware must program host-side address decoding, so HDM contributes to the system physical address map. A common milestone is establishing the system physical address window and asserting memory enable (mem_enable). When mem_enable is recognized, device firmware may finalize the coherent device attribute table (CDAT) for OS/firmware NUMA heuristics.
- CDAT delivery via DOE and mailbox exchange
CDAT is typically transported using data object exchange (DOE) over CXL.io. The CXL mailbox command interface supports diagnostics and device management. Treat DOE/CDAT success and mailbox responsiveness as separate health checks.
- Firmware table construction and OS handoff
Host firmware synthesizes ACPI tables, including CXL Early Discovery Table (CEDT), System Resource Affinity Table (SRAT), and Heterogeneous Memory Attribute Table (HMAT), exposing HDM ranges as distinct memory affinity domains—often NUMA nodes.
- OS driver binding
On Linux, cxl_pci binds to the PCI/CXL function, exposes memdev objects, and enables memory to be onlined. Once complete, the host can issue CXL.mem loads, stores, and DMA through the programmed decode window.
Read the boot flow as a chain of implied tests—power/clock/PERST, DDR training, valid HDM, stable link, decode/mem_enable ordering, CDAT/DOE liveness, ACPI coherence, driver bind, and memory online. Failures produce characteristic signatures at each stage.
Part 3 applies this framework to hands-on test and debug: lspci field interpretation, NUMA verification with numactl, memory-mode configuration with daxctl, and workload tools for bandwidth and stress validation.
Ameet Sanghavi works in post-silicon validation for PCIe and CXL at Nvidia with a focus on interface bring-up and validation on shipping products. He has worked on PCIe since 2005 (from PCIe 1.1 onward) and on CXL since 2020 (from CXL 1.1 onward).
Editor’s Note
Part 1 of this mini-series on CXL Type 3 memory technology explains why AI and data-intensive workloads are driving interest in memory expanders and how CXL Type 3 devices differ from local DIMMs even when they appear as ordinary RAM. Part 3 covers integration modes and when boot parameters apply.
The views and content of the article are author’s own and not affiliated to any of his current or previous employers.
Related Content
- Stripped Down CXL Scales Memory Wall
- CXL Efforts Focus on Memory Expansion
- CXL Adds Port Bundling to Quench AI Thirst
- CXL: The key to memory capacity in next-gen data centers
- From GPUs to Memory Pools: Why AI Needs Compute Express Link (CXL)
The post CXL Type 3: Tooling and boot path from power-on to usable memory appeared first on EDN.
Пілотне впровадження проєкту Erasmus+ «EcoMinds»
КПІ імені Ігоря Сікорського є активним учасником європейського проєкту Erasmus+ «EcoMinds» (Enhancing Environmental Data Collection through Machine Learning and Database Systems), до реалізації якого залучено п'ять факультетів університету. Проєкт поєднує інформаційні технології та екологію, готуючи майбутніх фахівців до розв'язання глобальних кліматичних і природоохоронних викликів.
Open source hardware and software watch pcb i made if anyone interested
 | submitted by /u/coolkid4232 [link] [comments] |
Making noise with a BANG, part 1: Concept and hardware
This noise generator has an adjustable bandwidth and a consistent amplitude no matter what bandwidth is selected.
When working on a recent Design Idea for an adjustable filter, I wanted to use an electrical noise source to generate an FFT spectrum graph on my oscilloscope. To set up the test, I reached for my signal generator, which I knew had a noise generator option. I hooked the signal generator to the filter input and the scope to the filter output and turned on the scope’s FFT display function. I then set the filter to 10 kHz and set the signal generator noise standard deviation to its maximum of 3.0 volts.
Wow the engineering world with your unique design: Design Ideas Submission Guide
The output of the filter was a minuscule signal. Here’s what I’d ignored – the signal generator outputs a white noise signal with a 3.0 v standard deviation, but its bandwidth is 25 MHz. When I reduced the bandwidth with the filter, the amplitude dropped. With a perfect brick wall filter, this would reduce the standard deviation by the square root of (10 kHz/25 MHz). So, the 3.0 v standard deviation becomes about 60 mV after filtering. This small signal can be easily corrupted by noise existing in a test setup.
This standard deviation reduction comes from the way white noise signals add. Basically, if a signal is uncorrelated white noise and you add it to a second uncorrelated white noise source of the same standard deviation, the combined signal’s standard deviation will increase by the square root of 2. Alternately, when you filter out half of the spectrum of a noise signal with a brick wall filter, the standard deviation will decrease by the square root of 2.
It occurred to me that a noise signal generator should compensate for this reduction if you want to use a narrower portion of its bandwidth. For example, if the project under test is a device for audio, maybe you only need a noise source spanning only up to 50 kHz. Or maybe you’re testing a signal chain’s response for a low-frequency vibration sensor; in this case maybe a 1 kHz span is enough. But in either example you will want the signal’s standard deviation to be large enough to get a clean FFT.
So, how would I create a testing device to give me a noise generator that has an adjustable bandwidth and a consistent amplitude no matter what bandwidth is selected? The first thought was the typical white noise generator created with reversed biased Zener diode or base-emitter transistor junction followed by an adjustable low-pass filter and then an amplifier with some form of automatic gain control (AGC). But then it occurred to me that a micro I’d used recently has a random number generator and a fairly fast DAC for output…hmm.
Let’s take a look at what I came up with (Figure 1). First the name – the concept for this project idea is a Bandwidth Adjustable Noise Generator, which gives rise to the device’s nondescript acronymic moniker of “BANG”. The BANG is a micro-based generator that allows you to set the bandwidth you desire using a touchscreen. It then generates a noise signal with the standard deviation digitally compensated for that bandwidth.
Figure 1 The BANG is a micro-based generator that allows you to set, on a touchscreen, the bandwidth you desire. It then generates a noise signal with the standard deviation digitally compensated for that bandwidth. The device also has a knob to manually adjust the generated signal.
The device also has a good old-fashioned knob to manually adjust the generated signal somewhat, so you can tweak it. Its output has a maximum output of around 3.1 v and is available as an AC signal (biased at 0 v) or a DC signal (biased at around 1.65 v). The bandwidth adjustment of the noise signal goes from 225 kHz to 500 Hz, and this adjustment is accomplished using an LCD and touchscreen.
The hardwareThe heart of the BANG is a Microchip Technology ATSAMD51 processor. The adjustable digital filter project mentioned earlier also used a ATSAMD51, which has a true random number generator (TRNG). It’s best to let the Microchip data sheet describe this feature:
The True Random Number Generator (TRNG) generates unpredictable random numbers that are not generated by an algorithm. It passes the American NIST Special Publication 800-22 and Diehard Random Tests Suites. The TRNG may be used as an entropy source for seeding an NIST approved DRNG (Deterministic RNG) as required by FIPS PUB 140-2 and 140-3.”
These 32-bit numbers sound perfect for constructing a noise signal source! Using the same processor as before also meant I could reuse a large portion of the LCD and touch screen code, IIR digital filter code, battery monitor code, and various other initialization and housekeeping pieces. Besides the micro, another major piece of the design is the touchscreen, which is an ILI9341 2.8″ 240×320 pixel TFT LCD with a SPI interface.
The other major electronic piece is the analog back end (ABE). One part of the ABE is a reconstruction filter (sometimes referred to as an anti-imaging filter) attached to a DAC on the micro. It essentially filters out-of-band high frequency content carried along with the digitally generated noise signal as it is sent out of the DAC. The filter is a 4-pole Sallen-Key low pass filter with a cutoff frequency of 250 kHz (I used TI’s Webbench filter design tool to calculate the component values). The ABE section also has a potentiometer-adjustable gain stage from around 0.25x to around 2.5x of the ADC signal. The last part of the ABE is a simple output buffer driving the AC and DC outputs. Figure 2 shows the complete schematic.
Figure 2 The heart of the BANG is a Microchip Technology ATSAMD51 processor.
There are a few odds-and-ends on the schematic that I haven’t mentioned yet. First, the micro format I used is an Adafruit Feather M4 Express Arduino board, powered via USB or, alternately, a 3.7 v lithium polymer battery. The Arduino board also contains a charger for the battery. Being able to power it from the battery may be more convenient in some situations, and better yet, it can provide ground isolation if desired in your setup.
The USB pin shown is actually a regulated 3.3 v source that is used to power the rest of the circuitry. You’ll also notice a voltage divider, connected to an ADC on the micro, used to measure the USB voltage for display purposes. The ON/OFF switch actually connects to the EN (enable) pin. The BANG is powered off when the EN pin is pulled to ground. A Vcc/2 reference circuit can also be seen and is used to provide a center voltage for the single-supply operated op-amps.
More to comeNext time, I’ll describe the BANG’s firmware, integration, and operating results. Until then, I welcome your thoughts in the comments on what I’ve discussed so far!
Note that the schematic, code, 3D print files, Arduino software, links related to various parts of the project, and additional notes and pictures on the project’s design and construction can be downloaded for free at the MakerWorld website.
Damian Bonicatto is a consulting engineer with decades of experience in embedded hardware, firmware, and system design. He holds over 30 patents.
Phoenix Bonicatto is a freelance writer.
Related Content
The post Making noise with a BANG, part 1: Concept and hardware appeared first on EDN.
КПІ ім. Ігоря Сікорського презентував міжнародним партнерам нові ініціативи з гуманітарного розмінування
🤝 У КПІ відбулася зустріч із представниками Японського агентства міжнародного співробітництва (JICA), Полом Хеслопом, старшим радником з протимінної діяльності Офісу Координатора системи ООН в Україні та міжнародною організацією PCM та MAT Kosovo (Kosovo Mine Action Training Centre).
Міжнародна конференція від Посольства Мальтійського Ордену
КПІ ім. Ігоря Сікорського долучився до міжнародної конференції «The Use of Artificial Intelligence in the Context of the Humanitarian Crisis in Ukraine: Risks and Opportunities», організованої Посольством Мальтійського Ордену в Україні з нагоди Різдва святого Івана Хрестителя.
US ITC’s final determination on Infineon vs Innoscience upheld after review
Neural implant merges photovoltaics with custom analog, PPM encoding
It seems as if every technical advance these days is either directly related to AI software and data centers, or at least tries to establish such a connection, even if that connection is somewhat of a tenuous “stretch.” Despite this, there are a lot of innovative and interesting projects underway that are very analog-centric, with little or no AI association. These advances show what “small” analog can do, where small refers to both physical size and focused functionality.
Consider a neural implant dubbed the Microscale Optoelectronic Tetherless Electrode, or MOTE, developed at Cornell University (Figure 1). Measuring about 300 microns long and 70 microns wide (yes, that’s microns), researchers maintain it’s the smallest neural implant capable of wirelessly transmitting brain activity data.
Figure 1 This brain-implantable MOTE measures just 300 microns long and 70 microns wide and requires no tether or wireless RF link for power or data. Source: Cornell University
It’s connected via red and infrared laser beams that pass harmlessly through brain tissue. The MOTE transmits data back using tiny pulses of infrared light, which encode the brain’s electrical signals. An aluminum gallium arsenide (AlGaAs) semiconductor diode both captures light energy to power the circuit and emits light to communicate the data.
The device also includes a low-noise amplifier and optical encoder, all built using the standard CMOS process technology. The optical link uses pulse position modulation (PPM) for its data encoding as that format is very power efficient, especially in this situation (Figure 2).
Figure 2 System overview shows a MOTE implanted in an awake mouse brain to chronically record neural activity in vivo—incoming light powers the MOTE, and the MOTE, in turn, emits the PPM pulses communicating the recorded data (a). Optical microscopy image compares a MOTE with a strand of human hair (b). MOTE is powered and is communicating optically; it’s continuously powered at a shorter wavelength and communicates at a longer wavelength, making the powering system easier to implement and avoiding power–communication crosstalk (c). Source: Cornell University
The dual-use diode, dubbed a photovoltaic light-emitting diode (PVLED), provides space-saving benefits, functioning as both an LED and a data-link transmitter. An external 623-nm LED source provides power to the PVLED, while MOTE emits 825-nm PPM pulses that encode electrophysiological signals.
The diode is used as a photovoltaic for 93.4% of the time and as an LED for 0.06% of the time, with the remainder of the time spent on transitions. By concentrating the transmitted power into short, bright pulses and encoding information in the timing of those pulses, PPM is much more resistant to noise than amplitude modulation and is very power efficient.
Atomic layer deposition (ALD) of SiO2, Si3N4 and Al2O3 encapsulates MOTE against corrosive biological media without substantially increasing its volume (total encapsulation thickness is under 1.5 µm). High-pressure platinum (Pt) sputtering then provides not only favorable electrode impedance but also an effective and conformal light shield to prevent incident light from generating unwanted photocurrents in the electronics. Critically, each fabrication step is done in parallel, simultaneously fabricating close to 100 MOTEs per chip—and scalable to thousands of MOTEs per square centimeter of silicon (Figure 3).
Figure 3 Bulk fabrication of MOTEs (left) integrating two disparate technologies—CMOS (silicon based) and PVLED (AlGaAs based)—and a cross-sectional view (right) of a fully fabricated MOTE illustrating how the ALD dielectrics and sputter Pt together constitute a shield against biological media and unwanted photocurrents. Source: Cornell University
The underlying CMOS circuits provide low-noise amplification, stable biasing and PPM encoding, and drive the PVLED as an LED (Figure 4). Overall power budget is miserly: nominal power consumption is just one microwatt, divided among the amplifier (50.0%), encoder (10.5%), LED driver (26.2%), and support circuits (13.3%).
Figure 4 Systemic description of a MOTE and its external counterpart for communication—MOTE’s output PPM pulses are detected by an external photodiode before being passed through a decoder (a). Schematics of the front-end amplifier based on pseudo-resistors (left) and the charge pump for optical pulse generation shown on the right (b). Power and area distributions of a MOTE in which the amplifier and filter take most of the power for low-noise amplification (left), and the frame and integration overhead for protection against unwanted light and photocarriers take most of the area, as shown on right (c). Source: Cornell University
How well did they do?
By design, incident LED irradiance is limited to less than 70 mW/mm2, well below the allowed threshold of 250 mW/ mm2, which may inflict heat damage in the brain. The team first performed Petri-dish “static” tests before moving on to live rats. The heads of the implanted live mice were “restrained” while computer-controlled motor moved a rod to stimulate a whisker of an awake, head-fixed mouse.
The implant successfully recorded spikes of electrical activity from neurons as well as broader patterns of synaptic activity—all while the mice remained healthy and active. In two of the six implanted mice, they placed MOTEs on the brain surface, from which they were able to measure the electrocorticographic (ECoG) signals; in the other four mice, they inserted MOTEs into the barrel cortex.
As expected, MOTEs captured the neural responses to whisker stimulations and transmitted the neural signal spike. MOTES were left in the test “subjects” for up to 300 days and continued to function, although there was some degradation in performance, which the Cornell researchers attribute to deterioration of the platinum electrodes.
Why even bother with such a project, rather than using conventional “stick-in” electrodes? In addition to the obvious limitation imposed by the associated wired tether or even a wireless interface attached to the rat, one of the motivations is that traditional electrodes can irritate the brain as the tissue moves around the implant and thus can trigger an immune response. Their goal was to make the device small enough to minimize that disruption while still capturing brain activity faster than imaging systems, and without the need to genetically modify the neurons for imaging.
In you want to know more about the project, its circuitry, and the test results on the rats (I didn’t feel the need to go into detail on that!), check out their detailed and highly readable paper “A subnanolitre tetherless optoelectronic microsystem for chronic neural recording in awake mice” published in Nature Electronics.
Whether it’s rat implants or something non-biologic, these projects—with their tight focus, custom die, minimized number of functional blocks, and no frills or features beyond what is absolutely needed—show what analog designs can do in micropower and microsize designs, and that innovative analog design has not reached a terminal point. As the late, great analog designer Bob Pease liked to remind us, “one good op amp can do more than a thousand logic gates.”
Bill Schweber is a degreed senior EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features. Prior to becoming an author and editor, he spent his entire hands-on career on the analog side by working on power supplies, sensors, signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing.
Related Content
- Hot car-seat deaths and sensor solutions
- When sensors are easy, but sensing is hard
- “Wideband” still elusive in electronic noses
- A 12-point overview of the advantages of custom analog ASICs
The post Neural implant merges photovoltaics with custom analog, PPM encoding appeared first on EDN.
Memory wall: Why cache miss tolerance defines CPU performance now
The memory wall is no longer a theoretical concern. It’s the defining bottleneck in today’s AI, automotive, and data center system-on-chips (SoCs). CPUs operate at GHz frequencies with single-digit nanosecond cycle times, yet DRAM latency remains stubbornly at 60─100 ns, and memory-mapped I/O (MMIO) accesses to on-chip accelerators across complex networks-on-chip (NoC) can take even longer.
As SoC designs scale up with more accelerators, larger memory subsystems, and deeper interconnect fabrics, the cost of every cache miss and every device register access grow. No single architectural feature can solve this. It demands a multi-dimensional approach.
This article shares our experience using Google’s FlatBuffers library as a memory subsystem stress test on the Andes AX46MPV RISC-V core. Our evaluation confirmed that outstanding transaction capability delivers significant benefit, up to 39%, when memory accesses are independent, but only 6% under pointer-chasing patterns where hard data dependencies prevent parallelism.
This demonstrates exactly why a single-dimensional solution is insufficient. The Andes AX46MPV addresses memory latency from multiple angles: outstanding transactions to exploit memory-level parallelism when access patterns allow, hardware prefetching to predict and fetch data before the core needs it, and software prefetch support to give programmers direct control over latency hiding.
Together, these capabilities form a comprehensive latency tolerance strategy—ensuring robust CPU performance whether the bottleneck is cacheable DRAM access or uncacheable MMIO traffic across the SoC.
Below are the six key premises that can help design engineers formulate a latency tolerance strategy to ensure robust CPU performance amid memory bottlenecks.
- The memory wall problem
Modern workloads, such as AI inference, databases, and graph analytics, are memory bound. As mentioned above, CPUs now operate at GHz frequencies with single-digit nanosecond cycle times, while DRAM latency remains stubbornly at 60─100 ns. This gap, commonly known as the memory wall, means a single cache miss can stall the processor for hundreds of cycles, leaving expensive compute resources idle.
The bandwidth–latency paradox
Technologies like high-bandwidth memory (HBM) and DDR5 are engineered for high bandwidth but realizing that bandwidth requires the CPU or GPU to sustain hundreds of outstanding memory requests simultaneously. Without a deep request pipeline, the memory bus sits idle between transactions, wasting the very bandwidth these technologies were designed to deliver. In other words, bandwidth is only as useful as the processor’s ability to keep the memory channel busy.
Beyond AI: The automotive case
The memory wall is not confined to data center workloads. In automotive SoCs, DRAMs are often soldered directly onto the PCB to withstand vehicle vibration. This soldering, combined with PCB routing constraints, can result in longer signal paths and increased DRAM access latency. Therefore, the CPU’s ability to sustain multiple cacheable in-flight requests is also critical in automotive systems.
- The MMIO dimension: Long latency beyond DRAM
The memory wall problem extends beyond cacheable DRAM to uncacheable MMIO as well. Modern SoCs integrate many peripherals and accelerators, such as AI engines, NPUs, and DMA controllers. The CPU configures and communicates with these devices through MMIO register accesses.
Each MMIO access is uncacheable and must travel on the on-chip bus. If the CPU can only issue one MMIO transaction at a time, programming a sequence of accelerator registers becomes painfully slow. This is a real bottleneck in systems where the CPU orchestrates multiple accelerators and needs to rapidly set up DMA transfers, kick off inference jobs, or poll status registers.
Real-world example: Meta’s MTIA accelerator
A concrete illustration is Meta’s MTIA—Meta Training and Inference Accelerator—which uses Andes RISC-V cores inside each processing element (PE). Within the chip, these cores access system registers and remote PE resources through an on-chip AXI interconnect, using uncached MMIO accesses whose latency varies depending on the physical distance across the grid.
Figure 1 Here is a look at the MTIA platform, the first-generation silicon targeting Meta’s recommendation systems. Source: Meta
The growing NoC latency challenge
As AI chips grow larger and more complex, accelerator blocks are spread further across the die, connected by NoC. An MMIO access to a block on the far side of the NoC can take 50─200+ cycles just for routing, and even longer under congestion. This makes the CPU’s outstanding MMIO transaction capability a meaningful factor in overall system throughput.
- FlatBuffers: A memory subsystem stress test
We chose Google’s FlatBuffers library not as a representative AI workload, but as a stress test for the CPU memory subsystem. FlatBuffers is an open-source, cross-platform serialization library designed for zero-copy data access, meaning it reads serialized data in place without a separate deserialization step. While this library design is efficient in many respects, it creates memory access patterns that are particularly challenging for CPU caches and memory subsystems.
What makes FlatBuffers demanding
FlatBuffers uses indirect, offset-based data navigation: accessing any field requires reading an offset, computing a field address, and then following that address to the actual data. This results in multiple dependent memory accesses per field lookup.
The read path, in particular, involves classic pointer chasing, which means each access depends on the result of the previous one. The chasing depth is configurable and can be set to a high value (for example, 2,000), meaning the traversal spans far more data than a single cache line can hold.
As a result, cache misses are frequent and unpredictable. Accesses tend to be small and scattered, touching a few bytes at one location before jumping to an entirely different cache line. Combined with extensive small function calls for field accessors, FlatBuffers stresses the instruction cache, branch predictor, and memory subsystem simultaneously.
Figure 2 Read pointers involve chasing in FlatBuffers. Source: Andes Technology
Establishing a performance floor
By evaluating under these deliberately demanding conditions, we establish a performance floor for the CPU. Real-world workloads, which typically exhibit more regularity and spatial locality, can be expected to benefit even more from the core’s architectural features for latency tolerance.
- What we learned: Outstanding transactions under two access patterns
Our evaluation on the Andes AX46MPV RISC-V core revealed that the architectural benefit of outstanding transactions varies dramatically depending on the memory access pattern, not just the cache miss rate.
FlatBuffer Create: Independent accesses, high benefit
In the FlatBuffer Create kernel, the CPU allocates buffers, writes fields, and builds the serialized data structure. These memory accesses are largely independent of each other; that is, the address of one write does not depend on the result of a previous read. Despite a low DRAM access frequency of just 0.23%—shared cache misses as a proportion of total instructions—the core achieved a 20% to 39% performance benefit from its outstanding transaction capability.
The range depends on how we model the worst case without outstanding transactions. The upper bound of 39% assumes every DRAM access fully stalls the pipeline for the entire memory latency with no instruction overlap whatsoever, which is a deliberately pessimistic assumption. The lower bound of 20% assumes that some instructions can still be executed during a DRAM stall, effectively halving the DRAM access cycles.
The actual benefit likely falls somewhere within this range, but even at the conservative end, a 20% gain from just a 0.23% miss rate demonstrates that when cache misses are independent, the hardware can issue multiple requests simultaneously and continue useful work while waiting. This is the ideal scenario for memory-level parallelism: rare but independent misses that can be fully overlapped.
FlatBuffer Read: Pointer chasing, limited benefit
The FlatBuffer Read kernel tells a very different story. This workload is dominated by pointer chasing. The CPU reads an offset, dereferences it to compute the next address, reads that location, follows the next offset, and so on. Each memory access depends on the result of the previous one, creating a strict chain of data dependencies.
Despite a much higher DRAM access frequency of 1.99%, the core achieved only a 6% performance benefit from outstanding transactions. The small gain likely comes from brief windows where the access pattern allows limited parallelism. Perhaps when reading multiple independent fields within a single FlatBuffer object after resolving its base pointer. But the dominant pointer-chasing pattern fundamentally limits how much latency the hardware is able to hide.
The key insight: Not all cache misses are equal
This contrast carries an important implication for system architects and workload designers. The value of outstanding transaction capability depends not on how many cache misses occur, but on whether those misses are sufficiently independent to be overlapped. Workloads with parallel, unrelated memory accesses can see dramatic benefits; workloads with serialized, data-dependent accesses will see far less improvement, regardless of how many outstanding transactions the hardware supports.
- Beyond outstanding transactions: Prefetching as a complementary strategy
Outstanding transactions are most effective when cache misses are independent and can be issued in parallel. However, not all workloads exhibit this pattern. When the access pattern has some regularity but not enough parallelism to exploit, outstanding transactions alone are insufficient. This is where prefetching can provide partial relief.
The Andes AX46MPV includes both hardware prefetch and software prefetch capabilities. Hardware prefetching detects regular access patterns, such as sequential or strided accesses, and speculatively fetches data into the cache before the core requests it. Software prefetch instructions give programmers explicit control, allowing them to insert prefetch hints at strategic points in the code where the hardware prefetcher cannot anticipate the access pattern on its own.
Together with outstanding transactions, these prefetch mechanisms form a multi-layered defense against memory latency, each addressing a different dimension of the problem.
- A multi-dimensional approach to the memory wall
When cache misses occur in a modern SoC, whether to cacheable DRAM or to uncacheable MMIO device registers across a complex interconnect, the resulting latency is a multi-dimensional problem. No single feature eliminates it. The Andes AX46MPV architecture addresses this challenge from multiple angles: outstanding transactions exploit memory-level parallelism when access patterns allow it, hardware prefetching predicts and fetches data before the core needs it, and software prefetch gives developers an additional tool to partially overlap latency.
Our FlatBuffers evaluation makes this concrete: outstanding transactions deliver a 20─39% gain when cache misses are independent, but under pointer-chasing patterns, the benefit drops to 6%. For SoC designers, this underscores a practical truth: understanding your workload’s access patterns is just as important as the hardware features themselves.
For those building the next generation of AI, automotive, and data center platforms, this kind of comprehensive, multi-dimensional latency tolerance is not a luxury. It’s a necessity.
Mia Chang is a solution architect at Andes Technology with more than 10 years of experience spanning semiconductor circuit modeling and CPU synthesis. She works directly with AI compute and automotive customers, performing in-depth kernel-level analysis to uncover performance bottlenecks in real-world system designs.
Author Acknowledgement
This article would not have been possible without the support of several colleagues. The CCBU team carried out the FPGA measurements that underpin our evaluation. Our NA team provided thoughtful reviews and suggestions that helped sharpen this article. Our knowledgeable architect and R&D team behind the AX46MPV were always willing to discuss the questions and challenges we encountered during benchmark analysis with us. Thank you all.
Related Content
- The Memory Wall Is Real, Here Is the Door
- AMD Snaps MEXT to Break the Memory Wall
- AI-Driven Memory Shortage Upends IT Budgets
- Massive AI Storage Demand Creates a New Memory Wall
- Why CXL Type 3 memory matters, what your platform must provide
The post Memory wall: Why cache miss tolerance defines CPU performance now appeared first on EDN.
Українські школярі — на Міжнародній олімпіаді з кібербезпеки та ШІ в Сіднеї
🇺🇦 Українські школярі з Києва, Кривого Рогу, Маріуполя та Полтавщини виступили на Міжнародній олімпіаді з кібербезпеки та штучного інтелекту в Сіднеї. Вони знають війну не з підручників, а з ракетних ударів і повітряних тривог.
Mini zvs mazilli driver
 | It is on irfz44n but I will probably change it to irf3205 to reduce heat. [link] [comments] |
TP-Link’s Tapo T300 sensor detects water and other liquid-leak dangers
Unintended fluids dripping from above? Accumulating from below? The T300 alerts you to them all. And mysteriously threaded contacts suggest other uses, too.
Back in March, I covered the activation and ongoing usage impressions of three interrelated TP-Link smart home devices: the Tapo H100 smart hub:
display-inclusive Tapo T315 hygrometer:
and Tapo T300 smart water leak sensor:
Toward the end of that March piece, and reiterating a quote I’d initially included in a mid-May follow-up post, I wrote:
I’ve also got a redundant Tapo H100 smart hub and T300 smart water leak sensor, both sitting on the shelf, queued up for teardown, along with a display-less sibling of the T315 hygrometer, the Tapo T310 Smart Temperature and Humidity Sensor:
The Tapo T310 was tore down and analyzed within that same mid-May writeup, with the teardown of the Tapo H100 predating it in late April. And now, in early July, we’re completing the dissection triumvirate with the spare Tapo T300, which I as-always aspire to return to fully functional form post-disassembly for ongoing leak-monitoring use somewhere in the residence.
Revisiting past historyYou already saw a set of box and other real-life shots for the sibling Tapo T300 in the initial mid-March entry in this series (assuming you read it, that is); that particular unit now resides at the base of my downstairs water heater. The “dumb” leak sensor previously at that location now sits below the also-downstairs whole-home water filter; another is at the back of my icemaker-augmented combo refrigerator/freezer in the kitchen.
As usual, I’ll start out with some outer box shots, also as usual accompanied by a 0.75″/19.1 mm diameter U.S. penny for size comparison purposes.
This last image of the bottom of the package reveals (among other things) the hardware version (v1.6, succeeding the original v1, as well as with its own v1.8 successor) and serial number:
The hardware version matches that of the Tapo T300 currently in use, although serial numbers differ (of course). Here’s a revisit of the associated box-bottom shot you saw in March:
Let’s see what’s inside:
starting with a sliver of quick-start literature (PDF…here are the accompanying full user guide and datasheet) and some protective foam:
Here’s our patient, still swathed in a translucent protective sleeve:
And now unclothed, once again echoing sibling-device images you saw back in March:
As before (referencing the packaging photos), with the exception of this bottom shot:
versus this differing-serial-number vantage point of the in-use sibling device:
in both cases (and in contrast to the bottom-perspective packaging precursors) now including the always-informative common FCC ID (2AXJ4T300).
The Tapo T300 comes already battery-equipped, as you’ve probably already ascertained from the translucent strip of plastic that begs for removal prior to first-time use, but a power-source swap will sooner-or-later be necessary (“up to three years” before replacement is the claim). The removal of two screws should gain us access to the battery compartment:
Toldja so (there’s two AAAs/LR03s inside):
Next up, four screws, one in each corner, this time with hex heads:
And with them removed, the two sections of the case separate straightaway, with no further implements of destruction or elbow grease required:
The inside of the bottom portion is largely unmemorable. Nice gasket, though, for likely-already-obvious liquid-intrusion-prevention purposes (IP67). Speaking of liquids, note the four metal pass-throughs, one on each corner, originating with the bottom-side contacts you saw earlier:
The other, larger portion is much more interesting (IMHO, at least):
Leak warning-sound transducer aka “buzzer” (claimed 90 dB!) on the side:
Let’s get that PCB outta there. Removing two more screws should do the trick:
That’s what I’m talkin’ about:
Toward the right are a pair of additional feed-through contacts from the top, intended to catch drips coming from above (vs. already-pooled fluids from below in the prior four-contact case). In the middle is a visible-light pass-through originating at the multi-color multi-function status LED, which I’m betting we’ll see shortly. And at left is the mechanical button portion of the topside control switch. The buzzer on the side, fed by the red-and-black two-color wiring harness, you’ve already met, right?
Now for the PCB itself, beginning with the bottom side, you’ve already glimpsed in past shots.
The proximity contacts for the previously pointed out bottom-side contacts are in the corners, labeled P11-P14. Two of the four battery terminals are here; you might have already noticed that the other two are attached to the case itself. And although at first glance, I’d thought the sizeable cylinder on the left edge was an electrolytic capacitor, the “L323” PCB marking next to it suggests otherwise (analog experts: is this what’s known as a “radial inductor”?). Note, too, that the D6 diode site below and to its right is unpopulated, seemingly, unless my eyes are playing tricks on me.
Now for the more interesting (IMHO) topside (which, bafflingly, is screenprinted “BOTTOM”):
Dominating the landscape at left is the PCB mounted portion of the aforementioned control switch. Below and to its right is a sixteen-lead square IC labeled as follows (I “think”…the “S” and “5” symbols aren’t distinctly different):
300A
S906
S15
Readers’ suggestions as to its identity and function(s) are welcomed. My bet is that, as with the Tapo T310 Smart Temperature and Humidity Sensor, it’s another obscured-marking CC1 series-variant of Texas Instruments’ MSP430 embedded controller family, for (among other things) “Sub-1 GHz dual-band” wireless connectivity. More on that connectivity bit in a moment.
Above and to its right, and at the PCB center, is the status LED. To its right is another, larger IC, this one more easily identifiable; it’s the same Cmsemicon BAT32G135GE application processor that I’d found in the earlier Tapo T310 Smart Temperature and Humidity Sensor teardown. To its right are two more landing pads, labeled T9 and T10 and this time corresponding to the earlier noted topside-located drip-sensing contacts.
And above the entire circuitry assemblage is ANT5, the embedded antenna for the company’s proprietary ultra-low power wireless protocol. Since this application’s data rate (as with hygrometry) is low, unlike with a smart camera (for example), additional Wi-Fi connectivity isn’t necessary in this case.
Speaking of sides, I’ll wrap up for today with four more PCB perspectives related to its backside, since that’s where the bulk of the “vertical” parts are located.
Along with one other tidbit that I came across during my research. You might have already noticed that two of the four contacts on the bottom of the device aren’t solid; instead, they seemed to have unfilled (not to mention M2 screw-threaded) centers. You’d be spot-on with that observation, although nothing I’ve found in the product documentation explains why.
Well, this guy (or gal; dunno) used them to transform the Tapo T300 into a door open/close sensor. If it wasn’t already obvious, the Tapo T300 doesn’t directly leverage a moisture sensor, as a hygrometer does (for example). Instead, it detects normally absent current flow between any of the three paired sets of two contacts, interpreting that conductivity as evidence of fluid presence. The switch used in this creative design derivation, in its “closed” position, generates the same current flow. And this same concept can also be employed for other purposes. Nifty!
Over to you for your thoughts in the comments!
—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.
Related Content
- The Tapo Hub: TP-Link joins the low-bandwidth, long-range RF club
- Smart hygrometers: Still largely useful even without integrated visual monitors
- TP-Link’s Tapo H100: Smart sensing unencumbered
- Tapo or Kasa: Which TP-Link ecosystem best suits ya?
The post TP-Link’s Tapo T300 sensor detects water and other liquid-leak dangers appeared first on EDN.
Inductive loop vehicle detectors: Still steady in the noise of AI
Artificial intelligence (AI) may dominate today’s conversations about smart cities and autonomous mobility, but beneath the pavement lies a technology that has quietly kept traffic flowing for decades. Inductive loop detectors (ILDs)—simple wire coils paired with reliable electronics—continue to deliver dependable vehicle detection, enabling adaptive traffic lights, toll systems, and roadway monitoring.
In a landscape buzzing with AI-driven vision and radar, ILDs stand out as the proven, resilient infrastructure that provides clarity and consistency, reminding us that not all progress depends on novelty—sometimes it rests on steady signal amid the noise.
Applications of inductive loops
In principle, an inductive loop (or induction loop) is an electromagnetic detection system that uses a moving magnet or an alternating current to induce an electric signal in a nearby wire. They are widely applied in transmitting and receiving communication signals and are also integral to hearing-assist devices, where audio signals are magnetically transmitted directly to compatible hearing aids, improving clarity in public venues such as theaters, lecture halls, and places of worship.
Inductive loops also play a crucial role in vehicle detection—embedded beneath road surfaces, they sense the presence of cars and trigger traffic lights or vehicle presence indicators. In addition, they serve in metal detectors and other object-sensing applications, but their impact on accessibility and traffic management makes them especially vital.
The rest of this post deals with inductive loop vehicle detectors.
Inductive loop vehicle detectors
Among current vehicle detection technologies, the inductive loop system remains the industry standard due to its optimal balance of performance, reliability, and cost-effectiveness.
At their core, inductive loop detectors operate by sensing changes in inductance when a metallic object disturbs an electromagnetic field.
This field is generated by a cable loop embedded directly into the roadway; as a vehicle passes over, it alters the coil’s inductance, triggering a detection signal. These systems provide the essential control logic for automating infrastructure, such as operating gates and traffic barriers, managing signal timing at intersections, or dispensing tickets in parking facilities.
Figure 1 A vehicle induction loop presence detector triggers gate mechanisms and logs traffic data for access management. Source: Roger Trade Centre
The system comprises two primary components: the sensing element and the electronic module. The sensing element consists of a wire coil buried within the pavement and a lead-in cable with the loop’s specific geometry defining the boundaries of the detection zone. The electronic module connects to this loop to monitor electromagnetic changes that indicate a vehicle’s presence.
Once a vehicle is detected, the module processes the resulting data according to its specific programming. This information can be acted upon immediately to trigger traffic signals or automated gates, stored locally for subsequent traffic pattern analysis, or integrated as a critical data point into a larger, networked management system.
Furthermore, the physical installation of the sensing element requires a saw cut, which involves milling a narrow groove—typically 1 to 2 inches deep—directly into the asphalt or concrete. Once the wire coil is laid within this channel, the slot is filled with a specialized loop sealant to protect the hardware from moisture and traffic-induced stress.
While this method enables precise placement and easy retrofitting on existing roads, the integrity of the saw cut is vital. Any degradation in the sealant or shifting in the pavement can lead to wire breakage, resulting in system failure or “ghost” detections.
Figure 2 A basic sketch illustrates an inductive loop vehicle detector system. Source: Author
More inductive loop vehicle detector essentials
Over the years, engineers have experimented with various inductive loop geometry configurations to optimize vehicle detection. While early designs were constrained by the limitations of rudimentary electronics, modern technological advancements have rendered many of those barriers obsolete.
This evolution necessitates a reevaluation of traditional standards to accommodate the sophisticated configurations now in widespread use. Today, selecting the ideal geometry requires a comprehensive analysis of site-specific parameters, including adjacent lane interference, the required detection zone area, the specific vehicle types being monitored, and the physical distance between the loop and the electronics module.
In practice, these loops are deployed to capture two primary types of data: presence and passage. Presence detection—monitoring a vehicle within a specific zone or lane—typically requires loops with larger surface areas. Conversely, detecting the passage of a vehicle over a specific point is best achieved using a single, smaller loop.
Once geometry is established, the next critical factor is the number of turns. While the geometry defines the physical detection zone, the number of turns dictates the loop’s inductance value. It is essential to account for the lead-in cable’s inductance, as it contributes to the total input inductance of the system. Engineers must balance these values carefully, as decreasing the loop inductance below recommended thresholds can significantly compromise system stability.
Furthermore, it’s important to note that a vehicle passing over a small portion of a large loop generates a significantly smaller change in inductance than it would when passing over a smaller loop. For maximum system reliability, the detector must be able to register the greatest possible change in inductance when a vehicle enters the detection zone.
Since the detector monitors an inductance shift that is directly proportional to the percentage of the loop area displaced by a vehicle, smaller loop areas inherently provide higher sensitivity. Consequently, when wide-area coverage is required—such as along large gates—multiple smaller loops are often connected to a single detector channel rather than using one oversized loop.
When connecting multiple loops to a single channel, it is standard practice to use identical loops. These loops should share the same dimensions, shape, and number of turns. Maintaining uniform inductance across all connected loops ensures a consistent level of detection sensitivity across the entire monitored area, preventing “dead zones” where a vehicle might go undetected.
For the sake of brevity, this discussion omits foundational concepts such as fundamental inductive theory, loop phasing, and detection height considerations. Furthermore, specialized topics—including the cancellation of undesired magnetic fields through twisted-pair wiring—are left as a subject for further study for those voracious readers seeking a more exhaustive understanding of the underlying physics.
Now, let’s look at some practical pointers for the circuit design notebook.
Practical design pointers
You can build an inductive loop vehicle detector prototype by embedding a wire coil in the roadway and monitoring its inductance. The coil functions as part of a high-frequency oscillator; when a metallic vehicle passes over the loop, it induces eddy currents that decrease the loop’s inductance. This causes a measurable shift in the oscillator’s frequency, which a microcontroller can then process to reliably detect the vehicle.
Success in loop design hinges on balancing sensitivity with environmental stability. Start by documenting the specific loop geometry and the gauge of the wire used, as these factors directly dictate the magnetic field’s reach.
It’s also essential to log the chosen operating frequency; ensuring your system stays within the recommended frequency range for your specific hardware helps avoid interference from nearby power lines or electronic equipment. Finally, always record the layout of the lead-in cables, ensuring they are tightly twisted to minimize noise, and note the pavement conditions to account for any metal reinforcement that might dampen the detector’s response.
As a quick design starting point, you can utilize a Colpitts oscillator built from standard components. The oscillation frequency—typically ranging from 30 kHz to 150 kHz—is determined by the capacitor values and the inductance of the coil windings. The oscillator output is then fed to a microcontroller, which measures the frequency to determine whether a vehicle has been detected.
For better stability, it is recommended to isolate the wire loop from the sensor electronics using a 1:1 ratio isolation transformer, though this is not strictly mandatory. It’s easy to find inspiring design ideas similar to this all over the web.
It’s worth trying a directional loop setup to track traffic flow more accurately. By tracking the activation sequence of two independent sensors, a directional logic loop detector identifies which way a vehicle is headed. The system registers movement based on which loop is tripped first, allowing it to differentiate between opposing flows of traffic.
This capability is particularly useful for shared entrance/exit points in parking facilities and alerting systems to wrong-way drivers on highway ramps. Moreover, these detectors often automate barrier gates, initiating an “open” command for traffic arriving from one side and a “close” command for those departing from the other side.
Figure 3 A directional logic loop detector tracks vehicle direction by monitoring two separate loops. Source: Author
Closing the loop
Inductive loop vehicle detectors prove that even in a world obsessed with complex sensors, the fundamental laws of electromagnetism remain the gold standard for reliability. While computer vision and LIDAR grab the headlines, these buried wire loops continue to quietly power our infrastructure with unmatched precision and weather resistance.
For engineers and makers out there, this technology is a playground of untapped potential—whether you’re optimizing urban traffic flow or building an automated entry system for your own workshop. Don’t just settle for off-the-shelf solutions; grab a spool of wire, dive into the physics, and start prototyping your own detection systems today.
Let’s see what kind of smarter, more responsive world you can build from the pavement up.
T. K. Hareendran is a self-taught electronics enthusiast with a strong passion for innovative circuit design and hands-on technology. He develops both experimental and practical electronic projects, documenting and sharing his work to support fellow tinkerers and learners. Beyond the workbench, he dedicates time to technical writing and hardware evaluations to contribute meaningfully to the maker community.
Related Content
- The Inductive Nature of Voltage-Control Loops
- 6 Considerations for Integrating Sensors in Vehicles
- How Can OEMs Use Connected Vehicle Sensor Data?
- Inside DSP on Automotive Signal Processing: Street Smarts
- The Autonomous Car Industry in 2024: Sensors, Software and Safety
The post Inductive loop vehicle detectors: Still steady in the noise of AI appeared first on EDN.
Pages
![[link]](https://i.redd.it/hx1sgih2xsbh1.jpeg){kind=link}