First day of S14 circuits class went ok

I went into the class with a long to-do list, and managed to cover the following:

1. Issued permission codes for students with missing prereqs to register ✔ but I forgot that they’d need permission codes for BME 101L as well—I’ll give those out as soon as I get them. The class is up to 9 students, which is still much less than the 20–40 I had projected. I’m going to have to use the same parts next year, so that the over purchase doesn’t cause budget problems.
2. Went over syllabus .✔I showed them the syllabus and managed to go over scheduling of labs, partner work, and online texts, but did not get to some of the boilerplate about cheating and about disability services. ✘ Oh well, it is enough that the boilerplate is on the syllabus.
3. Demoed pressure sensor ✔ and EKG ✔ with PteroDAQ on KL25Z board. I explained that I chose these labs to demo, since they were soldered onto protoboards, and so sturdier than ones built on breadboards. Amazingly, the alpha prototype of PteroDAQ worked fine for the demo. I was even able to illustrate a debugging technique. The EKG seemed to be missing a lot of my heartbeats, so I saved the data to a file, looked at it with gnuplot, and zoomed in, where it became obvious that the problem was that the R pulses on the EKG were shorter than the time between samples. I went back to the PteroDAQ control panel, increased the sampling rate from 20Hz to 120Hz, and took another 30 seconds of samples.  Saving that and viewing it with gnuplot made it clear that the EKG amplifier was working fine, and the PQRST parts of the EKG signal were all quite clear.
4. Ohm’s Law :  The students volunteered this when I asked them the relationship between voltage and current.  Good! ✔
5. Kirchhoff’s Current Law:  Again many had heard of the concept that if charge is not accumulating (steady-state), then the current into a node is the same as the current out of the node. In general, that the sum of all currents into a node is 0. ✔
6. Explained about voltage being a difference between two nodes or across a component, and contrasted that with the current through a component. I implicitly used Kirchhoff’s Voltage Law by introducing the notion of voltage at a node, as the voltage between that node and an arbitrarily chosen node that we call “ground”. ✔
7. I showed them a voltage divider and had them derive the voltage across each resistor (from having the same current), then from there deriving the voltage across the resistors in series (thus deriving the idea that series resistors add). We then solved for I in the Vin equation and plugged it into the equation for Vout, getting the standard voltage-divider formula .✔
8. I introduced the notion of an NTC thermistor (and listed other temperature sensors: PTC thermistor, RTD, thermocouple, bandgap temperature sensor, giving a brief idea when each would be used).✔ I did not plot the resistance as a function of temperature based on the model ✘, but that would be a good thing to do in the gnuplot lesson on Wednesday.
9. I did explain the notion of sensitivity of a sensor: the derivative of the output with respect to the input, and went over (in a general way, with helpful suggestions from the students) how one would go about maximizing sensitivity of a voltage divider with a thermistor and fixed resistor at a particular operating temperature.  I’ll see in lab tomorrow or during the analysis session on Wednesday whether students got the idea or not.✔

It was a very content-full class, but I did manage to get in a number of side remarks:

• reading the lab handouts well before lab, since they weren’t fill-in-the-blanks worksheets, but sometimes had design assignments buried in them.
• partners changing every week, so no one gets a free ride for very long and no one has to suffer with a freeloader.
• no failures on lab reports—just REDO, until the end of the quarter, when all un-redone work turns to F.
• need for perfect schematics. Sloppy schematics will trigger an automatic REDO.
• one of the students asked about the circuits-class t-shirt I was wearing, and I explained that I’d created the shirt for last year’s class and that if students were interested we could do another order this year.

Overall, I’m fairly happy with how the first day of class went.

