Gas station without pumps

2015 July 16

FG085 function generator bugs

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 17:50
Tags: , , ,

I previously reported on assembling the FG085 function generator kit and measuring its output impedance. I noted that the output impedance was only 46.7Ω, instead of 50Ω, and in Testing nFET body diode with function generator that the output current was limited to about ±5omA, which is ok for 50Ω at 5V peak-to-peak (±2.5V), but not enough when the maximum offset of 5V is added (or –5V, for that matter). I also complained about the buttons (particularly F/T and 0) needing to be pressed up from below, because the return springs weren’t strong enough to push the buttons back up.

I also noted in the first post that the cheap and noisy DAC had some bad glitches.  I decided to investigate that a bit more today, using the new version of PteroDAQ. The voltage calibration was reasonably good on the KL25Z board (about 0.28% too high), so I decided to use that one with 32× hardware averaging.

I set the FG085 function generator to 3.1V peak-to-peak and a 1.7V offset outputting a 1Hz upward ramp, and recorded for about 2 minutes (603882 samples). Looking at a couple of periods shows the glitches:

Glitches are observable in the traces caught by PteroDAQ.

Glitches are observable in the traces caught by PteroDAQ.

Although the glitches are visible, there seems to be some measurement noise. Indeed, zooming in makes the noise very evident:

The glitch at about the ¼ point is visible, but the discrete steps are hard to make out, being buried in noise.

The glitch at about the ¼ point is visible, but the discrete steps are hard to make out, being buried in noise.

I wrote a program (which I’ll be releasing after I do some more polishing on it, as part a suite of tools for analyzing data generated by PteroDAQ) to average copies of repetitive waveforms to reduce noise and get finer temporal resolution. This is similar to the code I wrote for dejittering the BitScope recordings, and I plan to merge the tools so that I don’t need two sets of software tools. Averaging 120 periods makes the waveform much cleaner—here are essentially the same two plots as above, but with the averaged waveforms:

Averaging the waveform reduces the noise.

Averaging the waveform reduces the noise.

After averaging the ¼-way glitch is very clear, and the discrete steps are easy to see and measure.

After averaging the ¼-way glitch is very clear, and the discrete steps are easy to see and measure.

Let’s also look at the top and bottom of the waveform, to see how well the voltage and period are set:

I synchronized the waveforms so that they passed downward through 2V at time=0.  The bottom voltage is approximately 64.44mV.

I synchronized the waveforms so that they passed downward through 2V at time=0. The bottom voltage is approximately 64.44mV.

The top voltage is approximately 3.25630V, and the period is approximately 1.00845s.

The top voltage is approximately 3.25630V, and the period is approximately 1.00845s.

The voltages were supposed to be 150mV and 3.25V, but instead came out as 64.44mV and 3.2563V. The top end is about right but the offset is 1.66V instead of 1.7V and the peak-to-peak voltage is 3.1919V instead of 3.1V. I don’t know if these are hardware errors (as the DAC nonlinearities are) or an off-by-1 error in the software that sets the peak-to-peak voltage.

The period being 0.845% too long is almost certainly a software error—the crystals aren’t that far off. It looks like they are almost exactly 2 steps off on the duration, as if they had added one instead of subtracted one from 256 somewhere. They claim a frequency error of at most 0.0005960 Hz when frequencies are below 40Hz, and the observed error is 14 times that. I am reasonably certain that the error is in the function generator, not PteroDAQ, since I get similar error when measuring with the BitScope digital oscilloscope.

The ¼-way glitch shown above is not the biggest one—the ½-way one is bigger:

The glitch at the midpoint is a transition downward of about 5 steps, instead of a transition upward of 1.

The glitch at the midpoint is a transition downward of about 5 steps, instead of a transition upward of 1.

I suspect that the error comes from not including the output impedance of the digital outputs in making their crude DAC, so that the resistor ladder is not properly balanced. But relying on digital output pins having carefully matched output impedances is a state of engineering sin.

Overall, the FG085 looks like a decent student project (maybe B work), but not the work of professional engineers.

Update 2015-Jul-16: Just a little after publishing this post, I checked the firmware release info on the FG085, and it seems that I don’t have the 113-08502-053 [ 2014.08.01 ]  release of the DDS core firmware which “Fixed a bug that caused frequency error when frequency setting is less than 40Hz.”  So now I have to figure out how to update the firmware.  The manual assumes that you have an AVR programmer, but I’ll be using an Arduino as ISP, which takes a while to look up and set up.

 

Update 2015-Jul-16 21:29:

I did the firmware upgrade, which took me much longer than I thought it would, because I had to install avrdude again, edit the ArduinoAsISP sketch to work with the Leonardo board, edit the avrdude.conf file to include m48p (it only had the m48, which has a different signature), and generally debug using the Arduino as an in-system programmer.  The command I ran that finally worked was 

avrdude -c avrisp -p m48p -P /dev/tty.usbmodem24141 -b 19200 -U flash:w:113-08502-053.hex -v -v -v -v

I recorded the waveform and now get a period of 1.0005 seconds, which is just within spec for the FG085.

With the up-to-date firmware the function generator now gets a period that is within space (they allow 596 ppm, and this is about 500ppm off).

With the up-to-date firmware the function generator now gets a period that is within space (they allow 596 ppm, and this is about 500ppm off).

2015 June 14

More on nFET Miller plateau

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 22:09
Tags: , , , ,

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

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.

2015 June 10

Update for nFET Miller plateau

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 22:47
Tags: , , ,

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.

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.

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

 

2015 June 8

Bitscope jitter and nFET Miller plateau

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 00:00
Tags: , , , ,

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.

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

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.

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

%d bloggers like this: