I’ve been following Garth’s CS Education Blog for a while, and his post Teaching programming is not getting easier resonated with me, particularly the lines

In programming memorization is a trivial part of the skill set needed to succeed. The primary skills needed are problem solving, strategizing, devolving problems into sub-tasks, interpreting, and general full bore head scratching. Those are an absolute bugger to teach, especially to kids that are not all that interested in learning those difficult skills.

I am not primarily teaching programming to beginners—my bioinformatics course has three programming courses as prerequisites and my applied circuits course does not require students to do any programming—but the same issues come up in all my courses.

Even after three previous programming courses, a lot of students have not had much practice at breaking a problem into subproblems or intelligent (rather than random) debugging. The block diagrams and “systems thinking” for the applied circuits class are precisely analogous to the decomposition of a software problem into modules, classes, or subroutines. Even in the senior thesis writing course that I taught for the last couple of years, a lot of the feedback is on getting students to structure their writing—to look at the thesis as having parts that communicate different information or with different audiences and getting the interfaces between the parts to work.

Almost all engineering requires similar problem-solving skills of decomposition into subproblems, designing and debugging parts independently, and debugging the interactions between parts. Teaching these skills in any context is difficult, and many teachers end up teaching special-purpose tricks that solve one type of problem but that does not help the student learn to solve novel problems.

Garth recognizes the problem in his own teaching:

I used to be a math teacher and math has somewhat the same thinking requirements and the same issues.  The big difference is the kids would have 10 home work problems a night, 8 of which were very easy to do so they would do those and ignore the hard ones.  The result would be an 80%.  With math there are a lot of problems with incremental steps of difficulty for almost any new concept.  Those students that can do the 70 or 80% in math survive just fine.  In math I usually have several different teaching strategies for a concept.  I have multiple “gimmicks” for devolving problems to make them easier to solve.  I have other math teachers to ask for new approaches and a whole lot of cool stuff on the internet to use as resources.   Programming on the other hand has diddly.

He learned some strategies for teaching math: assigning large numbers of small problems of gradually increasing difficulty, giving up on teaching most of the students to reach mastery, and providing gimmicks for students to memorize for the common problem types. These approaches have not worked for him teaching computer science—why not?

One difference is that the computer is not very forgiving of students who get things almost right—one punctuation mark wrong and the computer does the wrong thing or rejects the student’s attempt. Getting 70–80% of the way is not enough—students have to get the details right and not just the general picture.

Another difference is the one he notes: there are a lot more math teachers than CS teachers, particularly in K–12, so there is a lot more pedagogical content knowledge (knowledge of how to teach a subject) available in math. He notes that many CS teachers rely on a rather simple pedagogy:

After watching a number (3) of programming teachers teach it seems the teaching strategy is pretty consistent: show and tell and hope.

I wonder how much of the math pedagogy is really effective, though. A lot seems to be of the memorize-this-trick form, which gets students through their standardized tests, but does not develop transferable skills in problem decomposition or debugging.

The content in math and physics courses is also much more stable than in CS courses—what is taught at the high-school level has not changed much in the last century.  The main differences have been a loss of some tools (slide rules and trig tables) in favor of tools that are easier to use and teach with (calculators). Having a stable subject to teach allows teachers and textbook writers to experiment with how to teach, rather than what to teach. Although a lot of pedagogical experimentation fails (and the field of education is not very good at separating the successes from the failures), there are a lot of techniques available to choose from.

CS, however, keeps changing what is considered essential for a first course.  Fortran, LISP, Pascal, C, C++, Java, Python, Perl, Scratch, Processing, Alice, and other languages have all been proposed as “first” languages, and the programming language is often chosen for social rather than pedagogic reasons.

What topics are taught and in what order are often driven by the choice of language.  For example, LISP makes it easier to talk about recursion early, but makes it difficult to talk about strict type checking. Java and C++ force spending a lot of time on explaining data types and data type declaration. Python allows easy handling of sets and associative maps (“dict” in Python), but makes talking about information hiding and data abstraction somewhat more difficult. Scratch allows early discussion of race conditions in parallel programs, but not of complex data structures or program syntax.

CS teachers disagree about what order is most appropriate to present the topics in—not just the week-by-week order, but even what belongs in the first year and what in the second or third year. I think that in many cases the order doesn’t matter all that much—there are several different ways to get to a similar endpoint, and different students will respond well to different approaches. In the new bioengineering curricula that I’ve proposed, different concentrations have different programming requirements, with the bioelectronics track requiring bottom-up programming that teaches low-level interfacing to microprocessors in C, and the biomolecular track starting with bioinformatics-like programming tasks in Python.

Some of the teaching practices at colleges have not been helpful for developing desired skills.  For example, automated grading programs, which look just at I/O behavior of programs, are becoming more popular in huge college CS classes (and especially in MOOCs). But with automated grading students get almost no feedback on the decomposition into subproblems and clarity of documentation—those skills that are most needed for advancing in the field or transferring the learning to other domains.

I did end up teaching a tiny amount of programming in my freshman design seminar this past quarter: Arduino programming in C for gathering information from a thermistor or phototransistor and using it for simple on-off control (Twelfth day of freshman design seminar and Sixteenth day: Arduino demo).  I did not spend enough time on the programming, and a lot of it was “show and tell and hope”, so I suspect that only one or two of the students can do any programming independently now, but several who were not interested in programming became more interested in learning, which is all I expected of the course. The 2-unit course is only about 1% of their undergraduate education, so I can’t expect to make huge changes in their competence.

Next year I will spend more time on programming and on physical prototyping in the freshman design course, as those are areas that the students identified as having the most effect on them. So I may get to the point in the freshman seminar where I’ll also be facing the challenges of teaching CS concepts to beginners, rather than just piquing their interest.

One thing I think I will do in the freshman design seminar next year is to make the students actually wire up a thermistor or phototransistor to an Arduino board early in the quarter.  Having both a hardware and a software component to a design should help students learn problem decomposition and debugging, as there are obvious hardware/software boundaries—it can’t all be just one mushy “thing” in their heads.

The thermistor is particularly attractive as it requires several changes of representation—from temperature to resistance, to voltage, to ADC reading, back to  a numerical representation of temperature. Since the course is intended for bioengineers, the notion of sensors and different representations of what they sense is an important concept to build on, and temperature is a concept that they are familiar enough with that they can easily check whether what they are doing is working. Note that the data representation here is not just a software concept—the main constraint on the design is the analog-to-digital interface on the Arduino, which only measures voltage between 0 and 5V.

Having a thermistor lab early also works as part of a build-a-physical-prototype theme. I’m not going to use lab fees and handing out a lab kit, either, but make them find and order their own parts. One of the problems this year was students not realizing that getting parts requires a lot of lead time—having them experience that early in the quarter will make them more diligent about getting parts in time later in the quarter. To reduce shipping costs, I may have everyone look for parts separately, but then have them pool the orders, if they can agree on which parts they want to get.

In the coming quarter, in the Applied Circuits course, I’ll be trying to work more deliberately on both systems thinking and information representation, getting the students into being explicit about both earlier in the quarter.  (The first lab is a thermistor lab, which I am in the process of rewriting the lab handout for, which may be why it was the example I thought of using for the freshman design course.) I’ve heard discouraging reports about how little transfer there is of problem-solving skills between different subject domains, but I’m hopeful that having students encounter the same problem-solving concepts in several different domains will help them make the transfer.

I’ve been following Garth’s CS Education Blog for a while, and his post Teaching programming is not getting easier resonated with me, particularly the lines

In programming memorization is a trivial part of the skill set needed to succeed. The primary skills needed are problem solving, strategizing, devolving problems into sub-tasks, interpreting, and general full bore head scratching. Those are an absolute bugger to teach, especially to kids that are not all that interested in learning those difficult skills.

I am not primarily teaching programming to beginners—my bioinformatics course has three programming courses as prerequisites and my applied circuits course does not require students to do any programming—but the same issues come up in all my courses.

Even after three previous programming courses, a lot of students have not had much practice at breaking a problem into subproblems or intelligent (rather than random) debugging. The block diagrams and “systems thinking” for the applied circuits class are precisely analogous to the decomposition of a software problem into modules, classes, or subroutines. Even in the senior thesis writing course that I taught for the last couple of years, a lot of the feedback is on getting students to structure their writing—to look at the thesis as having parts that communicate different information or with different audiences and getting the interfaces between the parts to work.

Almost all engineering requires similar problem-solving skills of decomposition into subproblems, designing and debugging parts independently, and debugging the interactions between parts. Teaching these skills in any context is difficult, and many teachers end up teaching special-purpose tricks that solve one type of problem but that does not help the student learn to solve novel problems.

Garth recognizes the problem in his own teaching:

I used to be a math teacher and math has somewhat the same thinking requirements and the same issues.  The big difference is the kids would have 10 home work problems a night, 8 of which were very easy to do so they would do those and ignore the hard ones.  The result would be an 80%.  With math there are a lot of problems with incremental steps of difficulty for almost any new concept.  Those students that can do the 70 or 80% in math survive just fine.  In math I usually have several different teaching strategies for a concept.  I have multiple “gimmicks” for devolving problems to make them easier to solve.  I have other math teachers to ask for new approaches and a whole lot of cool stuff on the internet to use as resources.   Programming on the other hand has diddly.

He learned some strategies for teaching math: assigning large numbers of small problems of gradually increasing difficulty, giving up on teaching most of the students to reach mastery, and providing gimmicks for students to memorize for the common problem types. These approaches have not worked for him teaching computer science—why not?

One difference is that the computer is not very forgiving of students who get things almost right—one punctuation mark wrong and the computer does the wrong thing or rejects the student’s attempt. Getting 70–80% of the way is not enough—students have to get the details right and not just the general picture.

Another difference is the one he notes: there are a lot more math teachers than CS teachers, particularly in K–12, so there is a lot more pedagogical content knowledge (knowledge of how to teach a subject) available in math. He notes that many CS teachers rely on a rather simple pedagogy:

After watching a number (3) of programming teachers teach it seems the teaching strategy is pretty consistent: show and tell and hope.

I wonder how much of the math pedagogy is really effective, though. A lot seems to be of the memorize-this-trick form, which gets students through their standardized tests, but does not develop transferable skills in problem decomposition or debugging.

The content in math and physics courses is also much more stable than in CS courses—what is taught at the high-school level has not changed much in the last century.  The main differences have been a loss of some tools (slide rules and trig tables) in favor of tools that are easier to use and teach with (calculators). Having a stable subject to teach allows teachers and textbook writers to experiment with how to teach, rather than what to teach. Although a lot of pedagogical experimentation fails (and the field of education is not very good at separating the successes from the failures), there are a lot of techniques available to choose from.

CS, however, keeps changing what is considered essential for a first course.  Fortran, LISP, Pascal, C, C++, Java, Python, Perl, Scratch, Processing, Alice, and other languages have all been proposed as “first” languages, and the programming language is often chosen for social rather than pedagogic reasons.

What topics are taught and in what order are often driven by the choice of language.  For example, LISP makes it easier to talk about recursion early, but makes it difficult to talk about strict type checking. Java and C++ force spending a lot of time on explaining data types and data type declaration. Python allows easy handling of sets and associative maps (“dict” in Python), but makes talking about information hiding and data abstraction somewhat more difficult. Scratch allows early discussion of race conditions in parallel programs, but not of complex data structures or program syntax.

CS teachers disagree about what order is most appropriate to present the topics in—not just the week-by-week order, but even what belongs in the first year and what in the second or third year. I think that in many cases the order doesn’t matter all that much—there are several different ways to get to a similar endpoint, and different students will respond well to different approaches. In the new bioengineering curricula that I’ve proposed, different concentrations have different programming requirements, with the bioelectronics track requiring bottom-up programming that teaches low-level interfacing to microprocessors in C, and the biomolecular track starting with bioinformatics-like programming tasks in Python.

Some of the teaching practices at colleges have not been helpful for developing desired skills.  For example, automated grading programs, which look just at I/O behavior of programs, are becoming more popular in huge college CS classes (and especially in MOOCs). But with automated grading students get almost no feedback on the decomposition into subproblems and clarity of documentation—those skills that are most needed for advancing in the field or transferring the learning to other domains.

I did end up teaching a tiny amount of programming in my freshman design seminar this past quarter: Arduino programming in C for gathering information from a thermistor or phototransistor and using it for simple on-off control (Twelfth day of freshman design seminar and Sixteenth day: Arduino demo).  I did not spend enough time on the programming, and a lot of it was “show and tell and hope”, so I suspect that only one or two of the students can do any programming independently now, but several who were not interested in programming became more interested in learning, which is all I expected of the course. The 2-unit course is only about 1% of their undergraduate education, so I can’t expect to make huge changes in their competence.

Next year I will spend more time on programming and on physical prototyping in the freshman design course, as those are areas that the students identified as having the most effect on them. So I may get to the point in the freshman seminar where I’ll also be facing the challenges of teaching CS concepts to beginners, rather than just piquing their interest.

One thing I think I will do in the freshman design seminar next year is to make the students actually wire up a thermistor or phototransistor to an Arduino board early in the quarter.  Having both a hardware and a software component to a design should help students learn problem decomposition and debugging, as there are obvious hardware/software boundaries—it can’t all be just one mushy “thing” in their heads.

The thermistor is particularly attractive as it requires several changes of representation—from temperature to resistance, to voltage, to ADC reading, back to  a numerical representation of temperature. Since the course is intended for bioengineers, the notion of sensors and different representations of what they sense is an important concept to build on, and temperature is a concept that they are familiar enough with that they can easily check whether what they are doing is working. Note that the data representation here is not just a software concept—the main constraint on the design is the analog-to-digital interface on the Arduino, which only measures voltage between 0 and 5V.

Having a thermistor lab early also works as part of a build-a-physical-prototype theme. I’m not going to use lab fees and handing out a lab kit, either, but make them find and order their own parts. One of the problems this year was students not realizing that getting parts requires a lot of lead time—having them experience that early in the quarter will make them more diligent about getting parts in time later in the quarter. To reduce shipping costs, I may have everyone look for parts separately, but then have them pool the orders, if they can agree on which parts they want to get.

In the coming quarter, in the Applied Circuits course, I’ll be trying to work more deliberately on both systems thinking and information representation, getting the students into being explicit about both earlier in the quarter.  (The first lab is a thermistor lab, which I am in the process of rewriting the lab handout for, which may be why it was the example I thought of using for the freshman design course.) I’ve heard discouraging reports about how little transfer there is of problem-solving skills between different subject domains, but I’m hopeful that having students encounter the same problem-solving concepts in several different domains will help them make the transfer.

Yesterday’s class was originally planned to be an Arduino demo of analogRead() and Serial.print(), using either a pressure sensor or a phototransistor, but the class ended up going in a totally different direction.

At the beginning of class, I passed around a cheap vernier caliper and showed students how to measure the disposable cuvettes to 0.05mm precision. This was part of my continuing effort to expose students to simple tools that they should have seen in high school, but for the most part have not.

I started the class by collecting the proposals for design projects.  Since these were group efforts, there were only three proposals: a centrifuge, an incubator, and a PCR thermal cycler.  I’ve not read the proposals yet (I’m still under the weather, and ended up falling asleep last night right after dinner, and only waking up this morning barely in time to get to the department research seminar at noon), but I did read the titles in class, and started talking about what computer aspects there might be for each project.  The centrifuge is mainly a mechanical design, but a non-contact sensor (probably optical) for measuring the rotor speed would be useful—one might even want to include a motor speed control, but that depends on what they use for a motor. The other two designs both depend on regulating a temperature.  Important parameters include how tightly controlled the temperature has to be and how fast you have to move from one temperature to another.  An incubator generally needs to have a fairly fixed temperature, and only needs to respond to slow heat loss, except when the incubator is opened.  A PCR machine has to switch rapidly between three temperatures,  generally around 95° C, 50° C, and 75° C.

So we ended up talking about thermal control.  First I described the basic idea of having a “set point” and of simple on-off heater control, with high threshold and a low threshold.  We talked about temperature sensors, including the old-fashioned bimetal-strip thermostats, thermistors, thermocouples, and RTD sensors. I talked a little about how to choose among the different types (thermocouples for high temperature, RTD for high precision, thermistors for low cost and ease of interfacing).  I also mentioned semiconductor temperature sensors, which are used in a lot of integrated circuits (like CPUs and GPUs on their laptops), but are not very good for general temperature measurement.

We focused on thermistors as the simplest to use with the Arduino, and I showed them a data sheet for the NTCLE413E2103F520L thermistor we use in the Applied Circuits lab.  This lead to a discussion of how the thermistor resistance varies with temperature, and I showed them the Wikipedia page on thermistors, with its discussion of the Steinhart-Hart equation and the “B” parameterization of the formula.  I also explained what the B_25/85 specification on the data sheet meant (measuring resistance at only 25° C and 85° C, and solving for B).

I then tried to get the class to come up with a circuit to convert resistance variation into voltage variation, but they were stumped. So I showed them a voltage divider and had them work out as a class what the output voltage was using just Ohms law. They were then able to see that replacing one resistor with a thermistor would allow them to see a voltage variation as a function of temperature. I told them about the first homework in the Applied Circuits course (figuring out the optimal value for the fixed resistor, to get the maximum change in voltage with temperature at a particular operating temperature), but did not assign the problem. Not everyone in the class has had calculus yet, and the problem really does require being able to differentiate and use the chain rule.

I ran out of time before doing anything with the Arduino! I did assign them an Arduino homework, though:

For Wednesday 2014 Feb 19 (no class Monday Feb 17), write an Arduino program that will report over the USB cable once every two seconds the status of pins 8, 9, and 10, whether that pin is high or low. The report should be viewable on the Arduino Serial Monitor. It should look something like

 8:HIGH 9: LOW 10: LOW
 8: LOW 9:HIGH 10: LOW
 8: LOW 9:HIGH 10: LOW
 8: LOW 9: LOW 10: LOW

As a matter of common programming style, there should be a “block comment” at the beginning of every program telling what the program does (from a user’s standpoint, not how it works from a programmer’s standpoint), who wrote it, and when it was written. You may work on the programs in pairs (not larger groups), but the names of everyone who worked on

Turn in a printout of your program. This program is simple enough that I don’t need evidence of it working—for other class you may be asked to turn in the source code electronically, so that the graders can test the program, or provide input-output pairs that show evidence that the program is working correctly.

For those who find this program too easy, you can challenge yourself to do more ambitious programs:

• Read analog inputs from A0 through A5 and report the values.
• Accept characters from the USB serial line that change which pins you examine. (For example, getting the character ’8′ with Serial.read() might turn on looking at pin 8, and getting ‘*’ might turn it off looking at pin 8.)
• Write a little control program that turns on the on-board LED (pin 13) when some combination of conditions is true and off when the conditions are false.

At the end of class, I had everyone use my wire strippers to cut and strip a few small pieces of wire, so that they could do the hardware portion of the Arduino programming.

Yesterday’s class was originally planned to be an Arduino demo of analogRead() and Serial.print(), using either a pressure sensor or a phototransistor, but the class ended up going in a totally different direction.

At the beginning of class, I passed around a cheap vernier caliper and showed students how to measure the disposable cuvettes to 0.05mm precision. This was part of my continuing effort to expose students to simple tools that they should have seen in high school, but for the most part have not.

I started the class by collecting the proposals for design projects.  Since these were group efforts, there were only three proposals: a centrifuge, an incubator, and a PCR thermal cycler.  I’ve not read the proposals yet (I’m still under the weather, and ended up falling asleep last night right after dinner, and only waking up this morning barely in time to get to the department research seminar at noon), but I did read the titles in class, and started talking about what computer aspects there might be for each project.  The centrifuge is mainly a mechanical design, but a non-contact sensor (probably optical) for measuring the rotor speed would be useful—one might even want to include a motor speed control, but that depends on what they use for a motor. The other two designs both depend on regulating a temperature.  Important parameters include how tightly controlled the temperature has to be and how fast you have to move from one temperature to another.  An incubator generally needs to have a fairly fixed temperature, and only needs to respond to slow heat loss, except when the incubator is opened.  A PCR machine has to switch rapidly between three temperatures,  generally around 95° C, 50° C, and 75° C.

So we ended up talking about thermal control.  First I described the basic idea of having a “set point” and of simple on-off heater control, with high threshold and a low threshold.  We talked about temperature sensors, including the old-fashioned bimetal-strip thermostats, thermistors, thermocouples, and RTD sensors. I talked a little about how to choose among the different types (thermocouples for high temperature, RTD for high precision, thermistors for low cost and ease of interfacing).  I also mentioned semiconductor temperature sensors, which are used in a lot of integrated circuits (like CPUs and GPUs on their laptops), but are not very good for general temperature measurement.

We focused on thermistors as the simplest to use with the Arduino, and I showed them a data sheet for the NTCLE413E2103F520L thermistor we use in the Applied Circuits lab.  This lead to a discussion of how the thermistor resistance varies with temperature, and I showed them the Wikipedia page on thermistors, with its discussion of the Steinhart-Hart equation and the “B” parameterization of the formula.  I also explained what the B_25/85 specification on the data sheet meant (measuring resistance at only 25° C and 85° C, and solving for B).

I then tried to get the class to come up with a circuit to convert resistance variation into voltage variation, but they were stumped. So I showed them a voltage divider and had them work out as a class what the output voltage was using just Ohms law. They were then able to see that replacing one resistor with a thermistor would allow them to see a voltage variation as a function of temperature. I told them about the first homework in the Applied Circuits course (figuring out the optimal value for the fixed resistor, to get the maximum change in voltage with temperature at a particular operating temperature), but did not assign the problem. Not everyone in the class has had calculus yet, and the problem really does require being able to differentiate and use the chain rule.

I ran out of time before doing anything with the Arduino! I did assign them an Arduino homework, though:

For Wednesday 2014 Feb 19 (no class Monday Feb 17), write an Arduino program that will report over the USB cable once every two seconds the status of pins 8, 9, and 10, whether that pin is high or low. The report should be viewable on the Arduino Serial Monitor. It should look something like

 8:HIGH 9: LOW 10: LOW
 8: LOW 9:HIGH 10: LOW
 8: LOW 9:HIGH 10: LOW
 8: LOW 9: LOW 10: LOW

As a matter of common programming style, there should be a “block comment” at the beginning of every program telling what the program does (from a user’s standpoint, not how it works from a programmer’s standpoint), who wrote it, and when it was written. You may work on the programs in pairs (not larger groups), but the names of everyone who worked on

Turn in a printout of your program. This program is simple enough that I don’t need evidence of it working—for other class you may be asked to turn in the source code electronically, so that the graders can test the program, or provide input-output pairs that show evidence that the program is working correctly.

For those who find this program too easy, you can challenge yourself to do more ambitious programs:

