Tahmid's blog

Why is my buck output ripple higher than expected: ceramic capacitor derating vs voltage

2025-08-05T12:45:00.000-07:00

Fig. 0a - The test hardware comprising a buck converter operating at 50kHz and 50% duty cycle. The PWM signals are generated from an on-board RP2040. The buck inductor (not shown) is soldered on the reverse side of the PCB.

Fig. 0b - Back side of the test PCB, where the input electrolytic caps and output inductor are soldered.

Fig. 1 - Buck converter

In a typical buck converter shown in Fig. 1, the output ripple voltage is an important design specification. Sensitive loads may specify a maximum ripple voltage. The max allowable voltage for the load is also limited by the ripple, especially for loads with tight specifications such as many processors.

The output ripple voltage is given by

\[ \Delta V_\mathrm{out} = \frac{V_\mathrm{in}D(1-D)}{8LCf_\mathrm{sw}^2} \]

The derivation is given at the end of this post for those interested. The different parameters are:

$ \Delta V_\mathrm{out} $ = peak-to-peak output ripple voltage
$ V_\mathrm{in} $ = input voltage
$ D $ = duty cycle
$ L $ = inductance
$ C $ = output capacitance
$ f_\mathrm{sw} $ = switching frequency

We can look at the output ripple using the power testbench. The converter is run at 50kHz and 50% duty cycle, with varying input voltages. The output capacitor of the converter is the parallel combination of 4x 0805 10µF caps (GRM21BR61H106KE43) and 1x 1206 10µF cap (CGA5L3X5R1H106K160AB). The inductor is rated at 5.6µH, specifically the Wurth 732-3799-1-ND.

Based on this, you would expect the output ripple at 10V input to be given by:

\[ \Delta V_\mathrm{out} = \frac{V_\mathrm{in}D(1-D)}{8LCf_\mathrm{sw}^2} = \frac{10V \cdot 0.5 \cdot 0.5}{8\cdot 5.6\mu H \cdot 50\mu F \cdot (50\;kHz)^2} =0.45\;V \]

The ripple waveform is obtained with a scope that is AC coupled and can be seen below in Fig. 2. From the scope shot, it appears that the voltage ripple is about 0.75V, which is a fair bit higher than the expected ripple. So what gives?

Fig. 2 - Output ripple, AC coupled, 500mV/division, Vin=10V, Vout=5V

The culprit here is voltage derating of ceramic capacitors. Much like how I've previously written about electrolytic capacitors derating with frequency, ceramic capacitors (particularly class II dielectrics) can derate substantially with voltage. This has to do with the reduced permittivity of the dielectric, reducing the capacitors' ability to store energy at higher voltage biases. This is often given in manufacturer technical documentation. For our caps, the derating charts are reproduced below.

Fig. 3a - GRM21BR61H106KE43 DC bias characteristics, credit: Murata

Fig. 3b - GRM21BR61H106KE43 5V DC bias corresponds to a 6.4µF capacitance

Fig. 4a - CGA5L3X5R1H106K160AB DC bias characteristics, credit: TDK

Fig. 4b - CGA5L3X5R1H106K160AB 5V DC bias corresponds to a 9.1µF capacitance; you will often notice that larger packages correspond to reduced derating and hence have larger capacitances for the same initial capacitance and voltage rating

Considering the derating from Figs. 3-4, the total output capacitance is 34µF. With this new value plugged in, the expected output ripple is about

\[ \Delta V_\mathrm{out} = \frac{V_\mathrm{in}D(1-D)}{8LCf_\mathrm{sw}^2} = \frac{10V \cdot 0.5 \cdot 0.5}{8\cdot 5.6\mu H \cdot 34.7\mu F \cdot (50\;kHz)^2} =0.64\;V \]

This is much closer to the observed value with a 14.5% error, something that is fairly within the tolerance of different components.

If we now look at the results with 20V input (corresponding to 10V output), we would expect an output ripple of double that for the 10V input, corresponding to 1.3V; if the caps didn't further derate. However, we can find again from the manufacturer data that the total output capacitance is 19.7µF, down from 34µF, which would correspond to a greater increase in the ripple. This is shown in Figs. 5a and 5b.

Fig. 5a - GRM21BR61H106KE43 10V DC bias corresponds to a 3.2µF capacitance

Fig. 5b - CGA5L3X5R1H106K160AB 10V DC bias corresponds to a 6.9µF capacitance

Fig. 6 - Output ripple, AC coupled, 500mV/division, Vin=20V, Vout=10V

The output ripple observed with 20V input is shown in Fig. 6. The measured ripple corresponds to 2.7V, which further highlights the substantial capacitance drop with 10V bias for the output ceramic capacitors!

The expected ripple with ideal caps is given by

\[ \Delta V_\mathrm{out} = \frac{V_\mathrm{in}D(1-D)}{8LCf_\mathrm{sw}^2} = \frac{20V \cdot 0.5 \cdot 0.5}{8\cdot 5.6\mu H \cdot 50\mu F \cdot (50\;kHz)^2} = 0.9\;V \]

However, with derated capacitance, the expected ripple is

\[ \Delta V_\mathrm{out} = \frac{V_\mathrm{in}D(1-D)}{8LCf_\mathrm{sw}^2} = \frac{20V \cdot 0.5 \cdot 0.5}{8\cdot 5.6\mu H \cdot 19.7\mu F \cdot (50\;kHz)^2} = 2.3\;V \]

This is much closer to the observed ripple value.

For proper filtering, it is crucial to consider the DC bias impact on the ceramic capacitors and the corresponding derating, in addition to component tolerance! Otherwise, the filtering will be insufficient and the ripple will be much higher than expected, as shown here. This could result in poor circuit performance or even component damage!

Note that the circuit parameters here were chosen to have large output ripple to illustrate the concern described in this article. In almost any application, this circuit has a very high ripple percentage. Even with the components as present, the frequency can be increased substantially to reduce the ripple. Alternately, the output inductor or capacitance can be increased.

Ripple Derivation

Fig. D1 - Buck Converter

Fig. D2 - Buck Converter when QH is on

Fig. D3 - Buck Converter when QL is on

To find the output ripple in a buck converter, we start from the inductor current, which can be determined from the inductor voltage in either QH on or QL on state. We can identify that $ i_\mathrm{L} $ increases when QH is on since $ v_\mathrm{L} $ is positive then. And similarly, $ i_\mathrm{L} $ decreases when QL is on since $ v_\mathrm{L} $ is negative.

QH is on for a fraction of the switching period given by the duty cycle D. For a buck converter, the output voltage is given by $ V_\mathrm{out} = D V_\mathrm{in} $. The inductor voltage relationship $ v_\mathrm{L} = L \frac{di_\mathrm{L}}{dt} $ can be rewritten for constant voltage $ v_\mathrm{L} = L \frac{\Delta i_\mathrm{L}}{\Delta t} = L \frac{\Delta i_\mathrm{L}}{D T_\mathrm{sw}} $ where $T_\mathrm{sw}$ is the switching period.

The peak-to-peak inductor current ripple is thus given by

\[ \Delta i_\mathrm{L,pp} = \frac{V_\mathrm{in}-V_\mathrm{out}}{L}\cdot \frac{D}{f_\mathrm{sw}} = \frac{V_\mathrm{in}(1-D)D}{Lf_\mathrm{sw}} \]

We know from Fig. D1 that $ i_\mathrm{L} = i_\mathrm{C} + i_\mathrm{out} $. We can find the impedance of the output capacitor and determine the current split between it and the output load. We can assume (and confirm mathematically) that the impedance of the output cap at high frequencies (such as in a typical buck converter) is much lower than the load resistance. Thus, we can assume that the inductor ripple current is going through the output cap, as shown in Fig. D4, and that the DC amount is going through the load resistor.

Fig. D4 - Current going through the output capacitor

When the ripple current is positive (for half of $ T_\mathrm{sw} $ ), the output capacitor is charged and when the ripple current is negative, the output capacitor is discharged. The peak-to-peak capacitor voltage ripple can be found from the positive inductor current charging the cap, where Q is the charge $ \int i_\mathrm{C}\;dt = \frac{1}{2} \frac{\Delta i_\mathrm{L,pp}}{2} \frac{T_\mathrm{sw}}{2} = \frac{1}{8} \Delta \frac{i_\mathrm{L,pp}}{f_\mathrm{sw}} $

\[ \Delta V_\mathrm{out} = \frac{Q}{C} = \frac{1}{8Cf_\mathrm{sw}} \Delta {i_\mathrm{L,pp}} = \frac{1}{8Cf_\mathrm{sw}} \frac{V_\mathrm{in}(1-D)D}{Lf_\mathrm{sw}} = \boxed{ \frac{V_\mathrm{in}D(1-D)}{8LCf_\mathrm{sw}^2} } \]

As a final check, we can go back to checking the magnitude of the output capacitance compared to the load resistance (10Ω output resistor was used) with the circuit in Fig. 0.

\[ |Z_\mathrm{C}| = \frac{1}{2 \pi f_\mathrm{sw} C} = \frac{1}{2 \pi 50\;kHz \; 19.7\mu F} = 0.16 \Omega \ll 10 \Omega \]

Using a PV panel indoors by biasing with an external power supply

2025-05-01T01:07:00.000-07:00

My introduction to working with solar panels goes back a long time. In fact, in 2012, I posted this article when I was working on some charge controllers and inverters. One consistent challenge when doing such work is always having a consistent reliable PV panel outdoors in bright (ideally not-too-hot) sunlight. This becomes difficult with varying weather conditions and limits development.

Recently I learned about how you can very easily use an external power supply (capable of operating in constant current mode) to use the PV panel indoors and emulate its outdoor behavior! This ends up being great for testing charge controllers and MPPT algorithms!

Fig. 1 - Setup for characterizing PV panel behavior indoors
Panel: SLP010-12U
Power supply: Rigol DP832
Eload: Rigol DL3031