I’m less happy with the rest of the day, though. In the morning my son accompanied me to the lab to help me set up the Windows drivers and to test PteroDAQ on the Windows machines, but the lab staff had changed the system they used for authenticating administrators, so I couldn’t install the drivers. I knocked on their door (no answer) and sent them e-mail through the request system, but it took them about 3 hours to answer (by which time my son had gone home and I was teaching class). After they had reauthorized me, I spent 2 hours installing Windows drivers on the 12 machines in the lab, so that they could talk with the KL25Z boards.  (Windows is a major pain—I really hate having to deal with it.)  I finally got a chance to test PteroDAQ on the Windows machine, and it didn’t work—I tried installing Python3.4 on one of the machines and that changed the nature of the error, but did not fix it. [Did I mention that the students have to be able to use it on Thursday?]

My son will go in with me again tomorrow (he’s on Spring break) and try to get the PteroDAQ function at least to the level that it is at on the Mac, which is minimally functional under Python3, but with a mysterious failure to open the USB serial port under Python2.7.

I also found out that the missing parts that the lab staff forgot to order have just been shipped from Hong Kong, and should be here next week.  Unfortunately, that includes the USB cables that the students will need to connect up the KL25Z boards. [Did I mention that the students have to be able to use it on Thursday?]

Also, the TA union is probably going on strike system-wide Wednesday and Thursday. I don’t have a TA, but there will probably be pickets at the base of campus and city buses won’t cross the picket lines, so there will probably be some students who can’t make it to class or lab. (I never penalize students for honoring picket lines, but it is going to be very difficult to get back on schedule if we fall behind.

On the subject of possibly falling behind—the campus facilities people are promising some long power outages mid-week one or more times during the quarter—they find it better to make everyone else stop working rather than work on weekends themselves, I guess.

I did get the cups and coffee urn for the water baths needed in this weeks lab transported to the lab, but I found out that the staff had not ordered any 22 gauge hookup wire—there was only a small amount of red and black 24 gauge wire in the lab. The soldering irons weren’t in the lab either, but I need them for tomorrow’s lab. With the small class, I can probably get away with only 5 soldering stations, but I don’t even have a working one I can bring in from home.

One of the students in classed asked about the jumper wires I was using to connect to the KL25Z board.  I was using 9″ long female-female jumper cables with double-male pins (something like these from Adafruit though I probably bought them elsewhere).  I have a very cheap set of male-male jumpers, but I rarely use them, because they are incredibly high resistance (on the order of ohms instead of milliohms).  Adafruit has some high-quality male-male jumpers, which may be easier to work with than the female-female ones that I’ve been using. Sparkfun has a mixed pack (half M/M and half F/F), but a set of 100 is is $25.

The students are supposed to have double-male header pins in their kits anyway, since the pins are very handy for making oscilloscope probe points on a breadboard.

 

 

 

New modeling lab for electret microphone

Last year, in Mic modeling lab rethought, I designed the DC measurement of an electret microphone around the capabilities of the Arduino analog-to-digital converters:

Circuit for measuring DC characteristics of an electret microphone. The four labeled nodes are connected to the Arduino.

• The highest voltage allowed is 5v and the lowest is 0v.
• The resolution is only 10 bits (1024 steps).
• The steps seem to be more uniformly spaced at the low end of the range than the high end (so differences at the high end are less accurate than differences at the low end).
• The external reference voltage AREF must be at least 0.5v (this is not in the data sheet, but when I tried lower AREF voltages, the reading was always 1023).

Test fixture for measuring I-vs-V DC characteristics of electret microphone.

This year we’ll be using the KL25Z boards, which have different constraints:

• The highest voltage is 3.3v and the lowest is 0v.
• The resolution is 16 bits (15 bits in differential mode).
• Differential mode only works if you stay away from the power rails—clipping occurs if you get too close.
• The external reference must be at least 1.13v.  With less than a 3-fold range for the external reference, varying the external reference to get different ranges seems rather limited.

I think I’ll still have the students start with using the multimeter and the bench power supply to measure voltage and current pairs for 1V to 10v in steps of 1v.  But then I’ll have them wire up a different test fixture. The resistor R2 is one that students will have to choose to get an appropriate measuring range. Resistors R3 and R4 keep the voltages for the differential measurements E20–E21 and E22–E23 away from the power rails. I tried using smaller values, but 200Ω was not enough—I still got clipping problems. So 63mV is too close to the rails, but 275mV seems fine.  I suspect that the limit is around 100mV to 150mV, but I did not try to narrow it down.

I found that the differential measurements had less noise than single-ended measurements, despite having a resolution of about 100µV rather than the 50µV of single-ended measurements. Doing 32× hardware averaging also helped keep the noise down. (Note: the data sheet for the KL25 chip does claim a higher effective number of bits for differential measurement than for single-ended measurement, perhaps because of reduction in common-mode noise.)

I was able to get fairly clean measurements with just two different resistor sizes, to which I fit 4 different models:

• linear resistance:
• constant current
• blended:
• blended with exponent:

 

The blended fit with the extra exponent on voltage does a pretty good job of fitting over the full range (it looks good on a log-log scale also)

Because of the large characters used for the data points, the lines look fat, but the noise level is fairly small—about ±300µV Some of that may be due to the movement of the potentiometer, as the voltage and current aren’t measured at precisely the same time, but I suspect most is electrical noise in the processor itself.

Panicking about circuits class

I’m entering panic mode for the Applied Circuits class that starts tomorrow.

• I don’t know what procedure to tell the students to follow to get their parts kits. Last year, I bought the parts myself and sold the kits to the students, but this year there is a lab fee and the students have to get the parts from the lab support staff.
• I haven’t heard from the lab support staff that the parts kits are ready, but the students need them before Tuesday’s lab.  The last message I got was that they had forgotten to order some of the parts from China and were doing a rush order.
• I don’t know whether the support staff will have the soldering stations in the lab by Tuesday.  (We probably won’t need them until Thursday, though, so that is not critical.)
• We’re using KL25Z boards for the data acquisition system this year, but my son is behind schedule on implementing the new software, which we’re calling PteroDAQ. I’ll have my first chance to test alpha-release software this evening, and we’ll have to install it on the Windows machines in the labs tomorrow morning. The code has been massively refactored, and I’m worried that it will be fragile for the next couple of weeks. The new GUI looks good, and the new code should be much easier to add features to—I’m just keeping my fingers crossed that enough of the functionality will be there for the students to do the first lab.
• Not enough students enrolled, so I’ll be having to issue permission codes tomorrow to let students in who don’t have the Physics E&M course. I’m hoping that doesn’t cause problems when we get to capacitors, RC time constants, and complex impedance—I won’t have time to teach them everything about capacitors. I’m also hoping I don’t get any late adds, since arranging for them to make up labs if they don’t get their parts kits by Tuesday’s lab will be a real hassle.
• I’ve written and released the syllabus, a schedule of labs and lectures, guidelines for design reports, a study sheet (which they don’t need yet) with everything that they need to memorize for the course, and the first week’s lab handout. I’ve started rewriting the second week’s handout and should have that up tomorrow or Tuesday.  I’ll try to do two each weekend, so that I can be done with the lab handouts by the middle of the quarter.  The rewrites take me a long time, and the new lab on transimpedance amplifiers and phototransistors for an optical pulse monitor will probably take me much longer to write.
• There’s a lot of material to cover tomorrow:
  • Standard administrivia: office hours, lab times, organization of the class, texts, evaluation, … . I’m going to race through this stuff.
  • Demoing some of the labs from later in the quarter. Most likely the pressure sensor and EKG, since those are soldered boards and won’t have as high a risk of failure as carrying around a breadboard.  I’ll have to remember to put on EKG electrodes after my shower tomorrow morning. I should probably test the boards at home also. I demoed the pressure sensor just last week to show a visitor my son’s data logger (the old Arduino one, since PteroDAQ was not ready), so I think that is ok, but I’ve not tried the EKG since last year.  I’ll bring in an Arduino board with me, just in case PteroDAQ fails in the demo.
  • Ohm’s Law (I hope they remember this much from high-school physics)
  • Kirchhoff’s current law
  • Voltage dividers
  • Intro to thermistors
• I’ll probably have to talk about installing gnuplot in lab on Tuesday, as I want to do hands-on gnuplot scripting in lecture on Wednesday. That’ll have to come at the end of the lab, though, as I want to make sure that everyone gets a lot of thermistor resistance readings at different temperatures.
• Last year I loaned a bunch of the coffee cups I had bought (to use as water baths in the thermistor lab and as salt-water baths for the electrode lab) to another instructor for his sensors class. I never retrieved them, so today I went down to the thrift store and bought another 8 cups for $4. I’ll have to remember to pack them in my panniers tomorrow.
• The cabinet in the lab where the secondary containment tubs are kept is locked and I’ve forgotten the combination. I’d better remember to get that tomorrow!
• On Tuesday I’ll have to remember to get ice and to heat up the coffee urn to get some hot water for the thermistor lab.  I wish there were a way I could give the students somewhat hotter water, since the holding temperature for coffee is only 85°C.  Last year I had trouble running out of ice also, but I think I can get more from the 2nd floor lab this year.

My son gave me an alpha release of PteroDAQ just before dinner tonight, and I tested it out. It isn’t fully functional yet, but it is pretty close. I sent him back a prioritized list of bugs to fix, and I think we should have a usable beta release by tomorrow morning. Documentation and more advanced features will have to wait until later in the week.

By 10pm, most of the bigger bugs were fixed, and I sent him back for another round of more minor fixes. Right now I’m only looking for the analog voltages being read correctly, not the digital pins, and I’m only looking at the timer-based triggering, not the external triggering.  Both of those can wait until later in the week.  I would have liked to have been at this point 2–3 weeks ago, so that I could really stress-test the code before releasing the students on it, but they’ll have to put up with being alpha testers.

What makes teaching programming difficult?

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.

Exam day for freshman design seminar

Thursday the students turned in their final design reports (which I have not read), and showed me their prototypes.

None of the groups had working prototypes, because all of them started too late on acquiring parts and building. I will have to create and enforce a schedule next year that gets them started on prototyping much earlier. A lot ran into the problem that electronics parts need to be mail ordered, and that introduces a few days delay. Others ran into problems they had not expected (like that styrofoam coolers can’t be sold in Santa Cruz—a problem for the incubator group).

I went with two of the groups over to an electronics lab to help them debug the prototypes that they had started.

The incubator group had a thermistor temperature measurement circuit and Arduino program that was always reporting freezing temperatures. I walked them through measuring the thermistor resistance (seemed ok, and changed if the thermistor was warmed by holding it), measuring the voltage from the voltage divider (seemed ok, and went up if thermistor was warmed), looking at the raw reading from the Arduino (again, looked ok), and looking at the reading-to-temperature conversion routine (did not have a return statement, so was always returning 0).

The PCR machine group had two Peltier devices, one of which seems to have been damaged (open circuit with multimeter). I helped them debug their H-bridge circuit—they had it working when there was no load (though they had not verified that it did so), but the Peltier device was too big a load, and the H-bridge had a short-circuit protection circuit that turned off the H-bridge after 50μsec.  The Peltier device needed about 10A, and the H-bridge shut down at 8A.  Their power supply was only capable of delivering 1.5A anyway, so the Peltier device would not have cooled or heated the block fast enough anyway.

The centrifuge group had demoed their project earlier in the day.  Their design was primarily mechanical, and they were still having troubles with it not being stable. Based on the vibrations of their motor, I think that they were only getting up to about 600 RPM, not the 3000–4000 RPM that they wanted. The limitation may have come from an unbalanced rotor.

I think that next year I want to discourage mechanical design projects, because we don’t have facilities to do much construction and debugging of mechanical designs (and I have less expertise to help them). Electronic design and programming are fields that I can help them more with and which we have better facilities for.

The biggest changes for next year are

• more programming exercises with Arduino (including thermistor or phototransistor)
• start project sooner
• weekly lab time
• deadlines for parts ordering
• maybe enforcing one design project for entire class (with different teams trying different approaches)