Gas station without pumps

2015 May 21

Pulse monitor lab part 2 and power-amp lecture

Filed under: Circuits course — gasstationwithoutpumps @ 22:18
Tags: , , ,

Wednesday’s lecture covered a reasonable amount.  I went over PWM again, stressing the key concept: that the relevant value is the average value of the output. I showed the derivation of the average value from the high value, low value, and duty cycle.  I introduced nMOS (and, to a lesser extent, pMOS) field-effect transistors, and showed how they worked as switches, which is the only way we’ll use them.  I introduced both nMOS low-side switches and cMOS output stages, and talked about shoot-through current.

I did not get to comparators, open-collector outputs, and how to create PWM signals from a comparator and a triangle-wave generator, which is the meat of tomorrow’s lecture.

I spent over 9 hours in the lab again today, because I’ve promised the students that I’ll be in the lab 5 p.m.–7 p.m Tuesdays and Thursdays for the rest of the quarter, but the students were done with this week’s lab by 6 p.m.  I think all but one or two of the groups got working pulse monitors.  Debugging was difficult today.  The most common problems were

  • Wires in the wrong holes on the breadboards—usually an off-by-one error.
  • Phototransistor connected up backwards. Students kept thinking in terms of “long lead” and “short lead” and somewhat arbitrarily assigned a positive and negative meaning to them, without going back to the datasheet to see which was the collector and which the emitter.  This was difficult for me to debug, because the phototransistors had wires soldered on and were covered with electrical tape, so I could not see the original wire length nor the flat on the package, and had to trust the students’ claims about which wire was which.  In one case the problem was only debugged after I connected my LED and phototransistor (where I knew the color coding I’d used) to the student’s circuit and saw that the circuit was working.
  • Centering the high-pass filter and second stage of the amplifier at 0V, even though we were using a single-sided power supply, so they needed to make a virtual ground.
  • Swapping the wiring of the LED and the phototransistor.
  • Insufficient gain in the second stage.
  • Difficulty getting appropriate amounts of pressure on the finger to get a good pulse fluctuation.

The students having the most trouble had not prepared a schematic to work from or had very sloppy un-color-coded wiring, or both.  I’ll have to remind students that taking a half hour at the beginning to set things up carefully can save hours of debugging—too many want to dive in and wire up stuff without a clear idea what they are going to do, just hoping that it will somehow get fixed by the group tutor or me debugging their work. I refuse to do debugging for a group without a schematic, and in some cases I gave students some properly colored wire and asked them to rewire the circuit so that it could be debugged.

One student was unable to get a pulse reading from his finger on anyone’s circuit (including mine).  I don’t know what the difficulty was—he attributed it to too much caffeine today, so that he could not hold his finger steady in the block.  I suspect that he might have been pressing down too hard and squeezing the blood out of his finger.  One student even managed to get a pulse  reading through fingernail polish (she was wearing a red polish, which apparently was transparent enough to still work).

I had set up my transimpedance amplifier (which has adjustable gain from 66MΩ on up) with an oscilloscope for students to see what a good signal looked like.  There is a lot of 60Hz noise capacitively coupled in, but I was getting a 0.5V pulse signal with only about 200mV of interference.  I probably want to lower the corner frequency for the low-pass filter, to reduce the 60Hz signal further (one group that had miscomputed their corner frequency had very low interference, but their signal was also attenuated too much—I think that a reasonable compromise position can be found).  Even groups with very high 60Hz interference were able to get clean signals by sampling at a multiple of 1/60th of a second (20Hz or 30Hz, for example)—the aliasing eliminates the 60Hz signal, turning it into a DC offset.  The only ones who ran into trouble with 60Hz interference were ones who had the gain set so high that the 60Hz interference caused clipping, obscuring the pulse waveform added to the interference.

I expected this lab to be a little easier for students than it turned out to be, but I think that several students who had been having trouble with some of the concepts (like the virtual ground) were now getting the idea.  I hope so, as most of what they did in this lab will be directly applicable to the EKG lab in the last week of classes.

2015 May 19

Pulse monitor lecture and lab

Filed under: Circuits course — gasstationwithoutpumps @ 23:13
Tags: , , ,

I didn’t get a blog post up for last Friday’s lecture, because I spent the weekend alternately socializing with my in-laws and grading. Monday night was spent grading and working on the next chapter of the book, and most of today (Tuesday) was spent working on the book.

Last Friday was the one day I talked about pulse monitors, photodiodes, phototransistors, and transimpedance amplifiers.  It was a rather packed lecture, but seemed to go all right.

Monday’s lecture started out OK, answering questions about the homework exercises the students were about to turn in, but then fell apart when I tried to cover real power and pulse-width modulation.  Both presentations seemed too vague to me—having neither mathematical rigor nor clear exposition.  The written presentation I wrote for the book is much better than the lecture, which is a bit unusual for me.  I think I need to start getting more sleep, if my presentations have deteriorated to that level.

The prelabs I graded Monday night indicated to me that many students can’t follow a long chain of computations for computing signal levels, even when the chain is broken down into single steps for them.  The problem was estimating how much photocurrent we would get from an LED shining through a finger, starting from the power into the LED, figuring out how much light that would produce, how much would be absorbed by hemoglobin, how much scattered, how much collected by the phototransistor, and how much photocurrent the transistor would produce.  Some students managed to get about 80% of the steps, but a lot got only parts of one step right.

Today’s lab (the first half of the optical pulse monitor lab) took too long, because the students wasted a lot of lab time trying to redo the prelab computations that they had messed up over the weekend, rather than moving on to measuring the photocurrent as I had asked in the lab.  Only a few of the groups got as far as I thought they should have in the first half of the lab: getting their transimpedance amplifiers working and showing a pulse-rate fluctuation. They’ll be set up for adding a high-pass filter and second gain stage on Thursday, and recording pulse waveforms to pass through the digital filter script I provided them.

I spent a long time in the lab today, since I promised the students a 5–7 p.m. lab time for make-up or redone labs. I ended up in the lab from before 10 a.m. to after 7:30 p.m., and I expect to do that every Tuesday and Thursday for the rest of the quarter (2 and a half more weeks). I spent the time when I wasn’t helping students working on revising the class-D power amp chapter of the book, so that I could release the new draft of the book to the class—they’ll have to start work on the design of the class-D amplifier before they have quite finished the pulse monitor, or they won’t have enough time—there is no class next Monday for answering questions.

2015 May 15

Blood pressure lab part 2

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

I spent long hours in the lab yesterday (10 a.m.–6:30 p.m.), because students were not as far along as I had thought by the end of Tuesday. I stay in the lab until all the students are finished, even if that is a couple of hours past when the lab should end. A lot of students were still debugging their breadboarded instrumentation-amp circuits 2 hours into the lab session, when I had thought that they would be soldering after at most an hour more breadboarding.

Debugging on both the breadboards and the soldered boards took a lot of time, but the problems were pretty much the standard ones:

  • power not connected
  • wire missing
  • wire to wrong location
  • power supply hooked up backwards to one of the chips
  • bent pin on chip not making contact with breadboard

A couple of groups asked me for debugging help but did not have a drawn schematic to work from.  As I had said earlier in the quarter, I would not help them debug unless they had a schematic to work from.  (I think in both cases the problem was that they had connected up one wire incorrectly, but without a correct schematic to work from, there was no way that they could detect the error.)  Some students have been a bit sloppy about trying to work out of their heads rather than putting things down on paper, and this sloppiness is beginning to be a problem for them.  It has mainly been the weaker students who have been being this sloppy, so perhaps it has been more the case that they have been trying to work out of other people’s heads—copying bits and pieces from other students rather than working things out themselves and then implementing it.

I won’t be helping students debug unless they have shown some effort at making their designs debuggable (like having a clean schematic before they wire things up).

I’m not 100% sure, but I think that all but one group got a soldered instrumentation amplifier working and a blood-pressure measurement run done with it.  The one group that didn’t get that far did have a breadboarded amplifier working.

There were some students missing due to illness, so I’ll probably have to arrange some time next week for make-up lab times.  I’m not sure when that can be.

2015 May 14

Blood pressure lab