• Read analog inputs from A0 through A5 and report the values.
• Accept characters from the USB serial line that change which pins you examine. (For example, getting the character ’8′ with Serial.read() might turn on looking at pin 8, and getting ‘*’ might turn it off looking at pin 8.)
• Write a little control program that turns on the on-board LED (pin 13) when some combination of conditions is true and off when the conditions are false.

At the end of class, I had everyone use my wire strippers to cut and strip a few small pieces of wire, so that they could do the hardware portion of the Arduino programming.

I had a good discussion with Steve P. this afternoon about the order and purpose of the labs I’ve designed so far.  He’ll be putting together a list of EE topics we have to cover to coordinate with the labs, so that students will have enough theory to do each lab, but not be overwhelmed with theory that they don’t yet have a use for.

I’ve designed the labs mainly around the interests of bioengineering majors, but I’ve tried to keep in mind other possible students, such as Digital Arts and New Media students, who would be interested in practical sensor circuits for interfacing to art projects (particularly for inputs to Arduino microprocessors).

Lab 1: thermistor

See posts

1. More musings on circuits course: temperature lab
2. Temperature lab, part2
3. Temperature lab, part 3: voltage divider

The first lab will consist of 3 parts, all involving the use of a Vishay BC Components NTCLE413E2103F520L thermistor.

First, the students would use a bench multimeter to measure the resistance of the thermistor, dunking it in various water baths (with thermometers in them to measure the temperature).  They should fit a simple curve to this data (warning: temperature needs to be on an absolute scale).

Second, they would add a series resistor to make a voltage divider. They have to choose a value to get as large and linear a voltage response as possible at some specified “most-interesting” temperature (perhaps body temperature, perhaps room temperature, perhaps DNA melting temperature).  There should probably be a pre-lab exercise where they derive the formula for maximizing . They would then measure and plot the voltage output for the same set of water baths. If they do it right, they should get a much more linear response than for their resistance measurements.

Finally, they would hook up the voltage divider to an Arduino analog input and record a time series of a water bath cooling off (perhaps adding an ice cube to warm water to get a fast temperature change), and plot temperature as a function of time.

EE concepts needed: voltage, resistance, voltage divider, notion of a transducer.

Lab skills developed: use of multimeter for measuring resistance and voltage, use of Arduino with data-acquisition program to record a time series, fitting a model to data points, simple breadboarding.

Note:  Mylène suggested that we start student familiarization with the test equipment by having them use the multimeters to measure other multimeters.  What is the resistance of a multimeter that is measuring voltage?  of one that is measuring current? what current or voltage is used for the resistance measurement?  We might want to do this first.

 Lab 2: electret microphone

See posts

1. Oscilloscope practice lab
2. Op-amp lab

Mylène suggested that we start oscilloscope familiarity by looking at the output of power supplies. What ripple can you see on the voltage output of a benchtop supply? of a cheap wall wart?  This requires the students to learn the difference between DC and AC input coupling for oscilloscopes.  I think that we may be able to teach what we need here without measuring the power supplies, though that is a good backup plan.

First, we would have the students measure and plot the DC current vs. voltage for the microphone.  The microphone is normally operated with a 3V drop across it, but can stand up to 10V, so they should be able to set the Agilent E3631A power supply to various values from 0V to 10V and get the voltage and current readings directly from the bench supply, which has 4-place accuracy for both voltage and current.  There is some danger of the students accidentally delivering too much voltage and frying the mic, but as long as they get the polarity right, that isn’t too big a hazard.  Ideally, they should see that the current is nearly constant as voltage is varied—nothing like a resistor.

Second, we would have them do current-to-voltage conversion with a 5v power supply to get a 2.5v DC output and hook up the output of the microphone to the input of the oscilloscope.  Input can be whistling, talking, iPod earpiece, … . They should learn the difference between AC coupled and DC coupled inputs to the scope, and how to set the horizontal and vertical scales of the scope.

Third, we would have them design and wire their own DC blocking filter (going down to about 1Hz), and confirm that it has a similar effect to the AC coupling on the scope.

Fourth, they should play sine waves from the function generator through a loudspeaker next to the mic, observe the voltage output with the scope, and measure the voltage with a multimeter, plotting output voltage as a function of frequency.  Note: the specs for the electret mic show a fairly flat response from 50Hz to 3kHz, so most of what the students will see here is the poor response of a cheap speaker at low frequencies.  Those with extra time could look at putting the speaker and mic at opposite ends of tube and seeing what difference that makes.

EE concepts: current sources, AC vs DC, DC blocking by capacitors, RC time constant, sine waves, RMS voltage, properties varying with frequency.

Lab skills: power supply, oscilloscope, function generator, RMS AC voltage measurement.

Lab 3: electrode measurements

See posts

1. Trying to measure ionic current through small holes
2. Conductivity of saline solution
3. On stainless steel
4. Better measurement of conductivity of saline solution
5. Measuring Ag/AgCl electrodes

First, we would have the students attempt to measure the resistance of a saline solution using a pair of stainless steel electrodes and a multimeter.  This should fail, as the multimeter gradually charges the capacitance of the electrode/electrolyte interface.  For the safety of the lab equipment, we should have the beakers with salt water in a secondary containment tray at all times.

Second, the students should again use a voltage divider, with 10–100Ω load resistor, but with the function generator driving the voltage divider.  The students should measure the RMS voltage across the resistor and across the electrodes for different frequencies from 3Hz to 300kHz (the range of the AC measurements for the Agilent 34401A Multimeter).  They should plot the magnitude of the impedance of the electrodes as a function of frequency and fit an R2+(R1||C1) model to the data.  A little hand tweaking of parameters should help them understand what each parameter changes about the curve.

Third, the students should repeat the measurements and fits for different concentrations of NaCl (we’ll have to get a liter or so of each stock solution made up by one of the wet labs).  Seeing what parameters change a lot and what parameters change only slightly should help them understand the physical basis for the electrical model.

Fourth, students should make Ag/AgCl electrodes from fine silver wire. To avoid possible problems with Clorox in the lab, we’ll probably have them electroplate in NaCl solutions.  If their electrodes have an area of about 0.8 cm² (2.5cm of 18 gauge wire with a diameter of 1.024mm), we can electroplate at the recommended current density of 1mA/cm² (so 0.8mA) in 0.9% (0.16M) NaCl for a minute, reversing polarity occasionally to improve the chloride coat. The instructions I’ve seen vary a lot, so neither the salt concentration nor the current density seem to be particularly critical values. We could provide a constant-current supply, but we can probably get by with just having them use a bench supply and adjust the voltage manually to keep the current around 1mA, using visual feedback to terminate the process. (Some instructions just call for using a 9v battery and a whole coil of silver wire.)  According to Warner Instruments

The color of a well plated electrode will be light gray to a purplish gray. While plating, occasionally reversing the polarity for several seconds tends to deepen the chloride coating and yield a more stable electrode.

Fifth, the students should measure and plot the resistance of a pair of Ag/AgCl electrodes as a function of frequency (as with the stainless steel electrodes). We’ll have to think of an easy way for them to mount their electrodes so that they don’t move and so that the silver-copper interface is not near the salt water.

Sixth, if there is time, measuring the potential between a stainless steel electrode and an Ag/AgCl electrode.

EE concepts: impedance, series and parallel circuits, variation of parameters with frequency.

Electrochemistry concepts: At least a vague understanding of half-cell potentials. Ag → Ag⁺ + e^-,  Ag⁺ + Cl^- → AgCl.

Lab skills: bench power supply, function generator, multimeter, fitting functions of complex numbers, handling liquids in proximity of electronic equipment.

Lab 4: Sampling and aliasing

I don’t know the details of this lab, but Steve P. has a PC board that samples and digitizes an input with an 8-bit ADC, then reconstructs the waveform with a DAC.  He has worked out a lab for explaining and demonstrating aliasing of sampled signals using this board, a signal generator, and a dual-trace oscilloscope.  I’ll have to borrow the board and the lab handout from him to see if there is anything in the lab I’d want to tweak.

EE concepts: quantized time, quantized voltage, sampling frequency, Nyquist frequency, aliasing.

Lab skills: dual traces on oscilloscope.

Lab 5: Op amp basics

See post Op-amp lab

Use an op amp to build a simple non-inverting audio amplifier for an electret microphone, setting the gain to around 6 or 7.  Note that we are using single-power-supply op amps.

If this lab is too short, then students could feed the output of the amplifier into an analog input of the Arduino and record the waveform at the highest sampling rate they can with the software we provide (probably around 300–500 Hz).  This would again demonstrate aliasing.

EE concepts: op amp, DC bias, bias source with unity-gain amplifier, AC coupling, gain computation.

Lab skills: complicated breadboarding (enough wires to have problems with messy wiring). If we add the Arduino recording, we could get into interesting problems with buffer overrun if their sampling rate is higher than the Arduino’s USB link can handle.

Lab 6: capacitive touch sensor

See posts

1. Capacitive sensing
2. Capacitive sensing, part 2
3. Capacitive sensing with op amps
4. Capacitive sensing with op amps, continued

The students would build an op-amp oscillator (a square-wave one, not a sine wave) whose frequency is dependent on the parasitic capacitance of a touch plate, which the students can make from Al foil and plastic food wrap. Students would have to measure the frequency of the oscillator with and without the plate being touched.

We can provide a simple Arduino program that is sensitive to changes in the period of the oscillator (see example in Capacitive sensing with op amps, continued) and turns an LED on or off.

EE concepts: frequency-dependent feedback, oscillator, RC time constants, parallel capacitors.

Lab skills: more messy breadboarding.  Frequency measurement.

Lab 7: Phototransistor

See posts

1. Phototransistor
2. Synchronous demodulator
3. Pulse detection with light
4. Giving up on light-based pulse sensor
5. Looking at bioengineering measurements courses
6. Random thoughts on circuits labs

Since optical detection is such an important part of many biomolecular lab techniques, I really want to do something with an LED and phototransistor (or CdS cell or photodiode), but so far none of my ideas have worked out.  I have a nice Fairchild QRE1113 reflectance sensor that uses a matched 940nm wavelength LED and phototransistor, which I’ve used a tachometer for motors for the robotics club. Unfortunately, a tachometer is more appropriate for a mechatronics lab than a biengineering circuits course.

I thought that I might be able to use it to measure arterial pulses by reflection, but I don’t seem to get a signal at my heart rate (I did better with the uncomfortable ear clip).

The reflectance sensor is good for measuring finger tremor if you hold a finger close to (but not touching) the sensor.  The effect is optical, not capacitive coupling, since the signal is stronger if a non-conducting white piece of paper is held near the sensor rather than a finger.  The reflectance sensor is remarkably insensitive to ambient light, though shining a laser pointer on the sensor is easily detected.

We can easily do labs involving interrupting light beams, but there isn’t much “circuit” stuff for the simple ones and not much “bio” stuff either.  We could up the circuit content (perhaps too much) by modulating the light beam and using a synchronous demodulator to detect the beam even in the presence of high ambient light.

I still need to find something that is feasible and somehow related to bioengineering.  This needs more thought.

Lab 8: No idea

I’m still missing a lab.  I’ve not done anything with position, pressure, or volume sensing yet.  Of course, it is possible that some of the earlier labs will take longer than I think, and we’ll need to slip the schedule anyway.  The EKG lab looks pretty packed, so may be some portion of that could be foreshadowed here.  Perhaps bandpass filtering and characterizing a simple filter?  That would be useful, but rather boring.

Maybe an electronic music lab of some sort would be fun here?

Labs 9 and 10: EKG

See posts

1. EMG and EKG works
2. Two-stage EKG
3. EKG recording working
4. More thoughts on EKG
5. EKG blinky
6. Instrumentation amp protoboard
7. Instrumentation amp protoboard rev2.1
8. EKG blinky boards arrived

The electrocardiogram will be the final project for the course, and I think it will take two full lab sessions. The first lab session would consist of soldering up the instrumentation amp protoboard, checking for opens and shorts, and designing and characterizing a differential amplifier with an adjustable gain of about 100–1000 (including AC coupling to eliminate problems with DC offset saturating later stages).  The amplifier should have a bandwidth of about 0.01Hz–150Hz.

The second one would be and making a twisted-wire harness with alligator clips to attach to the EKG electrodes, connecting the amplifier to the electrodes, debugging the student-designed EKG amplifiers, and adjusting the gain.  I suspect that a few students will get a design that works in the first week, but that a lot of students will be doing a lot of unsoldering and resoldering as they find bugs in their design, hence the need for 2 weeks in the lab.

Student check out will require that they be able to blink an LED in time with their heart beat, display the EKG waveform on the oscilloscope, and record a minute of EKG signal at 200 samples/second using the Arduino, all without adjusting their board between demos.

EE concepts: biopotentials, instrumentation amplifier, common-mode signal, differential signal, twisted pair wiring, grounding to avoid common-mode signal saturating an instrumentation amplifier, Ac coupling, simple bandpass filtering.

Lab skills: soldering.

Summary

I have a pretty clear idea how I think the lab part of the course should start and how it should end, but there are a couple of weeks just before the end that are still a bit vague.  Perhaps as Steve starts aligning the EE topics with the labs he can identify some topics that need a lab exercise to clarify them.  Maybe some of my blog readers (those who haven’t deserted me during this long process of designing a course) can make some more suggestions—even repeating some old suggestions would not be a bad idea now, as I need a creative kick.

In Temperature lab, part2, I carefully measured the resistance vs. temperature curve for the Vishay BC Components NTCLE413E2103F520L thermistor, finding that either my thermometer was badly miscalibrated, or the manufacturer’s data sheet was misleading.  I got a resistance of 9.7kΩ (not 10kΩ±1%) at 25° C and a B-value of 3174°K, not 3435°K±1%.  A big part of the discrepancy is that I calibrated over a different temperature range, and the measured values deviated most from the manufacturer’s spec at low temperatures.

Actually, the manufacturer’s data sheet is not as bad as all that.  They give specs for the ratio of the resistance at various temperatures to the resistance at 25° C, and their numbers do not fall along a simple curve.  The report the B-value as a 2-point fit for T=25° C and T=85° C, but they also report resistance values every 5° C from –40° C to 105° C.  One can compute the B-value for any pair:

But even if I use their calibration data down to 0° C, I don’t get as small a B-value as I get from my measurements. My calibration curve does not fit their spec, even if I look at the table, rather than the simple B-value model (though the table is closer to my measurements, it doesn’t match).

How big a difference would if make if I used their curve rather than mine?  At R=6685Ω, we get the same temperature either way (96.446° F).  At the resistance they claim for 0° C (27348Ω), their B-value model would give 33.90° F and mine would give 29.37° F.  At the resistance I measured for 0° C (25.5kΩ), their model would give 36.67° F, while mine gives 32.32° F (which is closer than the measurement error I had on temperatures).  So it looks like relying blindly on their B-value model introduces an error of over 4° F at low temperature, but in a digital thermometer for human body temperature, one would get nearly the same result with either calibration.

Voltage divider

The second part of the lab was to use the calibration curve to design a circuit to convert the resistance variation into a voltage variation that is nearly linear with temperature, at least over a small range.  The simplest circuit to convert a resistance to a voltage is a voltage divider, which just requires a voltage source and another resistor.

A simple voltage divider for converting the thermistor resistance to a voltage. Because I want the output voltage to increase with temperature, but the resistance R(T) decreases with temperature, I put the thermistor on the top branch and fixed resistance on the lower branch.
Circuit drawn with the Circuit Lab editor.

The formula for the output voltage is simple: , where we are approximating for temperature T in Kelvin. We’d like the voltage to be as linear as possible, which means we want the second derivative of Vout with respect to T to be zero. Obviously, we can’t do that for all values of T, but we might be able to do it for a particular value of T, and to have a small second derivative in that neighborhood.

We can take the derivatives by hand (or use a tool like Maple or Mathematica):


The second derivative is 0 if , that is if .

We can use this formula to set the value for any temperature, for example, if we want linearity around 98.6° F (310.15° K), we can set the series resistor to 4323.64Ω.

Expected voltage curve using a voltage divider with series resistor optimized for 98.6° F. Note that the curve is fairly linear from about 70° F to about 130° F (where the red non-linear curve and the green linear approximation at 98.6° F are quite close.

Of course, commercially available resistors don’t come in values like 4323.64Ω, so in doing a design one has to pick an available resistor, using the EIA table of standard resistor values.  A 4.7kΩ resistor looks pretty close, which would be color code yellow-violet-red.  Too bad that I don’t have one.  I do have a 5.1kΩ resistor, which would be optimal for linearizing at 90.06° F.  We should, of course, ask students to do the resistor selection for a different temperature than the one we use in an example, and they should be using their own B-value.

Testing the voltage divider

I set up the voltage divider on a breadboard.  Because I knew my wall wart had a huge ripple, I added a low-pass RC filter consisting of a 100Ω resistor and a 470µF electrolytic capacitor.  This slightly complicates the analysis of the voltage output, since the Vdd voltage is itself dependent on a voltage divider.

Low-pass filter to clean up the output of the wall wart. With the low-pass filter in place, we can model the power supply as a 5.166V source and 100Ω series resistor.

Here is what the low-pass filter looks like on the breadboard. The red and black wires from the bottom come from the connector to the wall wart. The 100Ω resistor runs vertically up the center, and the electrolytic capacitor connects across to the ground. The red clip lead is from the multimeter and is set up for measuring the voltage at the output of the filter.

Here is the full breadboard, showing the RC filter, the series resistor, the leads to the thermistor (the red and yellow lines with the crimp-on connectors), and the clip leads to the multimeter (the red and black alligator clips). I’ve found it very handy to have a number of double-sided header pins to make easy connection points on the breadboard for clip leads.

Here is the setup used for testing. The thermistor and thermometer are in the ceramic-cup water bath, with the thermometer held to keep the bulb in contact with the thermistor. You can see that the least-significant digit of the LCD display is a bit hard to read—applying some pressure to the display often makes it readable. Clip leads are essential to doing this experiment—holding the multimeter probes to test points would be a major hassle.

I only made 21 measurements of voltage, since I was not going to be fitting a model to the data, but just using the model I fit from the resistance measurements.

Plot of measured and theoretical voltage vs. temperature for the thermistor. The non-linear theoretical curve seems to be a pretty good fit (though it was not fit on this data, but on the previous series of resistance measurements).

The range of the voltages with the series resistor (from about 0.85v at freezing to 4.15v at boiling) is fairly reasonable for direct conversion to digital for the Arduino 10-bit ADC. In the middle of the range, the slope is about 0.0233 V/°F, which would give a resolution of about 0.2°F for Arduino readings.  (Of course, with the Arduino, we would not need the low-pass filter, and Vdd would be a well-regulated 5v, so this calibration curve would have to be redone.)  Even if we use the computational power of the Arduino to correct the non-linearity of the voltage curve, it is still useful to select the series resistor for the temperature we are most interested in, since that point gets the largest slope and hence the highest temperature resolution for fixed-size steps in voltage quantization.

Series-parallel

A lot of thermistor circuits on the web have a resistor in parallel with the thermistor, as well as the one in series. I wondered what the effect of this extra resistor was.

Circuit with resistor in parallel with the thermistor, as well as in series.

I tried analyzing this circuit also, using the same brute-force approach of computing the second derivative of the voltage and setting it to zero.  I got a result that surprised me initially:  the second derivative is zero if , where is the resistance one would get for putting the series and parallel resistors in parallel. This is exactly the same condition as before, but with replacing the series resistor .

After I thought about this for a while, I realized that I should have been able to get there directly. If you think of the circuit as connecting the thermistor to a voltage divider consisting of R2 and R1, then you can replace the ground and that voltage divider by the Thévenin equivalent, which would be a voltage source with voltage and a series resistor consisting of  R1 and R2 in parallel: .  The only reason to put in a parallel resistor would be to restrict the voltage range (which might be useful if the output were to be amplified, but is not useful if the output is going directly into an analog-to-digital converter whose full-scale range is 0 to Vdd).

The thermistors that I ordered (see More musings on circuits course: temperature lab and Buying parts for circuits course) arrived today, about 2.1 days after I ordered them.  So I’ll try playing with them today, and see whether I can do the lab I’m thinking of for the students.

My son is still working on the Arduino data logger.  The Arduino code has been done for a while, but he’s been working on the Python front end.  He’s decided to do two front ends: a minimal one with no GUI and a fancy one using PyGUI.  He’s run into some problems (like PyGUI not supporting autoscrolling in TextEditor components), but everything seems to be solvable at this point.  He had a GUI interface working, but decided he needed to refactor his code to have a proper API for the datalogger, so that the user interface and the datalogger core code were as independent as possible with a documented interface between them—he’s teaching himself a lot about software engineering for this project, which is the first one for which he has had an external client.

The action plan for testing out a temperature measurement lab that I posted in More musings on circuits course: temperature lab was

• Get some thermistors and some thermometer probe sheaths and see if I can make adequate temporary waterproofing for pennies per student.  I’ll probably have to solder on wires to lengthen the leads.
• Try calibrating thermistors using a multimeter, cups of hot and cold water, and an accurate thermometer.
• Try reading the thermistor using a voltage divider and the Arduino ADC.  Plot the temperature and Arduino reading over a wide temperature range (say, as a cup of boiling water cools).
• Try linearizing the thermistor readings  using a parallel resistor and voltage divider.
• Try designing an amplifier to read the thermistor with much lower current through it (and so less self-heating).

I’ve got three types of thermistors (all 10kΩ nominal resistance at 25° C), none of which are intended for immersion:

• Vishay BC Components NTCLE100E3103JB0 a very cheap (23.5¢ each in quantities of 10) with B-value 3977°K).  There is high variation in the resistance (±5%), but low variation in the B-value (±0.75%).  These are glass-bead thermistors with 2cm uninsulated leads, so will need waterproofing. I bought 10 of these, but am hoping that I don’t need them.
• Vishay BC Components NTCLE413E2103F520L (34.9¢ each in quantities of 10) has 4cm leads and is epoxy coated, but with the warning “Not intended for fluid immersed applications or continuous contact with water.”  It has B-value 3435°K, both resistance and B-value ±1%.  I plan to find out today if it is waterproof enough for the relatively short duration of the labs. I bought 10 of these also, and have the highest hopes for these being the ones we use in the lab.
• Murata Electronics North America NXFT15XH103FA2B100 (66¢ each in quantities of 10) with B-value 3431°K, both resistance and B-value ±1%. The 9.5cm leads make these likely to be the easiest to use with thermometer probe covers, but they are more expensive.  I bought 4 @ 87¢, so as to keep the cost per thermistor type below $3.50. Note: the specs give different B-values depending which pair of temperatures used—I’ll have to look to see if they have specs for higher-order models of the resistance as a function of temperature.

The setup at 110°F, showing 4.60kΩ as the resistance.

I’ll try the epoxy-coated ones with the 4cm leads first. The first step is calibrating one with an ohmmeter. I used clip leads to connect a cheap multimeter to the thermistor, then dunked the thermistor in a glass of warm water with a thermometer (note: we’ll need to get some thermometers for this lab). The thermometer I used is a pasteurizing thermometer that I’ve had for years—it is, unfortunately, calibrated in Fahrenheit, not Celsius. Of course, we ideally want temperature in Kelvin.

I put a table of the measurements on a separate page, to avoid cluttering up the post with a table of 28 measurements.

I don’t expect many of the students will have the patience to make 28 measurements, but if we provide some different hot water sources (water boiled in a teakettle and ice water in a thermos), they should be able to make 10 measurements across a wide range of temperatures. I stopped at 28 measurements, because the alligator clip broke the wire and I didn’t feel like stripping more of the insulation and reconnecting.

I tried to fit the Steinhart-Hart equation to the data, where R is the resistance in Ω and T is the temperature in degrees Kelvin. But gnuplot got as good a fit using just A and B as using the third order fit, with providing an excellent fit.

Fitting the first two terms of the Steinhart-Hart model for thermistor behavior.

Simple Arrhenius fit for the data. When I fit the equation , which is the equation most often used in thermistor specs, I get A=0.24Ω and B=3157°K, which is not that close to the spec (10kΩ @ 25°C, B=3435±35°K, so A=0.0992Ω). Note that the spec curve fits the data quite well for warm temperatures, but deviates badly for cold ones.

There could be systematic problems with either my temperature readings or my resistance readings. The multimeter is more suspect than the thermometer, but the readings would have to be off by 500Ω to get that sort of error in the B-value. The numbers look particularly bad around 110°F. I think I need to get some new batteries for my other other cheap multimeter (which I think is a bit better) and see if it gives more reasonable results.

Wait a minute! I have an old Fluke 8060A multimeter (between 26 and 30 years old) that has a bit of a wonky LCD display, and a blown fuse on the 10A input, but is otherwise still probably my most accurate meter. If its batteries aren’t dead, I may be able to use it to get better measurements.

I tried measuring some known resistors, to see if the meters are way off. I tried an 11.8kΩ ±1% resistor: Fluke meter says 11.77Ω and the suspect multimeter says 11.67kΩ, while for a 732Ω±1% resistor, the Fluke meter says 731.1Ω, while the suspect meter says 718Ω. So the suspect meter appears to be reading 1–2% low, while the Fluke meter is within the accuracy of the resistors. So I boiled up some more water and tried another series of readings (the 63 readings are in a table on a separate page to avoid clutter here.)

Note that there are three runs of data: cooling down from boiling, cooling down from hot tap water, and cooling with ice from room temperature. I found it easiest to do this work on the counter in the bathroom, where I could easily adjust the temperature by pouring out some water and adding more hot or cold water. I was also very careful to make sure that the bulb of the thermometer was in contact with the thermistor while making the measurement, so that they were as nearly the same temperature as I could make them.

Let’s see what sort of fit we can get with this data.

The second data set, with 63 data points, is much cleaner than the first data set, and is well fit by a simple 2-parameter model (leaving out the third term of the Steinhart-Hart equation. Because it is hard to read the thermometer to better than 0.5°F, the fit is really quite good.

The data once again does not match the specified B-value of 3435°K±1%, but B=3174°K, though the curves are quite close for warmer temperatures.

The data sheet reports the 3435°K B-value as a B25/85 measurement, that is, it is based on values at 25°C (77°F) and 85°C (185°F).  If we just fit over that range, we can get the B-value up to 3236°K, which is still a long way short of the specified B-value.

Since I now trust that the resistance measurements are fairly good, the large error in the B-value has to be either from the thermometer or the thermistor. Because I don’t have a more accurate thermometer, and I’m not inclined to get one, I’m a bit stuck at this point in determining whether the thermistor meets the spec or not.

Doing a large number of measurements like this took far too long for the first part of a lab.  A lot of the time was spent waiting for the temperature of the water bath to change (or trying to make change by adding water or ice). We’ll probably have to ask for just 5 or 6 values, perhaps providing them with 5 or 6 water baths in thermoses that they can run their thermistors through one after another, to get the measurements rapidly. We will need some decent thermometers, capable of reading to ±0.2°C, if they aren’t too expensive.

Tomorrow I’ll try doing the electronics part of the lab, adding series and parallel resistors and measuring the voltage with the Arduino.

I’m going to need some parts to play with for the circuits course.  While I probably could get the parts I need at work from the Baskin Engineering Lab Support (BELS) staff, it would probably involve a bit of hassle, as there isn’t even a course number for the course yet, and so they’d have a difficult time figuring out which department to charge for the 30¢ and 60¢ parts—the cost in staff time (and my time) would be ridiculous.  So I decided to buy my own parts with my own money from Digikey.  My experience with them in the past is that in-stock parts generally get delivered by US mail within 2 days of ordering (it helps that they are not far away).

One experience we don’t give the students (at least, not until the senior design project) is trying to figure out what parts to buy.  It can be an overwhelming task—DigiKey has in stock 10,917 chips that come up in response to a search for op amps. We can reduce that to 1,249 if we restrict ourselves to through-hole rather than surface-mount parts. Adding a request for rail-to-rail outputs reduces that number to 314.  Sorting by price and looking through those under $1 shows many from Microchip Technology, each with slightly different specs.  I don’t see any way that a student in a beginning circuits class could make sense of most of the specs.

Thermistors are almost as bad, as there are a lot of specs for them also, and the price range is huge.  You have to know that you want NTC (negative thermal coefficient) devices, which gets you down to 1,369 thermistor types.  Eliminating surface mount parts reduces the number to 479, ranging in price from 23.5¢ each to $20 each.

I’ve decided to play with three different thermistors:

• Vishay BC Components NTCLE100E3103JB0 a very cheap (23.5¢ each in quantities of 10) 10kΩ thermistor with B-value 3977K).  There is high variation in the resistance (±5%), but low variation in the B-value (±0.75%).  These are glass-bead thermistors with short leads and will need some sort of waterproofing for the labs.
• The epoxy-coated Vishay BC Components NTCLE413E2103F520L has 50mm leads and is epoxy coated, but with the warning “Not intended for fluid immersed applications or continuous contact with water.”  It is a 10kΩ thermistor with B-value 3435K, both ±1%, and costs 34.9¢ each in quantities of 10. It may be waterproof enough for the relatively short duration of the labs, and the 2″ leads may make it easier to use with disposable thermometer covers from the drugstore.
• Murata Electronics North America NXFT15XH103FA2B100 a 10kΩ thermistor with B-value 3431K, with low resistance variation (±1%) and moderate B-value variation (±1%).  Note: the specs give different B-values depending which pair of temperatures used—I’ll have to look to see if they have specs for higher-order models of the resistance as a function of temperature. Although these thermistors cost more (66¢ each in quantities of 10), they have 100mm insulated, flexible leads, which should be long enough that we use these in a coffee-cup water bath, though they come with the warning not to use them in wet or humid locations, nor “Places with salt water, oils, chemical liquids or organic solvents”.  The long flexible leads may make this one the easiest to use with disposable thermometer covers.

It looks like I’d have to go to $2–$4 per part for thermistor probes with a brass, copper, or plastic sheath, and even then the manufacturers don’t say that they are waterproof.

