# Gas station without pumps

## 2014 May 7

### Quiz corrections

Filed under: Circuits course — gasstationwithoutpumps @ 20:36
Tags: , , , , , ,

As I reported last week, students did poorly on the first quiz, which came as no surprise to me.  I had the students redo the quizzes as homework, allowing collaborative work (as long as they acknowledged the collaboration in writing).  They turned in the homework on Monday, a week after the quiz, and I returned them today.  No one aced the redo, with the top score being still only 25/33 (which would have been an A on the first pass, on a redo maybe a B+).

A lot of the students still seem to be having trouble with complex numbers—they got the formulas right when working symbolically, but then the exact same question with numbers instead of letters (which could be done by just plugging into the formulas) came out with real numbers when complex impedances were asked for.  Also, a lot of sanity checked were skipped (several people reported a battery as doubling in voltage when hooked up to a resistor, for example).

These students are not major mathphobes (they’ve all passed a couple of calculus classes and most have done more math past that), but they don’t seem to have any sense for reasoning with or about math—they just want to plug in and grind, even on simple problems like ratios in voltage dividers. This class has almost no memory work (I gave them a one-page handout at the beginning of the year with all the math and physics I was expecting them to memorize), but relies heavily on their being able to recognize how to apply those few facts.  This often requires subdividing a problem, like recognizing that a Wheatstone bridge is the difference between two voltage dividers, or that a 10× oscilloscope probe is a voltage divider with R||C circuits for each of the two impedances.

I spent the entire class today working through each problem in the quiz, to make sure that everyone in the class could understand the solution, and (more importantly) see that they did actually have enough knowledge and math skill to do the questions. Some of the students were feeling overwhelmed on the quiz, because they are not used to doing anything more than 1-step pattern matching for problems, and some of the quiz problems required two steps.  None of the quiz problems were as hard as the prelab they had to do this week, which involved 8 or more steps to get the resistor values to set the gain of the amplifier:

1. Determine the pressure level of 60dB sound in Pa.
2. Determine the sensitivity of the microphone in A/Pa:
1. Convert -44dB from spec sheet to a ratio
2. Get V/Pa sensitivity for microphone for circuit on spec sheet
3. Convert to A/Pa given resistance of I-to-V conversion resistor on spec sheet.
3. Determine voltages needed for op amp power supply.
4. Determine I-to-V resistor needed to bias microphone in saturation region.
5. Convert A/Pa sensitivity, RMS pressure level, and I-to-V resistor to RMS voltage out of microphone.
6. Determine corner frequency and R, C values for DC-blocking filter.
7. Determine maximum output voltage range of the amplifier as the most limiting of
1. Voltage range of op amp outputs
2. Power limits of loudspeaker (10W)
3. Current limit of op amp (which is a function of the power-supply voltage) into 8Ω loudspeaker
8. Determine max gain as ratio of RMS voltage into op amp and RMS voltage out of op amp (I’m allowing them to be a bit sloppy about RMS voltage vs amplitude, since we are not looking just at sine waves—the amplitude of a symmetric square wave is the same as the RMS voltage.)
9. Choose resistor values to give the desired gain.

I’m hoping that pushing them go through these multi-step designs in the lab will give them more practice at decomposing problems into smaller pieces, so that two-step problems on a quiz no longer seem daunting, but routine.

I’m going to be giving them another quiz in about a week, covering op-amp basics and the amplitude response of RC filters.  I’ve got to figure out the best time to do this—possibly a week from Friday, after they’ve done another op-amp lab (using a phototransistor to make a pulse monitor, using this handout).  I think I’ll reorder the labs after that, doing the pressure sensor instrumentation amp lab, then the class D power amp, then the EKG.

## 2014 April 26

### As expected, students did poorly on the quiz

Filed under: Circuits course — gasstationwithoutpumps @ 15:43
Tags: , ,

I gave about the same quiz as I did last year,  changing the numbers, removing one of the harder questions, and making sure that some of the other questions reflected worked examples we had done in class. The quiz was again on the 12th day of instruction. I had intended to move it to the 10th day, but one of the students was called out of town, so I rescheduled it so that everyone could take it at the same time.