Despite fairly poor prelab homework turned in, the first half of the blood pressure lab went well.  After seeing how poorly students were doing on breaking down the problem into pieces (perhaps the main transferable engineering skill I’m trying to get them to develop), I ended up giving them more explicit instructions on the board at the beginning of lab:

  1. calculate sensor voltage difference for 100mmHg with 3.3v power
  2. measure sensor voltage difference for 100mmHg with 3.3v power (also 0mmHg and -100mmHg)
  3. determine upper and lower inputs of voltage for instrumentation amp INA126P from the data sheet, using worst-case rather than typical specs (“worst-case” meaning the smallest remaining voltage range)
  4. use Vout-Vref = G(V+ – V) to determine maximum gain to avoid clipping if input swing is +-180mmHg (+-24kPa)
  5. compute needed gain resistor, wire it up (and virtual ground)
  6. measure voltage at output of instrumentation amp at 0, +100mmHg, -100mmHg
  7. compute gain needed in second stage to get maximum range (without clipping) at final output
  8. wire up op amp and measure final output voltage at 0, +100mmHg, -100mmHg
  9. What is Vout as function of pressure?
  10. record with the PteroDAQ a blood pressure measurement with pressure slowly decaying from 180mmHg down to 40mmHg (not too slowly, or your hand will get swollen).  Check for clipping at high end.  Check that you are using nearly the full range. Check that pulsations are visible when plotting the data.
  11. Use bandpass-filter.py to filter the first channel of the recording (later channels will be discarded)

I may have to put some version of these instructions in the book, though this sort of hand-holding is precisely what I’m trying to cut out in the “descaffolding”.  I’m afraid we’re training a generation of technicians rather than engineers—they’re good at following very explicit instructions, but not so good at breaking problems down into smaller problems.

With these explicit instructions, most of the students managed to get breadboard versions of the pressure sensor amplifiers working. I may have to help out bench 4, as it turned out that their pressure sensor seems to have a 0.7mV offset (which is pretty big—way out of spec).  They’ll have to decide whether to change benches to get a different sensor, compensate for the sensor offset electronically, or compensate for it in the post-processing of the data.  Any of these solutions would be acceptable, but they aren’t all equally easy.

The students needed less help than in previous years in the lab, so I think that having the students struggle with the prelabs, even if they don’t get the answers right, is helping make the lab time more efficient—they only have to get past a couple of misunderstandings, rather than trying to learn all the material for the first time in lab, as so many did the last couple of years.

In lecture on Wednesday, I went over blood pressure waveforms defining pulse rate, systolic pressure, and diastolic pressure, and talking about the frequency ranges of the pulse rate. I then explained to them how the filter program was run (many students still don’t know about the “<” and “>” conventions for standard in and standard out on command lines). I also showed the gnuplot trick that allows using standard out from a program in place of a file in a plot command:
plot '< python bandpass-filter.py < pressure.data' using 1:3 with lines

I did not explain how digital filters worked, but I did say why I chose Bessel filters (to preserve as much of the time-domain structure of the signal as possible).  In response to a question I also explained the effect that choosing 5th order filters had (the rolloff as f5 or f–5, rather than f1 or f–1 as with a first-order RC filter). I also explained that the computation required more and more precise numbers as the order got higher, and that 5th-order was a good tradeoff between needed precision and fast rolloff.

One thing that I didn’t get to was explaining that “filtfilt” does the filtering twice: once with time going forward and again with time running backwards. The time reversal cancels a lot of the distortion in the time domain (so the choice of Bessel filters is not crucial), but doing two passes also doubles the order of the filter, so that the rolloff is really f10 or f–10.

I did remember to tell students that they needed to have the scipy package installed in order to run the filter program, and that if their python was installed from python.org that they could probably just run “pip install scipy”. At least one student in the class is using the Anaconda installation of python, which already has scipy installed.

At the end of the lecture I had only 10 minutes left, so I did not get into the internals of instrumentation amplifiers (needed for the EKG lab at the end of the quarter) nor transimpedance amplifiers (needed for next week’s lab). Instead I covered the voltmeter impedance measurements I made last week, explaining how I did the measurements, how I did the fitting, and what the results were.  In particular, I mentioned that swapping the sets of leads changed the behavior, so the extra capacitance (beyond the 100pF of the meter itself) appears to be coming from the leads.  I sent the data files and gnuplot script to them via e-mail, after one student requested them.

2015 May 13

Checking on my pedagogy

Filed under: Circuits course,Uncategorized — gasstationwithoutpumps @ 08:40
Tags: , , ,

Mark Guzdial just posted some of his pedagogical advice for teaching beginning programmers in How to Teach Computer Science with Media Computation | Computing Education Blog.  I decided to check how much of this I follow in my applied electronics course, which is aimed at a similar level of student (college students with no previous exposure to the content, and perhaps a belief that the material is not relevant or over their heads).

Over the last 10 years, we have learned some of the approaches that work best for teaching Media Computation.

  • Let the students be creative. The most successful Media Computation classes use open-ended assignments that let the students choose what media they use. For example, a collage assignment might specify the use of particular filters and compositions, but allow for the student to choose exactly what pictures are used. These assignments often lead to the students putting in a lot more time to get just the look that they wanted, and that extra time can lead to improved learning.