I also decided to get myself some op-amp chips to play with, since we will certainly be assigning some op-amp labs. Because I don’t have a bench power supply, I want to use a single power supply, like a 5v wall wart (or the 5v supply for the Arduino).  I also want a DIP package, so that I can use the op amp on a breadboard.  I looked for cheap op amps on Digikey, and the best choice I found was a Microchip Technology MCP6002-I/P (33¢ each in quantities of 10) for a dual op amp with rail-to-rail output.  It is a bit slow (1MHz gain-bandwidth product, 0.6V/µsec slew rate), but has a low input bias current (1pA) and will run on a single power supply anywhere from 1.8V to 6V, so should be easy to use with batteries or the Arduino power supply.

I will have to be careful not to blow up the chips with my function generator, though, as I believe it has a 10V peak-to-peak output.  Maybe I won’t have to worry about it—I just tried to turn on my function generator to check the output voltage, and it won’t turn on.  The fuse looks ok, but I don’t even get a power-on light, much less any signal at the output.  I don’t know whether I want to try debugging it or not, given that I don’t even have a manual for it, much less a schematic.  It worked fine the last time I turned it on, so I’ve no idea what the problem is.  I suppose I should have expected it, buying cheap, old equipment on e-bay, but I didn’t expect the function generator to fail after I had checked that it was working.  It will be harder for me to develop a lab that uses a function generator, though, if I don’t have a functional one to test the lab with.  I wonder whether it is better to try to fix the one I have or get another one.

The students will have Agilent 33120A Function/Arbitrary Waveform Generators to work with, which are very nice instruments, but out of my price range ($1300 refurbished on e-bay, $2200 MSRP).  I could get a cheap Victor VC2002 for about $130, which is about as good a price as the used stuff on e-bay.

I’ve decided to do a lot of my musing about the course design on my blog, so that others could contribute to the course design (or at least participate vicariously).  I think that having an open log of our thinking on the course design will be useful to grad students or new faculty who are having to do their own course designs, to show how us old farts do it (whether they wish to copy our methods or avoid using them).

The relevant posts so far are

Changing teaching plans
More on electronics course design
Yet another project idea
Another way to think about course design

I’ve got my son working on Arduino software to act as a data logger, so that students can have an easy-to-use tool that requires no programming, but which is easily modified if they want to do their own programming.  He has Arduino code for alpha testing already, and I think he’ll have a user interface ready for beta testing by the end of the week, but he’ll only have tested it on a Mac—we’ll need to get him access to a Windows machine to do testing there, because there are some operating system dependencies in talking to USB devices like the Arduino from a Python program. He’s been consulting with me on desired specs for the data logger, but doing all the coding himself. It is good practice for him both in interrupt handling and in user-interface design. He’s also having to think about portability for the first time, as the data logger has to run on Windows and Mac OS X (I think that Linux users should have no trouble with the version that works on Mac OS X, but we probably won’t be testing it). He’ll have to write user documentation and installation instructions also. Some of the packages he likes to use (like PyGUI) are enough of a pain to install that he’ll probably provide a stripped-down interface without a GUI for those who want to do minimal installation (Arduino software, Python, and PySerial are only essentials).

The first lab I’ve been thinking about is for temperature measurements. For the small temperature ranges normally needed in biosensor applications, the sensitivity, low thermal mass, and low cost of thermistors make them probably the best approach, and I think that they are what are used in the cheap digital oral thermometers sold in drug stores.  I wonder what techniques the manufacturers use to get medically acceptable calibration for those devices.

I’ve been thinking about the thermistor lab—it seems like we could do that in stages: first just reading resistance with a meter, then adding a series resistor to make a voltage output, then adding a parallel resistor to try to linearize the exponential curve a bit, finally adding larger series resistors and an amplifier to avoid self-heating currents through the thermistor and to allow nearly the full range of the ADC to be used.  This series of lab exercises could be spread out over the quarter, as students learn more about circuits.

For them to calibrate the thermistor, we could use hot and cold water baths, if the thermistor was in a waterproof package. From what I can see, that raises the price of a thermistor with leads from about 25¢ (for something like the NTCLE100E3333JB0 by Vishay BC Components) to $1.55 (for USP10982 from US Sensor) or $3 (for USP10973RA from US Sensor).  [Prices from DigiKey 10-unit price.]

I think that having the students do their own waterproofing is probably not a good idea.  Potting components gets to be a mess, and adding a large blob around the thermistor will slow its response time a lot.  I wonder whether using 5¢ disposable thermometer probe covers would work, or whether they tear too easily.  I probably need to look at some at the drug store, to see whether there is thicker one on the market that the cheap thermistors would fit into.

If waterproofing a cheap thermistor turns out to be too difficult, we need to think about whether to use the more expensive parts or work out some cheap, measurable temperature sources that are not wet.  We could make something like is used in PCR machines, with a couple of blocks of aluminum and a Peltier device, but I don’t think that the price is worth it—better to use the sort-of waterproof probes, a cup of water, and a thermometer.

I’ve noticed that for some applications, people are choosing voltage-output temperature sensors that rely on the thermal
coefficient of a transistor, rather than on a thermistor, like the MCP9700-E/TO from Microchip Technology (25 cents).  They have a fairly linear 10mv/degree C output, but their absolute accuracy is even worse than thermistors. These may be a better choice than thermistors in many applications, but would not provide the same teaching opportunities for a circuits class.

Using a thin-film platinum resistor temperature sensor (RTD) like the US Sensor PPG102C1RD would allow more accurate temperature measurement without calibration. With calibration, RTDs can be the most precise electronic temperature sensors, though I don’t know if the high precision is available in thin-film resistors, or only in the more expensive wire-wound ones. I suspect that repeatability from part to part is higher in the wire-wound RTDs, but that the thermal coefficients are the same, so that calibrating at one temperature should give about equal accuracy either way.

The naturally linear response of RTDs (100Ω at 0°C and 138.5Ω at 100°C in a very straight line) does not lend itself to as much circuit design as thermistors. On second thought, converting the 3850 ppm/°C resistance change into a voltage range readable by the Arduino ADC is not a bad circuit exercise, particularly if self-heating is to be avoided, though it is not as difficult as flattening the highly nonlinear response of a thermistor.  The biggest problem with RTDs is their price: at over $10 for a bare sensor they may be too expensive for class use.

Another possible temperature sensor is a thermocouple, which generates a voltage based on the temperature difference of two electrically connected junctions of dissimilar metals. One article in the engineering toolbox claims that thermocouples are cheap and RTDs expensive, and I think that is true if you are looking for high-temperature devices (like thermocouples for detecting pilot lights in furnaces), but not so true if you are looking for careful measurement in corrosive wet materials (like most biosensing applications). See Choosing and using a temperature sensor for more info comparing RTDs and thermocouples. Thermocouples have relatively low precision and sensitivity, and they measure only the difference in temperature between two points, and so are probably not very interesting for biosensing.

Action plan for testing out a temperature measurement lab:

• Get some thermistors and some thermometer probe sheaths and see if I can make adequate temporary waterproofing for pennies per student.  I’ll probably have to solder on wires to lengthen the leads.
• Try calibrating thermistors using a multimeter, cups of hot and cold water, and an accurate thermometer.
• Try reading the thermistor using a voltage divider and the Arduino ADC.  Plot the temperature and Arduino reading over a wide temperature range (say, as a cup of boiling water cools).
• Try linearizing the thermistor readings  using a parallel resistor and voltage divider.
• Try designing an amplifier to read the thermistor with much lower current through it (and so less self-heating).

Did you ever look for a cheap temperature monitor capable of collecting up to six sensor readings?

Johnathan Hottell needed to monitor the engine temperature of his LB7 Duramax diesel truck to avoid over-heating problems in hot days. Looking for commercial products, he found several quite expensive scanners (around hundreds of dollars), so he decided to build its own monitor using an Arduino Pro Mini, six NTC thermistors and a Nokia 3310 LCD screen to display the temperature readings.

The result, which is described here in great details, cost around 40 $.

Via: DangerousPrototypes