I expected similar distribution to last year’s (last year the range was 3/32 to 12/32), but was hoping for slightly better.  I saw a distinct bimodal distribution this year, with half the class getting scores from 0/33 to 6/33 and the other half getting 11/33 or 12/33. This is a little clearer distribution than last year’s, which spread the students out more uniformly. I was still hoping that some of the better students would get over half the points on the quiz, but they seemed to top out at 36%.

I worked this year’s quiz myself in about 24 minutes (which means the quiz was a little too long still—I want about a 3:1 ratio on time, and the students had only 70 minutes).

I was really depressed after last year’s quiz, because I had not been expecting such dismal performance. This year I was braced for it, but still hoping for better.  Still there were some surprises:

• There were a few questions that should have been free points (like asking for the impedance of a resistor with resistance R)—I was disappointed that some students missed even the trivial questions.
• I had a pair of questions which were identical, except that one asked for algebraic formulas for impedance and the other gave component values and asked for numbers. I put the algebraic ones first this year, so the numeric ones were just a matter of plugging the numbers into the algebraic ones (and doing a sanity check).  The algebraic ones had a mean score of 2/4 with a standard deviation of 1.2, while the numeric ones had a mean of 1.22/4 and a standard deviation of 1.2.  I had not expected a drop in performance on the numeric ones, since the received wisdom in the physics education community is that students do better with numeric examples than algebraic ones.
• No one got any points on the oscilloscope probe example, even though it was identical to an example we had worked in class.
• The average score on a load-line problem was 1/6 with a standard deviation of 1.3.  This did not look like a normal distribution, but an exponential one, with half the class getting no points.
• I had two low-pass RC filter questions. One asked for algebraic formulas; the other used the same circuit but asked for numeric answers using specific component values, voltages, and frequencies. The algebraic one was bimodal, with 2/3 of the class getting 0 and 1/3 getting the answers completely right. The numeric one was significantly worse, with only 2 out of 9 students getting any points (1/6 and 3/6).
• I asked a couple of voltage divider questions that required applying the voltage divider formula circuits in which the voltmeter was connected between two nodes, neither of which was ground.  One asked for an algebraic results (a Wheatstone bridge), the other for a numeric result (voltage across the middle resistor of three in series. Students did very poorly on both,  with only one person getting the voltage for the middle resistor (one got half credit for setting it up right, but computing wrong), and no one getting more than 1/5 for the Wheatstone bridge.

Last year I suggested several ways to handle the poor performance on the first quiz:

1. I could tell them to study and give them another quiz.  That would be totally useless, as it would just repeat the problems on this quiz.  They don’t know what it is that they need to know, and vague exhortations to study are pointless.  I don’t think the problem is lack of effort on their part, and that’s the only problem for which pep talks are a potential solution.
2. I could go over the quiz question by question, explaining how I expected students to solve them.  This is classic lecture mode and the approach I used to use. It would be easy to do, but I doubt that it would help much.  I already did an interactive lecture on the material, and another approach is now needed.
3. The students could get the quiz back and be told to go home and look up in their notes and on-line anything they did not get right.  They would find and write down the right answers, as if this were homework.  (This “quiz correction” is a standard strategy in high school teaching, but not common in college teaching.)  One difficulty here is that they might be able to find answers (say by copying from other students in the class) without understanding how to do the problems.  It is probably a better approach than yet another lecture, but I’m not sure it will work well enough.  If the students were trying to get from 80% understanding to 95%, it might be fine, but to get from 30% to 80%, something more directed is needed.  More time and open notes would help, but maybe not enough.
4. I could break them into groups and give each group a couple of the problems to work on together in class. This peer instruction technique would be a good one if about 1/2 the students were getting the problems right, but with the top of the class getting only 1/3 right, I may need to give them more guidance than just setting them loose.  For example, on some of the problems there was a fundamental misreading of the circuit schematics that was very common. I could clear up that misunderstanding in a minute or so and have them rework the problems that depended on it.  Then I could send them home to write correct solutions.
5. I could give out lots of problem sets to drill them on the material.  Of course, since it took me more than all day Sunday to make an 8-question quiz, it would take me forever to generate enough drill problems to be of any use.

I feel the same way this year about the possible teaching strategies, but this year I’m going to try a mix of methods 3 and 4, asking them to redo the quizzes at home, working with others until they are satisfied that they can now do the problems and other similar problems when asked.  I’ll have them hand it in this year as a homework, but not go over it in class until after they turn it in.  They need to take a more active role in trying to master the material, and not rely so much on my telling them what to do.

Monday we’ll cover inductors and loudspeakers, in preparation for the Tuesday measurement lab.

On Wednesday I was planning to do gnuplot analysis of the loudspeaker data, but I think I’ll keep that fairly short, so that we can get an intro to sampling and aliasing also before Thursday’s lab.  I have to decide whether to bring in my son’s stroboscope and a moving object to demonstrate aliasing.

Friday, I’ll introduce op amps, with the intent of developing the block diagram in class on Monday for a simple op amp microphone circuit for the Tuesday lab.  This weekend I need to rewrite that lab from last year—I decided last year to use the dual power supply with a center ground for their first op-amp design, rather than having them build a virtual ground (we’ll get that in the next lab assignment).

## 2014 April 7

### Feedback on first lab report

Filed under: Circuits course,Printed Circuit Boards — gasstationwithoutpumps @ 17:11
Tags: , , , , ,

Most of today’s class was taken up with feedback on the design reports that students turned in by e-mail on Saturday.  Overall the reports were not bad (better than the first reports last year), but I think that the students could do better.  Here are the main points:

• Anyone can redo the report to get it re-evaluated (and probably get a higher grade).
• No one attempted theV1 &V2 problem, so I reassigned it for Wednesday.

The circuit I had given as an exercise, asking them to determine the output voltage V_out.

• A lot of reports mixed together two different problems:the 1kΩ–3.3kΩ problem and the optimization to maximize sensitivity of the thermistor temperature sensor.  I encouraged students to use more section headers and avoid mixing different problems together.
• Figures should be numbered and have paragraph-long captions below each figure.  I reminded students that most engineering reports are not read in detail—readers flip through looking at the pictures and reading the picture captions. If the pictures and captions don’t have most of the content, then most readers will miss it. I also pointed out that many faculty, when creating new journal articles, don’t ask for an outline, but ask for the figures.  Once the figures tell the right story, the rest of the writing is fairly straightforward.
• A lot of the students misused  “would” in their writing, treating as some formal form of “to be”. The main use in technical writing is for contrary-to-fact statements: “the temperature would go down, if dissipating power cooled things instead of heating them”.  Whenever I see “would” in technical writing, I want to know why whatever is being talked about didn’t happen.
• A number of the students had the correct answer for the optimization problem, but had not set up or explained the optimization. Right answers are not enough—there must be a rational justification for them. In some cases, the math was incomprehensible, with things that weren’t even well-formed equations. I suspect that in many cases, the students had copied down the answer without really understanding how it was derived and without copying down the intermediate steps in their lab notebooks, so they could not redo the derivation for the report.
• A number of the plots showed incomplete understanding of gnuplot: improperly labeled axes, improperly scaled axes, plots that only included data and not the models that the data was supposed to match, and so forth. I pointed out the importance of sanity checks—there was no way that anyone ran their recording for 1E10 seconds! I was particularly bothered that no one had plotted the theoretical temperature vs. voltage calibration based on the parameters from their temperature vs. resistance measurements, so I could not tell whether the voltage divider was doing what they expected it to.
• No one really got the solution for the 1kΩ–3.3kΩ problem perfectly. A number of them set up the equations right and solved for R (getting 2.538kΩ), but then not figuring out what Vin had to be.  It turns out that Vin depends strongly on R, so rounding R to 2.2kΩ or 2.7kΩ results in different good values for Vin, and the 2.2kΩ choice gives a more desirable voltage (around 3.3v, which we have available from the KL25Z boards, as it is a standard power-supply voltage).

I also showed the students how I had expected them to setup and explain the optimization to maximize sensitivity at a particular operating temperature.

After that feedback, I started on new material, getting the explanation of amplitude, peak-to-peak, and RMS voltage. I think that the RMS voltage explanation was a bit rough.  I was deriving it from the explanation that we wanted a measurement that represented the same power dissipation in a resistor as the DC voltage, and I got everything set up with the appropriate integrals, but I forgot the trig identity $(cos(\omega t))^2 =\frac{1}{2} (1-cos(2 \omega t))$, and ran out of time before I could get it right.  I did suggest that they look up the trig identity and finish the integration.

I had hoped to get at least partway into Euler’s formula, complex sinusoids, and phasors, but the feedback took longer than I had expected. Those topics will have to wait until Wednesday or even Friday, since Wednesday we’ll want to do the modeling of the DC characteristics of the electret mic, and talk about how the mic works.

## 2014 April 5

### Hysteresis lab on KL25Z

Relaxation oscillator used in the hysteresis lab. The “variable capacitor” in this schematic is a person’s finger and a touch plate made from aluminum foil and packing tape.

I spent today writing code for the KL25Z board to act as a period or frequency detector for the hysteresis lab, where they build a relaxation oscillator using a 74HC14N Schmitt trigger inverter and use it to make a capacitance touch sensor (pictures of last year’s setup in Weekend work). I had written code for the Arduino boards last year, and I started by trying to do the same thing on the KL25Z, using the MBED online development system.  The Arduino code used “PulseIn()” to measure pulse duration, and the MBED system does not have an equivalent function.  I could have implemented PulseIn() with a couple of busy waits and a microsecond-resolution timer, but I decided to try using “InterruptIn” to get interrupts on each rising edge instead.

The basic idea of last year’s code (and the first couple versions I wrote today) was to determine the pulse duration or period when the board is reset, finding the maximum over a few hundred cycles, and using that as a set point to create two thresholds for switching an LED on or off. I got the code working, but I was not happy with it as a tool for the students to use.

The biggest problem is that the touch plate couples in 60Hz noise from the user’s finger, so the oscillator output signal is frequency modulated.  This frequency modulation can be large compared with the change in frequency from touching or not touching the plate (depending on how big C1 is), so setting the resistor and capacitor values for the oscillator got rather tricky, and the results were unreliable.

I then changed from reading instantaneous period to measuring frequency by counting edges in a 1/60th-second window.  That way the 60Hz frequency modulation of the oscillator gets averaged out, and we can get a fairly stable frequency reading.  The elimination of the 60Hz noise allows me to use less hysteresis in the on/off decision for the LED, making the touch sensor more sensitive without getting flicker on transitions. The code worked fairly well, but I was not happy with the maximum frequency that it could handle—the touch sensor gets more sensitive if C1 is small, which tends to result in high frequency oscillations. The problem with the code was that MBED’s InterruptIn implementation seems to have a lot of overhead, and the code missed the edge interrupts if they came more often than about every 12µsec.  Because I was interrupting on both rising and falling edges, the effective maximum frequency was about 40kHz, which was much lower than I wanted.

To fix the frequency limitation, I replaced MBED’s InterruptIn with my own interrupt service routine for PortD (I was using pin PTD4 as the interrupt input). With this change, I could go to about 800kHz (1.6e6 interrupts per second), which is plenty for this lab.  If I wanted to go to higher frequencies, I’d look at only rising edges, rather than rising+falling edges, to get another factor of two at the high end.  I didn’t make that change, because doing so would reduce the resolution of the frequency measurement at the low end, and I didn’t think that the tradeoff was worth it here.

The code is now robust to fairly large variations in the oscillator design.  It needs a 20% drop in frequency to turn on the green LED, but the initial frequency can be anywhere in the range 400Hz–800kHz.

To make it easier for students to debug their circuits, I took advantage of having an RGB LED on the board to indicate the state of the program: on reset, the LED is yellow, turning blue once a proper oscillator input has been detected, or red if the oscillator frequency is not in range. When the frequency drops sufficiently, the LED turns from blue to green, turning back to blue when the frequency goes up again.

For even more debugging help, I output the frequency that the board sees through the USB serial connection every 1/60th second, so that a program like the Arduino serial monitor can be used to see how much the frequency is changing.  I took advantage of that feature to make a plot of the frequency as the touch sensor was touched.

Plot of frequency of hysteresis oscillator, as the touch pad is touched three times. Note that the thresholds are very conservatively set relative to the noise, but that the sensitivity is still much higher than needed to detect the finger touches.

Overall, I think that the code for the KL25Z is better than what I wrote last year for the Arduino—now I have to rewrite the lab handout to match! I actually need to update two lab handouts this weekend, since week 3 will have both the hysteresis lab and the sampling and aliasing lab. Unfortunately, the features needed for those labs (trigger on rising and falling edges and downsampling) are not working in PteroDAQ yet.

Here is the code that I wrote for the frequency detector:

// freq_detector_own_isr
// Kevin Karplus
// 2014 Apr 5

// This program is intended to be used as a "capacitive touch sensor"
// with an external relaxation oscillator whose frequency
// varies with the capacitance of a touch.

// The program expects a periodic square wave on pin PTD4 with a frequency between
// about 400Hz and 800kHz. (LOW_FREQ_LIMIT and HIGH_FREQ_LIMIT).
// On reset, it displays a yellow light, then measures the frequency to store as the "off" frequency.
//
// If the frequency is out of range (say for a disconnected input), then the light is set to red,
//     and the off frequency checked again.
// Otherwise the LED is turned blue.
//
// After initialization, if the program detects a frequency 20% less than the initial freq,
// it turns the light green,
// turning it blue again when the the frequency increases to 90% of the original frequency.
//
// No floating-point is used, just integer arithmetic.
//
// Frequency measurements are made by counting the number of rising and falling edges
// in one cycle of the mains frequency (1/60 sec), giving somewhat poor resolution at lower
// frequencies.
// The counting time is chosen to that frequency modulation by the mains voltages is averaged out.
//
// This version of the code uses my own setup for the interrupt service routine, because InterruptIn has
// too much overhead.  I can go to over 800kHz (1.6e6 interrupts/second) with this setup,
// but only about 40kHz (80e3) interrupts/sec with mbed's InterruptIn.

#include "mbed.h"

#define PCR_PORT_TO_USE (PORTD->PCR[4])   // pin PTD3 is the pin to use

#define MAINS_FREQ (60)     // frequency of electrical mains in Hz
#define COUNTING_TIME (1000000/MAINS_FREQ)   // duration in usec of one period of electrical mains

// off_frequency must be between LOW_FREQ_LIMIT and HIGH_FREQ_LIMIT for program to accept it
#define LOW_FREQ_LIMIT (400)
#define HIGH_FREQ_LIMIT (800000)

// on-board RGB LED
PwmOut rled(LED_RED);
PwmOut gled(LED_GREEN);
PwmOut bled(LED_BLUE);
#define PWM_PERIOD (255)  // for the on-board LEDs in microseconds

// Set the RGB led color to R,G,B  with 0 being off and PWM_PERIOD being full-on
void set_RGB_color(uint8_t R, uint8_t G, uint8_t B)
{
rled.pulsewidth_us(PWM_PERIOD-R);
gled.pulsewidth_us(PWM_PERIOD-G);
bled.pulsewidth_us(PWM_PERIOD-B);
}

// InterruptIn square_in(PTD4);
volatile uint32_t edges_counted;

uint32_t low_freq_threshold, high_freq_threshold;  // thresholds for detecting frequency changes

extern "C"{
// interrupt routine that counts edges into edges_counted
void PORTD_IRQHandler(void)
{
edges_counted++;
}
}

// return the frequency for the square_in input in Hz
uint32_t frequency(void)
{
PCR_PORT_TO_USE &= ~PORT_PCR_IRQC_MASK;  // disable interrupts on pin PTD3
edges_counted=0;
PCR_PORT_TO_USE |= PORT_PCR_ISF_MASK | PORT_PCR_IRQC(11);  // clear interrupt for PTD3, and enable interrupt on either edge
wait_us(COUNTING_TIME);
PCR_PORT_TO_USE &= ~PORT_PCR_IRQC_MASK;  // disable interrupts on pin PTD3
uint32_t freq=edges_counted*MAINS_FREQ/2;
return freq;
}

int main()
{
rled.period_us(PWM_PERIOD);
gled.period_us(PWM_PERIOD);
bled.period_us(PWM_PERIOD);
set_RGB_color(255,255,0);   // set light to yellow

SIM->SCGC5 |= SIM_SCGC5_PORTD_MASK; // make sure port D has clocks on
PCR_PORT_TO_USE &= ~PORT_PCR_MUX_MASK;  // clearing the MUX field
PCR_PORT_TO_USE |= PORT_PCR_MUX(1);     // Setting pin as GPIO
FPTD->PDDR &= ~ (1<<4);  // make sure pin is input pin
NVIC_EnableIRQ(PORTD_IRQn);            // enable interrupts for port D

__enable_irq();

uint32_t off_frequency= frequency();
while ( off_frequency<low_freq_limit ||="" off_frequency="">HIGH_FREQ_LIMIT)
{   // timed out.  set color to red and keep trying
set_RGB_color(255,0,0);
printf("FREQ out of range: %luHz\n", off_frequency);
off_frequency= frequency();
}

uint32_t low_freq= 8*off_frequency/10;  // 80% of off_frequency
uint32_t high_freq= 9*off_frequency/10;  // 90% of off_frequency

printf("off= %luHz lo_thresh=%luHz hi_thresh=%luHz\n",off_frequency, low_freq, high_freq);
while(1)
{   uint32_t freq=frequency();
printf("%lu Hz\n",freq);
if (freq < low_freq)
{   // low_fequency found, turn LED green
set_RGB_color(0,255,0);
}
else if (freq >= high_freq)
{   // high frequency found, turn LED blue again
set_RGB_color(0,0,255);
}
}
}


## 2014 April 4

### Third day of circuits class was low key

Filed under: Circuits course,Printed Circuit Boards — gasstationwithoutpumps @ 21:34
Tags: , , ,

Today’s class was not content-rich, but a low-key decompression after yesterday’s too-long lab.

I started out taking some questions from the class, which were mainly about what to do in the design report.

I then discussed my ideas about what had gone wrong with yesterday’s lab that made it take so long, and both how I planned to fix the problem next year, and what we could do as a class to keep it from happening again this year. I particularly stressed the importance of doing the pre-lab work early, so that they could ask questions in the lecture portion of the class, rather than taking up valuable lab time. I also suggested that they do the writeups for the Tuesday lab before Wednesday’s class, so that they would have much less to write up after the Thursday lab—making the Friday deadline for the writeup feasible.

I asked the students for their ideas about what were problems with the lab, and they agreed that the soldering and installing PteroDAQ software took up almost 2 hours, so it would be best to separate that into its own lab period. They also brought up their frustration with the design problems I had given them: not so much the optimization for the lab, but the design exercise I had added: Design a circuit to convert a 1kΩ–3.3kΩ variable resistance sensor to a 1v–2v voltage output, with 1v for the 1kΩ resistance and 2v for the 3.3kΩ resistance. Use standard resistor values that you have in your kit. They were frustrated because they did not know how they were supposed to approach the problem.

This gave me an opportunity to explain what I was trying to do with problems like that. It was indeed entirely appropriate that they should have been uncomfortable with the problem, because I was trying to push them to think in new ways—to handle problems that were not completely laid out for them ahead of time, but where they had to struggle a bit to figure out how to formulate the problem. This is precisely what engineers have to do—to take problem statements that may be unclear or not precisely solvable, figure out how to formulate them more precisely, set up equations, solve them, check that the design they come up with makes sense, and (often) adjust the problem statement to reflect what is actually doable.  (I didn’t say it, but in this case you have to accept a few percent error in the output voltage or the resistances in order to use standard values.)  I promised them more uncomfortable problems in future, in an attempt to stretch them.  They seemed a little more at ease with the difficulty they’d been having, once they realized that this was expected—I think some had been afraid that they were in over their heads and were panicking.

Another student mentioned having heard of an analogy between programming and engineering. I pointed out that programming was a form of engineering, and that all engineering required identifying problems, breaking them into subproblems, and solving the subproblems.  Programming tends to involve many, many subproblems, with formal interfaces between them, but even the simple hardware we’d do in this course involves breaking problems into subproblems, using block diagrams (which I promised to talk more about later in the course).

Somewhere in the discussion of what engineers do, I brought up the example of the student who had presorted his resistors and taped them into a booklet.  What the student had done was to identify a problem (that it would be hard to find the resistors he needed), come up with a solution, and implemented it. I pointed out that the technology he used (scotch tape) was available to them all, as was the notion of sorting. The engineering thinking comes in looking at something unpleasant (finding a sheet of resistors in a pile of 64 different sizes) as a design problem to solve, rather than something to get irked about or try to avoid. I’m hoping to get them thinking more like engineers during the course of the quarter—anticipating problems and looking for ways to solve them.

Generic voltage divider circuit.

I took more questions from the class—there were a few about voltage dividers, which I explained again in a different way, using analogies to similar triangles and giving them the voltage divider formula in the form $I = \frac{V_{out}}{R_{1}} = \frac{V_{in}}{R_{1}+R_{2}}$.  I did not give the voltage divider in the “ground-reference” format shown to the left, but drew lines out horizontally from the nodes, and had the voltages indicated as distances between the lines (like in a mechanical drawing), to give them a more visual representation of voltages as differences.  I also had them figure out what the voltage across R2 would be and how it would relate to the other voltages.

The more different ways they work with voltage dividers, the better they will internalize the concepts and be able to use them in designs.

The circuit I had given as an exercise, asking them to determine the output voltage V_out.

The circuit with explicit sources and voltmeter implied by the circuit I had given them.

A question also came up about what it meant to have 2 input voltages with no ground shown in a circuit (as I had given them as an exercise in the first lab handout).  That is an excellent question—one that uncovered an assumption I had been making that I had never explained to them! I explained that what an “input voltage” meant was shorthand way of drawing two voltage sources.

I’ll have to fix the handout next year to include this explicit explanation of a common shorthand—I’ve used it for so many decades that it simply hadn’t occurred to me that it wasn’t obvious. I apologized to the class for having skipped the explanation, and pointed out the importance of them asking questions, because otherwise I would never know where some omission like this was confusing them unnecessarily.

When they ran out of questions, I got in some new material, explaining the difference between “precision”, “repeatability”, and “accuracy”. The digital thermometers they used in lab were a good example—they had a precision of 0.1°C, were repeatable within a single thermometer to about ±0.2°C, but between thermometers were repeatable only to about ±2°C. The accuracy is unknown, since we did not have anything traceable to a temperature standard, but the ice water baths should have been close to 0°C, so the thermometers we used on Thursday were probably less than 1°C off, but the larger set we used on Tuesday included some that were 3°C or 4°C off. In the repeatability part of the talk, I managed to bring in the biologists’ notion of technical replicates (different measurements of the same sample) and biological replicates (different cultures or tissue samples), and why biological replicates show less repeatability.

I also used this as a chance to talk about the uselessness of ±0.1°C or error bars without an explanation of what the range means (standard deviation, 90% confidence interval, 3σ, 5σ, observed range, …), and the even greater uselessness of “significant figures” as a way of expressing uncertainty.  I told them that I’d rather see 1.031±0.2 than 1.0 as a way of expressing the uncertainty in a measurement.

Towards the end of the 70-minute period, I got in a little discussion of AC voltages as time-varying voltages, and that we usually did analysis in terms of simple sinusoids, rather than the complex waveforms that we’d actually be measuring. I did assure them that, though there was a lot of mathematical machinery (Fourier analysis) that justified this way of doing things, the math was outside the scope of the class and I’d only be giving them intuitive ways of working with AC. I only got as far as giving them amplitude—telling them that I’d start with RMS voltage next time. (I’d originally hoped to explain RMS voltage today, but that would have taken another five minutes, and we were already 3 minutes over.)

Overall, I was fairly pleased with how today’s class went—the students are getting more comfortable asking questions and I’m getting a better sense of what they already know and what they need explained.  Undoubtedly I’ll make more mistakes like not explaining the “hidden voltage source at inputs” convention, but I think we’ll recover from such mistakes a little quicker each time, as the students get more confident in asking for clarification.

Next Page »