I’ve not allowed students much room for creativity in the course.  Of the 20 3-hour lab sessions, only one is a “tinkering” lab that allows students to explore several different things.  It may be the most fun of the quarter, and I should look into more ways to let students play with electronics design.

  • Let the students share what they produce. Students can produce some beautiful pictures, sounds, and movies using Media Computation. Those products are more motivating for the students when they get to share them with others. Some schools provide online spaces where students can post and share their products. Other schools have even printed student work and held an art gallery.

I’ve not had the students share their work.  This is difficult to do with the small electronics projects they do—unlike media computation, there isn’t an art by-product of the design process.  The electronics, being hardware and often on breadboards, is much harder to share than software, and the output is generally not easy for average students to appreciate. (EKG traces, though interesting, are not really art-gallery material.)

  • Code live in front of the class. The best part of the teacher actually typing in code in front of the class is that nobody can code for long in front of an audience and not make a mistake. When the teacher makes a mistake and fixes it, the students see (a) that errors are expected and (b) there is a process for fixing them. Coding live when you are producing images and sounds is fun, and can lead to unexpected results and the opportunity to explore, “How did that happen?”

I have always coded live in my classes.  All my lectures are extemporaneous improv performances with audience participation.  I certainly show debugging when doing gnuplot scripting live!  For the electronics design, it is a little harder to show debugging, as most of the problems that occur are difficult to debug at the lectern (I don’t usually carry oscilloscopes and voltmeters around with me, though I have taken out my Swiss Army knife to reseat a loose wire in a screw terminal).  Design errors are also hard to show how to debug—introducing fake errors in a design just confuses students, rather than clarifying the debugging process.  Real errors don’t get caught until the circuits are actually built, which takes more time than is available in a 70-minute lecture.

  • Pair programming leads to better learning and retention. The research results on pair programming are tremendous. Classes that use pair programming have better retention results, and the students learn more.

I have students work in pairs for every lab, and I force them to change partners every week.  This frequent partner changing prevents the common problem of one student carrying another through the course, and allows me to deconvolve performance into individual grades (which I have to issue at the end of the quarter). I do see evidence that students working in pairs do a better job on doing the designs than students working alone, though a big part of that may be just that max(a,b) is better than average(a,b)—that is, that the pair does as well as the better of the two students.

  • Peer instruction is great. Not only does peer instruction lead to better learning and retention outcomes, but it also gives the teacher better feedback on what the students are learning and what they are struggling with. We strongly encourage the use of peer instruction in computing classes.

The students do help each other learn in lab—particularly in the afternoon section.  As long as I’m around enough that they check confusing points with me, rather than propagating wrong ideas, the peer instruction works well.  I think that the afternoon lab section has been better about checking with me when they are confused.  A lot of the morning section still seems caught in “answer-getting”, asking their friends for the “answer” rather than for help with the method—that sort of sharing interferes with learning, rather than aiding in learning.

  • Worked examples help with learning creativity. Most computer science classes do not provide anywhere near enough worked-out examples for students to learn from. Students like to learn from examples. One of the benefits of Media Computation is that we provide a lot of examples (we’ve never tried to count the number of for and if statements in the book!), and it’s easy to produce more of them. In class, we do an activity where we hand out example programs, then show a particular effect. We ask pairs or groups of students to figure out which program generated that effect. The students talk about code, and study a bunch of examples.

I’ve not developed a good set of worked examples. Part of the problem is that I have trouble coming up with good design exercises, and I’ve ended up using almost all I’ve come with as assignments, leaving very little for use as worked examples.  I see this as the biggest hole in my book and in my course, and I hope to try to fill it in a bit over the summer.

Another problem with worked examples is that I’m using this course to try to “descaffold” the students, who have been getting far too much fill-in-the-blank sort of labs and homework.  I’m trying to get them from having their hands held for everything to being able to solve many-step design problems in only 10 weeks, which is probably an impossible task. I just wish that other teachers would do less scaffolding, so that the students were used to doing some problem solving and not just rote procedure following.

So I need to come up with worked examples that give students an idea how to solve multi-step problems (subdividing a system into parts, calculating sensitivity of sensors, working out needed gain by working from input and output constraints, … ) without solving the specific problems that they will address for them.

 

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 313 other followers

%d bloggers like this: