# Gas station without pumps

## 2014 June 26

### Instrumentation amp from op amps still fails

Filed under: Circuits course — gasstationwithoutpumps @ 17:02
Tags: , , , ,

I’ve been trying to decide whether to have students build an instrumentation amp out of op amps in the circuits course.  Currently the INA126P instrumentation amp chip that I have them use is a black box to them, even though I include an explanation on the lab handout showing how it is internally a pair of op amps and 4 resistors:

Internally, the INS126P instrumentation amp is two op amps and 4 resistors.

I won’t repeat that presentation here (there’s a condensed, early version of it in a previous blog post).  I’ve not actually lectured on the 2-op-amp design before the instrumentation-amp lab, in class, though I did manage to talk about the 3-op-amp instrumentation amp this year (a waste of time, since they did not really process the ideas).

What I was interested in today was whether the pressure-sensor lab could be done entirely with op amps, rather than with the more expensive INA126P chip.

I decided to design an amplifier with a gain of around 200 and an output reference voltage around 0.5 v (based on a 3.3v supply), using the 2-op-amp design and MCP6004 op amps. Here is what I came up with:

This is the design I came up with and built. It works, sort of.

The amplifier amplifies and seems to have about the right gain, but there is a large DC offset on the output: about 0.24V, which translates to an input offset of about 1.2mV. I checked with a multimeter, and the negative-feedback voltages are indeed about that far apart, while the inputs from the pressure-sensor bridge are less than 40µV apart. The pressure sensor sensitivity is about 80µV/kPa/V, or 264µV/kPa with a 3.3V supply. If I use the pressure sensor with a blood-pressure cuff, I’ll want to go up to about 180mmHg or 24kPa, so the sensor output should be in the range 0–6.3mV. An offset of 1.2mV is huge!

If I remove Rgain from the circuit, the output offset drops to 20.88mV, which is 1.1mV referenced to the input (close to the 1.22mV measured at the negative feedback inputs).  Further removing R2 or R4 does not change the voltage difference between the negative-feedback inputs.  In fact removing all three of Rgain, R2, and R4, so that we have two unity-gain buffers (with 180kΩ and 10kΩ feedback resistors), still leaves the negative feedback points 1.22mV apart.  Each seems to be about 0.6mV from the corresponding positive input.