Fig. 1 shows the test setup used for obtaining PV panel IV curves indoors. The only equipment required for emulating the PV panel itself is the power supply. The electronic load is used to vary the voltage imposed on the panel to obtain the IV curve. You can even see the panel facing down so that light is not incident onto it!

Fig. 2 - Simple PV panel model

We can start by recognizing that a PV panel may be simply modeled as shown in Fig. 2. Iph represents the photocurrent generated by the panel under sunlight. When the panel is indoors, Iph is a miniscule value under typical indoor lighting conditions. What we can do is, instead, use an external power supply to bias the panel with a constant current source. This is represented by Iext in Fig. 3.

Fig. 3 - External power supply used to emulate photocurrent in PV panel

This is as simple as configuring the power supply's voltage at (or higher than) the panel's open-circuit voltage (Voc), and setting the current limit at the panel's short-circuit current (Isc). For the panel I picked, these correspond to 21.6V and 0.68A (at 100% luminosity).

The short-circuit current limit for the PSU can be varied to provide Iext emulating varying luminosities! For example, using 50% of the panel's short-circuit current, a condition of approximately 50% luminosity may be emulated!

This may be taken even further by adding a series voltage source to emulate voltage shifts in the IV curve.

Tests with 10W panel:

To generate the IV curves in a repeatable fashion, I wrote a Python script that imposes different panel voltages by issuing the corresponding SCPI commands to the electronic load. The curve is then plotted in real-time, as shown in Vid. 1 below. The GUI was built by modifying the one from a previous blog post: SmartSinePy, and an example of GUI development with PySide6 ~ Tahmid's blog

Vid. 1 - Characterizing panel IV curve at 100% emulated luminosity

To illustrate the operation at 50% emulated luminosity, the power supply current is set to 0.34A instead of 0.68A. The corresponding curve is generated as shown in Vid. 2.

Vid. 2 - Characterizing panel IV curve at 50% emulated luminosity

These obtained curves are also shown below in Fig. 4 and Fig. 5.

Fig. 4 - Obtained IV curve at 100% emulated luminosity

Fig. 5 - Obtained IV curves at 100% (top, same as Fig. 4) and 50% (bottom) emulated luminosities

Fig. 6 - IV curves provided in the panel datasheet

Fig. 6 shows the IV curves of the panel from its datasheet, showing close agreement between the curves obtained indoors with the 25°C curve! Slight tweaking of the open-circuit voltage and short-circuit current to match the 25°C curve can give slightly better match!

More significantly, this now allows testing with the PV panel indoors without worrying about weather conditions! Of course, all final tests for any charge controller or MPPT algorithm should be run outdoors with the panel under varying weather conditions, but this emulation method can significantly improve development time. I will soon share a demonstration of an MPPT controller developed using this setup!

Characterization of a 100W panel:

The same technique can be used for different panels and power levels. Fig. 6 shows one such IV curve obtained using the techniques outlined here but with a more capable power supply and electronic load. The power supply was set to 24.3V (panel open-circuit voltage) and 5.21A (panel short-circuit current at 100% luminosity).

Fig. 6 - Obtained IV curve for a 100W panel

This simple technique can significantly improve development and testing times for projects using PV panels! For more details about this emulation technique and further enhancements, refer to the following papers which provide much greater detail:

1. S. Qin, K. A. Kim and R. C. N. Pilawa-Podgurski, "Laboratory emulation of a photovoltaic module for controllable insolation and realistic dynamic performance," 2013 IEEE Power and Energy Conference at Illinois (PECI), Urbana, IL, USA, 2013, pp. 23-29, doi: 10.1109/PECI.2013.6506029.
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6506029

2. T. -L. Huang, F. S. Bagci and K. A. Kim, "Indoor Panel-Based Photovoltaic Emulation Method Implementation and Evaluation," 2024 IEEE Workshop on Control and Modeling for Power Electronics (COMPEL), Lahore, Pakistan, 2024, pp. 1-7, doi: 10.1109/COMPEL57542.2024.10613957.
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10613957

Power Testbench and Upcoming Power Electronics Tutorials

2025-03-30T20:47:00.000-07:00

While I have written many articles on this blog about power electronics related topics, I am hoping to share more fundamentally structured tutorials and articles, based on power electronics fundamentals that have been reinforced during my time in graduate school. To that end, I have designed a testbench to cover topics ranging from basics to slightly more involved ones. I have completed the design of a power electronics test bench, sent out the PCB files to be fabbed at OSHPark, and ordered parts from Digikey.

Here are some ideas I have for topics to cover, and I'd love to get feedback on other topics of interest!

Basic demonstration of buck and boost conversion
Estimation of capacitor ripple
Bidirectional blocking circuit
Isolated vs bootstrapped gate drive
Sizing inductor and operating with large ripple current
Boundary conduction mode operation
Efficiency characterization
Impact of deadtime on efficiency
PV panel behavior emulation with lab power supply
MPPT operation with PV panel

Here are a couple 3D renders of the testbench hardware from Altium:

Top side render

Bottom side render

I will go over more details of the design and will be sharing the Altium design files and bringup progress when the board is back! I am hoping to use this design and framework to provide more structured tutorials on power electronics, building on past articles on this blog.

Sprucing up an old scope: fixing the dials on the Owon SDS6062V

2025-01-01T01:15:00.000-08:00

I got the Owon SDS6062V scope back in 2014 when it seemed a great deal compared to brands like Tektronix and much better than cheaper analog or portable digital scopes. These days, I've been using the Rigol DS1202 for hobby projects which is a better part, in my opinion. Of course, none of these are as nice as the Keysight MSOX scopes at work.

I've demonstrated the Owon scope in previous projects such as Generating complementary PWM with adjustable deadtime for the RP2040 and Stereo audio player using the PIC32, MCP4822, microSD card and the MDDFS library (back in 2015!). The dials on the front panel seem to all be "broken". When turning the dials, the response is erratic. For example, when turning the time division dial clockwise, sometimes the time division goes up, sometimes down, sometimes it jumps all the way down to the minimum or will jump up and back down. The same is true for all the other dials. Searching online revealed that this seems to be a common issue with the scope, with the encoders having worn out with age. Some sources suggested using filter caps on the output of the encoders (dials). However, this didn't help with mine. So I decided to just replace the encoders themselves.

The instructions for taking the scope apart and getting to the front panel PCB that houses the encoders is very well documented in the service manual. I uploaded a copy of the Owon service manual on Drive: Owon Service Manual (Drive mirror)

Fig. 1 - Owon SDS-6062V oscilloscope with original dials and caps

Fig. 2 - Scope with the encoders replaced

Fig. 3 - The front panel PCB with the encoders soldered

After accessing the front panel PCB, I desoldered all the encoders. I could not find part numbers for these encoders and just went ahead and bought a standard 10-pack of encoders (Amazon link). Fig. 4 shows that the ordered parts are quite a bit taller than the ones on the scope. However, with the different encoder caps as shown in Fig. 5, the height difference is substantially removed. When I was looking online for which encoders to order, I found several sources suggesting ordering "standard encoders" without part numbers. So my hope here is that if someone is trying to change the encoders on their scope, they have a reference part to order if they're lost.

Fig. 4 - Encoders for the scope. Left = encoders removed from the scope PCB. Right = encoders ordered from Amazon.

Fig. 5 - Encoders with their corresponding caps mounted. Left = encoders removed from the scope PCB. Right = encoders ordered from Amazon.

Once the new encoders are soldered into the panel, the scope dials now worked as expected. The replacement encoders I used all have steps in them. The scope's horizontal position encoders did not have steps. I didn't mind this at all and actually quite like the additional tactile feedback.

I am also a big fan of the look of the new encoder caps! The spruced up scope is shown in Fig. 2. This was a simple fix, but I wanted to document the service manual and the encoders here for someone else to find useful! This breathes new life into this trusty scope and hopefully it can continue functioning!

Here are some fun shots of the interior of the scope!

Insights from repairing a 30V 5A power supply (BPS-305)

2024-12-31T13:16:00.000-08:00

When I started working on a project (hopefully more on that soon), I reached out for an old 30V 5A power supply (Lavolta BPS-305). I rotated the voltage dial to try to get to 24V and observed that the voltage would not go past 15V, even though it is rated for 30V. Even though this supply was a few years old, I had not personally used it before. So, it wasn't clear whether it was a previously-functioning supply that stopped working, or whether it was always broken.

Fig. 1 - Lavolta BPS-305 power supply

Upon some more poking and prodding, I identified that the power supply had several issues:

Output voltage only goes up to about 15V instead of 30V max.
Output voltage is not stable and fluctuates at steady state, appearing unregulated. See video below.
Output voltage flickers when relays switch around ~7V and ~14V and the relays keep flickering unless the voltage is moved far away from the transition points.
Output current measurement (when HI/LO button is pressed down to LO) is off by a factor of 2.
Output current measurement (when HI/LO button is pressed up to HI) displays zero.

Output voltage unstable at "steady state" - moving between 10.2V to 11.1V with a fixed output load

Hopeful that I can repair the supply, I opened it up. Noticing a relatively simple one-layer PCB, I set out to find a schematic or other reference for the supply. This is where I realized that many many (low-cost) 30V 5A power supplies are based on the same couple designs. I'll link to a few useful resources here that I came across during my search:

The resources linked above contain many of the schematics for the supplies. I've added Drive mirror links to several of these schematics, in addition to the Lavolta PSU manual, here: https://drive.google.com/drive/folders/1G1oorJG2v6LsT8LSzIfBv23qdOBqhMGH?usp=drive_link

Instead of going through all my investigations, I'll highlight a few standouts here.

Broken potentiometers

After lots of investigating, the key offenders were 2 broken potentiometers. Referring to the file PS305D Schematic Main in the Drive link, these are VR104 and VR102. These are shown below in Fig. 2.

Fig. 2 - The culprits. VR104 is marked 502 (5kΩ) and VR102 is marked 501 (500Ω). Both parts measure open at component ends.

VR104 is used for output voltage feedback. Once this part was replaced with a functioning 5kΩ pot, the output voltage was now stable and would go all the way up to 30V. The pot is trimmed until the max output voltage is 30V.

VR102 sets the max output current when the HI/LO button is released (HI -> 5A current limit). There was no current limit being set in this setting with the faulty part. Since I did not have a 500Ω pot on hand, I replaced VR102 with a 5kΩ pot in parallel with a 470Ω resistor. This allows tuning the resistance as shown in Fig. 3. Fig. 4 shows the parallel 470Ω resistor soldered on the back side of the board. Once these parts were provisioned, the 5kΩ pot was trimmed until the max output current was set to 5A. The red dot in Fig. 3 indicates the final trimmed resistance.

Fig. 3 - combined resistance of 5kΩ pot in parallel with 470Ω resistance as the pot is trimmed.

Fig. 4 - soldered 470Ω resistor in parallel with VR102

FIg. 5 - the two blue potentiometers replace the broken ones in Fig. 2

Tuning the current display

Fig. 6 - Output current reading 6.89A when the real measured value is 5A

Fig. 7 - DMM on the PSU; the trim pots are the blue components near each chip. Left display is for current and the corresponding trimpot is VR211. Right display is for voltage and the corresponding trimpot is VR201.

When the HI/LO button is pushed down to the LO position, the PSU's output current limit is set to 2.5A tuned by VR101. When the HI/LO button is at the HI position, the output limit is set by VR102 (and the parallel 470Ω resistor) as described previously. However, there was a fair bit of error on this reading, as shown in Fig. 6. By adjusting VR305 (see PS305D Schematic Controls in the Drive link) in conjunction with the reference voltage set by the blue trimpot VR211 (see PS305D Schematic Display in the Drive link) in Fig. 7, the output current can be tuned. Since VR211 affects the reference voltage for the current meter, adjusting it affects both the HI and LO current readings. The procedure then was to set the switch to HI and then tune VR211; once that is corrected, switch to LO and then tune VR305.

Relay-selectable transformer secondary winding

Fig. 8 - secondary selection scheme with relay

Because the regulation stage in the power supply is based on a linear regulator, the difference between the input and output power is dissipated as heat. Since the power supply has a large selectable output range, this would result in very high power dissipation in the regulator at lower input voltages. To overcome this drawback and reduce the power dissipation, the power supply utilizes a selector circuit on the secondary as shown in Fig. 8.

As an example, let's consider that the output power is desired to be 3.3V. Suppose the input voltage post-rectifier is 40V (which is the case between S3-S0 for the BPS-305). At an output current of 3A, the power dissipated in the regulator would be roughly: Pout-Pin = Vout*Iout - Vin*Iin ~ (Vout-Vin)*Iout = 110.1W. All this for only 13.2W of output power. At lower output voltages and higher output currents, this gets even worse!

By using the scheme shown in Fig. 8, the voltage at the input of the regulator is selected based on the desired output voltage to reduce power dissipation. With the example above, now suppose that for 3.3V, the input to the regulator is 14.8V, the power dissipation is reduced to 34.5W now! That's 75W less than the previous example!

For my unit, the voltage bins transitions happen for output voltages 8V, 15V, 21V and 30V. This is a good design decision rather than having a fixed 40V input for the regulator.

Output testing

For testing the output, different resistor combinations were used as the load. In addition, a constant current circuit was used even as the output voltage is varied. A simple circuit can be designed using the jellybean LM317 part. The datasheet shows an example circuit in Section 9.3.3 (Precision Current-Limiter Circuit).

Fig. 9 - constant current circuit using LM317

The output (ADJUST pin) is tied to GND for testing. Using R1 = 4.7Ω provides a ~250mA constant current load. Similarly, R1 is swapped out for lower values for higher currents. It is important to have a heatsink mounted on the LM317, especially at higher voltages. This constant current value was also used to validate the output current display across PSU output voltages.

Other observations

The logic GND for the electronics are shorted to the positive output instead of the negative output. Even though the circuits in the PSU closely reflect those of PS305D Schematic Main/Display/Controls, this grounding scheme is reflected in hy_3005_dc_power_supply.
Many of these 30V 5A power supplies seem to be based on a couple base designs with slight tweaks in implementation.
The build quality appears shoddy. Many components were haphazardly soldered - many caps weren't fully seated. The fan wires run adjacent to (and touch) the (potentially very hot) heatsink for the transistors. However, none of these appear to impact functionality, at least in the short term.

A low-cost high-side current sense amplifier: design considering non-idealities

2024-07-10T04:37:00.000-07:00

Current-sensing is commonly used in power electronics and embedded systems, both for system monitoring, as well as to take decisions. Examples of common use cases for the latter are:

Monitoring inductor current for current-mode control in power converters
Monitoring converter current for overcurrent protection
Reading battery charge current to inform the charging process
Reading output current to compute output power to inform how to proceed in an MPPT charge controller

Use cases 1 and 2 require high-speed current measurements since they need to operate at either the converter's control frequency or based on a desired response time. Use cases 3 and 4, however, only require measuring "DC" current and so don't require high-speed current sense. The high-speed aspect ties to notions of slew rate and bandwidth for the amplifier. Other non-idealities, which I will describe here, affect even the DC behavior of the amplifier.

High-Side vs Low-Side Current Sensing

This article gives a good overview of the differences between high-side and low-side current sensing. Shown below are what they look like.

(a): High-side current sense
(b): Low-side current sense

Sense Resistor Selection

In both cases, the sense element is the series resistor Rs. By monitoring the voltage drop across Rs, you can compute the corresponding current from Ohm's Law: V=IR.

Tradeoffs for resistor selection include considerations for power and minimum sense voltage.

Power dissipation in the resistor is given by I_rms²R_s. A larger resistor will correspond to larger power dissipation for the same current.
Using a small resistor corresponds to a smaller sense voltage. When using a small sense resistor, you will use a current sense amplifier (CSA) to amplify the small sensed voltage to feed the corresponding circuit, which is often an ADC. A smaller resistor will correspond to requiring a larger gain in the amplifier or a greater ADC resolution.

High-side vs low-side

High-side current sense refers to placing the sense resistor in the "power" side without disrupting the power return or ground, enabling the use of a common ground overall circuit scheme. Low-side current sense refers to placing the sense resistor in the "ground" side, thereby disrupting the power return/ground. If common-ground is not desired for your application, you can use the low-side sense scheme.

In this article, we're looking at applications where you prefer high-side current sense!

Non-idealities Considerations and Circuit Design

In this application, I'm focusing on using a standard ultra-cheap op-amp instead of a dedicated current sense amplifier (such as INA180).

The op-amp I'm picking for this is the TL082 which I have on hand. The amplifier design is based on a standard differential amplifier configuration as shown in this article. The datasheet for the TL082 can be found on the TI website [1] [2]. LCSC shows the ultra-low cost of < $0.20 at volume!

The schematic for the current-sense amplifier (CSA) is shown below.

CSA implementation circuit (click to enlarge schematic)
R1=R2=2.2kΩ, R3=R4=5.6kΩ, Rs=0.5Ω, C1=C2=4.7uF, C3=0.1uF
VSNS+ = 12V

There are 3 parts to the output to consider:

VREF biases the output to 5V. Errors in the 5V reference will propagate to the output.
The diffamp gain is given by R3/R1 assuming R1=R2 and R3=R4. The input to the diffamp is given by the voltage across the sense resistor, which is the product of the current through it and its resistance.
The slope of the output voltage against current is negative due to the diffamp having negative gain. This is by design. See below.

We need to consider the amplifier non-idealities when designing the part. The ones we are considering, along with their impacts is shown below.

Input offset voltage

This is a mismatch in the input voltage of the op-amp, due to the input-side design of the op-amp itself. This gets amplified and shows up as an error on the output. The TL082 is specced at 5mV typically. With our amplifier's gain of 5.6/2.2=2.54, this means that this offset shows up at the output as ~12.7mV. Given that our system's current gain magnitude is 1.27V/A, this corresponds to a 10mA error in current reading.
Note that the offset can be positive or negative.
Additionally, the offset varies over part tolerances and temperature, going up to as much as 20mV, which will correspond to closer to 40mA of error.
Whether this is a problem or not depends on your application and desired current sense accuracy. You can perform an offset calibration to try to get rid of the steady-state error and only have to worry about the smaller temperature-dependent offset error. Alternately, you can use an opamp such as the TL081 which has additional pins to allow for offset nulling.
Better opamps with lower offset can be used if the offset is an issue and cannot be solved by calibration.

Input bias and offset current

A large input bias current will correspond to voltages dropped across R1 and R2, which will correspond to errors in the sensed voltage. The TL082 has bias currents in the 50pA-8nA range. Since this shows up on both inputs on this amplifier, the impact will depend on the mismatch between the input resistors. This will not be an issue in this particular application. In a low-side current-sense amplifier, the bias will show up differentially since one side will likely be grounded, so you will need to be more careful there.
A large input offset current will correspond to mismatch in this voltage dropped across the input resistors, which will get amplified and show up as an error on the output. The TL082 has an input offset current spec between 25pA-4nA. The impact of this is the same as for the input offset voltage. Given that the input offset voltage spec is worse than this corresponding offset, this can be ignored for this application.
The design will tend to get more sensitive to bias/offset current if you use larger input resistors, so you should be careful about that.

Input common-mode voltage range

Rail-to-rail opamps allow the input voltages to go as high as the supply voltage and as low as the supply return. However, the TL082 is not a rail-to-rail opamp, so you need to be careful about making sure that the input voltage is within the desired spec. The datasheet outlines that the input voltage can go as high as the supply rail but can only go as low as 4V above supply return. That means that in our single-rail application, the input voltage cannot go below 4V.
Note that this limit also means that you should not use the TL082 to buffer voltages below 4V!
With the 5.6k and 2.2k resistors, as well as the 5V VREF, this is not a concern in our application! However, this is something to keep in mind!

Output voltage range

You can notice that I flipped the + and - inputs on the op-amp relative to a non-inverting configuration. This gives negative gain, but why did I do this? By using VREF=5V, this then means that as current goes up, the output voltage will go down but will nominally be 5V. If I used VREF=0V and used a non-inverting configuration, that would result in the desired 0A output to be 0V. However, the TL082 cannot drive its output to within 200mV of the supply rail or return (or even worse if you have too low an output resistance!).
This means that if the output sits at 200mV with no input, we cannot resolve currents below 158mA. However, if we sit at 5V, we don't have this issue since 5V is far out from either supply rail or GND!
With a large enough current, the output still can't swing low enough, so the max current we can resolve is about (5V-0.2V)/1.27[V/A]=3.8A. Note that this would result in a large power in the sense resistor, so this is another constraint to consider!

Some additional considerations:

VSNS+ is bounded between 4V and 14.75V. The lower bound maintains the op-amp's input common mode voltage range. The upper bound is given by the op-amp's supply voltage (=12V here). VSNS+ can go higher than 12V as long as the input to the op-amp pins is maintained to be at most 12V. The op-amp voltage at its non-inverting input is given by the equation below. With the circuit components implemented, this sets the upper bound of VSNS+ to 14.75V.
Errors in the reference voltage VREF (=5V here) will propagate to the output. These can be accounted for with an initial calibration step. For best performance, use a voltage ref chip such as the LM4040. This will give better accuracy for the voltage reference.
You can set the VREF to a higher voltage and increase the gain.
You can use a voltage divider at the output to rescale the output to a lower range.
You should add a low-pass anti-aliasing filter between the current-sense amplifier's output and the next-stage ADC.

Measurements

With steady state currents, the following output voltages were measured.

0.33A : 4.70V measured vs 4.58V expected : +2.6% error
0.94A : 3.73V measured vs 3.81V expected : -2.0% error

The input offset contributes output error - with no input, you can measure the output and find the offset. The component tolerances also contribute additional error.

For the purposes of this demonstrative application, this is deemed sufficient! In a wide range of applications, this could also be sufficient, especially in cases where the application is very cost-sensitive! I wanted to share some of the non-ideality considerations through this application and would love to hear if this has helped you understand them!

Generating complementary PWM with adjustable deadtime for the RP2040

2024-07-03T04:55:00.000-07:00

I have previously discussed the benefits of using the Raspberry Pi Pico, leveraging the easy-to-program Micropython along with the capable hardware peripherals: 2023 Updates: PhD; Pi Pico and Quick and dirty PIC16F72 programmer with the Pico

Several articles in the blog have previously described applications of PWM in embedded systems, such as Stereo audio player using the PIC32, MCP4822, microSD card and the MDDFS library, DC motor control with PIC16F877A - Practical example of PIC PWM and Generation of sine wave using SPWM in PIC16F684.

Complementary PWM signals with 500ns deadtime

The underlying RP2040 in the Pi Pico provides an easy-to-use and still powerful and flexible set of PWM peripherals that can enable a wide range of applications. A common requirement in power electronics is the generation of complementary PWM signals. For example, the complementary PWM signals are used in a synchronous buck converter, shown below, to drive the switches S1 and S2.

Synchronous Buck Converter
Image source: https://commons.wikimedia.org/wiki/File:300px-Synch_buck.PNG

To prevent shoot-through, a deadtime is employed. Shoot-through is the event when both S1 and S2 are turned on, causing a large current through them due to shorting across the supply voltage. Even if the generated PWM signals are non-overlapping (ie S1 and S2 are never turned on together), delays in the circuitry - through the gate drivers and the power switches themselves - can still result in shoot-through conditions. In a severe case, the shoot-through can cause damage to the switches, blowing them out. In a more moderate case, small overlap times can result in reduced efficiency due to wasted power, but not necessarily damage to the switches. To combat this issue, a deadtime is inserted between the S1 and S2 driving signals. This is an amount of time when both switch control signals are zero allowing for system transients to settle out. How large it should be depends on the circuit parameters and behavior.

In many cases, gate drivers can have built-in features to insert dead-times, such as the LM5106. However, the ability to generate this in the microcontroller itself gives greater flexibility in the selection of gate driver. Further, it allows tuning the time easily in software rather than needing to change hardware components to change deadtimes.

Fortunately, the Pi Pico makes it fairly straightforward to do this!

The details of the PWM peripheral are outlined in the RP2040 datasheet section 4.5. You can find the code sample here: https://github.com/SyedTahmidMahbub/comppwm_rp2040

The corresponding source code is copied below for convenience:

The RP2040 has 8x PWM slices, each with 2 channels. The complementary PWM waveforms are produced on these 2 channels (A and B) on a given slice. The slice to GPIO mapping is shown below.

PWM slice+channel mapping to GPIO pins
Image source: RP2040 datasheet section 4.5.2

The key aspects of the code are:

Use Micropython to init PWM for the associated GPIO pins (A and B).
Alter RP2040 registers to configure for complementary PWM. This consists of two settings being changed.

Invert channel B relative to channel A.
Use center-aligned (phase-correct) PWM instead of edge-aligned. This ensures that the deadtime is applied to both rising and falling edges of channel A. If edge-aligned PWM was used, the channels would be set high together and the deadtime would only be applied on the falling edge of channel A.

The deadtime is applied to channel B such that channel A's duty cycle corresponds to the desired/set duty cycle.
The duty cycles corresponding to both channels A and B are updated with one register write.
The frequency of the output PWM using center-aligned/phase-correct mode is half that when using the default edge-aligned mode.

An example of phase-correct/center-aligned PWM operation is shown in the figure below, taken from the RP2040 datasheet.

Image source: RP2040 datasheet section 4.5.2.1

To generate the complementary signal on channel B, the duty cycle is computed as the sum of the pulse count corresponding to the desired duty cycle and the desired deadtime ticks. With a 125MHz clock for the RP2040 and default clock/divider settings, this corresponds to 8ns per tick. The inversion of channel B then ensures the production of the desired complementary setting.

Shown below are waveforms for GP16 (PWM 0A) and GP17 (PWM0B) for 100kHz PWM, 25% duty cycle and a 504ns deadtime. The deadtime can be verified by recognizing that it corresponds to one horizontal division, which is set to 500ns.

Complementary PWM signals with 500ns deadtime

Taking a zoomed out view of the waveform highlights the 100kHz frequency and illustrates the complementary PWM generation over multiple cycles, as shown below.

3 cycles of 100kHz PWM complementary signals

A natural use case for this generated complementary PWM signal is to control a synchronous buck converter to achieve high efficiency step down operation. Since Micropython will limit the design of a fast control loop, applications where the high frequency PWM is coupled with a low-bandwidth controller make for a natural home for this use case. A solar MPPT battery charger would make for an ideal usage scenario. Alternately, if the same configuration technique is applied in C, fast control loops can then be designed and implemented.

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

2024-03-23T17:56:00.000-07:00

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.

Quick and dirty PIC16F72 programmer with the Pico

2024-01-02T01:40:00.000-08:00

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:

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.
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.
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:

Configure the IOs for their corresponding functions.
Configure PWM for the boost converter, running at 50kHz.

Adjust the duty cycle until the output is near 13.2V.
The output voltage is sensed by an ADC channel.

Hold this duty cycle for the output voltage - at this point, the feedback loop is stopped.
Detect the target PIC.
If detected, issue a bulk erase and then check that the part is blank.
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:

Sizing IR2110 high-side bootstrap capacitor

2023-12-21T19:50:00.000-08:00

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.

The LTSpice file can be found at: https://github.com/SyedTahmidMahbub/boostrapcap_ir2110/blob/main/ir2110_capsizing.asc

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:

Github link: https://github.com/SyedTahmidMahbub/boostrapcap_ir2110/blob/main/delV_bs.py

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!

SmartSinePy, and an example of GUI development with PySide6

2023-11-10T11:53:00.011-08:00

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!

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

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!

Modified Sine Wave Inverter: Harmonic Elimination

2023-11-03T02:18:00.005-07:00

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.

2023 Updates: PhD; Pi Pico

2023-08-13T23:04:00.003-07:00

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:

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.
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.
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.

A digital communication project using OFDM and 32-QAM

2017-06-15T23:45:00.001-07:00

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!

PIC32 JTAG Loader / ICSP programmer

2016-12-16T09:24:00.002-08:00

This past semester, I worked on an independent study/project where I explored the programming of the PIC32. I've provided the details in the following PDF document. The key takeaway I believe is:

"This document presents sufficient background information on the project, and implementation specific details. The most important contribution this makes is adding the experiences and a full implementation of the project. For even more detail and a thorough understanding, it is recommended that this report be read along with the reference documents mentioned in Section 4.1."

I plan on improving this, as well as exploring the option of programming other PICs this summer. A cursory look made me think that the PIC32 programming standard was more complicated than the PIC16's. I'll find out!

All the project code and settings can be found here. This includes the PIC32 project, as well as the MATLAB code for the programmer software
https://drive.google.com/open?id=0B4SoPFPRNziHeUhXQlZSRWxyeW8

Please let me know if you have any comments or feedback!

Creating my own TV Tuner IR remote with a PIC16F684

2016-02-06T15:49:00.002-08:00

While I was home this winter, I saw that the remote for our TV tuner was damaged physically, causing the buttons to not function responsively. Some of them just didn't work. I saw this as an opportunity for a fun couple days' project to build a new remote controller for the tuner.

The TV tuner was manufactured by a brand name RealView and, as expected, I couldn't find much detail about it. Thus, I had to reverse engineer the remote. From my previous experience in working with IR remotes, I had a hunch that the IR was most likely modulated at ~38kHz or ~56kHz. For those of you who don't know how this works, I highly recommend going through this website: http://www.sbprojects.com/knowledge/ir/

Thus, I connected a 38kHz IR receiver I had at home (TSOP1738) to an oscilloscope in order to figure out what IR protocol is used by the remote. Upon pressing the 4 key on the remote, I saw the following waveform:

Fig. 1: Oscilloscope waveform capture of the received IR signal

Note that I inverted the signal on the oscilloscope since the IR receiver output is active-low.

