New dimmer software

Based on the success of the stroboscope software, I rewrote the dimmer software for my desk lamp (see LED lamp projects for more about the lamps).  The new software provides smoother control of the light levels (having 256 levels plus off, rather than 63 levels plus off) and now has a 256:1 brightness range rather than the approximately 256:6 range of the previous code.

I removed a lot of the general-purpose crap that was inherited from core13 (which was in turn stripped down from the Arduino core software).  I did not get rid of all of core13, so I could probably take out another 50–100 bytes, but the code is down to 222 bytes (and the ATtiny13A has 1kB of flash, so I’m way below the limit).

The actual brightness range of the new dimmer is a bit more than 256:1, because on the shortest pulse the FET doesn’t turn all the way on.  The pulse duration from the ATtiny13A is approximately 3.4µs times the brightness level (9.6MHz clock divided down by 4 and by 8), but I had deliberately slowed the FET transitions by adding a series resistor to the gate, so that nFET doesn’t finish turning on for 5.2µs (as judged by the end of the Miller plateau on the gate).  So at the lowest brightness level, the nFET does not turn all the way on and the voltage on the drain only gets down to 3.5V, which leaves 5.5V across the LED board—enough to turn on the LED, but with only about 10mA, not 118mA. At this low level, the LEDs sometimes flicker, perhaps as a result of some thermal feedback effects. The all flicker together, so the effect is probably in the dimmer’s nFET, not on the LED boards.

ATtiny output (green) and gate voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length. The gate voltage has not quite reached the end of the Miller plateau before being discharged again.

ATtiny output (green) and drain voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length. The BitScope BS-10 oscilloscope clips the voltage to 5.5V—it actually goes to 9V.

At the next brightness level, the drain voltage does drop to 0V for at least 2.4µs and stays low enough for the LED board to be at maximum current (below 2.5V) for at least 5.5µs.  There is an enormous difference in brightness between length 2 and length 1 pulses (more like 1:20 than 1:2), because of the low current for pulse length 1, but for length 2 and longer the steps in brightness are pretty much as one would expect from the pulse lengths.

ATtiny output (green) and gate voltage (yellow) at 2V/division and 2µs/division for the shortest pulse length. The gate voltage has gone past the end of the Miller plateau and started charging past that point. The Miller plateau is also visible on the discharge as the nFET turns off.

ATtiny output (green) and drain voltage (yellow) at 2V/division and 2µs/division for the second shortest pulse length. The BitScope BS-10 oscilloscope clips the voltage to 5.5V—it actually goes to 9V.
The longer pulses allow the nFET to turn on fully.

The conversion from the linear 10-bit analog-to-digital reading (0–1023) to pulse lengths is done by the following method:

expon = ADC>>7
frac = 0x80 + (ADC & 0x7f)
pulse_len = ADC < 0x20? 0:  ADC < 0x40? 1: 1+ (frac>> (7-expon))

The stepwise nature of the brightness at low levels is apparent in a plot of the conversion function:

The steps in brightness are quite visible at the low end, but after the first 10 steps, the differences are small enough not to be easily noticed.

Overall, I’m pleased with the rework of the dimmer code. I’ll probably have to solder up another of the dimmer boards this summer, since I’ll want one for the light fixture that I haven’t started building yet and one for the Halloween stroboscope.

More on nFET Miller plateau

In Bitscope jitter and nFET Miller plateau and Update for nFET Miller plateau I talked about using the Bitscope BS10 USB oscilloscope and post-processing to remove the trigger jitter to get a better trace of the Miller plateau when switching an AOI518 nFET.  I wasn’t entirely happy with that result, as I was using an external function generator (albeit a cheap Elenco FG500 box that puts out rather poor waveforms).  I thought I could do as well or better using a hysteresis oscillator to generate the square waves.

So I came up with the following circuit:

Test fixture for looking at the Miller plateau on the AOI518 nFET.

The top-left section, with the capacitors and the big inductor are just to keep the power supply clean. Because the power is coming from the 5V USB supply, passed through the Bitscope, any noise coupled back through the power supply can affect the readings, so I made sure that no high-frequency noise would be coupled back to the Bitscope that way.  One 4.7µF bypass capacitor (C6) is right next to the 74HC19N Vcc power pin on the breadboard and the other (C5) next to the emitter of the S9013 NPN transistor.  These helped in reducing ringing on the transitions of the square wave.

The Schmitt trigger U1 is the relaxation oscillator that oscillates at about 550kHz, and U2 buffers the output so that the load on the oscillator is constant.  R2 and C4 couple the output of the oscillator to the base of the NPN transistor Q2, which is configured as a common-emitter amplifier.

