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.

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.

Jun 15, 2017

A digital communication project using OFDM and 32-QAM


This past semester (my last one during my undergrad years!), I was enrolled in ECE4670 -- Intro to Digital Communication with Professor Aaron Wagner. The final project required constructing the encoder and decoder (in Matlab) to send data over an existing channel (Cornell’s commcloud server). The project was done in groups of 2 and I had worked with my friend Balazs Szegletes. It was a fun learning experience, and I wanted to share the details of the project here!

The communication channel is effectively a DAC that outputs the results of the encoder, X, a low-pass filter, and then an ADC that samples this and sends data, Y, to the decoder. The means for sending data to the channel involves writing the data to a wav file, which is then passed as an input parameter to a program called ccplay that is provided for the class. The program handles the DAC and ADC and saves the sampled output as another wav file. The goal is to be able to push data through the channel as quick as possible with few number of bit errors. The figure of merit is computed as:
FOM = (min(R, 300000)*(1-N/50000)10)/max(1,400*Po)
Where R is the data rate defined as (100,000/(L/44100)) where L is the length of the output of the encoder
N is the number of bit errors
Po is the average transmitted power

The channel properties can be modeled by the Toeplitz matrix H, such that:
Y = HX + Z, where Z is iid (independent, identically distributed) Gaussian noise. The commcloud server has two such channels, audio0 and audio1.

This builds on a previous lab, where orthogonal frequency division multiplexing (OFDM) is used with on/off keying to send data over the channel. This scheme achieved a data rate of about 14,000 bits per second with zero errors, resulting in a figure of merit of about 14,000. The high performance design utilizes orthogonal frequency division multiplexing (OFDM) and quadrature amplitude modulation (QAM) to achieve a figure of merit much higher than the previous lab.

The overall OFDM system block diagram is shown below (taken from Professor Wagner’s course’s Scribe notes):

The big gain in performance stems from the use of QAM, which allows encoding multiple bits per sample, in the complex plane. A modulation order (M) of 5 was selected for the design, ie 32-QAM. This was experimentally determined to be the optimal modulation order, which gives the highest data rate (R) before bit errors (N) start outweighing the benefits from a higher data rate.

The encoder encodes the incoming bit-stream into frequency components and then processes it as described below before sending out its time-domain signal over the channel.

The encoder accepts the input vector (of length 100,000) and encodes the vector using 32-QAM into 100,000/5 complex samples in a vector x. The encoder then separates x into 8 equal sized data blocks D1...D8 of length L1. The size of L1 is determined by modulation order M: L1=(100,000/(8*5)). Two training blocks, T1 and T2, each a vector consisting all 1’s and of length L1,  are inserted to create the following vector, x, of length 10L1.


Using a seed of 1, and Matlab’s rand function, a vector, p1, of pseudorandom phase angles (between 0 and 2 pi) is generated. These are used to create a vector p2 of phasors, where:
p2(i) = gamma*exp(1jp1(i)) for all i = indices of elements of p1,p2. The constant gamma sets the average power level.

The elements of this vector are then multiplied element-wise with the elements in vector x. This is to prevent the constructive addition of several frequency components in the time domain which would cause the time-domain signal to clip or saturate. 

Each block is then prepended by NZpre zero’s. NZpost zero’s are appended to each block. Let this vector be called X. X is then padded with 0 for DC and concatenated with X*. This ensures that the time domain signal is real-valued. The inverse DFT of this is taken to get the real-valued time domain signal. Each block is prepended with a cyclic prefix (length Kc) to make the (Toeplitz) channel transformation effectively look circulant. The encoder then outputs this vector.

The training blocks are inserted into the data vector so that it may be used at the decoder end for training of channel properties. Each element of a training block (in the frequency domain) has magnitude 1 and a phase theta_t. When this element goes through the channel, it is attenuated and incurs a phase shift and is presented to the decoder with magnitude gamma_c(attenuation of the channel) and phase (theat_t+theta_c) where theta_c is the phase added by the channel. Each frequency component has an associated attenuation and phase addition. Since the training block is the same length as any individual data block, there exists known training information about attenuation and phase for each frequency of interest in the system/encoding at the decoder end. The decoder is then able to use this block’s received data to cancel channel effects for the other blocks. However, it must be noted that the the attenuation and phase addition of the channel are not static and vary with time. Thus it is important not to let the training data be stale. This is the reason two training blocks are used, and also why they are inserted in the order they are, with respect to the data blocks.

It was observed that placing only one training block at the beginning of the data vector allows determining channel phase reasonably well for only a couple data blocks adjacent to it. Additionally, it was noted that decreasing the number of blocks also made the prediction worse. By placing the two training blocks as they are in the vector allows using a block to cancel channel effects for two adjacent data blocks. The phase variation from the training data to the two data blocks is small enough to allow sufficiently high figure of merit. The phase variation from D1 to D4 is illustrated below:
While the shift is somewhat significant, it is still possible to correctly decode the information. As can be imagined, too far from this and the bit error rate gets terrible.

At the decoder end, synchronization is performed to determine the start of the signal. This is done by thresholding the average power level over five samples. To recover the samples encoded in the frequency domain, the decoder reverses what the encoder did, firstly ignoring the cyclic prefix, performing a DFT, dropping the flipped conjugate second half of the vector and then dropping the zero-padding. Since gamma_c*exp(1j*theta_c) is known from the training block for each of the frequency levels, the samples in D1 to D4 are divided by gamma_c*exp(1j*theta_c) from T1 to cancel the channel effects. Similarly, D5 to D8 use the channel information from T2. Finally, the pseudo-random phases added at the encoder side are removed by dividing by each of the known phases element-wise. These phases are known since the random number generator had a fixed seed of 1. The individual data blocks are then demodulated (QAM) and concatenated to each other to form the 100,000 long bit vector. For modulating and demodulating using QAM, Matlab’s inbuilt functions qammod and qamdemod are used.

The following constants were determined to give the highest figure of merit:
NZpre = 110
NZpost = 1050
gamma =7.8 (chosen to meet the power constraint of 1/400)
Kc = 170

Experimentally, the figure of merit scores are about 44,000, and 56,000 for channels audio0 and audio1 respectively. The constants NZpre, NZpost, gamma, modulation order M, number of data blocks, number of training blocks, and placement of training block were all experimented with and the results presented here represent the best combination for the highest figure of merit. With only one training block, the phase drift was high enough to negate the benefits of higher data rate obtained from 32-QAM. However, adding a third training block was seen as a waste since it would minimally reduce the number of bit errors but would hurt the data rate appreciably. Using convolutional coding was considered but it was determined as not worth the effort given the performance obtained and the added complexity.

I expect to write another post soon to discuss some technical background behind OFDM, training and synchronization. Let me know what you think and if there's something else from the project you'd like me to cover in more detail!