I then compared the waveform to some of the common IR protocols, paying particular attention to the initial first high and low states. After going through SIRC, RC5, RC6 among others, I noticed that this matched the NEC protocol: http://www.sbprojects.com/knowledge/ir/nec.php

Fig. 2: Standard NEC IR protocol pulse train

Fig. 3: NEC IR protocol logic high and logic low signals

Using the waveform shown above, I found that ~address was not being sent, meaning that the extended NEC protocol was being used:

Fig. 4: Extended NEC IR protocol pulse train

From the waveform, I found that the address was 0xBD02. I then proceeded to make a simple decoder with a PIC16F877A since I had a development board with an IR sensor mounted on it. Using this, I found all the required commands for the different keys of the remote. I decided to exclude some of the keys that were never used (eg play, pause, stop, fast forward, rewind).
You can find this part of the project here:
https://drive.google.com/file/d/0B4SoPFPRNziHZjk2N3pNLVE5V1E/view?usp=sharing

This left me with the following keys and commands:

Key	Command
0	9
1	0
2	1
3	2
4	3
5	4
6	5
7	6
8	7
9	8
UP	18
DOWN	19
RIGHT	16
LEFT	17
PREVIOUS CHANNEL	13
-/--	10
POWER	20
MENU	21
MUTE	12

I then proceeded to write an IR transmitter using the PIC16F684 (using the MPLAB X IDE and XC8 compiler), following the timing information from the extended NEC protocol. In order to connect all the keys, I connected them in matrix keypad form.

In order to power the remote off 2xAA batteries, it is necessary to use sleep mode - otherwise the battery will be drained extremely quickly. So, in order to detect when a button is pressed, an interrupt is used. After the IR command is sent, the microcontroller goes to sleep. The interrupt wakes up the microcontroller when a button is pressed. Debouncing is achieved using simple software delays. When a button is held down, the NEC command repeat sequence is not sent. Instead, the remote relies on releasing the button and pressing it again.

To minimize leakage current through the input capacitor, I decided not to use an electrolytic capacitor. A red LED illuminates to confirm that a button has been pressed.

Fig. 5: Schematic of IR remote design

Everything was put together, a PCB was designed and when tested with the TV tuner, everything worked as expected! I measured the sleep current with a portable DMM and it was read as 1.6μA! I'm not sure how accurate the DMM is at such low currents, so I wouldn't entirely trust this number - however, it does seem to be within spec for the PIC16F684.

Due to a lack of time, I had to put the remote together with electric tape! Here you can see pictures of the final design:

Fig. 6: Final IR remote, top

Fig. 7: Final IR remote, bottom

I am back at college now, but I have been told that the same set of batteries are still working on the remote, and it is working perfectly fine!

You can find the MPLABX project, source code, schematic and pcb files all here:
https://drive.google.com/file/d/0B4SoPFPRNziHV2I1U1Bldm1OYUE/view?usp=sharing

Let me know what you think! If you have any questions, let me know in the comments section!

Using an input device on Embedded Linux: An example with a USB mouse on the Intel Edison

2015-12-28T04:41:00.001-08:00

The Intel Edison test board, along with the USB mouse

I have recently been using the Intel Edison for the Cornell robotics project team (which co-hosts the Intel-Cornell Cup USA competition). Building on my previous knowledge of embedded systems, I started learning to use and program on Linux. The distro used is Yocto (all information is available on the Intel Edison website).

One of the prototypes we worked on relied on using a wireless Playstation 4 controller for locomotion user interface. The concept of using an input device on Linux is not complicated, but can be a daunting task for someone new to Linux programming. Hence, I have decided to write this article giving an example of using an input device on an Embedded Linux platform. This demo application I am showing uses a USB mouse as the input device connected to the Intel Edison.

Prerequisite: I have assumed that you have a flashed Intel Edison board, know how to access the terminal (through the USB COM port, or through SSH) and have the Eclipse IDE installed and can program with it. Of course, if you don't have the IDE, you can compile the code through the terminal and I'll tell you how to do it at the end. If you are using a platform other than the Edison, details may change but the general idea is similar. Additionally, it is assumed that you have a basic understanding of C programming.

First thing to note when you connect the USB mouse is that the switch on the board (labelled SW1) must be switched towards the USB-A connector from the default position facing the microUSB port.

The device drivers in Linux abstract away the low-level nitty gritty details of the interface with the input device, presenting an input through file descriptors that can be interfaced with as files. The input devices can be viewed and read from in the Linux environment just like files, as mentioned before. The input device appears in the /dev/input directory. Initially, before the mouse is plugged in, you can see that there is an event0 and an event1 file. Upon connecting the mouse, you can see an event2 file.

Fig. 1: Input device files without mouse connected

Fig. 2: Input device files with mouse connected