When Q2 is turned on, it sinks about 18.5mA of current (5V/270Ω), which at the nominal current gain of 120 for S9013 transistors, means about 150µA of base current. When Q2 is turned on it initially sinks even more current, discharging the gate  Q1 fast, but when Q2 is turned off, the gate is pulled up more gradually by the 270Ω resistor R1.  This gradual rise of the nFET gate voltage allows us to observe the Miller plateau when the nFET actually switches on.

The common-emitter amplifier using Q2 can switch very rapidly with no load, but adding the gate capacitance of Q1 makes the rise follow an RC charging curve. If the 150Ω load resistor R4 is omitted, the curve is smooth, as there is no voltage swing on the drain. Putting in R4 results in the drain voltage dropping rapidly when Q1 turns on, which is coupled back to the gate through the Miller capacitance, resulting in the Miller plateau.
These traces were gathered and dejittered separately (each is the average of over 500 traces). The time alignment was done by hand, and may not be completely accurate.

The initial rise in the drain voltage (from about -0.9 to -0.7 µs in the plot) is due to capacitive coupling of the rising gate voltage to the drain with the nFET off, and there is a similar overshoot at the lower end as the nFET is turned off (just before 0µs).

I played around quite a bit with the bias network R2 and C4 for the base of Q2. The resistor alone doesn’t work, as the base voltage remains a constant 340mV and the NPN transistor remains always on—I was a little confused by this, as the 340mV measurement on the Bitscope seemed too low to turn on an NPN transistor. I think that there is a calibration error on the Bitscope—according to my Kikusui COS5060 analog oscilloscope, the high voltage is about 600mV, which seems to be a more reasonable Vbe for a transistor that is on.

It seems that the offset that the Bitscope BS10 provides is inaccurate: I get a reading of 740mV for an offset of 2V, 1V, or 0V; 500mV with an offset of -1V; and 320mV with an offset of -2V or -3V.  Looking at the ground line with the same channel also shows an error for the -1V, -2V, -3V and -4V offsets (on the 11V range): -300mV for -1V, -560mV for -2V, -3V, and -4V. But those offsets are different from the ones I’m seeing with the oscillating base signal, so I suspect that it isn’t even a simple offset error.  This is bad—I’m going to have a hard time correcting such large and varying errors. I should probably ask the Bitscope technical staff whether large errors in the offsets are normal, or I have a damaged Bitscope BS10.  They’ve not made the schematic available, so I’m not sure what they are doing internally to provide the offset voltages.

The capacitor C4 alone also doesn’t work to bias the base, as the voltage on the base then doesn’t get high enough for  the NPN transistor to  turn on. With both the resistor R2 and the capacitor C4, the base swings about 5V, with the high value being the Vbe where the NPN transistor turns on. The resistor value is not critical—reducing R2 to 2kΩ moves the bottom end of the swing up a little, but seems to work just as well.  A very large resistor (100kΩ) seems to result in slow turn on for Q1.

The effect of changing C4 was not something I would have predicted—as I lower C4 (raising the corner frequency of the high-pass), I get a lot more ringing of the gate voltage, but faster transitions as well. I think that the faster transitions come from the base voltage not dropping as far below threshold when Q2 is off, so that it can rise above threshold sooner when Q2 needs to be turned on.

Smaller capacitors for C4 result in faster edges when turning on the NPN transistor, with more overshoot and ringing. Once the capacitance is large enough, there is little further change.

The curves above were synchronized by the setting 0µs at the upward transition past 4.0V, which seems to overlay the dejittered waveforms fairly well. Over 900 traces were averaged for each of the 5 curves.

I could also provide a DC bias current for Q2 by removing R2 and connecting the base via a 10kΩ resistor to the clean +5V supply. That seems to work just as well, but moves up the lower end of the base voltage swing, which may result in slightly faster turn-on of the NPN transistor.

It’s nice that I can use the Bitscope (with dejittering) to produce the Miller plateau figure for the textbook, but I’m concerned about the erroneous offsets on the Bitscope.  I’m wondering what else I’ve been relying on that is miscalibrated.

Update for nFET Miller plateau

In Bitscope jitter and nFET Miller plateau,  I gave a nice super-resolution plot of the gate voltage on an nFET using the Bitscope and subsequent dejittering of the trigger:

Here is an example of the Vgs voltage of an nFET transistor being driven by an S9013 NPN transistor and a 270Ω pullup (the NPN  base was driven by the square wave from my Elenco FG500 function generator, through a 2kΩ resistor). The drain of the nFET had an 8Ω loudspeaker to a 5V USB power line.

Keeping the power supply noise from propagating back to the Bitscope cleans up the signal considerably. The 10MHz ripple is now clearly visible. I tried zooming in with gnuplot and the resolution looks as good as on my 60MHz analog scope. The dejittering and averaging has made for a very fine signal.

But I didn’t give the schematic for the test jig.  So here it is:

Test jig for creating the Miller-plateau plot.

Something else I didn’t point out in the previous post: the quantization error is still visible in the slow-moving parts of the signal (at the beginning and near the top of the gate charging), but is essentially eliminated in fast-changing portions of the signal.  I think that the dejittering and averaging gets good values if the jitter is large enough to move the signal to value that would have a different quantized output, so we are averaging values that are sometimes too high and sometimes too low. But if the jitter doesn’t move the signal that far, then we’re relying entirely on voltage noise to change the quantized output and get averaged out, and the voltage noise seems to be much smaller than the step size of the analog-to-digital converter.

For the book, I might redo the plot using a comparator to drive the nFET, rather than the S9013 NPN transistor, though there is some advantage to leaving the comparator out of the picture, so that students will have to think a bit about their own design, rather than simply copying.

I might want to try slowing down the falling edge, so that Miller plateau is visible on both edges. I could slow down the fall by increasing the size of R2 (reducing the base current from 1.2mA and hence the collector current).  I could probably reduce the base current to 200µA and still switch the nFET off, since with a typical current gain of about 120 for the S9103, I should still be able to get a collector current of about 24mA, which is more than 5V/270Ω=18.5mA.  Even 100µA may be enough, but then the low voltage on the nFET gate may start creeping up, and we don’t want to leave the nFET partially on. (The same reasoning argues against adding a series resistor between the collector and the gate.)

The current through the S9013 seems to be much larger than available from the LM2903—maybe I should do current vs. voltage (Ic vs Vce) plots for the S9013 with various base-emitter currents, though the data sheet already has a nice plot of that.

I should probably also try using a resistor rather than a loudspeaker as a load, though the inductance of the speaker is helping to limit the current and avoid overloading the USB power supply.  With a simple 10Ω resistor,  I’d be getting 500mA, which is the USB limit. With the inductive load of the loudspeaker, the current builds up slowly when the nFET is on, and never gets close to what we’d expect from the nominal 8Ω value.

Another thing I might do is to use a hysteresis oscillator to drive the NPN transistor.  That would be more in keeping with the minimal-equipment approach I’m going to try to add to the book this summer.  (I might also play with a larger voltage for the loudspeaker, since that should give a larger swing on the drain voltage, and hence a clearer Miller plateau.)

 

Bitscope jitter and nFET Miller plateau

I got a little less than half my grading done this weekend (all the lab reports for the final lab, but not the redone reports from earlier labs, and not the 2–3 senior theses that had to be redone from last quarter) before I burned out.  I decided to do a little playing with my Bitscope USB oscilloscope, as a break from grading, and that sucked me in—I still haven’t gotten back to the grading.

Here is the problem I was addressing: In my book draft and in my blog post Third power-amp lecture and first half of lab, I presented a view of the Miller plateaus of an nFET, obtained by slowing down the transitions with series resistors and added gate-source capacitance, recording the result with my Bitscope USB oscilloscope, and averaging many traces together.

Here are the gate and drain voltages for an AOI518 nFET, slowed down by adding a series resistor to the gate signal and a large capacitor between the gate and drain. I slowed it down so that I could record on my low-speed BitScope USB oscilloscope—students can see high-speed traces on the digital oscilloscopes in the lab. The Miller plateaus are the almost flat spots on the gate voltage that arise from the negative feedback of the drain-voltage current back through the gate-drain capacitance.

I was rather unsatisfied with this approach, as I really want to show the full-speed transitions. In Power amps working, I showed some Tektronix plots, but their little screen images are terrible (as bad as the Bitscope screen images), and I can’t use them in the book.

With an 8Ω loudspeaker as a load, turning off the nFET (gate voltage in blue) causes a large inductive spike on the drain (yellow).

What is the fascination that scope designers have with black backgrounds? I know that the traditional cathode-ray-tube scopes gave no other choice, but for digital scopes black backgrounds are just evil —they don’t project well in lectures and they don’t print well on paper. It would be possible for me to use the data recording features of the Tektronix scopes, and plot the data using gnuplot, but I’d rather use the Bitscope at home if I can (much less hassle than transporting everything up the hill to the lab every time I need some more data).

