Embedded Systems and Power Electronics

Total Pageviews

About Me

My photo
I am currently a PhD student at UC Berkeley, following a 6-year journey working at Apple after my undergrad years at Cornell University. I grew up in Dhaka, Bangladesh where my interest in electronics was cultivated, resulting in the creation of this blog.

BTemplates.com

Powered by Blogger.

Mar 23, 2024

Electrolytic caps over frequency: why is my 470uF actually 20uF?


While using an LCR meter to measure a 470uF cap in lab, the meter read the expected values at low frequency (100 Hz). But when measured at 100 kHz, the meter read 19uF. While I expected a capacitance drop due to parasitic inductance, I was still surprised at this sharp of a drop. I decided to dig further.

Simplistically, we can model a real capacitor as the following circuit:

Simplistic capacitor model including parasitic elements

C is the main capacitor and the other terms represent parasitic elements: Rs and Ls are the series resistances and inductances, whereas Rp is the parallel (leakage) resistance.

When using ceramic capacitors, datasheets often provided impedance charts over frequency and clearly highlight the self-resonant frequency. Let's consider the C3216X5R1V226M160AC. The impedance chart for the part is shown below. The drop in the impedance magnitude below ~1MHz follows the expected shape of a capacitor. Past ~1MHz, the inductance starts rising again, following the expected shape of an inductor. The minimum point is the self-resonant frequency (SRF) where the capacitance and inductance reactances "cancel" and the impedance is driven by the series resistor. Since the impedance rises again past the self-resonant frequency, the effective capacitance is lower.

C3216X5R1V226M160AC impedance vs frequency

Let's consider a point past the SRF now:
C3216X5R1V226M160AC impedance highlighted at 8.684MHz

The cap is nominally 22uF. At 8.648MHz, the expected impedance would be given by:

Expected impedance would therefore be 0.84 mΩ. However, the chart indicates that the impedance is 56 mΩ. Based on that, the effective capacitance can be back-worked to be 0.33uF for this 22uF cap!

Now you could say that, this frequency is pretty high and way past the SRF so of course the cap isn't behaving as we expect it to. However, this ties directly to the electrolytic cap I was trying to use too.

When looking at the electrolytic part's datasheet, I noticed no equivalent SRF or impedance information. Electrolytic capacitors are known to have lower SRF than ceramic capacitors, but how bad is it actually?

As an aside, what causes the parasitic inductance and why is it better than the ceramic caps? A good reference to understand this is Improved Spice Models of Aluminum Electrolytic Capacitors for Inverter Applications 

In summary, consider the construction of a typical electrolytic capacitor where the contact foils are rolled within the package. The images below are taken from the paper linked above.
 

The current flow through the structure can be modelled as an RC ladder network with distributed resistances and capacitances. This translates to capacitances further down the ladder network (such as C5 shown below) have larger series resistances and the associated time constants are large compared to the period of the voltage across the cap. This results in a drop in capacitance with frequency, greater than that of just the contact and packaging inductances.

A side note of interest is that the opposing current directions through the foils can help cancel the parasitic inductances, asides from small mismatches in foil alignment, depending on device assembly.

Is there an easy way to verify this for the cap I have? And can I trust the 19uF reading from the LCR meter? That's why I proceeded to do. (The reason for the distrust was more due to the meter misbehaving in lab for other measurements but is good to check against.)

I have a Digilent Analog Discovery 2 at home, which I have found to be very handy! I recently learned I can use it as an impedance analyzer
Digilent Analog Discovery 2

The following is the required setup to get impedance measurements.
Impedance measurement setup: "Load" is the cap under test

Using this setup, I am now able to get some quick impedance measurements for my cap. A key aspect of this is to perform the short compensation to ensure that measurement parasitics are taken into account. Without performing this compensation at first, I saw very different results due to the ~50nH of additional parasitic inductance through my measurement setup.

The reactance measurement is shown below:
Reactance measurement from 1kHz to 1MHz

I exported the reactance measurements, and then found the values of C0 and L0. C0 is the capacitance at the lowest measurement frequency and L0 is the inductance at the highest measurement frequency. This allows me to simply model the capacitor as a constant C0 in series with constant L0 (and also a constant series resistor but that isn't factored into this reactance measurement).

For these measurements, the values of C0 and L0 are 407.6 uF and 34.5 nH. C0 is within 20% of the 470uF capacitance, as per the part's spec. Overlaying the reactance due to C0 and L0 on the measured reactances yields the following plot.
Parasitic L, C fit on reactance measurements

This shows that barring the area around the SRF, the reactance is very well modelled by the constant C0 and L0. Considering the reactance, then, the equivalent capacitance can be computed as shown below.
"Effective" capacitance fit on reactance measurements


At 100 kHz, the capacitance is about 80 uF and at 200 kHz, the capacitance is about 20 uF! That is a HUGE drop from the 470 uF rating of the part (and measured 408 uF at low frequency). The self resonant frequency is about 40 kHz, which is very low compared to the ceramic cap shown previously. Of course, this is a different part in a different larger package and so that is not a fair comparison.

Back to where I was trying to use this! This is the input cap for a buck converter operating in the 80-200 kHz range. With such a substantial drop in effective capacitance, the input current ripple will be substantially higher than that predicted/computed with a 408uF cap!

In this particular converter, the 408uF cap would lead to about 23 mVpp ripple. However, with a 20uF cap, this goes up to 463 mVpp. Interestingly, operating this converter at a slower 100 kHz with the same cap (80uF @ 100kHz) could result in a lower ripple!

Be careful which parts you use! And make sure you consider the frequency-dependent behavior! Once you're above the SRF, the capacitance value drops precipitously. If possible, operate below the SRF or make sure you understand what the impact will be if you don't. There's also the consideration of ESR but with electrolytic caps, that tends to decrease with resistance - which is why you'll see ripple current specs get better at higher frequencies for electrolytic caps.

Jan 2, 2024

Quick and dirty PIC16F72 programmer with the Pico


Accompanying Github repo: https://github.com/SyedTahmidMahbub/q-dpico_picprog72

Having come to Dhaka over winter break, I was able to scrounge through the 10+ year-old collection of electronics stuff my parents had in storage from when I would experiment with electronics during the initial days of this blog. Among the many parts, I stumbled upon a large number of PIC16F72 MCU's - the defacto 8-bit cheap MCU of choice for many (commercial) projects. However, I couldn't seem to find the corresponding PICKIT2/3 programmer from back then - or one of the clones I had made - within the storage cabinets. At the same time, I had been working on some projects with the Pi Pico (as mentioned in the blog previously: https://tahmidmc.blogspot.com/2023/08/2023-updates-phd-pi-pico.html). This seemed like the perfect use case for the Pico - a very quick and dirty programmer to flash the PIC16F72. With its 2MB onboard flash, a very easy-to-program Micropython interface and the PIC16F72's fairly timing insensitive ICSP protocol (http://ww1.microchip.com/downloads/en/devicedoc/39588a.pdf), I set out to build a programmer to flash some test code onto the PIC16F72. I made use of whatever parts I could scrounge from the parts bin to put the project together.

As expected, Micropython on the Pi Pico enabled a super-quick development time. To echo what I had previously quoted from the Raspberry Pi foundation:

Computing is just so cheap compared to what it has been historically. That then enables things that are maybe not super efficient, not super tight timing like Micropython but who cares at that point? A lot of people will come in and say things like 'in this benchmark, I found that MicroPython is 100x slower than C' but if your C code is 100x faster than you need, then it doesn't matter. You just write the code you need and you focus on the parts that add value to your project and then you move on to your next project.

And this is the perfect use case! It's not the highest performance result but it gets the job done and the project development was super quick!

The details for the PIC16F72 programming are covered in Microchip's documentation: http://ww1.microchip.com/downloads/en/devicedoc/39588a.pdf

A description of Microchip's HEX file format is provided here: https://microchipdeveloper.com/xwiki/bin/view/software-tools/ipe/sqtp-file-format-specification/intel-hex/

The hardware elements of the project have a few key aspects:

  1. A higher voltage power supply is required for programming. This is between 12.75V and 13.25V VPP. To achieve this, a boost converter is used to raise the 5V USB rail to about 13V. I didn't have any inductors on hand except one unmarked part I found, that measured around 1.8mH. The boost converter operates in discontinuous conduction mode with the minimal VPP required current. Because of the 3.3V IO level of the Pico, I used an NPN transistor instead of a logic level MOSFET I had on hand due to the MOSFET's relatively high threshold voltage.
  2. A VPP level shifter is required to drive the VPP pin up to 13V or hold it low. A PC817 optocoupler is used for this.
  3. Level shifters are not needed for the PGD and PGC programming lines since the 3.3V from the Pico is high enough (>2V) for the PIC to register, even though the PIC is powered off 5V.
One useful and interesting aspect of the project is that no separate programming interface is required to transfer the PIC's HEX file from the PC to the Pico. Since the PIC16F72's flash storage is so small compared to the Pico's onboard storage, and using the Micropython setup on the Pico exposes a filesystem, I can just copy the HEX file contents onto a file on the Pico using the Thonny editor. And then hit run in Thonny to program the PIC!

The software is effectively the following:
  1. Configure the IOs for their corresponding functions.
  2. Configure PWM for the boost converter, running at 50kHz.
    1. Adjust the duty cycle until the output is near 13.2V.
    2. The output voltage is sensed by an ADC channel.
  3. Hold this duty cycle for the output voltage - at this point, the feedback loop is stopped.
  4. Detect the target PIC.
  5. If detected, issue a bulk erase and then check that the part is blank.
  6. Upon success, flash the words read from the HEX file.
To modify for another similar (small) PIC, adjust the constants at the beginning of the code:
  • CODE_START_ADDR
  • CODE_END_ADDR
  • CONFIG_START_ADDR
  • CONFIG_END_ADDR
  • DEVID_PIC16F72
If you use a different inductor for the boost, you can play around with the switching frequency and loop time too.


The schematic for the setup is shown below:


The code can be found here on this github repo: https://github.com/SyedTahmidMahbub/q-dpico_picprog72

The repo also has 2 test hex files test.hex and testbig.hex where the latter has a large array in flash to program over a larger amount of the flash storage.

Shown below is an example output from Thonny when I set the target voltage to 13.15V and flashed the testbig.hex file:
The code and project are by no means optimized for speed or performance. They are, however, optimized for development time! The project could easily be adapted to support other MCUs, and to create an ultra-cheap programmer - something I had previously done with the PIC16F1459 but the Pico enables greater versatility. Due to the onboard stoarage, the Pico could also program a PIC with no interface to a computer for isolated industrial flashing settings.

Finally, a quick photo to truly highlight the quick and dirty build:


Dec 21, 2023

Sizing IR2110 high-side bootstrap capacitor


I have previously discussed the IR2110 gate driver on this blog: https://tahmidmc.blogspot.com/2013/01/using-high-low-side-driver-ir2110-with.html

A crucial part of the high-side gate driver is the sizing of the bootstrap cap. A common sizing strategy is to "use a large cap" and use a larger one for small frequencies. Here, I present a simple method to model the discharge of the cap in a simple LTSpice simulation to inform the capacitor sizing. Shown below is the simulation setup along with the functional block diagram of the IR2110.




A few key points regarding the setup:
  • S1 and S2 represent the high side gate drive FETs in the IR2110 that drive the HO pin.
  • S3 and S4 represent the low side gate drive FETs in the IR2110 that drive the LO pin.
  • Ibs represents the quiescent VBS current and the offset supply leakage current: Ibs = ILK + IQBS. From datasheet, that evaluates to a max of 50µA + 230µA = 280µA.
  • GDH and GDL have their threshold voltages set at +0.5V (refH) and -0.5V (refL) respectively. These, along with yH and yL generate the drive pulses for S1-S4 and correspondingly M1-M2.
  • C1 is the bootstrap cap here, specified at 1µF.
The logic for generating the drive signals for S1-S4 is shown in the diagrams below. Click on the images to expand.

Now, let's go on to the key discussion regarding the cap sizing.

Once the cap is charged, there are a few discharge paths:
  • Charge transferred to the gate of the MOSFET being driven
  • Current draw due to the gate-source resistor
  • Leakage paths - the largest one modeled here is Ibs
For the charge transfer, consider the gate charge of the MOSFET being driven. This can be gathered from the datasheet of the MOSFET. For the IRFZ44N in this simulation, this is around 40nC-50nC as can be seen from Fig 6 in the IRFZ44N datasheet:
The voltage droop due to charging the MOSFET gate (Qg) can be estimated as:
The voltage droop due to driving current through the gate-source resistor can be estimated as:

VD1 is the forward drop for the bootstrap diode D1. Ton is the on-time given by the product of the duty cycle and period.

Below is the voltage across the boostrap cap from the sim:

Observations from this waveform:
  • Between 440µs and 500µs, M2 is on, which charges the bootstrap cap C1 through D1. A larger charge resistance (D1 on-state resistance) or a larger bootstrap cap C1 would increase this charging time.
  • At 500µs, M1 is turned on. Note that this simulation doesn't model the deadtime, but since we're primarily interested in the boostrap cap's dynamics, that is fine.
  • The sharp vertical drop right after 500µs is the charge transfer to M1's gate.
  • The continued droop afterwards, to 540µs, is due to Ibs and the gate-source-resistance.
  • The voltage drops from 11.403V to 10.921V.
  • VGS for M1 tracks this voltage from 500µs to 540µs.

Below is a simple script to estimate the total droop with Python:
import numpy as np

D = 0.4
Tperiod = 100e-6
Ton = D * Tperiod
V0 = 11.403

Cboostrap = 1e-6
Qg_FET = 45e-9
Rg_on = 1031
Ibs = 280e-6

dV_Qg = -Qg_FET/Cboostrap
dV_Rg = -V0 * (1 - np.exp(-Ton/Rg_on/Cboostrap))
dV_Ibs = -Ibs/Cboostrap * Ton

V_final = V0 + dV_Qg + dV_Rg + dV_Ibs
print("Droop sources:")
print(f" Gate charge: {dV_Qg :.3f} V")
print(f" Gate resistor: {dV_Rg :.3f} V")
print(f" Ibs: {dV_Ibs :.3f} V")

print(f"Droops from {V0 :.3f} V to {V_final :.3f} V")


The output of the script is:

Droop sources:
  Gate charge: -0.045 V
  Gate resistor: -0.434 V
  Ibs: -0.011 V
Droops from 11.403 V to 10.913 V

The computed droop matches very well with the simulation!

Key observations:
  • The droop will get worse with reduced gate-source resistance. Using a larger resistance than 1k will reduce the droop.
  • The droop will get worse with a longer on-time. This is why a larger capacitance is needed when operating at lower frequencies such as 50Hz or 60Hz.
  • Using a super large cap will increase how long the cap will require being charged at startup. This may be dealt with by precharging the cap (by turning on M2) before M1 has to be turned on.
  • A 100% duty cycle can't be used since the bootstrap cap can't be recharged. How high the max possible duty cycle is depends on how long it takes to recharge the cap through the bootstrap diode.
  • Gate charge for the MOSFET is a weak function of applied voltage and a very strong function of gate voltage. A larger gate drive voltage will result in a greater droop. Note though that this may not matter if the gate-source resistor dominates the droop.
  • A good max allowable droop is given by the 9.7V figure for the IR2110's max VBS undervoltage threshold. Given that there are always additional leakage components, and the cap has an associated tolerance (in many cases >20%), you will want to build in lots of margin.

Hopefully, this was a useful introduction to sizing the bootstrap capacitance for the IR2110 (or other gate driver). Here is also a good reference to look at: AN-978

If you want further clarification on any aspect of this, do let me know in the comments!

Nov 10, 2023

SmartSinePy, and an example of GUI development with PySide6


Source code at: https://github.com/SyedTahmidMahbub/SmartSinePy

Quite a very long time ago, I had posted a Windows tool called Smart Sine to generate a sine table. See: https://tahmidmc.blogspot.com/2012/10/smart-sine-software-to-generate-sine.html

This was very useful for pre-generating the sine-table instead of in the main program itself, often useful to save space (and not have to perform trig operations) especially on 8-bit microcontrollers.

I was recently looking into developing quick GUIs for some test bench automation and was primarily looking for something where I could position and size GUI elements visually (a WYSIWYG editor, basically) and decided to dig into QT Designer and PySide6. I don't mind defining properties and event handlers programmatically (in fact I do prefer it) but what I really don't want to do is have to add every GUI element in code and define its location and size - this is where the QT Designer's visual editing really comes in helpful! Reminds me a lot of the Visual Studio GUI editor back in Visual Basic development days.

This provided a good opportunity to redo Smart Sine and have an example project for developing the GUI application. A few aspects explored on the GUI side of things:

  • Creating the layout in QT Designer
  • Getting inputs from a table
  • Working with GUI widget signals (events such as button pressed or slider value changed)
  • Updating text in labels and a text browser (textbox)
  • Generating a plot with matplotlib and embedded it on the GUI
This is a great reference for embedding matplotlib: https://david.roesel.cz/notes/posts/matplotlib-figure-embedded-in-qt/
Particularly about temporarily adding a text box within the widget to specify the layout.

For this particular project, I read in the .ui file (that QT Designer generates) straight in the main code without an intermediate conversion.

Here is a snapshot from QT Designer:

Here are a couple snapshots of the application running:
There are a fair few Python dependencies that you will have to install. A one-line command for installing them is:
python3 -m pip install pyside6 numpy pyperclip matplotlib

If there's interest in packaging this up into an executable, let me know!

The code is commented and should be self-explanatory. But if there are specific questions or anything that is unclear, let me know and I can clear it up!

Nov 3, 2023

Modified Sine Wave Inverter: Harmonic Elimination


In inverter designs, we see the concept of a modified (or quasi) sine wave inverter - "better" than a square wave but still very easy to implement by adding a deadtime. By adjusting the duty cycle of the square wave, the output RMS value can be adjusted - and this is often used in inverters for feedback regulation.

One concept that is tied to how a modified sine wave output is better than a square wave has to do with harmonic elimination.

To start off with, let's remind ourselves that a square wave is composed of an infinite number of sine waves at odd multiples of the wave's frequency. Here is a great reference for this: Fourier Series--Square Wave -- from Wolfram MathWorld

Now, if we consider the modified sine wave, what happens to the harmonic contents?


We can solve for the nth harmonic (where n=1, 3, 5, 7, ...) which gives a Fourier coefficient of:

Why is this interesting? Can we fix the duty cycle so that we eliminate certain harmonics? Yes! We can make the cos term go to zero by picking nδ = π/2 = 90°. We could then pick δ = 30° and eliminate the 3rd harmonic! Or we could pick δ = 18° and eliminate the 5th harmonic. If we had to pick just one, it would then make sense to eliminate the 3rd harmonic which has a higher Fourier coefficient than the 5th! This will contribute to a better THD (total harmonic distortion).

We can of course time shift this waveform and retain the same benefits - this would then correspond to a standard (edge-aligned) PWM. If we are using a full-bridge to generate this waveform, this would correspond to a duty cycle (for each pair of diagonal switches) of (180°-30°-30°)/360° = 33.33%. The off time would, of course, reduce the output RMS voltage compared to a square wave, so you would have to keep that in mind!

What about multiple harmonic eliminations? We can come up with a scheme where we add multiple notches and eliminate multiple harmonics. And, in fact, this is what SPWM achieves by forming these notches in a "sinusoidally optimal" fashion and eliminating several lower order harmonics. I have several articles where I have discussed SPWM (such as Generation and Implementation of Sine Wave Table) albeit not in the context of harmonic elimination.

Can we do this in one-stage inverters like with an iron core? No. Unfortunately, in these one-stage inverters, the output voltage regulation is obtained by altering the duty cycle and so you can't have a fixed δ and optimize for a particular harmonic elimination.

Can we do this with two-stage inverters such as ones where the input voltage is first stepped up with a ferrite transformer at high frequencies followed by an H-bridge to generate the output? Yes - if we use feedback to control the output of the first stage, we can use this constant δ on the output of the second stage.

Aug 13, 2023

2023 Updates: PhD; Pi Pico


It's 2023 and I'm back to keep the blog going! Lots have changed in my life in the past 6 years since I last posted on the blog.

PhD

After a six-year stint working as a hardware engineer at Apple, I am excited to now be pursuing my PhD in Electrical Engineering, focused on Power Electronics, at UC Berkeley. I start working with Professor Robert Pilawa-Podgurski this week! I anticipate more posts centered around power electronics in the future.

Why did I want to go back to school in a PhD program? There are 3 key aspects to this:

  1. Technical depth. With the recent rapid advances enabled by wide bandgap semiconductors, the recent explosion in adoption of EVs and an expansion in the number of research labs in academia, now is an exciting time for power electronics.
  2. Positive contributions to climate crisis solutions. Growing up in Bangladesh, I witnessed firsthand the devastating impact of natural disasters that continue to be exacerbated by the climate crisis. Direct impacts of this are witnessed every year half-way across the world in California where I now live. I envision pursuing research opportunities to significantly reduce emissions in the transportation and energy sectors: the largest contributors to the climate crisis and fields that can be directly improved through power electronics.
  3. Education. This blog has been an early testament to my interest in sharing engineering information and knowledge. I would like to continue to do so, but also engage in a more formal manner through educational institutions, particularly with typically underserved institutions.

Pi Pico

In the short term, I am exploring the Raspberry Pi Pico (based on the RP2040 MCU) using MicroPython. Having the resources to support running MicroPython, in a super-cheap part, is an exciting opportunity for me to explore. The idea here is to use Python (very simple software bringup time) to do the software heavy lifting and leveraging on-board hardware for timing-sensitive/hardware applications.

Here is a great relevant podcast episode: The Amp Hour #529 – Embedded Hardware with the Raspberry Pi Team

Why Micropython? Listen to 11:30-12:30 in the linked podcast episode where the below qutoes are taken from.

Computing is just so cheap compared to what it has been historically. That then enables things that are maybe not super efficient, not super tight timing like Micropython but who cares at that point? A lot of people will come in and say things like 'in this benchmark, I found that MicroPython is 100x slower than C' but if your C code is 100x faster than you need, then it doesn't matter. You just write the code you need and you focus on the parts that add value to your project and then you move on to your next project.