The problem is that the input offset voltage of the MCP6004 op amps is only guaranteed to be between –4.5mV and +4.5mV:  I’m lucky that the input offset voltage is under 1mV!  Even the INA126P instrumentation amps that we’ve been using have an input voltage offset of up to 250µV (150µV typical). One can obviously get better instrumentation amps, but the selection in through-hole parts is limited, and I’d have to go to an instrumentation amp costing \$4.25  (LT1167CN8#PBF) instead of \$2.68 to get the input offset voltage down to 20µV.

I’m going to have to rewrite the section of the book on instrumentation amps, to discuss (at least briefly) offset voltages.  I had originally thought that that the signals we were looking at were big enough that the offset voltages didn’t matter. For the INA126P, a 150µV offset would be about 0.6kPa, while the 1.22mV offset I was seeing in my homemade instrumentation amp would be about 4.6kPa.

I wonder also whether I can make an EKG circuit using this 2-op-amp instrumentation amp circuit.  The EKG already has to deal with potentially large input voltage offsets due to differing electrode-skin contacts.  In fact those offsets may be over100mV, far larger than the 1.2mV from the amplifier.  I’ll have to add another stage of amplification (after a high-pass filter), but that shouldn’t be a problem. I looked at this problem a year ago in 2-op-amp instrumentation amp and Common-mode noise in EKG, and concluded then that common-mode noise would be too large, but I’m tempted to try again, using the design here with gain 19 and a second stage with a gain of around 80 (for a combined gain around 1520), as last year I rejected the idea before actually building the circuit.

## 2014 June 1

### Blood pressure monitor

I thought of a new variant on the pressure sensor lab for the circuits course: a blood pressure monitor.  I happen to have a home blood pressure monitor with a cuff and squeeze bulb that can be detached from the monitor and hooked up to the MPS2053 pressure sensor instead.  With this setup and an instrumentation amp, I can easily record the pressure in the cuff and observe the oscillations in the cuff pressure that are used for oscillometric blood pressure measurement.

Cuff pressure measurements using an MPX2053DP sensor, and instrumentation amp, and a KL25Z microcontroller board running PteroDAQ software.

The fluctuations can be observed by removing a baseline (fitting an exponential decay to the dropping pressure, for example, and the subtracting it out) or by using some sort of digital filter. I tried using a 0.3Hz–6Hz bandpass filter (4th order Bessel filter, applied using scipy.signal.filtfilt):

Oscillations corresponding to the pulse are very visible when the slow pressure decay is filtered out. I’ve zoomed in on just the time of the dropping pressure, marked with lines on the previous plot.

The pulse is very easy to see (about 40.4bpm in this sample—low even for me), but figuring out the systolic and diastolic pressure from the fluctuations is a bit messy:

The oscillometric method of measuring blood pressure with an automated cuff yields valid estimates of mean pressure but questionable estimates of systolic and diastolic pressures. Existing algorithms are sensitive to differences in pulse pressure and artery stiffness. Some are closely guarded trade secrets. Accurate extraction of systolic and diastolic pressures from the envelope of cuff pressure oscillations remains an open problem in biomedical engineering.
[Charles F Babbs, Oscillometric measurement of systolic and diastolic blood pressures validated in a physiologic mathematical model, BioMedical Engineering OnLine 2012, 11:56 doi:10.1186/1475-925X-11-56 http://www.biomedical-engineering-online.com/content/11/1/56]

One shortcut is to find the maximum amplitude of the envelope of the oscillations, and look at the pressures at fractions of the amplitude:

However, it has been shown that the pressure, Pm, at which the oscillations have the maximum amplitude, Am, is the mean arterial pressure (MAP). Empirical and theoretical work has shown that the systolic and diastolic pressures, Ps and Pd respectively, occur when the amplitudes of oscillation, As and Ad respectively, are a certain fraction of Am:

• Ps is the pressure above Pm at which As/Am = 0.55
• Pd is the pressure below Pm at which Ad/Am = 0.85

[Dr. Neil Townsend, Medical Electronics, Michaelmas Term, 2001, http://makezine.com/go/obpm]

I’m too lazy right now to try to come up with a good envelope follower and find the times for 55% and 85% of peak. The peak seems to be around 48.3s in this plot with magnitude of 0.336kPa and a predicted MAP of 16.28kPa (122mm Hg).  I based the MAP on low-pass filtering the signal to remove the fluctuations and make a good smooth curve for finding the systolic and diastolic pressure, once times on the envelope are picked.  Again, a 4th order Bessel filter applied with filtfilt looks good:

Low-pass filtering removes the fluctuations, so that picking two time points can give clean pressure readings for the systolic and diastolic pressure.

From the standpoint of the course, the filtering to get a good signal is probably too difficult, but students could record the cuff pressure and observe the fluctuations. They might even be able to do some crude RC filtering, though this is really an application that calls out for digital filtering.

## 2014 May 22

### Class-D lab revision didn’t work

In Long weekend, I discussed what I was planning to do about anticipated problems with the class-D amplifier lab, specifically

• Replace the AOI518 nFET with one that has a lower input capacitance, such as the PSMN022-30PL,127.  The gate charge at VGS of 4.5v is 4.4nC, about half that of the AOI518.
• Replace the open-collector comparator with one that has push-pull output, like the TLC3072, which can provide ±20mA current (more than the LM2903, even before we allow for the current through the pullup resistor).

I did a neat version of the schematics last night using the TLC3072 comparators and the AOI518 nFET. This year I remembered to include an adjustable gain stage in the preamp, so that I could more easily control the volume. Today in the lab, while the students were soldering up their instrumentation amps for the pressure sensor, I wired up the class-D amplifier, one stage at a time, confirming that each stage worked using the oscilloscope before moving on to the next. The build took me longer than I had expected—almost 2 hours.

Everything worked fine until I connected the drains of the two FETs together.  Initially it worked ok, but after about 20 seconds the shoot-through current increased, causing the current limitation of the bench power supply to kick in.  Then the voltage on the lower power rail moved up  close to ground, and the input voltage on the comparator was swinging below the negative rail.  I think that this damaged a couple of my TLC3072 chips—I’ve marked them, and I’ll have to test them before using them.

Replacing the AOI518 transistor with the smaller  PSMN022-30PL,127 did not help.

I finally borrowed an LM2093P chip from one of the students (I’d left mine at home, by mistake) and tried replacing the TLC3072 chip with the LM2093P. They have the same pinout, but the LM2093P is an open-collector output, so I had to add pullup resistors.  I guessed a couple of values, based on vague recollections of last year’s design, and the amplifier worked.

Initially I could only run the amplifier up to ±7v on the power supply, without the FETs getting too warm—there was still too much shoot-through current during transitions.  I switched to a lower resistance for the pullup on the pFET gate, to make the voltage swing less and the turn-off faster.  At that point the amplifier worked quite happily with a ±8v swing without the transistors getting warm.The circuit worked with either of the nFET transistors, so I’ll just have the students stick with the AOI518 in their parts kit.

I couldn’t crank up the volume on the speaker, though, because I got feedback squeal whenever the gain got too high.  Perhaps I should make a long speaker extension cable for students to do testing next week.  I seem to be out of speaker wire, though.

The class-D amplifier design will be a tough one for the students, and I’ll need to do a supplemental handout on open-collector outputs (I’d cut that material from the handout when I thought that we would be using the TLC3072 comparators).

Last week I thought that the students could start on the class-D amplifier in lab today, having finished the soldering for the pressure-sensor amp on Tuesday, but it took almost the whole lab time today for students to finish the soldering, even though everyone had working breadboards on Tuesday.  The lab ran over by almost 2 hours for one group, taking a total of 8 hours instead of 6 (last year the same lab took only 4 hours for the slowest group, probably because last year’s class came to lab more prepared).

The layout took longer than students expected, as did the soldering.  Everyone did (eventually) get working soldered instrumentation amps, though for a couple of groups I had to point out that their wiring did not match their schematic (they had called me over to help debugging).

In one case they had connected a resistor to the wrong point in their circuit.  I found the bug by tracing where their virtual ground was connected, and asking them to identify each component. Even after I showed them both resistors connected to their virtual ground, where only one was supposed to be, it took them a long time to realize what the discrepancy was. They had wired exactly what they had laid out, but the bug was in their layout, and they had not done a thorough enough job of checking against their schematic.

Another group had a working circuit but with too little gain. After checking a few of the DC voltage levels with them, I compared each of their resistors to the schematic.  In one place they had wired in a 1kΩ resistor where the schematic called for a 10kΩ resistor.  They unsoldered the incorrect resistor and soldered in the resistor from the design, which salvaged the circuit.

I also returned Wednesday’s quiz in lab today—pretty much like last year, the scores were much better on the second quiz than the first one, though still only half what I think the students should be able to do at this point of the quarter.  I’m once again assigning the students to redo the quiz as homework.  I need to decide soon whether to give them another quiz during the final exam time.

## 2014 May 19

### Long weekend

In Problems rewriting the Class-D amplifier lab I discussed the problems I was having with rewriting the class-D amplifier lab, and came up with the following ideas:

• Try the same basic design as last year, and see if I can get a power supply voltage and pullup resistor settings that work.  I’ll have to do this in the lab on campus, because I don’t have a power supply at home that provides the same voltage ranges.
• Replace the AOI518 nFET with one that has a lower input capacitance, such as the PSMN022-30PL,127.  The gate charge at VGS of 4.5v is 4.4nC, about half that of the AOI518.
• Replace the open-collector comparator with one that has push-pull output, like the TLC3072, which can provide ±20mA current (more than the LM2903, even before we allow for the current through the pullup resistor).
• Add a driver chip that is intended for driving a pair of FET transistors, like the FAN7382, which can provide very fast rise and fall times even into 1000pF loads. But the driver chips are intended for two nFET transistors, and the charge pump for the high-side driver would be difficult to explain in this course and requires external components (diodes, resistors, and capacitors) that the students would have no idea how to choose.
• Use an H-bridge or half-H-bridge chip instead of having students design the power stage with FETs.  Most are designed for controlling motors, and don’t give timing specs that would tell me whether they could handle a high enough PWM frequency for audio output.

Yesterday I ordered some TLC3072 comparator chips and some PSMN022-30PL,127 nFETs, also some MCP6004 op-amp chips, since I seem to have run out, and they are quite cheap.  (I probably need more instrumentation amp chips also, but they are more expensive so I’ll probably wait until I really need them). I hope that I can get the TLC3072 comparator chips before lab on Thursday, so that I can test out the circuit before the students need to build it.  Otherwise I’ll have to cycle into work over the weekend to test the lab. Digi-key shipped it this evening by first-class mail, which probably means I won’t get it until Friday—when they’ve shipped early Monday morning, I ‘ve gotten things by Thursday.

This weekend had me spending a lot of time on the circuits course—I estimate that I spent about 35 hours on the course from Friday night until Monday morning. In addition to figuring out how to rescue and simplify the class-D amplifier lab, I also had to rewrite all the tutorial material for the lab handout, create a quiz for Wednesday’s class, and grade their optical pulse monitor lab reports.

The grading is still a bit painful, as some of the students write nearly incomprehensible English and some are still making trivial mistakes on the schematics (like leaving out component values and shorting out components).  One error on this round was particularly worth commenting on to the class: consistently using mΩ when MΩ was meant.  What is a factor of a billion between friends?  About half the class still can’t explain sensitivity and gain computations, even when they get the right answer.  In some cases, they probably had not come up with the answer themselves, as they made mistakes that magically got cancelled and disappeared when they reported their final results. They keep such awful lab notebooks though, that it is quite possible that they had done the correct computation at one point, but could not reconstruct their work when they went to write it up a few hours later, so I won’t accuse anyone of cheating.

Today I collected prelab homework at the end of class.  The assignment of prelab homework to be turned in did get students to read the assignment and make a stab at doing the design work, and (for the first time) I got questions about the design on Monday rather than halfway through lab on Tuesday.  Most of the designs were incomplete and had serious errors, but at least an attempt had been made to understand the problem, and I was able to clear up several misunderstandings in class:

• Several students tried to put the op amps before the instrumentation amp.  I obviously had not made it clear what an instrumentation amp was for.
• Many of the students had not gotten the idea that an instrumentation amp is a single symbol in a schematic not a conglomeration of op amps and resistors.  This was probably my fault for trying to explain how an instrumentation amp works, rather than how to use one.  It doesn’t help that the INA126P data sheet shows only the innards, and not the external view of the amplifier. I think that next year I may skip explaining how an instrumentation amp works internally, though I think it is kind of cool.

Instrumentation amplifier symbol. I prefer putting Vref on the bottom, rather than the top of the amplifier, but either way works.

• I spent a fair amount of time trying to help the students understand the notion of output voltages being referenced to a specific other voltage. I think that next year I will make a point of always writing the gain equations as $V_{out} - V_{ref} = g(V_{p} - V_{m})$, so that the output is always a difference between two voltages, rather than as $V_{out} = V_{ref} + g (V_{p} - V_{m})$, like I’ve been doing this year.  Although the two statements are algebraically the same, I think that they’ll be better able to do multistage gain computations and less likely to forget to connect up Vref if they have the output expressed as a difference.
• I cleared up some small misunderstandings of how to do layout on the protoboard PDF drawings.

At the end of class I collected all the homeworks, and I “graded” them tonight.  I’m providing feedback and a done/not-done check, not a grade (which is lucky for them, since most were such sloppily done notes that I doubt that most of the students could reconstruct their thoughts from the notes).

I did get a chance to introduce the students to pulse-width modulation and FETs today, which are essential topics for the class-D power amp next week, but I’m not happy with the presentation I gave—I did a better job in the handout, which I suspect most of the students will never read.  The problem with working so much this weekend was that I was very tired all afternoon today, and was not able to put together as coherent a presentation as I wanted to.

I still have to do a design for the class-D power amp with the new comparators, but I’m too tired to do it tonight.  I’ll probably sketch it on paper tomorrow and do a neat schematic in SchemeIt tomorrow night. I’ll wire up all I can at home either tomorrow or Wednesday night, while waiting for the comparator chips and MCP6004 op amp chips to arrive.  (Actually, I’ll probably just use an MCP6002 chip, since I don’t need 4 op amps, and I still have a couple of MCP6002 chips left.)

Tomorrow I need to remember to bring in the cheap aquarium air pump, some tubing, and a clamp so that students can observe back pressure and the fluctuations in pressure from the pump (assuming that they get their amplifiers working).

## 2014 March 5

### Sixteenth day: Arduino demo

Filed under: freshman design seminar,Pressure gauge — gasstationwithoutpumps @ 20:57
Tags: , , , , , ,

Today’s class in the freshman design seminar went well. I started by returning the drafts of the design reports and giving some generic feedback. I realized on reading the reports that I had not given a good explanation of what I meant by describing the components of the system—two of the groups had given me long parts lists on the first page of their reports, something that would only really be appropriate in an appendix. I explained that what I wanted was what the main blocks in the block diagram were, and that they should use the block diagram to organize their report, writing a page for each block. I also suggested that they use the block diagram to partition the project among the group members, with each group member working on a different component, then getting back together to reconcile any discrepancies. Note that this is much more like real engineering group work than the usual K–12 group project, which is usually done most efficiently by turning the whole project over to the most competent member of the group.

After the feedback on design reports, I offered the students a chance to get a demo of building an Arduino program with sensing and motor control. This was a completely extemporaneous demo—I had gathered a number of possibly useful components, but had not tested anything ahead of time nor even figured out what order to do the demo in.  I asked the students if they wanted me to start with sensing or control—they asked for the motor control first.

I started by pulling a motor out of box of motors I had gotten when the elementary school my wife works at cleaned out their closets.  I told the students that I had no idea what the spec of the motor were, but since it came from an elementary school, it probably ran on 3v batteries.  I tested the motor by hooking it up first to the 3.3v, then to the 5v power on my Arduino Uno.  It spun just fine on 3.3v, but squealed a bit on 5v, so we decided to run it on 3.3v.

I then pulled out the Sainsmart 4-relay board that I had bought some time ago but never used.  I explained how a relay worked, what single-pole double-throw meant, and normally open (NO) and normally closed (NC) contacts. I used the board unpowered with the NC contacts to spin the motor, then moved the wire over to the NO contacts to turn the motor off.  I then hooked up power to the board and tried connecting input IN1 to power to activate the relay.  Nothing happened. I then tried connecting IN1 to ground, and the relay clicked and the motor spun.  The inputs to the Sainsmart board are active low, which I explained to the students (though I did not use the terminology “active low”—perhaps I should have).  I did make a point of establishing that the relay provides very good isolation between the control logic and the circuitry being controlled—you can hook up AC power from the walls to the relay contacts without interfering with the logic circuitry.

Having established that the relay worked, the next step was to get the class (as a group) to write an Arduino program to control the motor using the relay. With me taking notes on the whiteboard, they quickly came up with the pinMode command for the setup, the digitalWrite and delay for the loop, and with only a tiny bit of prompting with a second digitalWrite and delay to turn the motor back off.  They even realized the need to have different delays for the on and off, so we could tell whether we had the polarity right on the control.  Here is the program we came up with:

```#define RELAY_PIN (3)

void setup()
{   pinMode(RELAY_PIN, OUTPUT);
}

void loop()
{
digitalWrite(RELAY_PIN,LOW); // turn motor ON via relay (or off via transistor)
delay(1000);  // on for 1 second
digitalWrite(RELAY_PIN,HIGH); // turn motor OFF via relay (or on via transistor)
delay(3000); // off for 3 seconds
}
```

I typed the code in and downloaded it to the Arduino Uno, and it worked as expected.  (It would be nice if the Arduino IDE would allow me to increase the font size, like almost every other program I use, so that students could have read the projection of what I was typing better.)

I then offered the students a choice of going on to sensing or looking at pulse-width modulation for proportional control.  They wanted PWM. I explained why PWM is not really doable with relays (the relays are too slow, and chattering them would wear them out after a while.  I did not have the specs on the relay handy, but I just looked up the specs for the SRD-05VDC-SL-C relays on the board: They have a mechanical life of 10,000,000 cycles, but an electrical life of only 100,000 cycles.  The relay takes about 7msec to make a contact and about 3msec to break a contact, so they can’t be operated much faster than about 60 times a second, which could wear them out in as little as half an hour.

So instead of a relay, I suggested an nFET (Field-Effect Transistor). I gave them a circuit with one side of the motor connected to 3.3V, the other to the drain of an nFET, with the source connected to ground.  I explained that the voltage between the gate and the source (VGS) controlled whether the transistor was on or off, and that putting 5v on the gate would turn it on fairly well. I then got out an AOI518 nFET and stuck it in my breadboard, explaining the orientation to allow using the other holes to connect to the source, gate, and drain.

I mentioned that different FETs have the order of the pins different, so one has to look up the pinout on data sheet. I pulled up the AOI518 data sheet, which has on the first page “RDS(ON) (at VGS = 4.5V) < 11.9mΩ”. I explained that if we were putting a whole amp through the FET (we’re not doing anywhere near that much current), the voltage drop would be 11.9mV, so the power dissipated in the transistor would be only 11.9mW, not enough to get it warm. I mentioned that more current would result in more power being dissipated (I2R), and that the FETs could get quite warm. I passed around my other breadboard which has six melted holes from FETs getting quite hot when I was trying to debug the class-D amplifier design. The students were surprised that the FETs still worked after getting that hot (I must admit that I was also).

I hooked up the AOI518 nFET using double-headed male header pins and female jumper cables, and the motor alternated on for 3 seconds, off for one second. We now had the transistor controlling the motor, so it was time to switch to PWM. I went to the Arduino reference page and looked around for PWM, finding it on analogWrite(). I clicked that link and we looked at the page, seeing that analog Write was like digitalWrite, except that we could put in a value from 0 to 255 that controlled what fraction of the time the pin was high.

I edited the code, changing the first digitalWrite() to analogWrite(nFET_GATE_PIN, 255), and commenting out the rest of the loop. We downloaded that, and it turned the motor on, as expected. I then tried writing 128, which still turned the motor on, but perhaps not as strongly (hard to tell with no load). Writing 50 resulted in the motor not starting. Writing 100 let the motor run if I started it by hand, but wouldn’t start the motor from a dead stop. I used this opportunity to point out that controlling the motor was not linear—1/5th didn’t run at 1/5th speed, but wouldn’t run the motor at all.

Next we switched over to doing sensors (with only 10 minutes left in the class). I got out the pressure sensor and instrumentation amp from the circuits course and hooked it up. The screwdriver I had packed in the box had too large a blade for the 0.1″ screw terminals, but luckily the tiny screwdriver on my Swiss Army knife (tucked away in the corkscrew) was small enough. After hooking up the pressure sensor to A0, I downloaded the Arduino Data Logger to the Uno, and started it from a terminal window. I set the triggering to every 100msec (which probably should be the default for the data logger), the input to A0, and convert to volts. I then demoed the pressure sensor by blowing into or sucking on the plastic tube hooked up to the sensor. With the low-gain output from the amplifier, the output swung about 0.5 v either way from the 2.5v center. Moving the A0 wire over to the high-gain output of the amplifier gave a more visible signal. I also turned off the “convert to volts” to show the students the values actually read by the Arduino (511 and 512, the middle of the range from 0 to 1023).

Because the class was over at that point, I offered to stay for another 10 minutes to show them how to use the pressure sensor to control the motor. One or two students had other classes to run to, but most stayed. I then wrote a program that would normally have the motor off, but would turn it full on if I got the pressure reading up to 512+255 and would turn it on partway (using PWM) between 512 and 512+255. I made several typos when entering the program (including messing up the braces and putting in an extraneous semicolon), but on the third compilation it downloaded successfully and controlled the motor as expected.

One student asked why the motor was off when I wasn’t blowing into the tube, so I explained about 512 being the pressure reading when nothing was happening (neither blowing into the tube nor sucking on it). I changed the zero point for the motor to a pressure reading of 300, so that the motor was normally most of the way on, but could be turned off by sucking on the tube. Here is the program we ended up with

```#define nFET_GATE_PIN (3)

void setup()
{   pinMode(nFET_GATE_PIN, OUTPUT);
pinMode(A0, INPUT);
}

void loop()
{ int pressure;
if (pressure < 300)
{    digitalWrite(nFET_GATE_PIN,LOW);  // turn motor off
}
else
{   if (pressure>300+255)
{ digitalWrite(nFET_GATE_PIN,HIGH);  // turn motor on full
}
else
{    analogWrite(nFET_GATE_PIN,pressure-300); // turn motor partway on
}
}
}
```

Note: this code is not an example of brilliant programming style. I can see several things that I would have done differently if I had had time to think about the code, but for this blog it is more useful to show the actual artifact that was developed in the demo, even if it makes me cringe a little.

Overall, I thought that the demo went well, despite being completely extemporaneous. Running over by 10 minutes might have been avoidable, but only by omitting something useful (like the feedback on the design reports). The demo itself lasted about 70 minutes, making the whole class run 80 minutes instead of 70. I think I compressed the demo about as much as was feasible for the level the students were at.

Based on how the students developed the first motor-control program quickly in class, I think that some of them are beginning to get some of the main ideas of programming: explicit instructions and sequential ordering. Because we were out of time by the point I got to using conditionals, I did not get a chance to probe their understanding there.

Next Page »