The Bitscope B10 is capable of 20Msamples/s, which should give me decent time resolution, but the discretization noise is pretty large, so I want to average  multiple traces to reduce the noise. When using the “DDR” (DSO Data Recorder) option of the BitScope, it becomes very clear that they do not have any software engineers working for them (or didn’t at the time they defined the format for the recorder files).

The files are comma-separated values files, with no documentation (that I could find) of their content except the first line:

trigger,stamp,channel,index,type,delay,factor,rate,count,data

Each row of the file after that seems to have one trigger event, serially numbered in the first field, with a low-resolution time-stamp in the second field (hh:mm:ss, but no date and no finer time divisions).  The channel is 0 or 1, the index increments serially separately in each channel, the type is always 0, the delay is when the trace starts relative to the trigger (in seconds), the factor is always 1, the rate is the sampling rate (in Hz), the count is the number of data points, and the data is not a single field but “count” more fields. There is no other meta-data about the settings of the scope!

The data, unfortunately, is not the voltage measured by the scope, which is what one would naively expect.  Instead, you have to divide by the volts_per_division and add the offset voltage—neither of which are recorded anywhere in the data file! (You probably have to adjust for the probe as well, but I was using a 1X probe, so I can’t tell from this data.)

It is clear that the “engineers” who designed this format never heard of metadata—maybe they were used to just scrawling things on the backs of envelopes rather than keeping data around.  Yes, Bitscope designers, I am publicly shaming you—I like the Bitscope hardware well enough, but you are clearly clueless about data files! A correct format for the data would have had a block at the beginning of the file recording every setting of the scope and the full date and time, so that the precise conditions under which the data were recorded could be determined and used. (For example, was the RF filter on or off? what were the trigger conditions?)

I was able to read the DDR csv file and extract the data, but I found a number of other apparently undocumented properties of the B10.  If I switched away from post-trigger recording to having the trigger 25% or 50% of the way through the recording, the maximum sampling rate drops by a factor of 3 to 6.7MHz, so I need to use POST triggering, in which the recording starts about 1.25µs after the trigger. I can delay the part of the data I look at (only the part on the screen is saved), but if I delay too much, the sampling rate drops back down again.

One big problem is that the jitter on the Bitscope trigger is enormous—up to 150ns, which is 3 samples at the highest sampling rate. The image bounces around on the screen, and the data recorded in the files is similarly poorly aligned.

If I average a bunch of traces together, everything smooths out.  Not just the noise, but the signal as well! It is like passing the signal through a low-pass filter, which rather defeats the purpose of having a high sampling rate and averaging traces.

So today I wrote a program to do my own software triggering in a repetitive waveform. I recorded a bunch of traces that had the waveform I was interested in—making sure that the RF filter was off and the waveform was being sampled at the highest sampling rate. The program that read the csv file then looked in each trace for a new trigger event, interpolating between samples to get the trigger to much higher than single-sample resolution (by triggering on a fast rise, I can get about 0.1 sample resolution). I then resampled the recorded data (with 5-fold oversampling) with the resampling synchronized to the new trigger.  The resampled traces were then averaged.

Here is an example of the Vgs voltage of an nFET transistor being driven by an S9013 NPN transistor and a 270Ω pullup (the NPN  base was driven by the square wave from my Elenco FG500 function generator, through a 2kΩ resistor). The drain of the nFET had an 8Ω loudspeaker to a 5V USB power line.

The two traces on the right show a single trace (red) and an average of all the traces (magenta). Both of these are aligned by the Bitscope trigger event, which was substantially before the recording (much more than the minimum 1.25µs, as I’d deliberately delayed to get the next pulse).
The left-hand trace is also an average, but after retriggering on the first rising edge at 0.2v.
Note that the jitter in the trigger (and in the signal source) caused enormous rounding of the magenta curve, but retriggering to better than 5ns resolution allows the signals to be properly averaged.

The averaged plot is probably usable in the textbook. I also tried averaging the same traces triggering on the falling edge, to see if that got any more clarity for the ringing when the nFET is turned off, but it ended up looking essentially the same. On my Kikusui 60MHz analog scope, I see the little ripples after the downward transition (a 10MHz damped ripple), but I don’t see the hump in base line visible in the Bitscope trace.  I think that hump may be an artifact of taking too much power from the 5V USB line powering the Bitscope (or of coupling back of the inductive spike).

I tried putting in an LC filter on the 5V power line from the Bitscope (a 470µF capacitor to ground, a 200mH inductor, and another 470µF capacitor to ground).  This seems to have cleaned up the problem (this was hours later, and the frequency of the generator was almost certainly different, as I’d played with the tuning potentiometer several times):

Keeping the power supply noise from propagating back to the Bitscope cleans up the signal considerably. The 10MHz ripple is now clearly visible. I tried zooming in with gnuplot and the resolution looks as good as on my 60MHz analog scope. The dejittering and averaging has made for a very fine signal.

One problem with this retriggering approach is that it doesn’t really work with two channels—the Bitscope traces for the two channels are separate events, and the only synchronization information is the hardware trigger. I could get a clean Vgs signal and a clean Vds signal, but aligning them is not going to be any better than the jitter of the hardware trigger. I’ll have to think about averaging (or taking the median) of the trigger times relative to the hardware trigger, and using that to align the two traces.

Still, I wonder why the Bitscope designers have not taken advantage of the trigger jitter to do averages of repetitive traces—it allows one to reconstruct signals in software that are much higher bandwidth than the sampling rate of the scope.  These sorts of super-resolution techniques are pretty common, and it only requires better software, not new hardware.

I’ve been thinking that I might even try writing some software that talks directly to the Bitscope hardware (they have published their communication protocol), so that I can do things like capturing the data with full metadata and looking at it with decent plotting software (Matplotlib or gnuplot).  I’m not into doing GUI programming (an infinite time sink), so I’d probably write a Python library providing a application program interface to the Bitscope and a number of simple single-use programs (like capturing and averaging waveforms) with a configuration file or command-line arguments to set the parameters. Yet another thing to add to my to-do list (but near the end—there are many more important things to work on).

Power amps working

The power-amp lab went quite smoothly today—just about everybody got a class-D power amp working and a couple of groups wired their sup to a headphone plug and played music from their cell phones.  They were impressed at how loud the amplifiers were (though they were only producing about 4W of music, and their speakers could go to 10W or 15W, depending which model they got).

The biggest problems I saw in helping students debug was careless wiring—often because students had not bothered to make complete schematics including pin numbers and every power connection.  Connecting power up incorrectly was common.  Another common problem for students who did multi-sheet schematics (not recommended for such a small circuit), was having discrepancies at the boundaries between the sheets (like leaving out the high-pass filter needed for recentering the output of the pre-amplifier at the same voltage as the triangle wave).  A number of students got confused between the lowest power rail and ground (especially since the LM2903 data sheet calls the low power voltage to it GND, even though in the student schematics it was connected to the lowest power rail.

Despite my rather awkward lectures on the class-D power-amp, I think that the building and testing went smoother this year—perhaps because I tried having them do a crude-approximation-and-test approach to sizing the pull-up resistors.  I think that few groups ended up using the resistor sizes they started with.  Most had to make the nFET gate’s pull-up larger and the pFET gate’s pull-up smaller, to make the transistors turn off fast enough.  I’ll have to see if I can come up with some design guidance that will make the initial estimates closer, without complicating the design process.

I have to correct something I said yesterday in Last power-amp lecture—I did include a current-vs-voltage graph for the LM2903 comparator!  I need to rewrite the prelab to have them use that figure to compute their open-collector pull-up resistors: choose a desired low output voltage, figure out the current at that voltage, then use the voltage drop across the pull-up resistor to size the resistor.

I tried using the digital scope in lab today to get Miller plateau pictures without slowing down the transitions, and I recorded a few with the lower power rail at –6V, the upper power rail at +6V and a 330Ω pull-up resistor to 0V on the open-collector output:

Rising edge for the gate voltage with a 330Ω pullup to 0V from –6v.

Falling edge for the gate voltage with no load on the FET, from 0v down to –6v.

With an 8Ω loudspeaker as a load, turning off the nFET (gate voltage in blue) causes a large inductive spike on the drain (yellow).

Here is a detail of turning off the nFET, showing both the Miller plateau on the gate voltage (blue) and a large inductive spike on the drain (yellow).

The on-transition of the nFET shows the Miller plateau clearly in the gate voltage (blue), with a smooth transition in the drain voltage (yellow).

Unfortunately, these tiny little images were all the scope recorded, and they are too low quality as images to put in the book.  I’ll have to do it again sometime, with the scope downloading the data for me to plot properly.  Unfortunately, the download format is a 3.8Mbyte CSV file, which takes a long time for the scope to download to a flash drive (slow USB 1 speeds, I fear). I did not have the patience to do that today, together with writing scripts to ignore the meta data and plot just the real data.  I saved one file, which I’ll use for script writing, and some time later go back and record the transitions again.