By reading the event2 file, you can read the mouse data. To dump data from the file, you can use the od command (man page: http://man7.org/linux/man-pages/man1/od.1.html)

For example, to view the output dump in hex format:
od -x event2

Move the mouse around, press the buttons, scroll the wheel and you'll see data appear on the console:

Fig. 3: File event2 data dump using od command

Hit Ctrl+C when you're satisfied you've seen enough of the dump.

Now to make sense of this input, decipher it and meaningfully use it, I have written a simple C application. I'll walk you through the process of developing it before I provide the code.

First thing to do is to go through these references as part of the kernel documentation:
https://www.kernel.org/doc/Documentation/input/event-codes.txt
https://www.kernel.org/doc/Documentation/input/input.txt

Additionally, you should go through the linux/input.h header file. You can find a copy here:
http://lxr.free-electrons.com/source/include/linux/input.h?v=2.6.38

You can also type it into Eclipse, hit Ctrl on your keypad and left mouse click on the header file name to view the file itself.

From the kernel documentation and the input.h file, you should find that the data output happens such that every time an event occurs, it can be "fit" into the following structure (defined in linux/input.h):

struct input_event {
    struct timeval time;
    __u16 type;
    __u16 code;
    __s32 value;
};

You can find that this has a total length of 16 bytes. You can look through the different data types and add, and confirm using the sizeof function in Eclipse:
fprintf(stdout, "Size of event is: %d\n", sizeof(event));

Each event has a timestamp, type, code and value as you can guess from the input structure. Additionally events are separated by EV_SYN type events which are just markers. EV_SYN is defined as 0.

You can read the file in a C program and then just print out the values separated as fields in the input event structure to confirm that and observe the different types of data as you interact with the mouse. You can limit the type of event as you interact with your mouse. To understand the meaning of the numbers you receive, peruse the linux/input.h file and the kernel documentation linked above. You will see a section describing the events:

/*
* Event types
*/

#define EV_SYN            0x00
#define EV_KEY            0x01
#define EV_REL            0x02
#define EV_ABS            0x03
#define EV_MSC            0x04
#define EV_SW             0x05
#define EV_LED            0x11
#define EV_SND            0x12
#define EV_REP            0x14
#define EV_FF             0x15
#define EV_PWR            0x16
#define EV_FF_STATUS    0x17
#define EV_MAX            0x1f
#define EV_CNT            (EV_MAX+1)

You can also find a section describing the different keys/buttons for a keyboard, gamepad, mouse, etc. The section describing the mouse is:

#define BTN_MOUSE       0x110
#define BTN_LEFT        0x110
#define BTN_RIGHT       0x111
#define BTN_MIDDLE    0x112
#define BTN_SIDE        0x113
#define BTN_EXTRA       0x114
#define BTN_FORWARD     0x115
#define BTN_BACK        0x116
#define BTN_TASK        0x117

/*
* Relative axes
*/

#define REL_X            0x00
#define REL_Y            0x01
#define REL_Z            0x02
#define REL_RX           0x03
#define REL_RY           0x04
#define REL_RZ           0x05
#define REL_HWHEEL       0x06
#define REL_DIAL         0x07
#define REL_WHEEL        0x08
#define REL_MISC         0x09
#define REL_MAX        0x0f
#define REL_CNT        (REL_MAX+1)

You can compare these against the values you see to see if they make sense (they should!). Then, you can proceed to mold this to read the different codes, types and values based on these. This is what I have done in my demo application, which should be commented enough for you to understand. (Obviously, if you have questions, let me know in the comments section!)

One last thing that I haven't covered yet (but you may already know) is how to do the file read. I have used the low-level file IO functions open and read:

Opening the file:

// Use low-level Linux file IO operations
// Device is presented as a file, event2 in /dev/input for the Edison
int fid = open("/dev/input/event2", O_RDONLY);
if (fid == 0){
    fprintf(stderr, "Could not open event2 device!\n");
    return EXIT_FAILURE;
}
fprintf(stdout, "Opened event2 device!\n");

Reading the file:

int nbytes;
struct input_event event;
// Event type from <linux/input.h>
nbytes = read(fid, &event, sizeof(event));

The demo application prints out messages describing mouse motion, wheel motion and left, middle (wheel) and right button presses. See Fig. 4 below.

You can find the full code for my demo project here: https://drive.google.com/file/d/0B4SoPFPRNziHUUVCRHVPNjkwZ2s/view?usp=sharing

A typical output is shown below:

Fig. 4: Output of the demo application

Programming without the Eclipse IDE: As I have mentioned before, even if you don't have the Eclipse IDE (which you should get), you can still program the Edison. Here are a few ways you can do so. You can copy-paste the code from a text editor to the terminal (using PuTTY, mouse right-click is paste), or even write the code on the terminal. Additionally, you can use a program such as WinSCP to transfer a C file. Be careful with Windows files since lines end in a newline and a carriage return character, whereas on Linux, they end with only a newline character. The carriage return character will be displayed as ^M if you open the file with the text editor. Once the file is on the Edison file system somewhere, cd into that folder and compile it:

gcc -o <output name> <source file name>
eg: gcc -o mouse mouse.c

Then you can run it:
eg: ./mouse

I have attempted to make the code self-explanatory and provide sufficient background detail here for you to understand what's going on. By changing the code and type checks, you can extend this to other devices. Hopefully you'll find this useful! Let me know what you think!

PIC32 Tic-Tac-Toe: Demonstration of using touch-screen, TFT and the Protothreads threading library

2015-08-02T13:04:00.000-07:00

I had previously used the Adafruit TFT display using my library (ported from the Adafruit Arduino library). I decided to optimize the library to improve drawing speed. The same display I use comes with a 4-wire resistive touch-screen as well. I decided to write a simple library for the touch-screen and give Protothreads a try. To incorporate all this, I thought it would be cool if I used these to make a simple game. Tic-tac-toe came to mind as a fun little demo.

I'm sure everyone's familiar with the game so I won't explain the rules there. The touch-screen is simply two resistive sheets placed on top of each other on top of the TFT screen. When it is pressed down at a given place, the two sheets make contact and a voltage divider is formed. Using the IO's and the ADC, this voltage is read in the X and Y directions to register a touch.

Here is a very good pictorial depiction of the resistive touch screen (taken from the Atmel AVR341 document):

So in order to read the touch, the X+ and X- points are applied power, and one of Y+ or Y- is read to read the x-coordinate. Then Y+ and Y- are applied power and one of X+ or X- is read to read the y-coordinate. X+, X-, Y+ and Y- are connected to four GPIO pins on the PIC32 that are configured to outputs when driving the touch-screen and analog inputs when reading. Every time the IO pin switches state, a long delay is provided to allow the outputs to stabilize. Alternately, the ADC is significantly slowed down to negate effects of capacitive charging by high source impedance. The library is written in the form of a simple state machine cycling through its states every few milliseconds, decided by the application calling the library functions. In my application, I use 5 milliseconds.

To organize the game, I've made use of the Protothreads threading library. Protothreads is a very light-weight, stackless, threading library written entirely as C macros by Adam Dunkels. Bruce Land has ported Protothreads over for the PIC32. You can find more details on his excellent site: http://people.ece.cornell.edu/land/courses/ece4760//PIC32/index_Protothreads.html

There are two main executing threads, one is the main game thread and the other is a clock thread that keeps track of, and displays, time since the program was started. There is a third thread used to retrieve touch information. It is spawned by the main game thread when touch input is required. The main Protothreads functions (macros) I've made use of are:

PT_setup()
PT_INIT()
PT_SCHEDULE()
PT_SPAWN()
PT_WAIT_UNTIL()
PT_YIELD_TIME_msec()
PT_GET_TIME()

Pin connections:

BL (backlight): I left it unconnected, but you can connect it to 3.3V for backlight.
SCK: connected to RB14 on the PIC
MISO: left unconnected, since I'm not reading anything from the screen
MOSI: connected to RB11 on the PIC
CS: connected to RB1 on the PIC
SDCS: left unconnected as I'm not using the microSD card for this
RST: connected to RB2 on the PIC
D/C: connected to RB0 on the PIC
X+: connected to RA4 on the PIC
X-: connected to RB13 on the PIC
Y+: connected to RB5 on the PIC
Y-: connected to RB15 on the PIC
VIN: connected to 3.3V supply
GND: connected to gnd

Here is a demo of the game:

Besides the game itself, you can see the running clock on the bottom left right above the players' scores. To the bottom right you can see a flickering circle that is either green or red, depending on if it's player 1 or 2's turn, respectively. Once the game is over, you have the option of playing another game while score is being tracked.

Here is a link to the MPLABX project with all required header and source files:
https://drive.google.com/file/d/0B4SoPFPRNziHbURwVWVSN1c3VVE/view?usp=sharing

I have commented the code to make it fairly self-explanatory. If you have doubts or questions about anything, let me know and I'll add more detail. Let me know what you think!

Stereo audio player using the PIC32, MCP4822, microSD card and the MDDFS library

2015-01-07T14:35:00.003-08:00

Oscilloscope screen capture of output from the audio player

Top - left channel

Bottom - right channel

Using the PIC32MX250F128B, I decided to make a simple audio player. I wanted to play back good quality audio from a large memory space - a microSD card. So, I made this WAV player that can play back 16-bit 44.1kHz WAV files with 12-bit stereo audio output. Of course that's not all it can play back. It is programmed for automatic period configuration so that the period is set on the fly based on the song sample rate. It can play back both 8-bit and 16-bit mono and stereo audio files and I have tested from 8kHz 8-bit mono to 44.1kHz 16-bit stereo. The player itself does not include an audio amplifier to drive speakers but can drive earphones. I've used an external stereo speaker for testing.

The hardware is fairly simple! Using the Microchip Memory Disk Drive File System (MDDFS) library, and my previous work using the MCP4822 dual 12-bit DAC, integrating these components to make a working audio player was quite fun and a good learning experience.

Here I share all my project files and source code, along with documentation regarding this project. Let me know what you think!

Schematic of PIC32-based audio player

Running demo of the audio player:

All project files and schematic can be downloaded from:
https://drive.google.com/file/d/0B4SoPFPRNziHRGE0bVNZYV9uVjQ/view?usp=sharing

Documentation can be downloaded from:
https://drive.google.com/file/d/0B4SoPFPRNziHaWpIWFQ3RkJFVzQ/view?usp=sharing

Interfacing a color TFT display with the PIC32MX250F128B

2014-10-30T12:06:00.002-07:00

I have been working on interfacing the PIC32MX250F128B with a small 2.2" TFT display from Adafruit. It's a nice little display that is fairly easy to communicate with, using SPI communication. The display I'm using is: http://www.adafruit.com/product/1480

Adafruit provides nice open-source libraries for their products. However, they are for Arduino and thus cannot be directly reused for the PIC32. I went through the library and ported it over for the PIC32, in C. I have attached my project file as a .zip file and you can download it to go through the library header and source files, as well as the demo code. I've tried heavily commenting the code so that it is self-explanatory.

As far as hardware goes, with the demo code, the pin connections for the display are:

BL (backlight): I left it unconnected, but you can connect it to 3.3V for backlight.
SCK: connected to RB14 on the PIC
MISO: left unconnected, since I'm not reading anything from the screen
MOSI: connected to RB11 on the PIC
CS: connected to RB1 on the PIC
SDCS: left unconnected as I'm not using the microSD card for this
RST: connected to RB2 on the PIC
D/C: connected to RB0 on the PIC
VIN: connected to 3.3V supply
GND: connected to gnd

The pins I used are defined in the code and you can easily change them as required.

I used my custom proto-board for testing on a breadboard. You can find details here: http://tahmidmc.blogspot.com/2014/02/pic32-proto-board-details-schematic-pcb.html

Here's a video showing the PIC32 running the demo code and doing some simple graphics on the screen. You can see that it runs fairly quickly and quite smoothly.

Project files with all source and header files:
https://drive.google.com/file/d/0B4SoPFPRNziHdksweU1vUkZ4SHM/view?usp=sharing
http://www.4shared.com/zip/O-LcEU0Ace/Adafruit_TFTX.html

If you have any comments, questions or suggestions, do let me know!

PIC32 DMA+SPI+DAC : Analog output synthesis with zero CPU overhead

2014-10-16T22:14:00.002-07:00

I have previously shown how to use the PIC32 SPI module to use the 12-bit DAC MCP4822: http://tahmidmc.blogspot.com/2014/10/pic32-spi-using-mcp4822-12-bit-serial.html. While that does allow you to generate analog outputs as desired, it requires you to use CPU cycles to process the timer interrupt and accordingly drive the SPI module.

Since the PIC32 contains DMA channels, the process can be completely offloaded from the CPU. For an idea of the PIC32 DMA module, refer to my previously written article: http://tahmidmc.blogspot.com/2014/05/simple-pic32-dma-example.html

Fig. 1 - The generated sine wave at fpwm = 400kHz and 32 elements in the sine table

So, the simple way of offloading the SPI update to the DMA module would be to let the DMA channel transfer data to the SPI buffer. The SPI module is configured for 16-bit data transfer (since the MCP4822 write command requires 2 bytes). This means that the cell size for the DMA channel has been set to 2 (2 bytes to transfer once triggered). The DMA transfer is triggered by a timer interrupt. Unlike the previous example where I used Timer 1 and its interrupt for the SPI transfer, here I use Timer 2. The reason for this is that, if I want the entire process to be offloaded from the CPU, the SS (Slave Select) or CS (Chip Select) also has to be done entirely in hardware. For that I used the Output Compare 1 module. To use the OC1 module, either Timer 2 or Timer 3 (or the combined 32-bit timer) has to be used. So, I just went with Timer 2.

Configuring the DMA module for transferring data to the SPI buffer was the simple part. I found the configuration of the SS/CS pin the more challenging part. The idea here was to use the OC module in "dual compare mode continuous output pulses" mode. The OC module in this mode generates continuous pulses - the output pin OC1 - which I used as CS/SS - is set high one PBCLK (peripheral bus clock) after the Timer value reaches OC1R; the OC1 pin is cleared one PBCLK after the Timer value reaches OC1RS. Since SS/CS is active low, I set ( (period register) - 4) to be OC1RS and a variable CSlength to be OC1R. CSlength was chosen to be 80% of the period register. What this meant was that. One PBCLK after the Timer reached the (period register - 4), the OC1 pin went low (CS/SS went low) "selecting" the DAC. After about 0.80*(period register) from there, the OC1 pin went high. This means that the CS pin is low for 80% of the period - it goes low a small time right before the DMA transfer happens and is raised high late enough, after the DMA transfer occurs. I determined that 80% the period was enough time since that is higher than the time required to shift out 16 bits of data at 20MHz SPI clock. See Fig. 2 below for an illustration of the operation of the output compare module in the "dual compare mode continuous output pulses" mode:

Fig. 2 - Output Compare module in Dual Compare Mode: Continuous Output Pulse mode (taken from PIC32 reference manual, figure 16-16)

Beyond that, the idea is simple. There is a sine table that is the DMA source. The key thing to remember here is that the 12-bit data must be OR-ed with 0x3000 since that is required for the DAC (to set gain=1, shutdown = 0 and channel = A):

void generateTables(void){
    uint8_t i;
    for (i = 0; i<TABLE_SIZE; i++){
        sineTable[i] = (short) (2047.0 * sin(6.2832*((float)i)/(float)TABLE_SIZE));
        sineTable[i] = sineTable[i] + 2047;

        sineTable[i] = 0x3000 | sineTable[i];
    }
}

Since the entries in the sine table are of "short" data type (each element occupies two bytes), the source size (in bytes) is twice the number of elements. The destination source size is two bytes since I'm transferring two bytes to the SPI buffer register. The cell size is two bytes since the DMA channel has to transfer two bytes (16 bits) at a time to the SPI buffer register. The DMA configuration is:

    DmaChnOpen(0, 3, DMA_OPEN_AUTO);
    // (ch, ch priority, mode)
    DmaChnSetTxfer(0, sineTable, &SPI1BUF, TABLE_SIZE*2, 2, 2);
    // (ch, start virtual addr, dest virtual addr, source size, dest size, cell size)
    DmaChnSetEventControl(0, DMA_EV_START_IRQ(_TIMER_2_IRQ));
    // (ch, trigger irq)
    DmaChnEnable(0);

A point of note is that, the DmaChnSetTxfer( ) takes in the virtual addresses of the source and destination, not the physical addresses. The virtual-to-physical address conversion is done by the function itself as opposed to it being required manually when doing register level operations (as done in my previous DMA example article).

To demonstrate that the DAC control is done with no CPU overhead, in the main( ) function, I have an infinite loop that is just toggling RA0. The output is checked on an oscilloscope:

Fig. 3 - RA0 toggle being demonstrated

Observe that the frequency of the square wave is 4.0MHz - the same that would be observed if all the PIC was doing was the pin toggling.

This also gave better performance than my previous experiment where I did not use DMA. The output sine wave has a higher frequency than observed before and this matches exactly as expected: 400kHz/32 = 12.5kHz as seen (see Fig. 1).

The rest should be very easy to understand and self-explanatory. If you have any questions or suggestions, feel free to comment!

Here are the source and header files:
config.h: https://drive.google.com/file/d/0B4SoPFPRNziHcmlxMmg2Si0zWjQ/view?usp=sharing
main.c: https://drive.google.com/file/d/0B4SoPFPRNziHcmlxMmg2Si0zWjQ/view?usp=sharing

PIC32 SPI: Using the MCP4822 12-bit serial dual DAC

2014-10-11T20:57:00.001-07:00

I recently got a few pieces of the MCP4822 DAC. You can check out the datasheet here: http://ww1.microchip.com/downloads/en/DeviceDoc/22249A.pdf

I found them to be neat little devices. In a small 8-pin PDIP package, the MCP4822 comes with 2 12-bit DACs, which you can easily configure over SPI. This was a great opportunity to get a simple PIC32 SPI application going. I worked on this today to see how fast I can get the DAC output going.

Here's the pinout of the MCP4822:

Fig. 1 - MCP4822 pinout (taken from datasheet)

The MCP4822 can be supplied a voltage in the range of 2.7V to 5.5V. Since I use 3.3V for my PIC32, I used the same 3.3V supply for the VDD for the MCP4822. Pin 5 is the active low signal LDAC that is used to synchronize the two DAC channels. When this pin is brought low, the data in the DAC's input register is copied to the output and both outputs are updated at the same time. I just had this tied to ground. VoutA and VoutB are the two output pins. The other pins are the regular pins for SPI communication - CS (active low) chip select, SCK serial clk, SDI serial data in.

The datasheet provides a nice diagram explaining the timing and pin functions very nicely:

Fig. 2 - Write command for MCP4822 (taken from datasheet)

The write command to the MCP4822 is a 16-bit wide command sent over SPI. Bit 15 (A/B) selects which channel you're sending data to: 1 signifies channel B, 0 signifies channel A. Bit 13 (GA) selects the gain. The MCP4822 has an internal 2.048V reference it uses for the DAC. So, that means that with a gain of 1, the maximum possible output voltage is 2.04975V (4095/4096 * Vref). If a higher output is required, the gain can be increased. The MCP4822 has a configurable gain of 1 or 2. When GA = 1, gain = 1; when GA = 0, gain = 2. Bit 12 SHDN is the shutdown signal. When SHDN is low, the output of the DAC is shut down. The 12 data bits from there on: D11 to D0 ([D11:D0], [bit11:bit0]) are the 12 data bits for the digital to analog conversion.

The transfer function is the very-simple, (almost) typical-for-DACs:

Vout = (D_12 / 4096) * 2.048V * Gain

D_12 is the digital value given by D11 to D0 in the write command, 4096 = 2^12 (12-bit resolution), 2.048V = internal voltage reference, gain = 1 or 2 depending on bit GA in write command.

While I typically use the registers and configure them manually, I decided to use the Microchip plib (peripheral library) here for the SPI module. The peripheral library consists of a lot of low-level functions and macros that essentially require understanding the peripheral but just make the code nicer and easier to read.

I decided to clock the MCP4822 at 20MHz (max for MCP4822) to get quick data transfers.

The SPI module can be initialized using one of 2 options:
1) Using the OpenSPIx(config1, config2) and SpiChnSetBrg(spi_channel, spi_brg) functions
2) Using the SpiChnOpen(spi_channel, config, spi_divider) function

