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

Building a motorized welding turntable solves a common problem: welding around circular or cylindrical objects without walking around the workpiece. Greenhill Forge’s project creates a large motorized lazy Susan with adjustable speed and a modest budget. The table rotates the piece under the torch, so the welder stays still and both hands are free to guide the arc.

The heart of the system is a stepper motor mounted under the table surface. Rotation passes through a gear reducer and a standard spider coupling, which transmits motion to the top plate. The reducer increases torque and lowers speed, so the table moves smoothly even with heavy parts. Everything is controlled by an Arduino UNO Rev3 board, which drives the motor and reads user commands.

Speed control and user interface

The user adjusts rotation speed with a rotary encoder. The knob is comfortable to use even with welding gloves. A small OLED screen shows the set speed, so control is immediate and precise. The firmware on the Arduino UNO reads the encoder, updates the display, and drives the stepper motor with the correct pulse frequency.

For those who want to replicate the project, choosing components is straightforward. A Uno R3 with ATmega328 is the same board used in the original project. A NEMA 17 stepper motor rated at 1.2 A has the right torque for a table of this size, which rotates through a reducer anyway. A 12 mm rotary encoder with knob connects directly to digital pins and can be turned even with welding gloves. Finally, a 128×64 OLED display shows parameters clearly.

• Stepper motor with gear reducer for torque
• Spider coupling to connect shaft and table
• Lazy Susan bearing for rotating support
• Rotary encoder for adjustment
• OLED display for visual feedback

Grounding through the shaft

An important detail is grounding management. In welding, current must return to the generator through the workpiece. If the turntable is not grounded, current passes through the lazy Susan bearings, causing arcs that damage them quickly. Greenhill Forge solves the problem with a ground strap that runs through the motor shaft.

The strap maintains conductivity between the table surface and the workpiece. This way, welding current has a dedicated path and the bearings stay protected. The strap is a wear item, but with normal use it should last a long time. Also, replacement cost is minimal, so maintenance stays economical.

The project is documented in a Greenhill Forge video, which follows the entire process: cutting and welding the frame, mounting the motor under the table, and grounding. At the end, the table is shown in action during a real weld, with speed adjusted on the fly.

Why build a turntable

This project appeals to both beginners and experienced welders. Construction is simple and requires few tools. Moreover, electronic control with Arduino UNO opens the door to future modifications, such as programmed rotation or foot pedal control. The modest cost makes the project accessible to many makers.

The welding turntable is an example of how a stepper motor, an encoder, and an OLED display can turn a simple support into a professional tool. Well-designed grounding protects components and ensures quality welds. Finally, adjustable speed lets you adapt rotation to any type of work.

Source: https://youtu.be/WQSzLMcc9zQ?si=DB7dDrRwHsfXU1OI

Related products

• 12mm rotary encoder with knob

The post Motorized welding turntable with Arduino UNO appeared first on Open Electronics.

In a radio receiver, the analog-to-digital converter (ADC) sampling rate and the complexity of the analog anti-alias filter in front of it are not independent choices. A sampled system can uniquely represent signals only over a bandwidth of Fs/2, so any content falling outside the chosen Nyquist zone must be removed before it reaches the converter. The closer the sampling rate sits to the theoretical minimum, the narrower the filter’s transition band becomes, and the higher the filter order required to reach a given attenuation.

Sampling faster relaxes that filter. The reason designers do not simply sample much faster is the cost on the other side: a higher sampling rate means a more expensive converter and more data for the downstream FPGA or ASIC to process. The optimum sits wherever those two costs balance, and in a conventional signal chain, it’s the digital side that limits how far the balance can move.

That constraint changes when the converter itself performs the processing. ADCs are now available that integrate a DSP block alongside the ADC cores, providing decimation, digital downconversion (DDC), and IQ mismatch correction on chip.

Because the decimator reduces the output data rate, sampling faster no longer adds to the downstream burden; in fact, it can reduce it. The optimum moves toward higher sampling rates with relaxed analog filtering, and a significant portion of the digital front-end moves off the FPGA at the same time.

This article works through three radio receiver designs: a direct conversion receiver, a direct conversion receiver with digital channel selection, and an IF sampling receiver. These are each built around a 14-bit dual-channel ADC with an embedded DSP block from Silanna’s SD1148 family, which offers sample rates from 40 to 250 MS/s.

1. Direct conversion receiver

The direct conversion, or zero-IF, receiver architecture shown in Figure 1 uses a quadrature RF mixer that converts the RF signal directly to baseband. The signal chain starts with a band-select filter followed by a low noise amplifier (LNA), and the local oscillator (LO) is centered on the RF signal band.

Figure 1 Here is a simplified architecture of a direct conversion receiver. Source: Silanna

The mixer has two paths, one producing the in-phase (I) output and the other the quadrature (Q) output. So, a quadrature LO signal with sine and cosine components is required.

The baseband IQ signal path following the mixer typically consists of a programmable gain stage, an anti-alias filter, and finally the ADC. Many implementations include additional filtering along the signal chain and some amount of RF gain control. Channel selection can be either analog (by changing the LO frequency) or digital, in which case the LO frequency is fixed.

The entire band of interest is digitized by the ADC, and digital downconversion plus filtering are used to select the desired channel. Even with analog channel selection, channel-select filtering is often performed partially in the digital domain.

Implementation challenges

The direct conversion architecture does not have to deal with image rejection, as the signal is its own image. Its implementation challenges lie in LO feedthrough, 1/f noise, and gain transients. In the baseband, these issues are concentrated in the vicinity of DC and are most severe for systems using narrow channel widths, measured in kHz.

They are easier to deal with when using wider channel widths and modulations that are less sensitive to low-frequency content. When digital channel selection is used, placing the LO between channels largely solves them.

Another challenge is IQ mismatch: amplitude and phase mismatch between the I and Q components, which results in leakage between the I and Q signal paths. All baseband blocks, the mixer, and the LO contribute to this mismatch.

Differential gain errors between the I and Q paths in the mixer, amplifiers, and ADCs, together with the filter passband gain, contribute to gain mismatch. Phase mismatch is caused primarily by phase error between the LO sine and cosine components, by mismatch in the filter frequency response, and, to a lesser degree, by clock phase mismatch between the two ADCs.

Using dual devices for the amplifier and the ADC that are specifically designed for IQ applications significantly reduces the contribution from these blocks. Calibration is commonly required to suppress the remaining mismatch to a tolerable level. For signals with modest bandwidths, a frequency-independent calibration is typically sufficient.

Sampling rate and anti-alias filtering

ADC sampling-rate selection and baseband filtering are tightly coupled. Sampled systems, including ADCs, can uniquely represent signals only over a bandwidth of Fs/2, where Fs is the ADC sampling frequency. This condition is known as the Nyquist criterion.

If the ADC input contains spectral content in both the region from 0 to Fs/2 (the first Nyquist zone) and the region from Fs/2 to Fs (the second Nyquist zone), the sampling process folds frequency components from these regions onto one another. This effect is called aliasing and must be avoided. Either region can be used to place the signal of interest, but not both simultaneously.

The anti-alias filter is an analog filter placed in front of the ADC to suppress unwanted signal and noise content outside the selected Nyquist zone prior to sampling. When the signal band extends to Fs/2 − Δf, the frequencies that must be fully rejected by the filter begin at Fs/2 + Δf, giving a transition band 2Δf wide.

The narrower the transition band, the higher the filter order required to achieve a given attenuation. For this reason, it’s advantageous to increase the ADC sampling rate beyond the theoretical minimum stated by the Nyquist criterion in order to relax the filter specification. This margin is typically at least 30% and is often higher.

The trade-off is higher ADC cost and increased digital signal-processing requirements versus the cost and complexity of analog filtering. An ADC with an embedded DSP block offsets the digital processing burden, which shifts the optimum toward higher sampling rates with relaxed analog filtering.

Design example

The first example uses the dual ADC in a direct conversion receiver. The RF signal is a 26 MHz-wide band centered at 915 MHz. After downconversion, the baseband I and Q signals extend from 0 to 13 MHz. The ADC sampling rate is set to 65 MS/s, which provides a relaxed anti-alias filter transition band from 13 MHz to 52 MHz.

Figure 2 The above configuration represents a direct conversion receiver application. Source: Silanna

As shown in Figure 2, the DSP block offers adders and multipliers that can be programmed to correct the DC offset and the IQ gain mismatch. Hardware for IQ phase correction is also present. The user provides the control values for these blocks.

The DSP block includes a decimator that can be programmed for rates of two and four; in this case the rate is set to two. The decimation process includes a digital finite impulse response (FIR) low-pass filter whose passband is 40% of the output sampling rate, which here is 0.4 × 65 MHz/2 = 13 MHz, matching the requirement.

When a low-pass filter is applied to the I and Q paths separately, the combined effect produces a symmetric band-pass response centered at 0 Hz, resulting in a passband from −13 MHz to +13 MHz. Figure 3 shows the frequency-domain signals at each step of this direct conversion receive chain.

Figure 3 Here is how frequency domain signals look like in a direct conversion receiver. Source: Silanna

The decimator has reduced the output sampling rate to 32.5 MS/s. The combination of oversampling and digital filtering improves the signal-to-noise ratio by about 3 dB for every decimation factor of two.

One consequence is worth noting. Because the decimation filter suppresses signals in its stop band, it can affect the gain control loop of the system. If a strong signal is present at the ADC input, but is filtered out of the digital output, a loop that monitors the output might not detect that the ADC is starting to clip. This can be avoided by incorporating the overrange bit provided by the ADC into the gain control algorithm.

2. Direct conversion receiver with digital channel selection

The second example operates on the same 26 MHz RF band, now divided into four 6.5-MHz channels. The application receives one channel at a time, occasionally switching between channels.

Figure 4 The radio receiver design uses a built-in DDC to perform channel selection within the digitized band. Source: Silanna

The RF and analog portion of the receiver remains the same as in the first example. We enable the digital downconverter built into the ADC, shown in Figure 4, and tune the numerically controlled oscillator (NCO), which provides the digital LO to the center frequency of the desired channel. This shifts the selected channel to 0 Hz, as shown in Figure 5. The decimation factor can then be programmed to four, reducing the output sampling rate to 16.25 MS/s.

Figure 5 Frequency domain signals are shown in a direct conversion receiver using digital channel selection within the digitized band. Source: Silanna

We can also consider reducing the ADC sampling rate from 65 MS/s to the 50–55 MS/s range, which maintains reasonable anti-alias filter requirements while further reducing the output data rate. Using these DSP blocks offloads a significant amount of digital signal processing from the FPGA to the ADC, providing both cost and power savings.

3. IF sampling receiver

The third example uses an IF sampling radio architecture, which is essentially a superheterodyne receiver in which the second downconversion stage is implemented digitally. A simplified block diagram is shown in Figure 6. The RF signal is converted to baseband in two steps: first to an IF, where it is digitized, and then to baseband using a digital mixer.

Figure 6 IF sampling receiver converts RF signal to baseband in two steps. Source: Silanna

This architecture eliminates the IQ matching issues and the challenges in the vicinity of DC associated with direct conversion receivers. The improvement comes at a cost: the system must achieve image rejection, which typically requires more analog filtering.

In addition, the ADC input is at a higher frequency, which demands a higher-performance ADC and places tighter requirements on sampling-clock jitter. A common way to keep the ADC sampling rate reasonable is to locate the input signal in the second (or third) Nyquist zone. In the IF sampling receiver, the ADC input signal is real, requiring only a single ADC per receive chain instead of a dual-channel device.

Figure 7 IF sampling receiver is show with DSP’s DDC and decimation functions enabled. Source: Silanna

In this example, we process a 40 MHz RF signal in the 2.4 GHz ISM band. This requires an increased sampling rate than in previous examples, and the 210-MHz device from the same family was selected. The IF is chosen as 150 MHz, which places the image 300 MHz away from the desired signal at RF.

The ADC sampling rate is chosen as 200 MS/s, which centers the IF in the second Nyquist zone. Operating in higher Nyquist zones requires band-pass anti-alias filtering; in this case the lower stopband is from DC to 70 MHz, the passband is from 130 MHz to 170 MHz, and the upper stopband is from 230 MHz and above.

Figure 8 See the frequency domain signals in IF sampling receiver. Source: Silanna

The aliasing effect, which in this case is a useful feature of the sampling process, is used to bring the signal to a 50 MHz center frequency. It’s worth noting that a signal sampled from the second Nyquist zone appears spectrally inverted, so the alias that lands in the first Nyquist zone is flipped relative to the original. Figure 8 shows the spectrum of the signal throughout the signal chain.

Negative frequencies are typically omitted when dealing with real signals, as they are a mirror image of the positive frequencies. Here, however, it’s useful to note that the signal image in the negative frequencies is not flipped relative to the original analog signal. With this insight, we can enable the DDC and program the digital LO to −50 MHz. This rotates the spectrum by 50 MHz toward the positive frequencies, bringing the band to a 0-Hz center frequency with the proper orientation.

The image originally in the positive frequencies is now shifted toward Fs/2 and partially appears in the negative frequencies around −Fs/2. To remove this unwanted image and reduce excess bandwidth, the decimator must be enabled with a decimation factor of two or more. The 40-MHz signal bandwidth permits additional decimation, so the decimator is set to decimate-by-four.

This reduces the output sampling rate to 50 MS/s. Because we have translated a real signal into a complex one, we now have both I and Q components, which together carry the same data rate as a real 100 MS/s signal. The 40% decimator filter bandwidth results in a passband from −20 MHz to +20 MHz, a good fit for the 40-MHz signal band.

Common pattern in three RF architectures

The same pattern holds across all three architectures: moving decimation, digital downconversion, and IQ correction into the converter relaxes the analog filtering in front of it while reducing, rather than increasing, the data rate behind it.

In the direct conversion example, raising the sampling rate from 40 MS/s to 65 MS/s widened the anti-alias transition band by 2.8×, added 2.1 dB of oversampling gain, and still lowered the output data rate by 19%. In the channel-selection example, the output rate fell to 16.25 MS/s and the channel filter moved off the FPGA entirely. In the IF sampling example, a real 200-MS/s input became a complex 50 MS/s output with the unwanted image removed on chip.

The practical consequence is that the sampling-rate-versus-filter-order trade-off no longer must be settled in the analog domain alone. Where the digital front-end processing is effectively free, because it happens inside the converter, the optimum moves toward faster sampling and simpler analog filters, and a meaningful portion of the FPGA workload moves with it.

Mikko Waltari is director of data converter designs at Silanna.

Related Content

• Radio Architectures: ADCs and Receivers
• RF-sampling ADCs for multiband receivers
• A checklist for designing RF-sampling receivers
• Analyzing ADC Noise Impacts on Wireless System Performance
• ADC Parameters for Your Wideband Telecommunications Receiver

The post A comparison of traditional and DSP-enabled ADCs in radio receivers appeared first on EDN.

I was asking Mouser costumer support because I could not find some ADI chips in stock in their webpage and after some emails, they answered me with the image attached. English translation: "As for ADI's distribution, we will no longer be distributors; it's not that certain ADI products will be restricted, but rather that we will no longer represent them." So this confirms what has been talked several times about online sellers suddenly requiring identification for ADI purchases and stopping the B2C sells. --- For the mods: I know this is not a component level circuit question, but perhaps the topic is important enough to be posted. -- The black bars are there to hide personal names. submitted by /u/Anroalh [link] [comments]

Butterworth response circuits come in both low- and high-pass versions, as well as ideal, Sallen-Key, emitter follower and DC accurate variants.

Many decades ago, I published a Design Idea about using equal value resistors and capacitors to implement a third-order active filter with the classic Butterworth response. This topology required two or three unity gain op-amps, depending on where the first-order RC section was located. And by swapping the positions of the resistors and capacitors, you could switch from a low-pass to a high-pass Butterworth response, while the 3 dB corner response remains the same at 1/(2*pi*R*C).

Wow the engineering world with your unique design: Design Ideas Submission Guide

The normalized Butterworth polynomial of S^3 + 2*S^2  + 2*S +1 can be factored into (S + 1)*( S^2 + S + 1), thereby revealing a multiplied first-order and second-order quadratic. In the original filter, the first-order section could be placed either ahead of or behind the second-order section, with the later yielding a two op-amp version; the op-amps are unity gain and provide isolation between the sections. These are the Type I versions.

A while back, I began working with different active filter topologies, including a revisit of the original Sallen-Key Type I version with an emitter follower implementation used much earlier in a car radar application. In the process, I discovered another filter version, where the factored Butterworth polynomial is directly implemented with a single op-amp. This approach, which also works with equal-value resistors and capacitors as well as an op-amp configured with a gain of 2, is called a Sallen-Key Type II. This particular configuration has a pass band gain of 2, while the Type I has a gain of 1.

The emitter follower version was implemented by replacing the unity gain op-amps in the Sallen-Key Type I with an emitter follower, and can use either two or three emitter followers similar to the op-amp version Type I. With both versions, the emitter followers can be complementary (NPN and PNP, or visa versa) which achieves a better effective input-to-output DC offset voltage, since the VBEs cancel. Since the emitter follower has a voltage gain of slightly less than unity, this characteristic causes the amplitude response to fall between Butterworth and Bessel regions, although the phase response follows the classic Butterworth.

While continuing my investigation of various active filters, another topology popped up that apparently dates way back to early 70s Fluke DMMs (digital multimeters). Known as the DC accurate second-order low-pass filter, it was utilized as a voltage reference noise filter. This filter is quite interesting in that the filtering is achieved by shunt capacitors working against an input series resistance; the active op-amp has no resistive connection to the input or output and therefore contributes no offset voltage or bias current.

It’s also interesting (to me, at least!) that if the op-amp 2*R resistor feedback resistance is implemented with two separate series resistors of value R, along with a shunt capacitor to ground installed between them, this configuration transforms into a third-order Butterworth low-pass filter with equal-value resistors and capacitors. If the shunt capacitor to ground is then removed, the filter reverts back to a second-order Butterworth, albeit with a lower corner frequency by a factor of 2/pi. I found it quite amazing that removing a shunt capacitor to ground actually lowers the corner frequency of a low-pass filter!

Figure 1 shows the various forms of these low-pass filters for simulations, including an ideal filter version with the Butterworth transfer function.

Figure 1 The various third-order active Butterworth response low-pass filters discussed in this Design Idea include ideal, Sallen-Key Type I and II, emitter follower and DC accurate variants.

Figure 2 shows LTspice AC simulation results, illustrating the limitations of the op-amp output impedance on the stop-band rejection. Note that the emitter follower version has slightly less than unity gain and a slight deviation from the ideal response, as expected.

Figure 2 In these LTspice linear AC low-pass filter simulations, note the stop band attenuation limits due to op-amp model finite output impedance.

Figures 3a and 3b  show actual lab measurements performed with a DSO (digital storage oscilloscope)/AWG (arbitrary waveform generator) combination, utilizing the built-in Bode feature, for various low-pass filters. Compare them with the previous simulations shown in Figure 2, and note the stop band limitations due to the finite op-amp output impedance.

Figure 3 Low-pass filter Bode measurements in the lab show stop band effects due to physical op-amp output impedance limitations (a, left). In the emitter follower version’s Bode plot, note that the DC gain is -0.6 dBV (b, right).

So far so good; this is getting increasingly fun for me as I move through these various active filter topologies, and hopefully you agree! The detailed analysis for each of these filter topologies, left as an exercise for the reader, is an interesting adventure that helps illustrate what’s going on. For now, there’s more exploration to come!

Now, lets swap the resistors and capacitors in each filter topology, thereby transforming each filter from a low-pass to a high-pass version (Figure 4). The only filter to complete this transformation with any negative effects whatsoever is the DC accurate version. With this particular filter, the DC isolation due to the shunt capacitors is now replaced with shunt resistors, which obviously couple the op-amp input and output offset to the filter output. Otherwise, this filter, like its peers, behaves as expected in its high-pass form.

Figure 4 Swapping resistors and capacitors results in high-pass versions of the circuits previously seen in Figure 1.

Figure 5 illustrates the simulation results with the resistor and capacitor swaps made to each previous filter type, thereby transforming it from a low-pass to a high-pass filter with the same characteristic (i.e., Butterworth) and 3dB corner of 1/(2*pi*R*C).

Figure 5 Shown here are simulations of the high-pass filter derivations of Figure 1’s circuits, i.e., the circuits shown in Figure 4, in each case achieved by swapping resistors (R) and capacitors (C).

Figure 6a and 6b are actual lab measurements which reveal some of the measurement setup and equipment limitations in dynamic range at the low-frequency end.

Figure 6 In these lab-based Bode high-pass filter measurements (again, a at left, b at right), note the dynamic range limitations at lower frequencies.

I hope that the Bode Plot lab measurements on actual hardware for both the various low-pass and high-pass filters, for comparisons with the simulation results, are helpful for you. The circuit were built using 1% tolerance resistors and 10% tolerance film capacitors, on plug-in protoboards. You can judge for yourselves as to whether the lab measurements and simulations are in reasonable agreement; reader thoughts on this topic or anything else regarding this Design Idea are welcomed in the comments. More generally, have fun with these active filters!

Michael A Wyatt is a life member with the IEEE and has continued to enjoy electronics ever since his childhood. Mike has a long career spanning Honeywell, Northrop Grumman, Insyte/ITT/Ex-elis/Harris, ViaSat and retiring (semi) with Wyatt Labs. During his career he accumulated 32 US Patents and in the past published a few EDN articles including Best Idea of the Year in 1989.

Related Content

• Dual amplifier active filters
• Toward better behaved Sallen-Key low pass filters
• Component tolerance sensitivities of single op-amp filter sections

 

 

The post Fun with third-order active filters appeared first on EDN.

Power designs now face the same demands at the same time: higher efficiency, smaller size, lower cost, and more power from the same space. For years, silicon has supported these designs. However, in a growing number of applications, it is close to its practical limits, and further optimisation increases losses and heat.

For this reason, gallium nitride (GaN) power transistors are receiving significant attention. ST has added a new 700 V and 100 V PowerGaN family to its portfolio and brings these advantages to mainstream power conversion. This article explains what the technology offers power designs and why it matters now.

Why Use GaN Power Transistors

Gallium nitride is a wide-bandgap semiconductor and, in a power converter, its main advantage is speed. Gallium nitride (GaN) power transistors, also called gallium nitride high electron mobility transistors (GaN HEMTs), switch much faster than silicon devices and lose less energy each time they turn on and off. Two effects follow from this behaviour. Less energy is wasted as heat, and the converter can operate at a higher switching frequency without losses increasing as they do with silicon.

Almost every benefit of GaN results from these two effects. Until recently, the technology appeared mainly in specialised, high-end products where the cost was justified. With a broad 700 V to 100 V family now in production, GaN has become a practical choice for everyday power conversion across a wide range of designs.

Improved Efficiency

The clearest benefit is efficiency. Because GaN has low conduction and switching losses, more of the input power reaches the load, and less of the power turns into heat. In ST reference designs, PowerGaN has achieved power-supply efficiency of up to 98.6%. Higher efficiency affects the entire design: lower operating costs, less energy consumption over the product life cycle, and lower demand on the cooling system.

For equipment that operates continuously, such as power supplies, lighting, and energy systems, even a small efficiency gain accumulates over thousands of operating hours. Efficiency is usually the first reason that a design team considers GaN, and it leads directly to the next two benefits.

Increased Power Density

The second benefit is size. A higher switching frequency allows the bulky magnetic components and filters in a converter to shrink, and the rest of the design shrinks with them. That creates two options for a design team: deliver the same power in a smaller, lighter product, or fit more power into an existing enclosure.

Gallium nitride (GaN)-based designs have reached an average size reduction of around 50%, compared with earlier silicon equivalents, at power densities above 100 watts per cubic inch. For products with tight space and weight constraints, such as compact adapters, chargers, and on-board systems, that extra headroom can determine whether a design fits at all. Increased power density is where the move to GaN becomes visible in the finished product.

Reduced System Cost

The third pillar is lower system cost. It results as much from the design around the transistor as from the device itself. A gallium nitride (GaN)-based converter uses smaller passive components and fewer passive components and often requires little or no heat sink. As a result, the overall system cost decreases, and the design is simpler.

Cooler operation also improves reliability and life cycle, which means that the system tends to last longer and requires less servicing. Lower energy consumption over the product life cycle adds to the savings. Together, these effects reduce the cost of building and operating the system, and they are a large part of why GaN deserves its place in a design.

Where 700 V & 100V PowerGaN Fits

These benefits are not tied to a single product type. The same value higher efficiency, greater density, and lower total cost) extends across a broad range of designs, including AC-DC and DC-DC power supplies, USB Type-C adapters and chargers, LED lighting, motor control, AI servers, robotics, industrial systems, and advanced consumer applications such as home appliances, as well as power and energy systems such as solar and storage. The same value also supports the growing power demands of computing and electrification.

Across these areas, priorities differ, but the same three advantages apply. A choice of package options allows a design team to match the device to the power level and board layout of each application. Because the 700 V & 100V PowerGaN family is already in production and available, these benefits can already be built into designs today.

Backed by a Broad Portfolio

Adopting a new switching technology is a decision about support as much as about the device itself. Alongside the 700 V and 100 V family, ST brings decades of power semiconductor experience, a broad product portfolio, a reliable supply chain, and strong technical support. For a team that works with GaN for the first time, that combination reduces the risk of the transition and shortens the path from an idea to a working design. It is part of what makes the value of PowerGaN practical rather than theoretical.

Why GaN, And Why Now

GaN power transistors provide higher efficiency, greater power density, and lower system cost for power conversion. The new 700 V and 100 V PowerGaN family makes these benefits available to mainstream designs. For a design team that is considering the move to GaN, the technology has reached the point at which its advantages are practical today rather than promised for tomorrow.

The post GaN Power transistors: What 700 V and 100 V PowerGaN Bring to Power-Supply Design appeared first on ELE Times.

Let’s get to know and learn how to use a board for RF tag identification, easily paired with Arduino.

We have covered radio-frequency identification, better known as RFID, several times before; for example, in issue no. 254 we dedicated an in-depth look at it with a thorough theoretical introduction and some usage examples based on the RFID PN522 module, accompanied by the ever-present Arduino board. In this article, we pick up the discussion again by experimenting with another module, the RFID-RC522, based on the MFRC522 chip produced by NXP (the datasheet is available at the web link https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf).

The RFID-RC522 module

The MFRC522 is a highly integrated RFID reader/writer for contactless communication at 13.56 MHz, supporting the ISO/IEC14443A/MIFARE and NTAG standards.

The transmitter inside the MFRC522 can drive an antenna designed to communicate with cards and transponders without additional active circuits. The internal receiver can efficiently demodulate and decode signals from cards and transponders compatible with the standards listed above.

The MFRC522 supports the MF1xxS20, MF1xxS70, and MF1xxS50 models. It also supports contactless communication with MIFARE transfer rates up to 848 kB (kiloBaud) in bidirectional mode.

The MFRC522 is compatible with all variants of the MIFARE identification protocols MIFARE Mini, MIFARE 1K, MIFARE 4K, MIFARE Ultralight, MIFARE DESFire EV1, and MIFARE Plus RF, grouped under the generic term MIFARE.

Below we summarize the main technical features of the module:

• analog circuit to demodulate and decode responses;
• buffered drivers for connecting an antenna with a reduced number of external components;
• supports ISO/IEC 14443 A/MIFARE and NTAG;
• typical operating distance in read/write mode up to 50 mm depending on antenna size and tuning;
• supports MF1xxS20, MF1xxS70, and MF1xxS50 encryption in read/write mode;
• supports ISO/IEC 14443 with high transfer rate communication up to 848 kbaud;
• supports MFIN/MFOUT;
• additional internal power supply to the smart card IC connected via MFIN/MFOUT;
• supported host interfaces: SPI up to 10 Mbit/s, I²C-Bus up to 400 kBd in Fast mode, up to 3400 kBd in High-speed mode, serial UART RS232 up to 1,228.8 kB/s, with voltage levels depending on the pin supply voltage;
• the FIFO buffer manages sending and receiving at 64 bytes;
• flexible interrupt modes;
• hard reset with low-power function;
• software power-down;
• programmable timer;
• supply voltage from 2.5 to 3.3 V;
• programmable I/O pins.

The RFID-RC522 module is detailed in Fig. 1, where you can see all the available connections.

Connecting to Arduino

Since all current libraries for using the module with Arduino reuse the SPI connection, we will focus only on that; Fig. 2 illustrates the connection to make for the subsequent tests with Arduino UNO.

In Table 1 we describe the connections analytically with their signals: on the left are those of the Arduino UNO and on the right the contacts of the RFID-RC522 module with the corresponding wire colors in the diagram in Fig. 2. The IRQ pin of the RFID module should be left unconnected because we do not manage it in this project and do not need it.

Of course, you must be very careful, because swapping just two wires will cause the module to fail; another important thing is power: the module requires 3.3 V, and the corresponding pin on Arduino is right next to the 5 V one; a moment of distraction would almost certainly damage the module.

The board (the RFID module used in the project) comes with two 8-pin strip headers (one straight and one at 90°) to solder as you prefer into the appropriate signal holes, an RFID Tag Card, and an RFID keychain Tag for initial testing.

Libraries for RC522

Using this module is made easier by the availability of specific libraries, of which we have selected two: the one from Velleman and the one written by Miguel Balboa.

Velleman: it is a minimal library consisting of only two files (RFID.h and RFID.cpp). Once downloaded from the link: https://www.velleman.eu/downloads/29/vma405_library.zip, you need to include it by opening a new sketch with an updated version of the IDE (in our case 1.8.12). Run the command Sketch – Include Library – Add .ZIP Library… and select the .zip file (Fig. 3), then close the IDE; it will be available when you reopen it.

Miguel Balboa: this library, much more powerful and articulated, is recommended by the official Arduino website; it is constantly updated, so it is always best to go to the link https://www.arduino.cc/reference/en/libraries/mfrc522/ or directly to the GitHub https://github.com/miguelbalboa/rfid; at the time of writing, the latest version is 1.4.8.

Its inclusion in the IDE is done in the same way as seen before. This library is quite demanding and requires considerable skills in RFID and programming to exploit it, so we only point it out to more experienced readers, while for the test we will see later we will use the one distributed by Velleman.

Functionality test

Let’s start with a test to verify the connections and the correct installation of the vma405 library. We have prepared a sketch named “RFID_TAG_CODE”; open it in the IDE and upload it to the Arduino UNO, then open the Serial Monitor, which will show the message “Avvicina un Tag al Modulo” (Bring a Tag close to the Module); at this point, bring the Tag close to the part of the module where the radio wave symbols are silkscreened (Fig. 4).

Keep in mind that the module should always be kept away from devices that can generate electric or electromagnetic fields, otherwise it might not work correctly.

The moment the Tag is recognized, the module reads its UID (unique identification code) and displays it on the Serial Monitor, both in decimal and hexadecimal format; in Fig. 5 we can observe the successive reading of two Tags.

If after the first identification you bring the same Tag close again, nothing will happen because we have not included an alternative action in the sketch; bringing another Tag close instead will give its UID in both formats.

When this test succeeds, you need to decide which Tag will be the “System Administrator” of the circuit we have prepared for experimenting with this module and note the five decimal numbers that make up its UID. For our example, we will use the first group visible in the figure (197, 5, 190, 35, 93).

Access control project

With the help of a breadboard and very few other components, let’s now build a circuit to simulate an access control system using RFID technology with our RC522 module.

The sketch we have prepared can be downloaded and is called Access_Control.rar; it consists of two tabs, and the folder obtained from decompressing the file must be placed in the sketch folder of your IDE; the vma405_library must have been installed beforehand.

The idea is a hypothetical access control system, where the acceptance of a Tag is indicated by the alternating on/off of a blue LED, while rejection is represented by a red LED turning on for about 3 seconds.

Authorized Tags are pre-stored in the EEPROM of the Arduino microcontroller; our sketch supports up to three, but they can be increased up to the availability of the EEPROM. Storage only happens with prior authorization from the “System Administrator,” who has an RFID CARD Tag whose UID must be manually entered in the sketch and which, once read by the module, allows other Tags to be brought close to accredit them and store them in the EEPROM.

From this point on, when you bring an authorized tag near the module, the blue LED will turn on or off with each pass, toggling its state. The red LED, on the other hand, will light up for three seconds when someone tries to gain access with an unregistered tag, effectively denying authorization, and then it will turn off.

Before uploading the sketch to the Arduino, you need to open it and assign the corresponding decimal values of the chosen tag’s UID to the five variables dec_code0 through dec_code4 (Fig. 6), replacing the pre-stored values you will find there.

At this point you can upload the sketch to the Arduino and then disconnect the USB cable to remove power. Next, move on to building the practical layout shown in Fig. 7, which explains how to connect all the required components.

Required materials

The materials needed to build the project are:

• RFID-RC522 module
• Arduino UNO
• Breadboard with side power rails (red and black, or red and blue)
• 6×6 mm push button
• Red LED
• Blue LED (or another color of your choice)
• 2 resistors of 220 Ohm
• 1 resistor of 10 kOhm
• 5 M-M jumper wires
• 7 M-F jumper wires
• 1 jumper bridge, 3-pin
• 1 jumper bridge, 5-pin
• 1 jumper bridge, 19-pin
• 4 tags, one of which marked as administrator

Note that regarding jumper wires and bridges, we provided the list to replicate our exact practical layout; of course you can make any variation, as long as you correctly make the proposed connections, otherwise the circuit will not work. Above all, be extremely careful not to reverse the power supply (3.3V and GND), otherwise you risk burning the module!

A special note about the breadboard: during our tests we came across a model with the power rails interrupted in the middle section. This was actually clearly indicated by the break in the red and blue silkscreen lines, but since it is unusual, we initially did not notice it. As a result, the RC522 module’s LED still turned on (due to current carried by the signals), but tag reading did not work. We therefore had to add two jumper wires to connect the two rails along their entire length (Fig. 8), i.e., to bridge them.

How the access control works

Once the circuit is complete on the breadboard and the connections are checked, to begin simply reconnect the USB cable from the PC to the Arduino UNO board. You will see the RC522 module’s red LED light up (but as explained earlier, this does not indicate correct power supply), while the two red and blue LEDs on the breadboard remain off.

Now open the Serial Monitor of the Arduino IDE, and the message “Controllo accessi attivo” will appear. The first operation to perform is to bring the Administrator tag near the module. If everything is in order, the two LEDs will blink simultaneously three times and remain on; the Serial Monitor will also show the message visible in Fig. 9, indicating that Administrator mode is active.

If at first power-up a number other than 0 appears (usually it will be 255), you need to reset the EEPROM. Simply press the push button mounted on the breadboard to achieve the desired result (Fig. 10).

After the reset, you will exit Administrator mode and the LEDs will turn off. You must pass the Administrator tag again to re-enter, then simply bring the tag you want to authorize near the module to store its UID (Fig. 11).

This operation can be performed for a maximum of three tags; after that, no more can be stored unless you modify the sketch accordingly.

Daily use of the system

At this point we can observe the circuit’s behavior depending on the type of tag we bring near the RFID reader; there are two possibilities.

Unregistered tag: the red LED turns on for about three seconds, then turns off; authorization is denied.

Registered tag: if the blue LED is off, it turns on, indicating that authorization has been granted; the LED stays on until you pass the same tag or another registered tag, at which point it turns off.

One last curiosity: if you lack other tags to simulate unauthorized access, you can use your own smartphone. If you have a phone with an NFC chip running Android 5.0 or later, simply enable NFC in the settings and then use the smartphone as if it were a tag.

In fact, when you bring it near the module with the chip side facing it, it will be recognized as a tag, but with a peculiarity that prevents its use as an authorized tag: with each new read, the UID turns out to be different from the previous read. This is easily verifiable with the “RFID_TAG_CODE” sketch. So even if you store the chip as authorized, it will not be recognized on subsequent reads.

In some rare cases, the smartphone may need a specific app to function as a tag. Simply download “NFC Tools” from the Play Store and leave it active, without doing anything else.

Conclusions

We end this article with a suggestion: as you can easily imagine, this project can be expanded by adding, for example, a relay driven by the same pin as the blue LED, which would allow you to activate an actuator such as an electric lock. The only limits are those of your imagination.

Naturally, the greater the complexity of the expansion, the more variations and implementations you will need to make to the sketch, but it will all be a useful programming exercise that will increase your skills and give you great satisfaction.

The post RFID with RC522: Radio-Frequency Identification with Arduino appeared first on Open Electronics.

Let’s get to know and learn how to use a board for RF tag identification, easily paired with Arduino.

We have covered radio-frequency identification, better known as RFID, several times before; for example, in issue no. 254 we dedicated an in-depth look at it with a thorough theoretical introduction and some usage examples based on the RFID PN522 module, accompanied by the ever-present Arduino board. In this article, we pick up the discussion again by experimenting with another module, the RFID-RC522, based on the MFRC522 chip produced by NXP (the datasheet is available at the web link https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf).

The RFID-RC522 module

The MFRC522 is a highly integrated RFID reader/writer for contactless communication at 13.56 MHz, supporting the ISO/IEC14443A/MIFARE and NTAG standards.

The transmitter inside the MFRC522 can drive an antenna designed to communicate with cards and transponders without additional active circuits. The internal receiver can efficiently demodulate and decode signals from cards and transponders compatible with the standards listed above.

The MFRC522 supports the MF1xxS20, MF1xxS70, and MF1xxS50 models. It also supports contactless communication with MIFARE transfer rates up to 848 kB (kiloBaud) in bidirectional mode.

The MFRC522 is compatible with all variants of the MIFARE identification protocols MIFARE Mini, MIFARE 1K, MIFARE 4K, MIFARE Ultralight, MIFARE DESFire EV1, and MIFARE Plus RF, grouped under the generic term MIFARE.

Below we summarize the main technical features of the module:

• analog circuit to demodulate and decode responses;
• buffered drivers for connecting an antenna with a reduced number of external components;
• supports ISO/IEC 14443 A/MIFARE and NTAG;
• typical operating distance in read/write mode up to 50 mm depending on antenna size and tuning;
• supports MF1xxS20, MF1xxS70, and MF1xxS50 encryption in read/write mode;
• supports ISO/IEC 14443 with high transfer rate communication up to 848 kbaud;
• supports MFIN/MFOUT;
• additional internal power supply to the smart card IC connected via MFIN/MFOUT;
• supported host interfaces: SPI up to 10 Mbit/s, I²C-Bus up to 400 kBd in Fast mode, up to 3400 kBd in High-speed mode, serial UART RS232 up to 1,228.8 kB/s, with voltage levels depending on the pin supply voltage;
• the FIFO buffer manages sending and receiving at 64 bytes;
• flexible interrupt modes;
• hard reset with low-power function;
• software power-down;
• programmable timer;
• supply voltage from 2.5 to 3.3 V;
• programmable I/O pins.

The RFID-RC522 module is detailed in Fig. 1, where you can see all the available connections.

Connecting to Arduino

Since all current libraries for using the module with Arduino reuse the SPI connection, we will focus only on that; Fig. 2 illustrates the connection to make for the subsequent tests with Arduino UNO.

In Table 1 we describe the connections analytically with their signals: on the left are those of the Arduino UNO and on the right the contacts of the RFID-RC522 module with the corresponding wire colors in the diagram in Fig. 2. The IRQ pin of the RFID module should be left unconnected because we do not manage it in this project and do not need it.

Of course, you must be very careful, because swapping just two wires will cause the module to fail; another important thing is power: the module requires 3.3 V, and the corresponding pin on Arduino is right next to the 5 V one; a moment of distraction would almost certainly damage the module.

The board (the RFID module used in the project) comes with two 8-pin strip headers (one straight and one at 90°) to solder as you prefer into the appropriate signal holes, an RFID Tag Card, and an RFID keychain Tag for initial testing.

Libraries for RC522

Using this module is made easier by the availability of specific libraries, of which we have selected two: the one from Velleman and the one written by Miguel Balboa.

Velleman: it is a minimal library consisting of only two files (RFID.h and RFID.cpp). Once downloaded from the link: https://www.velleman.eu/downloads/29/vma405_library.zip, you need to include it by opening a new sketch with an updated version of the IDE (in our case 1.8.12). Run the command Sketch – Include Library – Add .ZIP Library… and select the .zip file (Fig. 3), then close the IDE; it will be available when you reopen it.

Miguel Balboa: this library, much more powerful and articulated, is recommended by the official Arduino website; it is constantly updated, so it is always best to go to the link https://www.arduino.cc/reference/en/libraries/mfrc522/ or directly to the GitHub https://github.com/miguelbalboa/rfid; at the time of writing, the latest version is 1.4.8.

Its inclusion in the IDE is done in the same way as seen before. This library is quite demanding and requires considerable skills in RFID and programming to exploit it, so we only point it out to more experienced readers, while for the test we will see later we will use the one distributed by Velleman.

Functionality test

Let’s start with a test to verify the connections and the correct installation of the vma405 library. We have prepared a sketch named “RFID_TAG_CODE”; open it in the IDE and upload it to the Arduino UNO, then open the Serial Monitor, which will show the message “Avvicina un Tag al Modulo” (Bring a Tag close to the Module); at this point, bring the Tag close to the part of the module where the radio wave symbols are silkscreened (Fig. 4).

Keep in mind that the module should always be kept away from devices that can generate electric or electromagnetic fields, otherwise it might not work correctly.

The moment the Tag is recognized, the module reads its UID (unique identification code) and displays it on the Serial Monitor, both in decimal and hexadecimal format; in Fig. 5 we can observe the successive reading of two Tags.

If after the first identification you bring the same Tag close again, nothing will happen because we have not included an alternative action in the sketch; bringing another Tag close instead will give its UID in both formats.

When this test succeeds, you need to decide which Tag will be the “System Administrator” of the circuit we have prepared for experimenting with this module and note the five decimal numbers that make up its UID. For our example, we will use the first group visible in the figure (197, 5, 190, 35, 93).

Access control project

With the help of a breadboard and very few other components, let’s now build a circuit to simulate an access control system using RFID technology with our RC522 module.

The sketch we have prepared can be downloaded and is called Access_Control.rar; it consists of two tabs, and the folder obtained from decompressing the file must be placed in the sketch folder of your IDE; the vma405_library must have been installed beforehand.

The idea is a hypothetical access control system, where the acceptance of a Tag is indicated by the alternating on/off of a blue LED, while rejection is represented by a red LED turning on for about 3 seconds.

Authorized Tags are pre-stored in the EEPROM of the Arduino microcontroller; our sketch supports up to three, but they can be increased up to the availability of the EEPROM. Storage only happens with prior authorization from the “System Administrator,” who has an RFID CARD Tag whose UID must be manually entered in the sketch and which, once read by the module, allows other Tags to be brought close to accredit them and store them in the EEPROM.

From this point on, when you bring an authorized tag near the module, the blue LED will turn on or off with each pass, toggling its state. The red LED, on the other hand, will light up for three seconds when someone tries to gain access with an unregistered tag, effectively denying authorization, and then it will turn off.

Before uploading the sketch to the Arduino, you need to open it and assign the corresponding decimal values of the chosen tag’s UID to the five variables dec_code0 through dec_code4 (Fig. 6), replacing the pre-stored values you will find there.

At this point you can upload the sketch to the Arduino and then disconnect the USB cable to remove power. Next, move on to building the practical layout shown in Fig. 7, which explains how to connect all the required components.

Required materials

The materials needed to build the project are:

• RFID-RC522 module
• Arduino UNO
• Breadboard with side power rails (red and black, or red and blue)
• 6×6 mm push button
• Red LED
• Blue LED (or another color of your choice)
• 2 resistors of 220 Ohm
• 1 resistor of 10 kOhm
• 5 M-M jumper wires
• 7 M-F jumper wires
• 1 jumper bridge, 3-pin
• 1 jumper bridge, 5-pin
• 1 jumper bridge, 19-pin
• 4 tags, one of which marked as administrator

Note that regarding jumper wires and bridges, we provided the list to replicate our exact practical layout; of course you can make any variation, as long as you correctly make the proposed connections, otherwise the circuit will not work. Above all, be extremely careful not to reverse the power supply (3.3V and GND), otherwise you risk burning the module!

A special note about the breadboard: during our tests we came across a model with the power rails interrupted in the middle section. This was actually clearly indicated by the break in the red and blue silkscreen lines, but since it is unusual, we initially did not notice it. As a result, the RC522 module’s LED still turned on (due to current carried by the signals), but tag reading did not work. We therefore had to add two jumper wires to connect the two rails along their entire length (Fig. 8), i.e., to bridge them.

How the access control works

Once the circuit is complete on the breadboard and the connections are checked, to begin simply reconnect the USB cable from the PC to the Arduino UNO board. You will see the RC522 module’s red LED light up (but as explained earlier, this does not indicate correct power supply), while the two red and blue LEDs on the breadboard remain off.

Now open the Serial Monitor of the Arduino IDE, and the message “Controllo accessi attivo” will appear. The first operation to perform is to bring the Administrator tag near the module. If everything is in order, the two LEDs will blink simultaneously three times and remain on; the Serial Monitor will also show the message visible in Fig. 9, indicating that Administrator mode is active.

If at first power-up a number other than 0 appears (usually it will be 255), you need to reset the EEPROM. Simply press the push button mounted on the breadboard to achieve the desired result (Fig. 10).

After the reset, you will exit Administrator mode and the LEDs will turn off. You must pass the Administrator tag again to re-enter, then simply bring the tag you want to authorize near the module to store its UID (Fig. 11).

This operation can be performed for a maximum of three tags; after that, no more can be stored unless you modify the sketch accordingly.

Daily use of the system

At this point we can observe the circuit’s behavior depending on the type of tag we bring near the RFID reader; there are two possibilities.

Unregistered tag: the red LED turns on for about three seconds, then turns off; authorization is denied.

Registered tag: if the blue LED is off, it turns on, indicating that authorization has been granted; the LED stays on until you pass the same tag or another registered tag, at which point it turns off.

One last curiosity: if you lack other tags to simulate unauthorized access, you can use your own smartphone. If you have a phone with an NFC chip running Android 5.0 or later, simply enable NFC in the settings and then use the smartphone as if it were a tag.

In fact, when you bring it near the module with the chip side facing it, it will be recognized as a tag, but with a peculiarity that prevents its use as an authorized tag: with each new read, the UID turns out to be different from the previous read. This is easily verifiable with the “RFID_TAG_CODE” sketch. So even if you store the chip as authorized, it will not be recognized on subsequent reads.

In some rare cases, the smartphone may need a specific app to function as a tag. Simply download “NFC Tools” from the Play Store and leave it active, without doing anything else.

Conclusions

We end this article with a suggestion: as you can easily imagine, this project can be expanded by adding, for example, a relay driven by the same pin as the blue LED, which would allow you to activate an actuator such as an electric lock. The only limits are those of your imagination.

Naturally, the greater the complexity of the expansion, the more variations and implementations you will need to make to the sketch, but it will all be a useful programming exercise that will increase your skills and give you great satisfaction.

The post RFID with RC522: Radio-Frequency Identification with Arduino appeared first on Open Electronics.

Global smartphone production in second-quarter 2026 reached 275 million units, down 8% year-on-year, according to market research firm TrendForce. The decline was narrower than previously forecast, resulting in better-than-expected overall performance...

Aheesa Digital Innovations, a DLI-scheme backed fabless semiconductor company headquartered in Chennai, has signed a Memorandum of Understanding (MoU) with Optilink Networks Pvt. Ltd., onboarding the company as its packaging partner for VIHAAN-I, Aheesa’s indigenous RISC-V broadband networking System-on-Chip (SoC). The partnership marks another step towards commercialising VIHAAN-I, strengthening the pathway from indigenous chip design and silicon validation to packaging, distribution and market deployment.

The partnership brings together two complementary parts of the broadband technology ecosystem. Optilink has supported the VIHAAN-I journey through testing, validation and engineering support, with its in-house capabilities across product design, firmware development and hardware integration. Under the MoU, Optilink will support end-to-end product development from prototyping to packaging, while the companies work towards developing, qualifying and commercialising ONT/CPE products based on the VIHAAN-I chipset. The collaboration is aimed at delivering solutions that are cost-efficient and comply with Indian and global standards, while accelerating commercialisation through Optilink’s engineering and manufacturing expertise.

This further advances Aheesa’s ambition to establish itself as a semiconductor design house with a portfolio of Indian-designed chips serving both domestic and global markets. With design, silicon validation, packaging and distribution capabilities progressively coming together, Aheesa is now leaping towards commercial deployment in early 2027.

The partnership comes in a landmark year for Aheesa. VIHAAN-I achieved tape-out on Republic Day 2026, followed by Aheesa securing investment from the Tamil Nadu Infrastructure Fund Management Corporation (TNIFMC) through the Tamil Nadu Emerging Sector Seed Fund. On this Independence Day, the chip achieved first-pass silicon success on its very first attempt.

Commenting on the partnership, Sridharan Mani, Founder and CEO, Aheesa Digital Innovations, said, “Building a chip is only half the journey as the real test is turning that silicon into a product people can use. No semiconductor ecosystem thrives on the strength of one player alone; it takes multiple partners, each doing their part, to carry a design to the consumer and make this sector succeed. With Optilink joining us for packaging, VIHAAN-I takes a step closer to that reality. We have spent years estabilishing that world-class semiconductor design can happen in India. Now with Optilink, we’re building the pathway to take it from systems to scale.”

Devchand Haria, Managing Director, Optilink Networks Pvt. Ltd said, “At Optilink, we’ve spent close to two decades building the networking hardware that connects Indian homes from fiber access to broadband CPE. Partnering with Aheesa for VIHAAN-I lets us bring that same experience to an Indian-designed chip, taking it from silicon to the products that will actually sit in Indian households. This is exactly the kind of collaboration our sector needs, that is Indian design and Indian manufacturing expertise working together to put homegrown silicon inside the devices people use every day.”

Founded in 2005 and headquartered in Mumbai, Optilink Networks Pvt. Ltd. is an Indian Original Equipment Manufacturer (OEM) that designs, manufactures and distributes IP-based networking hardware, Fiber-to-the-Home (FTTH) solutions and IP Television (IPTV) technologies. Serving ISPs, telecom operators, cable and MSO networks, enterprises and government customers, Optilink has built a strong B2B presence through its channel partners, distributors and system integrators across India.

Aheesa’s work spans indigenous semiconductor and networking technologies across telecom, broadband, cybersecurity and edge computing. This partnership now reflects the wider momentum in India’s semiconductor design ecosystem, now scaling under Semicon 2.0 — the ₹1,27,500 crore programme approved in July 2026 to build a globally competitive supply chain across chip design, manufacturing, packaging and materials. As indigenous designs move from validation towards commercial adoption, it is partnerships like this, pairing Indian chip design with the reach to deploy it, that will help define how homegrown silicon scales.

The post From Silicon to Scale: Aheesa Signs Packaging MoU with Optilink Networks appeared first on ELE Times.

Sirojudin Munir has released an open-source FOC driver for BLDC and PMSM motors. The project includes firmware for STM32, hardware designed in KiCad, Gerber files, a BOM, and a Python GUI for control and monitoring. It is a complete resource for anyone who wants to build or study the vector control of a brushless motor. The permissive MIT license and the stated component cost of $28.58 make it accessible to many makers.

The heart of the system is the STM32F405 microcontroller, which runs the Field-Oriented Control calculations. The ADC reads current, the PWM drives the inverter, and SPI communicates with the magnetic encoder. The DRV8323RH gate driver manages the MOSFETs and also acts as a voltage regulator. The AS5047 encoder detects the rotor position, while the INA240A1 amplifier measures current with precision. All these components work together for efficient and responsive control.

How FOC control works

The firmware implements the Field-Oriented Control algorithm to manage motor torque and speed. The self-commissioning process measures motor resistance and inductance and calibrates the encoder. This way, the driver adapts to the connected motor without manual intervention. Several control modes are available: current, speed, position, open-loop, and motor disable. This flexibility makes the project suitable for many practical applications.

• Current control to manage torque
• Speed control with encoder feedback
• Position control for precision applications
• Open-loop mode for quick tests
• Full motor disable for safety

The PyQt/PyQtGraph GUI allows real-time data visualization and sending commands to the driver. The Python tools include functions for calibration and monitoring. Additionally, the improved client written by Munir simplifies system tuning. The project is designed to be studied and modified, with clear documentation and well-organized files.

Hardware and main components

The schematic and PCB are made in KiCad, with Gerber files ready for production. The board operates with voltages from 6 to 24 V and current up to 1 A. The 3-pin connector with 1.25 mm pitch makes motor connection easy. Those who want to study brushless control starting from something ready-made can look at a brushless motor driver with a Hall sensor: it does not do vector control, but it lets you see the inverter and power MOSFETs in action before making your own board. For testing, you will need a brushless motor.

The DRV8323RH gate driver is a key component: it drives the inverter MOSFETs and integrates a voltage regulator. The AS5047 magnetic encoder offers high resolution for rotor position. The INA240A1 measures current with a dedicated amplifier. These components are chosen to ensure reliable performance and good value for money.

Software tools and commissioning

The firmware compiles with PlatformIO in Visual Studio Code, starting from the STM32CubeMX configuration. The project board includes all the steps for commissioning. Self-commissioning automates the measurement of motor resistance and inductance. Encoder calibration is guided, reducing errors. Finally, the Python GUI lets you test the different control modes in real time.

Munir’s project is an excellent example of open-source technical documentation. It includes demonstration videos and clear instructions for reproduction. For those taking their first steps with brushless motors, this driver offers a solid foundation. Even those with experience can find interesting ideas in the design and firmware.

In summary, this is a complete, well-documented FOC driver with a permissive license. The component cost is low and the build quality is high. For anyone wanting to delve into brushless motor control, this is a project worth studying carefully. The combination of STM32, DRV8323RH, and AS5047 delivers remarkable performance in a compact format.

Source: https://github.com/sirojudinMunir/sf-motion

Related products

• Brushless motor

The post Open-Source FOC Driver for BLDC Motors: Sirojudin Munir’s Project appeared first on Open Electronics.

Sirojudin Munir has released an open-source FOC driver for BLDC and PMSM motors. The project includes firmware for STM32, hardware designed in KiCad, Gerber files, a BOM, and a Python GUI for control and monitoring. It is a complete resource for anyone who wants to build or study the vector control of a brushless motor. The permissive MIT license and the stated component cost of $28.58 make it accessible to many makers.

The heart of the system is the STM32F405 microcontroller, which runs the Field-Oriented Control calculations. The ADC reads current, the PWM drives the inverter, and SPI communicates with the magnetic encoder. The DRV8323RH gate driver manages the MOSFETs and also acts as a voltage regulator. The AS5047 encoder detects the rotor position, while the INA240A1 amplifier measures current with precision. All these components work together for efficient and responsive control.

How FOC control works

The firmware implements the Field-Oriented Control algorithm to manage motor torque and speed. The self-commissioning process measures motor resistance and inductance and calibrates the encoder. This way, the driver adapts to the connected motor without manual intervention. Several control modes are available: current, speed, position, open-loop, and motor disable. This flexibility makes the project suitable for many practical applications.

• Current control to manage torque
• Speed control with encoder feedback
• Position control for precision applications
• Open-loop mode for quick tests
• Full motor disable for safety

The PyQt/PyQtGraph GUI allows real-time data visualization and sending commands to the driver. The Python tools include functions for calibration and monitoring. Additionally, the improved client written by Munir simplifies system tuning. The project is designed to be studied and modified, with clear documentation and well-organized files.

Hardware and main components

The schematic and PCB are made in KiCad, with Gerber files ready for production. The board operates with voltages from 6 to 24 V and current up to 1 A. The 3-pin connector with 1.25 mm pitch makes motor connection easy. Those who want to study brushless control starting from something ready-made can look at a brushless motor driver with a Hall sensor: it does not do vector control, but it lets you see the inverter and power MOSFETs in action before making your own board. For testing, you will need a brushless motor.

The DRV8323RH gate driver is a key component: it drives the inverter MOSFETs and integrates a voltage regulator. The AS5047 magnetic encoder offers high resolution for rotor position. The INA240A1 measures current with a dedicated amplifier. These components are chosen to ensure reliable performance and good value for money.

Software tools and commissioning

The firmware compiles with PlatformIO in Visual Studio Code, starting from the STM32CubeMX configuration. The project board includes all the steps for commissioning. Self-commissioning automates the measurement of motor resistance and inductance. Encoder calibration is guided, reducing errors. Finally, the Python GUI lets you test the different control modes in real time.

Munir’s project is an excellent example of open-source technical documentation. It includes demonstration videos and clear instructions for reproduction. For those taking their first steps with brushless motors, this driver offers a solid foundation. Even those with experience can find interesting ideas in the design and firmware.

In summary, this is a complete, well-documented FOC driver with a permissive license. The component cost is low and the build quality is high. For anyone wanting to delve into brushless motor control, this is a project worth studying carefully. The combination of STM32, DRV8323RH, and AS5047 delivers remarkable performance in a compact format.

Source: https://github.com/sirojudinMunir/sf-motion

Related products

• Brushless motor

The post Open-Source FOC Driver for BLDC Motors: Sirojudin Munir’s Project appeared first on Open Electronics.

Infineon Technologies AG introduces the TDA235E5 and TDA235E0, a dual-phase smart power stage family designed to meet the rapidly growing power density requirements of next-generation AI accelerators and vertical power delivery modules. Integrating Infineon’s OptiMOS 6 MOSFETs and a dual-phase driver IC in a compact 6 x 6 x 0.8 mm³ package, the new family delivers benchmark power density exceeding 2 A/mm², setting a new reference point for power stage performance in high current AI processor applications. As hyperscalers and datacenter operators continue to scale AI infrastructure, the demand for power delivery solutions that combine higher current capability with shrinking physical footprints is becoming a critical bottleneck.

“Infineon customers are designing AI systems that will define the next decade of computing infrastructure,” said Rakesh Renganathan, Vice President Power ICs at Infineon. “The TDA235E5 and TDA235E0 power stages give designers the power density, thermal performance, and design flexibility to move faster and build with confidence, backed by Infineon’s full AI server power delivery ecosystem.”

The two devices support up to 300 A peak current and 120 A total design current (TDC), making them well suited for next generation AI xPU accelerators as well as conventional server CPUs in datacenter environments. Both lateral and vertical power delivery configurations are supported, providing the design flexibility required as the industry transitions toward vertical power module architectures in advanced AI processor packages. Superior thermal impedance from junction to top side enables efficient liquid cooling integration, a characteristic that is increasingly important as power levels per processor socket continue to rise and traditional air-cooled thermal budgets are exhausted. Combined with Infineon’s digital multiphase controllers, the power stages support flexible, scalable multi-rail architectures that reduce time to deployment in fast-evolving AI server platforms.

The TDA235E5 and TDA235E0 integrate into Infineon’s end-to-end AI server power delivery ecosystem, spanning the full power chain from grid interface to processor core rails. By combining the complementary strengths of silicon, silicon carbide, and gallium nitride, Infineon provides datacenter customers with a proven, scalable path to the highest efficiency, robustness, and power density available for AI-optimized infrastructure. The datacenter power delivery market is one of the semiconductor industry’s fastest-growing demand segments, driving Infineon’s continued product investment to serve this opportunity at the component level where power density requirements are most critical. 

The post Infineon Sets New Power Benchmark for AI accelerators and Vertical Power Delivery with 2 A/mm² Dual-Phase Smart Power Stages appeared first on ELE Times.

Hello everyone, Six months ago I set upon the journey of making my own AWG, with frequencies of up to 1MHz. 6 months later I present you my very own awg. Full Repo I set out to build my own function generator after finding commercial units both too expensive and more general-purpose than I needed, and it looked like a good excuse to work through analog synthesis, filtering, and mixed-signal PCB design end to end. The sine path is an 8-bit R-2R ladder driven by a Raspberry Pi Pico W (overclocked to 225MHz) generating samples via a DDS phase accumulator; the square wave comes from the same chip’s PIO hardware. I started off with a breadboard and tried sallen key filters for noise but they amplified the noise aswell. I also tried discrete components for the sauare wave before replacing it outright with a TC4427 gate driver. The sine chain settled on a 5th-order doubly-terminated LC Butterworth reconstruction filter, replacing an earlier cascaded-RC design that was capping amplitude, followed by LM318 gain and buffer stages. Three PCBs went out; two came back dead. V1.0 was completely non-functional because a BOM matcher substituted 2.21Ω resistors for 2.21kΩ across the entire R-2R ladder. V1.1 moved to an all-SMD board with the LC Butterworth filter but came up dead silent; testing the square path first (it worked) narrowed the fault to the sine chain, which traced to a KiCad-to-Altium migration that had silently shorted two LM318 input pins onto one net. V1.2 fixed that short, soldered the Pico directly to the board in place of a socket, and came up working: sine characterised from 0Hz to 1MHz and square to 2MHz, with AM, FM, and noise modes added on top in firmware, all controllable from a Python desktop UI over USB. Looking at it now, a redesign with some improvements (better op-amps and also fewer) would be better but I also want to work on other stuff, so for now this is it. To be clear, I made every schematic and protoype and thought up everything myself. As such this may not be the best way to do this. My main goal, was experience after all. full webpage submitted by /u/S4vDs [link] [comments]

In Yole Group’s White Paper ‘Photonics at the Speed of AI’ (part of the firm’s AI White Papers Collection), it argues that optical transceivers — once a supporting piece of data-center infrastructure — have become a system-level requirement for scaling artificial intelligence...

Phil Underwood has spent twenty years mapping underground caves. His work has produced a series of open hardware devices that increase the speed and accuracy of surveys. The journey starts with tools based on 8-bit microcontrollers and arrives at a complete photogrammetry system. Each generation solved a specific problem, improving the design incrementally.

The first version, presented in 2008, used an accelerometer and a magnetometer to determine direction and angle. Distance, however, was still measured manually. The heart of the system was a PIC18LF2550, an 8-bit microcontroller. This approach proved that part of the survey could be automated, but human intervention was still needed for linear measurements.

The turning point came in 2020. Phil added a laser rangefinder and a 32-bit microcontroller. This allowed the device to calculate distances autonomously and handle more complex operations. Data collection also became faster and less error-prone. The move from 8 to 32 bits made it possible to process more information directly in the field.

Improved design and community

In 2023 the project received special attention. The enclosure was 3D-printed, with silicone buttons resistant to water and dust. The firmware moved to CircuitPython, a language that makes community contributions easier. Many makers were able to modify the code without deep electronics knowledge. This accelerated development and made the project more open.

Choosing CircuitPython made the code more readable and easier to maintain. 3D printing also allowed custom enclosures for each environment. The modular design made it simple to replace damaged components. As a result, the device became a reliable tool for cavers.

• 2008: accelerometer, magnetometer, PIC18LF2550 8-bit
• 2020: laser rangefinder and 32-bit microcontroller
• 2023: 3D-printed enclosure and CircuitPython firmware

Latest version: Raspberry Pi 5 Compute Module and photogrammetry

The latest generation represents a technological leap. The system uses a Raspberry Pi 5 Compute Module and two low-light cameras. The cameras capture images of the cave interior, then the software processes them to create textured 3D models. This approach eliminates the need to measure every point manually. The result is a detailed and realistic map.

For those wanting to experiment with similar sensors, a 9-axis module with accelerometer, gyroscope, and magnetometer combines in one unit the two measurements that supported the 2008 version. For processing, a Raspberry Pi 5 with 4 GB of RAM handles photogrammetry without strain, and a 5-megapixel camera for Raspberry Pi is the cheapest way to try dual capture.

Phil Underwood’s project shows a methodical approach to hardware design. Every choice, from materials to computing power, was guided by the real needs of cavers. The lessons learned apply to any rugged instrumentation. In particular, modularity and ease of maintenance are essential in extreme environments.

Lessons for makers

The story of this project teaches that incremental evolution works. You start with a simple prototype, test it in the field, then improve it. Each generation solved a concrete problem. Moreover, openness to the community accelerated the process. Documentation and code are available for anyone who wants to contribute.

Cave mapping with photogrammetry is just the latest milestone. The complete system, with Raspberry Pi 5 Compute Module, is an example of how open source hardware can tackle complex challenges. The device is called Shetland Attack Pony, and the sixth generation (SAP6) is fully documented: schematics, component list, and CircuitPython code are public.

Source: https://stic.readthedocs.io/

The post Mapping Caves with Photogrammetry and Raspberry Pi appeared first on Open Electronics.

Phil Underwood has spent twenty years mapping underground caves. His work has produced a series of open hardware devices that increase the speed and accuracy of surveys. The journey starts with tools based on 8-bit microcontrollers and arrives at a complete photogrammetry system. Each generation solved a specific problem, improving the design incrementally.

The first version, presented in 2008, used an accelerometer and a magnetometer to determine direction and angle. Distance, however, was still measured manually. The heart of the system was a PIC18LF2550, an 8-bit microcontroller. This approach proved that part of the survey could be automated, but human intervention was still needed for linear measurements.

The turning point came in 2020. Phil added a laser rangefinder and a 32-bit microcontroller. This allowed the device to calculate distances autonomously and handle more complex operations. Data collection also became faster and less error-prone. The move from 8 to 32 bits made it possible to process more information directly in the field.

Improved design and community

In 2023 the project received special attention. The enclosure was 3D-printed, with silicone buttons resistant to water and dust. The firmware moved to CircuitPython, a language that makes community contributions easier. Many makers were able to modify the code without deep electronics knowledge. This accelerated development and made the project more open.

Choosing CircuitPython made the code more readable and easier to maintain. 3D printing also allowed custom enclosures for each environment. The modular design made it simple to replace damaged components. As a result, the device became a reliable tool for cavers.

• 2008: accelerometer, magnetometer, PIC18LF2550 8-bit
• 2020: laser rangefinder and 32-bit microcontroller
• 2023: 3D-printed enclosure and CircuitPython firmware

Latest version: Raspberry Pi 5 Compute Module and photogrammetry

The latest generation represents a technological leap. The system uses a Raspberry Pi 5 Compute Module and two low-light cameras. The cameras capture images of the cave interior, then the software processes them to create textured 3D models. This approach eliminates the need to measure every point manually. The result is a detailed and realistic map.

For those wanting to experiment with similar sensors, a 9-axis module with accelerometer, gyroscope, and magnetometer combines in one unit the two measurements that supported the 2008 version. For processing, a Raspberry Pi 5 with 4 GB of RAM handles photogrammetry without strain, and a 5-megapixel camera for Raspberry Pi is the cheapest way to try dual capture.

Phil Underwood’s project shows a methodical approach to hardware design. Every choice, from materials to computing power, was guided by the real needs of cavers. The lessons learned apply to any rugged instrumentation. In particular, modularity and ease of maintenance are essential in extreme environments.

Lessons for makers

The story of this project teaches that incremental evolution works. You start with a simple prototype, test it in the field, then improve it. Each generation solved a concrete problem. Moreover, openness to the community accelerated the process. Documentation and code are available for anyone who wants to contribute.

Cave mapping with photogrammetry is just the latest milestone. The complete system, with Raspberry Pi 5 Compute Module, is an example of how open source hardware can tackle complex challenges. The device is called Shetland Attack Pony, and the sixth generation (SAP6) is fully documented: schematics, component list, and CircuitPython code are public.

Source: https://stic.readthedocs.io/

The post Mapping Caves with Photogrammetry and Raspberry Pi appeared first on Open Electronics.

Заслужений професор КПІ Юрій Лукач. До 100-річчя від дня народження Інформація КП пн, 09/07/2026 - 17:00

Here is my project repo https://github.com/fredriknk/chatgpt_astra_test2 I saw the Chatgpt Astra kicad demo, and wanted to try it out myself and im pretty damn impressed...! I only have a openai 20$/mo plus subscription so i had to use the lowest setting, but i got this design in 3 hours with 5 prompts in total and ate up my 3 usage resets. My only contributions to the design was to create the empty kicad template project, and the initial prompt: "Lets test a esp32 design with a 24v input voltage which can output and read 4-20ma signals. Lets start planning!" All design choices, component choices, design, schematics and, layout and documentation was done by the chatgpt astra 6 low through codex cli. So final verdict? Its actually pretty damn usable.... Like, its not perfect by any means. some examples: There are a quite a few routing decisions i dont agree with, especially the USB routing and unneccesarry internal layer routing. The schematics are very hard to read as it doesnt use GND/Power symbols, and only use global labels instead of wires. But as far as i can tell from the schematic, this is a working design and i do agree with a lot of its component choices. I feel it is pretty much where AI coding was in around 2024 (on its lowest setting), so im wondering where this will be in a year or two..! submitted by /u/Gjfiyfyifiyf [link] [comments]

The simplest explanation is likely the best, even if its validity isn’t always intuitively obvious in advance.

Speaking of USB-C, and the cables (including splitters) that connect to it to other things…

My long-in-the-tooth Intel-based 2018 Apple Mac mini is still sitting on my desk, humming to my right, even though its M2 Pro Apple Silicon-based successor has been sitting downstairs in storage awaiting its turn in the spotlight for going on three years now. The legacy hardware is no longer a candidate for new Apple operating system releases, but it’s still receiving bug fixes and security patches, until sometime in the second half of next year, if past-history trends remain valid. And as the saying goes, “if it works, don’t touch it” (I’d also be tempted to haul out the “a penny saved is a penny earned” quote, but since I’ve already bought its replacement…).

In conjunction with my transition to it from its 2014-era Mac mini predecessor roughly 2.5 years ago, I upgraded the two-display suite above it to a set of Dell P2415Q 4K LCDs.

The Mac mini leverages the displays’ HDMI inputs; a “Project Volterra” Windows-on-Arm dev kit 2023 stacked above it connects to those same LCDs over their DisplayPort connections, and front panel buttons toggle the displays between the two systems when running concurrently.

Look back at that 2018 Mac mini rear panel “stock” photo a couple of paragraphs ago, however, and you’ll only see one HDMI output, into which I’ve plugged a “straight” HDMI cable running directly to one of the LCDs. How, then, did I connect the system to the other display’s HDMI input? That’s where today’s teardown victim enters the picture.

It’s an Anker A8730 6’ USB-C to HDMI adapter cable; I’d bought and pressed it into immediate service way back in mid-2021. I sourced from Anker’s outlet store on eBay, where it cost $25.90 as a refurb. So, you can say I’ve gotten my money’s worth out of it! Speaking of fiscal topics, there’s a 0.75′′ (19.1 mm) diameter U.S. penny alongside in the second (and non-stock) image that follows, along with subsequent others, for size comparison purposes.

A multimedia-centric repurpose

How it works is (at least to me) an interesting story in and of itself. It fundamentally leverages a DisplayPort technology called “Alt Mode”, which repurposes USB 3.x’s “SuperSpeed” data and Configuration Channel (CC) lines to transport dedicated audio and video streams sourced from the graphics and sound subsystems. The CC leverage explains why, among other implementation reasons, it’s only applicable to USB-C, not also to prior-generation USB physical connector standards.

Macs don’t additionally support DisplayPort’s Multi-stream Transport (MST) mode, either in the operating system (generally) or in hardware (for newer Apple Silicon-based systems). If MST support had existed, it would have conceivable enabled me to extended-mode tether both displays to a single USB-C (or Thunderbolt 3, aka TB3, in this case) system connector, in combination with a separate inter-display connection. But again, per the system back panel photo, I had plenty of spare connector candidates available, not even counting those on the separate expansion hubs (the latter added subsequent to the snap of the earlier “stack” picture).

But what’s with all this DisplayPort talk? I thought we were discussing connecting the computer to a display’s HDMI input! We are, and that’s where the bulge surrounding the adapter cable’s HDMI connector end comes in. Conceptually, and I hope to definitively confirm today, inside is likely a DisplayPort to HDMI protocol-converting bidirectional transceiver; a particularly robust one, it seems, since the Anker A8730 touts 4K 60 Hz specs. HDMI once also had an “Alt” mode for USB-C, at least on specification paper, although actual products never made it to market.

Erratic function = dissection rationalization

Since the adapter cable had been operational in my abode since mid-2021 (and, considering it was a refurb, maybe even earlier than that with its original owner), why’d I decide to take it apart? Curiosity was as always one motivation, although I generally hold that particular urge at bay for as long as the gear remains operational. But this one had eventually failed, in another story-in-and-of-itself, through whose telling I aspire to also rationalize the “Occam’s Razor” title reference.

As previously mentioned, the 2018 Mac mini is still receiving periodic patches for its last-supported MacOS 15 “Sequoia” operating system release. A few updates ago, the left-side display of the pair (the one leveraging the Anker adapter) was no longer recognized by the system after the upgrade and subsequent reboot. Online research revealed that mine wasn’t a unique post-update quirk, and swapping the adapter cable to a different TB3 system connector got the display going again.

So, I figured that an obscure “Alt Mode” bug (specifically, since the first TB3 port still worked fine for generic data) introduced along with the upgrade had made it through Apple’s pre-release QA checks. This purported scenario was unsurprising albeit still disappointing, given that Intel-based Macs in general, and this system in particular, were on their “last legs” and likely no longer receiving their fair share of QA attention. Why my surmised bug only affected one TB3 port but not another wasn’t clear, but…

The next time I did an update, however, the exact same thing happened, this time to the second TB3 connector. Swapping the cable adapter back to the first TB3 connector didn’t resurrect the display. And I no longer had any other spare TB3 ports on the system available to try. At this point, I began to fear I had a fundamental system hardware degradation issue on my hands.

But after unplugging the cable adapter from the Mac mini and trying it with the “Project Volterra” system instead, where it also didn’t work, I was reassured by the now-nonfunctional repetition across multiple systems (and O/Ss) that a dead cable adapter was the likely culprit. An “Amazon Basics” cable adapter replacement fired up fine, sealing the Anker A8730’s fate.

What was behind the cable adapter’s initial failure, temporary resurrection, and eventual permanent demise? I hoped the pending teardown might provide visual Achilles’ Heel evidence (hold that thought). But I suspect it has something to do with MacOS’s use of display-supplied Extended Display Identification Data (EDID) information for software interface purposes versus Windows’ leverage of (when available) display-specific drivers.

My guess is that EDID (re-) enumeration in MacOS happens both when a display is first-time plugged into a new system connector and after each sufficiently impactful operating system update. In this particular case, the aforementioned DisplayPortHDMI bidirectional protocol translator in-between the system and display initially began operating erratically and eventually failed completely. But that’s just my conjecture; reader theories in the comments are as-always also welcomed!

Eyes-on conceptual validation (or not)

Speaking of tearing down, let’s dispense with further abstract chit-chat and get to dissecting, shall we? Here are a few more real-life device photos as prep. Packaging is long gone at this point, along with any potential originally accompanying literature. The USB-C end, to start.

With a product-code sticker behind it.

Intermediary cable markings next.

And now the bulge-augmented HDMI other end, starting with the seam-less cable-intro side.

The connector side conversely does have a visible seam at its circumference.

But attempts to surmount it with hair dryers and heat guns, along with spungers and such, were for naught. So, I escalated my attack by breaking out the hacksaw with hopeful deft technique.

That’s what I’m talking about!

For anyone following in my footsteps who prefers a less Neanderthal-reminiscent dissection approach, here’s the HDMI connector-surrounding piece I was unsuccessfully trying to extract earlier. Note specifically the locations of the retention tabs.

Finally, what you’re all most interested in, the PCB. As I’ve mentioned before, “top”, “bottom” and other orientation terms are particularly nebulous where HDMI is concerned. So instead, here’s the side corresponding to the wider HDMI connector edge.

Now zooming in for a closer look.

I was admittedly surprised to encounter a preponderance of passives, given that the most common adapter-usage orientation would have put this side on top, with the remaining (and proportionally higher heat-generating) stuff you’ll see next on the other side and below it. Given that heat rises (don’cha know), and that there’s no passive ventilation venting available, that’s a seeming premature failure-inducing decision. But not in my case, since the HDMI connector points downward with this display, not horizontally straight out the back as with many others.

Components of particular note include a five-lead SOT23-packaged step-down (buck) DC-DC converter at lower left, marked as follows.

JWA5J
91D5T

There’s also a “2R2” (2.2 µH) inductor to its immediate left, and a 27 MHz oscillator to its right. And what does that clock chip likely drive? Let’s flip the PCB over to the other side.

Now that’s more like it (unless you’re into passives, that is). Again, we zoom in for a closer look.

At lower left is Via Labs’ VL100, a (surprise, surprise…not…) DisplayPort USB-C Alt-mode controller. To its right is (surprise, surprise…truly, this time, at least a bit…) another oscillator, 24 MHz this time. Continuing to the right is, I’m guessing (readers?), a serial interface nonvolatile memory for code and data storage purposes, marked as follows.

125S40
BG17K8
P19030

In the lower right corner is another JWA5J DC/DC converter. Above it is (once again, no surprise) Paradise Technologies’ PS176 DisplayPort to HDMI video interface converter. And again for the passives fans among you, there are plenty more examples to see on this side of the PCB, too!

That’s a “wrap” for today, folks. Share your thoughts with me and your fellow readers in the comments, please!

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

Related Content

• USB-C’s lingering incompatibilities and other complexities, part 1: Direct-connect complications
• USB-C’s lingering incompatibilities and complexities, part 2: Splitter issues
• The 2025 WWDC: From Intel, Apple’s Nearly Free, and the New Interfaces Are…More Shiny?
• Connecting systems to displays with DVI, HDMI, DisplayPort: What we got here is failure to communicate
• USB: Deciphering the signaling, connector, and power delivery differences

The post Occam’s Razor and a USB-C to HDMI adapter appeared first on EDN.