These are both described in the plib documentation.

The DAC initialization routine I wrote is shown below:
//================================================================
// SS = PORTA4
#define SS      LATAbits.LATA4
#define dirSS   TRISAbits.TRISA4
void initDAC(void){
/* Steps:
*    1. Setup SS as digital output.
*    2. Map SDO to physical pin.
*    3. Configure SPI control and clock with either of a or b:
*        a. OpenSPIx(config1, config2) and SpiChnSetBrg(spi_channel, spi_brg)
*        b. SpiChnOpen(spi_channel, config, spi_divider)
*/

    dirSS = 0;                    // make SS an output
    SS = 1;                        // set SS = 1 to deselect slave
    PPSOutput(2, RPB5, SDO2);    // map SDO2 to RB5

///////
#define config1 SPI_MODE16_ON | SPI_CKE_ON | MASTER_ENABLE_ON
    /*    FRAME_ENABLE_OFF
    *    ENABLE_SDO_PIN        -> SPI Output pin enabled
    *    SPI_MODE16_ON        -> 16-bit SPI mode
    *    SPI_SMP_OFF            -> Sample at middle of data output time
    *    SPI_CKE_ON            -> Output data changes on transition from active clock
    *                            to idle clock state
    *    SLAVE_ENABLE_OFF    -> Manual SW control of SS
    *    MASTER_ENABLE_ON    -> Master mode enable
    */
#define config2 SPI_ENABLE
    /*    SPI_ENABLE    -> Enable SPI module
    */
//    OpenSPI2(config1, config2);
    // see pg 193 in plib reference

#define spi_channel    2
    // Use channel 2 since channel 1 is used by TFT display

#define spi_brg    0
    // Divider = 2 * (spi_brg + 1)
    // Divide by 2 to get SPI clock of FPBDIV/2 -> max SPI clock

//    SpiChnSetBrg(spi_channel, spi_brg);
    // see pg 203 in plib reference

//////

//////

#define spi_divider 2
/* Unlike OpenSPIx(), config for SpiChnOpen describes the non-default
* settings. eg for OpenSPI2(), use SPI_SMP_OFF (default) to sample
* at the middle of the data output, use SPI_SMP_ON to sample at end. For
* SpiChnOpen, using SPICON_SMP as a parameter will use the non-default
* SPI_SMP_ON setting.
*/
#define config SPI_OPEN_MSTEN | SPI_OPEN_MODE16 | SPI_OPEN_DISSDI | SPI_OPEN_CKE_REV
    /*    SPI_OPEN_MSTEN        -> Master mode enable
    *    SPI_OPEN_MODE16        -> 16-bit SPI mode
    *    SPI_OPEN_DISSDI        -> Disable SDI pin since PIC32 to DAC is a
    *                            master-to-slave    only communication
    *    SPI_OPEN_CKE_REV    -> Output data changes on transition from active
    *                            clock to idle clock state
    */
//    SpiChnOpen(spi_channel, config, spi_divider);
//////
}
//================================================================

The code block above has code written using both the initialization functions (one is commented out). Essentially, the configuration is that SPI channel 2 is enabled as a master, it is configured for 16-bit data transmission, the SDI pin is disabled, it is configured for serial output change from active high (1) to active low (0) as required by the MCP4822 (see Fig. 2) and the clock divisor is set to 2 so that SPI clock = 20MHz.

The SCK pins for the PIC32 are mapped physically to the RB15 (SCK2) and RB14 (SCK1) pins (check pinout on page 4 in datasheet). The SDO and SDI pins are remappable pins and thus require you to map them to physical pins. The SDI pin here is unused since the PIC32-to-MCP4822 is a one way communication with the PIC32 as the master and the MCP4822 as the slave.

The datasheet provides the table for all the PPS (peripheral pin select) mappings. The relevant section for the SDO is:

Table 1 - PPS configuration for SDO

I decided to use RPB5:

PPSOutput(2, RPB5, SDO2); // map SDO2 to RB5

The connections I used for the MCP4822 are:

Fig. 3 - MCP4822 connections

The chip select / slave select line (CS as shown on the MCP4822 pinout, see Fig. 1) has to be controlled manually. (For a hardware-based processor-free control scheme, see PIC32 DMA+SPI+DAC : Analog output synthesis with zero CPU overhead.) This is an active low chip select signal. When data is being sent to the MCP4822, while the SPI transaction is occurring, the CS pin must be kept low. Initially I checked to see if there was a way the hardware would take care of that. I looked into the framed SPI mode. However, this did not serve my purpose. From what I've read, the framed SPI mode is an SPI mode where the clock is always output (instead of only during transactions as traditionally done). However, the hardware generates a low sync signal (by pulling CS low) before the data is transmitted from the PIC32. The problem here was that the CS pin was pulled low and kept low for one SPI clock period before raising CS high as data is transmitted out from SDO. This isn't going to work for the MCP4822 since the chip requires that CS be held low during the entirety of data transmission (see Fig. 2). So I just decided to use RA4 as the pin for CS. Before starting any transmission, I pull CS low in software and raise it high at the end.

Here's the code for writing to the DAC:

inline void writeDAC(uint16_t data){
    SS = 0; // select slave device: MCP4822 DAC
    while (TxBufFullSPI2()); // ensure buffer is free before writing
    WriteSPI2(data);   // send the data through SPI
    while (SPI2STATbits.SPIBUSY); // blocking wait for end of transaction
    SS = 1; // deselect slave device, transmission complete
}

Since I called this function from the ISR in my code, I decided to make it an inline function to eliminate function call overhead.

In my test code, I just wanted to see how fast an output I can get. So I clocked the MCP4822 at 20MHz and tried to maximize the frequency of the output signal I generate: I used channel A to generate a sine wave output and channel B to generate a triangle wave output. I used a timer (Timer 1) to control the timing and in the ISR, I just called the writeDAC inline function to generate outputs as required from two pre-generated tables.

Here are the different waveforms and outputs I generated:

Fig. 4 - Generating the outputs with timer period = 400kHz, sine table entries = 64

Fig. 5 - Generating the outputs with timer period = 550kHz, sine table entries = 32

Fig. 6 - Generating the outputs with timer period = 550kHz, sine table entries = 64

Fig. 7 - SPI clock and data transmission

You can clearly see the SPI clock during transmission here. From the measurement panel on the right you can see that the SPI clock is 20MHz. There are also 16 pulses you can count - since a write command to the DAC consists of 16 bit transfers. CH2, on the bottom, shows the data being transmitted. Since the first signal (leftmost) is a 1, and since this corresponds to bit 15, this is a snapshot of data being transmitted to DAC channel B.

Fig. 8 - DAC steps - zoomed in

Fig. 9 - DAC steps - zoomed out

Fig. 10 - Hardware test setup

For the PIC32 proto board, I used my own custom proto board: http://tahmidmc.blogspot.com/2014/02/pic32-proto-board-details-schematic-pcb.html

Here are the header and source files for my test program:

config.h: https://drive.google.com/open?id=0B4SoPFPRNziHdk5KT2hWNUNCckE
main.c: https://drive.google.com/open?id=0B4SoPFPRNziHWFc0Y01qSW5XUkE

While this was a quick test I did to test the PIC32 SPI and the MCP4822, this is in no means a complete evaluation of the MCP4822. For example, I updated the DAC more quickly than I should have, to push for speed, as this didn't give enough of a settling time. However, I was satisfied with the results and so, stuck with that. I will do some further testing on this later.

For more details of the PIC32MX250F128B SPI module, refer to the datasheet and reference manual. For more details on the MCP4822, refer to its datasheet.

If you have any questions, feel free to ask. Let me know what you think, in the comments section below!

Note: Updated September 10, 2015

PIC32MX250F128B ipl7: odd shadow register set behavior and observations

2014-06-23T08:48:00.000-07:00

This issue has now been solved. Scroll to the bottom for the update.

I started working on a pure sine wave inverter based on the PIC32MX250F128B. The first stage was to just get the SPWM working and test that before proceeding to add the power stage, feedback and other control, etc.

This led me to some interesting observations regarding the PIC32MX250F128B interrupts, especially the use of the shadow register set and a related problem.

I set up Timer 2 to be the time base for sine wave generation (DDS/SPWM) using OC1. In the Timer 2 interrupt, the duty cycle update request is performed (OC1RS is updated). Timer 2 interrupt priority was set to 7.

This all worked fine. The initial ISR definition was:

void __ISR(_TIMER_2_VECTOR, ipl7) T2int(void) {
.....
}

However, when I used the ADC (input from potentiometer for amplitude control - a start at implementing feedback), accessing any of the ADC registers in the while (1) loop in main stopped the PIC32 from working.

I then added a line of code in main to continuously toggle RA0 (PORTA bit 0). This would stop when trying to access the ADC registers as well. (It worked fine if I removed the code that accessed the ADC.) This meant that the core was being stopped. So, I thought that it might be some kind of exception being thrown (?).

However, changing the timer 2 interrupt priority from 7 (which I had initially) to anything else fixes the problem. My guess was that something went wrong when the shadow register set was being used for interrupt priority level 7 (?).

So I did some more tests and came up with this:

The way I have the ISR defined initially selects the "AUTO" mode of selection where, I believe, the compiler decides whether to use the shadow register set or software for context save/restore.

Forcing the compiler to use the software context save/restore instead of the shadow register set seems to fix it:

void __ISR(_TIMER_2_VECTOR, ipl7SOFT) T2int(void) {
.....
}

I forced the shadow register set just to confirm:

void __ISR(_TIMER_2_VECTOR, ipl7SRS) T2int(void) {
.....
}

and sure enough it didn't work.

So, since it worked with ipl6, my guess was that for ipl6 (and for any ipl except 7), the compiler chooses software for AUTO, whereas for ipl7, the compiler chooses SRS.

So, I forced the shadow register set on ipl6:

void __ISR(_TIMER_2_VECTOR, ipl6SRS) T2int(void) {
.....
}

and sure enough, it didn't work.

Forcing software for ipl6 fixes it (as does AUTO).

I looked through the errata of the chip and couldn't find anything. (The errata is an interesting read.) I am also a little surprised since I did have ipl7 running fine previously. Maybe something weird happens with a certain combination of peripherals (?) that I unfortunately happened to use. I'll still see if I can find this documented, and I'll have to check whether an exception is thrown and if so, what type. If nothing else, at least it was a nice, albeit frustrating, lesson. Hopefully, it'll help someone else who might run into a similar problem.

UPDATE/SOLUTION: It turns out that the PIC32MX250F128B does not have a shadow register set, as mentioned in the datasheet. I seemed to have missed that while concentrating on the reference manual which talks about the shadow register set for the PIC32 series. Thus, from the point of view of my 'experiments', the lesson learnt could very well just be that when using ipl7, force the compiler to use software instead of the default AUTO mode (which may make the compiler try to use the shadow register set, which doesn't exist - explaining the problem I faced earlier).

---------------------------------------------------

DDS = direct digital synthesis

ipl = interrupt priority level

ISR = interrupt service routine

SPWM = sinusoidal pulse width modulation

SRS = shadow register set

Simple AC voltmeter

2014-06-17T11:27:00.001-07:00

I had long been thinking of designing a simple AC voltmeter but had somehow never gotten to it. However, with school just ending, and me going back to electronics, this was a neat simple yet useful circuit that I felt I could just get done with in a day or two.

The concept is fairly straight forward. Since I needed this only to measure the mains AC voltage and the output voltage of the sine wave inverter I was working on (based on the PIC32MX250F128B - more on this later), I didn't need to do any "true RMS" measurement. All I had to do was to convert the mains AC to DC, filter it and measure the peak voltage. Of course this had to be scaled down to a safe range for the microcontroller. The RMS voltage for a sine wave is equal to 0.707 (to 3 decimal places) the peak voltage.

The design was based on the Microchip PIC16F676. However I realized that I didn't have any in stock with me. So, I just used the pin-compatible PIC16F684. On the software side of things, the difference between the code for PIC16F676 and PIC16F684 is just one line. (See source file attached below.)

The variable resistor is adjusted so that the reading of my AC voltmeter matches that of a commercial voltmeter (Extech MA640 DMM). This is a sort of calibration.

CAUTION: THIS CIRCUIT IS NOT ISOLATED FROM THE MAINS AC AND HAS THE POTENTIAL TO BE LETHAL. YOU MUST BE VERY CAREFUL IF YOU ARE GOING TO USE THIS DESIGN. DO NOT ATTEMPT IF INEXPERIENCED. I CANNOT AND WILL NOT BE HELD RESPONSIBLE FOR ANY DAMAGE DONE WHILE USING THIS CIRCUIT.

Here's the schematic:

Fig. 1 - Voltmeter

Here are some pictures:

Fig. 2 - The PCB without (above) and with (below) the transformer

Fig. 3 - The test setup

Fig. 4 - Measuring voltage set with the variac

Fig. 5 - Measuring voltage set with the variac

Fig. 6 - Measuring voltage set with the variac

Fig. 7 - Measuring voltage set with the variac

C source file:
https://drive.google.com/file/d/0B4SoPFPRNziHdDB6cDdzNGZPdXc/edit?usp=sharing

http://www.4shared.com/file/Cz56s9Zlba/ACvoltmeter.html

mikroC project file:
https://drive.google.com/file/d/0B4SoPFPRNziHN2MydDRDalRWS1k/edit?usp=sharing
http://www.4shared.com/file/JwW3bpJNce/ACvoltmeter.html

Parts list (Excel XLSX file):
https://drive.google.com/file/d/0B4SoPFPRNziHb2ZCcnFNVnNpc2s/edit?usp=sharing
http://www.4shared.com/file/b_NcW4vdce/parts_list.html

Schematic (ARES DSN file):
https://drive.google.com/file/d/0B4SoPFPRNziHb1NFWDdwcWpJV2M/edit?usp=sharing
http://www.4shared.com/file/U6kPQH_rce/schematic.html

PCB (ARES LYT file):
https://drive.google.com/file/d/0B4SoPFPRNziHNDhhMDBkNFlnWW8/edit?usp=sharing
http://www.4shared.com/file/ZVczMJ7Wba/schematic.html

PCB (PDF files):
https://drive.google.com/file/d/0B4SoPFPRNziHMV9LdTBab1BXeDg/edit?usp=sharing
Mirrored: https://drive.google.com/file/d/0B4SoPFPRNziHSmxvT1pSbXBWOTA/edit?usp=sharing

It's a fun simple yet useful project that you can build pretty easily if you want. Let me know what you think in the comments section below!

A further study into the use of the PIC32MX250F128B, with side projects using the AT91SAM3X8E (Arduino Due) and the Intel Galileo

2014-05-22T23:15:00.005-07:00

Download PDF from:
http://www.4shared.com/office/kRJ8hVWPce/A_further_study_into_the_use_o.html