Posts with «engineering education» label

Fifth day of freshman design seminar

Today we continued the design exercise I started last week (see also 4th class) designing a photospectrometer.

I started the class by collecting the work I had asked them to do on fleshing out the design of the photospectrometer, which I have not read yet.  Just glancing at the pile, it looks like most wrote very little, and just drew a picture of the components we talked about in class, not adding much. I’ll know more about the class once I’ve had a chance to look at what they did more carefully.  I have asked them to mail their work to the class e-mail list by tomorrow night, so that the rest of the class can see what everyone has done.

I then told them that we’d do some electronics and computer programming, since many of them had requested that on the first-day survey, and that we’d use Arduino boards to do that learning.  I suggested that they get Arduino Uno Rev 3 boards as being the current standard (about $30), but told them that almost any Arduino board that used an ATMega processor would be fine—the older boards, like a Uno that is not Rev 3, are often half the price.  They can probably get the boards from the University through BELS (the lab support group for the engineering labs), but it might be cheaper on line.

I then asked them for some details that they had added to the photospectrometer design.  The first one to come up was the photodetector, so we started talking about different photodetectors. They came up with photodiode, photomultiplier, and photocell, to which I added phototransistor and photoresistor.  I asked them what sort of characteristics might be important to a photodetector, and (with some prompting) got them to come up with the ideas of sensitivity and which wavelengths the detector was sensitive to.

One student came up with “resolution” for the sensor, and I took that as an opportunity for a digression into the differences between accuracy, precision, and resolution.  I also talked about resolution being a property of the whole system (how many digits were in the numbers), but that there was a property of sensors that was related—how much noise they had. Sometime later in the class (I forget exactly when), I talked about Arduinos having a 10-bit analog-to-digital converter, and asked them to guess what that meant.  The only guess was that it meant that there were 10 different levels.  I was actually fairly pleased with this answer, as it got to the notion of resolution, and I could correct it from 10 to 210 without making anyone feel stupid. I told them that they should remember 210=1024, as that was a frequently used “magic” number in computers.

I quickly sketched rough sensitivity plots for phototransistors/photodiodes and photoresistors, and explained that that was why photoresistors were used as ambient light sensors—because of how they matched human visual sensitivity.  I also mentioned the slowness of photoresistors and said that they weren’t used for much for other applications.

I told them how to find datasheets—either by Googling “photodiode data sheet” or by doing a search on Digi-key, choosing the cheapest part that seemed to do what they want, and looking up its data sheet.  I assigned them the task of finding and trying to read a photodiode and a phototransistor data sheet.  I’ll make that more explicit on the class web page later tonight.  I’ll probably give them a part number for one, and make them look for the other from just a description.

I showed them the schematic symbol for a phototransistor (though, unfortunately, not for a photodiode), but I didn’t attempt to explain how it works.  I just told them that the current through the phototransistor was proportional to the light intensity as long as voltage across the transistor was at least 0.7v.  (I’ll have to tell them where to find that information on the data sheet.)  I also mentioned the notion of “dark current”, which prevents the phototransistor from getting down to 0 current.

I then tried to get them to figure out how to convert the current into a voltage that could be measured by the Arduino.  After a few tries, one of them finally remembered Ohm’s Law (V=IR), and they decided they needed a resistance.  I told them that there were fairly constant resistance devices available (called “resistors”) and mentioned the notions of resistor tolerance and that resistors had thermal coefficients, so that the resistance changed as a function of temperature.

I then gave them the phototransistor circuit below (though not the photodiode circuit):

Simple circuits for measuring light with an Arduino. Update 2014 Feb 6: Q1 is intended to be an NPN phototransistor, not PNP as shown here!

We then spent a fairly long time before they figured out that they needed to know what value resistor to use in the circuit. I got them (eventually) to the point where they realized that the maximum light intensity determined the maximum current, and if we set the maximum voltage to be as high as possible while keeping the transistor properly biased, the desired resistor was determined by R=Vmax/Imax. I showed them how increasing the value of R made the circuit more sensitive, but that if we made R too big the circuit would not be able to handle high light intensity.

We then looked at the overall spectrometer design, and saw how the optics coupled everything together: the brightness of the light, the absorbance of the sample, the efficiency of the monochromator, and the sensitivity of the photodetector. I introduced the notion of interface specifications, so that design problems could be divided up among a team, and the need for negotiating changes to the interface specs rather than just “throwing problems over the fence” for some other part of the team to solve. I gave the example of the lamp designer finding out that the initial spec called for an expensive, bright light (like and HID bulb) but being able to reduce the cost and power enormously with a somewhat less bright LED. The change to the spec might be accommodated by shortening the optical path in the sample (but that would need non-standard cuvettes) or by making the light sensor more sensitive (which is pretty cheap to do).

We ran out of time then, so did not get to looking at any other parts of the design.

Some of the students were amazed at how much thinking went into just one little detail of the design (one resistor value). They are used to big-picture, fuzzy thinking, where getting the general idea is what is important, and are not used to sweating the details. Part of getting them to “think like engineers” is getting them to realize that the details do matter.

For homework, I’ll ask them to figure out good values for R1 and R2 for particular parts (or maybe for one part that I specify and one that they choose), based on the data sheets and some light spec. In class on Monday, I’ll build the design they specified, and we’ll test it with the Arduino data logger.  If I happen to pick a bad resistor choice, either because I gave them a bad light intensity to design for or because their math was wrong, we’ll get bad results, and I’ll show them how to debug the design and iteratively improve it.


Filed under: freshman design seminar Tagged: Arduino, bioengineering, engineering education, photodiode, phototransistor, spectrometer, spectrophotometer, spectroscope

Fifth day of freshman design seminar

Today we continued the design exercise I started last week (see also 4th class) designing a photospectrometer.

I started the class by collecting the work I had asked them to do on fleshing out the design of the photospectrometer, which I have not read yet.  Just glancing at the pile, it looks like most wrote very little, and just drew a picture of the components we talked about in class, not adding much. I’ll know more about the class once I’ve had a chance to look at what they did more carefully.  I have asked them to mail their work to the class e-mail list by tomorrow night, so that the rest of the class can see what everyone has done.

I then told them that we’d do some electronics and computer programming, since many of them had requested that on the first-day survey, and that we’d use Arduino boards to do that learning.  I suggested that they get Arduino Uno Rev 3 boards as being the current standard (about $30), but told them that almost any Arduino board that used an ATMega processor would be fine—the older boards, like a Uno that is not Rev 3, are often half the price.  They can probably get the boards from the University through BELS (the lab support group for the engineering labs), but it might be cheaper on line.

I then asked them for some details that they had added to the photospectrometer design.  The first one to come up was the photodetector, so we started talking about different photodetectors. They came up with photodiode, photomultiplier, and photocell, to which I added phototransistor and photoresistor.  I asked them what sort of characteristics might be important to a photodetector, and (with some prompting) got them to come up with the ideas of sensitivity and which wavelengths the detector was sensitive to.

One student came up with “resolution” for the sensor, and I took that as an opportunity for a digression into the differences between accuracy, precision, and resolution.  I also talked about resolution being a property of the whole system (how many digits were in the numbers), but that there was a property of sensors that was related—how much noise they had. Sometime later in the class (I forget exactly when), I talked about Arduinos having a 10-bit analog-to-digital converter, and asked them to guess what that meant.  The only guess was that it meant that there were 10 different levels.  I was actually fairly pleased with this answer, as it got to the notion of resolution, and I could correct it from 10 to 210 without making anyone feel stupid. I told them that they should remember 210=1024, as that was a frequently used “magic” number in computers.

I quickly sketched rough sensitivity plots for phototransistors/photodiodes and photoresistors, and explained that that was why photoresistors were used as ambient light sensors—because of how they matched human visual sensitivity.  I also mentioned the slowness of photoresistors and said that they weren’t used for much for other applications.

I told them how to find datasheets—either by Googling “photodiode data sheet” or by doing a search on Digi-key, choosing the cheapest part that seemed to do what they want, and looking up its data sheet.  I assigned them the task of finding and trying to read a photodiode and a phototransistor data sheet.  I’ll make that more explicit on the class web page later tonight.  I’ll probably give them a part number for one, and make them look for the other from just a description.

I showed them the schematic symbol for a phototransistor (though, unfortunately, not for a photodiode), but I didn’t attempt to explain how it works.  I just told them that the current through the phototransistor was proportional to the light intensity as long as voltage across the transistor was at least 0.7v.  (I’ll have to tell them where to find that information on the data sheet.)  I also mentioned the notion of “dark current”, which prevents the phototransistor from getting down to 0 current.

I then tried to get them to figure out how to convert the current into a voltage that could be measured by the Arduino.  After a few tries, one of them finally remembered Ohm’s Law (V=IR), and they decided they needed a resistance.  I told them that there were fairly constant resistance devices available (called “resistors”) and mentioned the notions of resistor tolerance and that resistors had thermal coefficients, so that the resistance changed as a function of temperature.

I then gave them the phototransistor circuit below (though not the photodiode circuit):

Simple circuits for measuring light with an Arduino. Update 2014 Feb 6: Q1 is intended to be an NPN phototransistor, not PNP as shown here!

We then spent a fairly long time before they figured out that they needed to know what value resistor to use in the circuit. I got them (eventually) to the point where they realized that the maximum light intensity determined the maximum current, and if we set the maximum voltage to be as high as possible while keeping the transistor properly biased, the desired resistor was determined by R=Vmax/Imax. I showed them how increasing the value of R made the circuit more sensitive, but that if we made R too big the circuit would not be able to handle high light intensity.

We then looked at the overall spectrometer design, and saw how the optics coupled everything together: the brightness of the light, the absorbance of the sample, the efficiency of the monochromator, and the sensitivity of the photodetector. I introduced the notion of interface specifications, so that design problems could be divided up among a team, and the need for negotiating changes to the interface specs rather than just “throwing problems over the fence” for some other part of the team to solve. I gave the example of the lamp designer finding out that the initial spec called for an expensive, bright light (like and HID bulb) but being able to reduce the cost and power enormously with a somewhat less bright LED. The change to the spec might be accommodated by shortening the optical path in the sample (but that would need non-standard cuvettes) or by making the light sensor more sensitive (which is pretty cheap to do).

We ran out of time then, so did not get to looking at any other parts of the design.

Some of the students were amazed at how much thinking went into just one little detail of the design (one resistor value). They are used to big-picture, fuzzy thinking, where getting the general idea is what is important, and are not used to sweating the details. Part of getting them to “think like engineers” is getting them to realize that the details do matter.

For homework, I’ll ask them to figure out good values for R1 and R2 for particular parts (or maybe for one part that I specify and one that they choose), based on the data sheets and some light spec. In class on Monday, I’ll build the design they specified, and we’ll test it with the Arduino data logger.  If I happen to pick a bad resistor choice, either because I gave them a bad light intensity to design for or because their math was wrong, we’ll get bad results, and I’ll show them how to debug the design and iteratively improve it.


Filed under: freshman design seminar Tagged: Arduino, bioengineering, engineering education, photodiode, phototransistor, spectrometer, spectrophotometer, spectroscope

New freshman design seminar

This week I filed paperwork for yet another new course for bioengineering majors: a freshman design seminar.  The course idea was started by the Biomedical Engineering Society (BMES), a student club at UCSC.  They were seeing a lack of engineering in the first couple of years of the bioengineering major.  The first two years at UCSC usually have 12 technical courses and 6 general-education courses, but the bioengineering major has 16 required lower-division courses, mostly science and math.  That means that most students don’t get any engineering design courses in their first two years.

The BMES officers brought the idea of a lower-division project first to the dean of the School of Engineering, who encouraged them to get it created as a permanent course in the department.  They then brought the idea to David Bernick and me, and we brainstormed how to convert the project idea into a workable course that has no prerequisites.  We decided to go with a 2-unit course (about 60 hours total work) rather than a standard 5-unit course (about 150 hours) or a 7-unit lecture plus lab (about 210 hours), because bioengineering students can’t really afford to delay any of their technical coursework, so the design seminar has to be handled as overload.

We decided on winter quarter to offer the seminar.  Fall quarter was rejected, since students will need to be advised to take it and summer advising sessions do not really provide much opportunity for peer advising by fellow engineering students. Spring quarter was rejected, because I’ll have the circuits course (with 12 hours a week in lab, plus 3.5 hours a week in lecture, plus grading), so won’t have the time to do the freshman seminar as well.  David could probably do it in Spring, but it would be best if there were more than one possible instructor available.  It’s not clear who would teach the course the first year—I would have to take it on as overload if I did it, and money would have to be found to hire David to do it, as the course wasn’t even thought of when the curriculum leave plan was written for the next fiscal year.

The class is limited to freshmen and sophomore bioengineering majors (or premajors), but upper-division bioengineers will be encouraged to volunteer as mentors (and some may be paid as group tutors).

Here is the catalog copy I submitted (limited to 40 words):

A first course in engineering design for bioengineers. In co-operation with the Biomedical Engineering Society (BMES).  Students choose a design project and work on it in competitive and cooperative teams. Covers team building, design, prototyping, and report writing.

And here is the more detailed “supplemental sheet” that has the actual course description:

Undergraduate Supplemental Sheet

Information to accompany Request for Course Approval


Sponsoring Agency: Biomolecular Engineering
Course #: 88A
Catalog Title: BMES freshman design seminar
Please answer all of the following questions using a separate sheet for your response.


1. Are you proposing a revision to an existing course? If so give the name, number, and GE designations (if applicable) currently held.
This is not a revision to any existing course.

2. In concrete, substantive terms explain how the course will proceed. List the major topics to be covered, preferably by week.
This course is a project course for freshmen, done in conjunction with the Biomedical Engineering Society (BMES), a student organization on campus.

  1. The class will choose a project for the quarter, with advice from BMES and the instructor.  Lab and fabrication facilities will be toured.
  2. Instructor and reference librarians will introduce students to finding detailed information in the library and on the web relevant to the course (finding data sheets for parts, finding tutorials on relevant theory, searching for survey articles and application notes, using EndNote or BibTeX to maintain a bibliography, …).  Students will choose topics relevant to the project to research.
  3. Students will present the results of background research and brainstorm approaches to the design problem.  Students will be assigned the task of finding and reading data sheets for components they might need.  Students will write a clear set of design goals for the project.
  4. Teams will be formed to prototype different approaches. Dynamics of team formation and functioning will be discussed.  Procedures will be determined for abandoning unpromising approaches, merging teams, and starting new ones.
  5. Weeks 5–8 will involve prototyping projects, with instruction in prototyping technologies and tools (laser cutter, soldering, drill press, glass bending, … ) as needed.  Written drafts of design reports will be required every 2 weeks—these are cumulative reports, not just what has been done since last time.
  6. Weeks 9 and 10 will involve testing and comparison of the different design approaches and a collaborative final design report from the entire class that includes an analysis of all the different designs—their strengths and their weaknesses.  The final design report will be given as a public oral presentation, as well as in a written report.

3. Systemwide Senate Regulation 760 specifies that 1 academic credit corresponds to 3 hours of work per week for the student in a 10-week quarter. Please briefly explain how the course will lead to sufficient work with reference to e.g., lectures, sections, amount of homework, field trips, etc. [Please note that if significant changes are proposed to the format of the course after its initial approval, you will need to submit new course approval paperwork to answer this question in light of the new course format.]
Students will spend 3.5 hours a week in lab/lecture and about 3–6 hours a week in reading, writing, and group design meetings, depending on level of commitment to the course, making this course 2–3 units of effort.

4. Include a complete reading list or its equivalent in other media.
The students will be reading primarily about the background and components for the particular project they are doing, which will most likely be different each year.  For example, if students do a project on building a device to continuously monitor optical density in a liquid culture, they will be reading about the theory of optical density measurements, how liquid cultures are grown, light sources (LEDs, laser diodes, and incandescent lights), photo detectors (photodiodes, phototransistors, and photoresistors), and whatever other knowledge they need to design and build their prototypes.  Most of this reading will be from the internet and books or journal articles from the library.
Discussions on team formation may be based on a book like Teamwork and Project Management, 3rd edition by Karl A. Smith and P.K. Imbrie, but a shorter, more readable presentation is probably needed.  Short articles like http://www.mindtools.com/pages/article/newLDR_86.htm (“Forming, Storming, Norming, and Performing”) or http://www.clemson.edu/OTEI/documents/teamwork-handbook.pdf‎ (“Successful Strategies for Teams”) may be more appropriate.

5. State the basis on which evaluation of individual students’ achievements in this course will be made by the instructor (e.g., class participation, examinations, papers, projects).
Students will be evaluated primarily on design reports and participation in project design.

6. List other UCSC courses covering similar material, if known.
This course is similar to capstone design courses and senior theses, but on a much smaller scale.  It is intended to be a first introduction to engineering design for bioengineering majors.

7. List expected resource requirements including course support and specialized facilities or equipment for divisional review. (This information must also be reported to the scheduling office each quarter the course is offered.)
Students will need access to a lab where they can use both electronic equipment and standard molecular biology equipment.  Baskin 287 has all the molecular biology equipment, but lacks a multimeter, bench power supply, oscilloscope, function generator, and soldering station.  Several of the electronics labs have the electronics equipment, but lack water, sinks, and biomolecular lab equipment.  A Bunsen burner for shaping glass tubes would be useful for some projects.
Students may also need access to the laser cutter and other fabrication tools in Baskin Engineering 138.

8. If applicable, justify any pre-requisites or enrollment restrictions proposed for this course. For pre-requisites sponsored by other departments/programs, please provide evidence of consultation.
There are no prerequisites for the course, as it is intended as a freshman seminar.  Enrollment is limited to bioengineering majors and pre-majors who are freshman or sophomores, to keep the freshmen from being overwhelmed by upper-division students.  A small number of upper-division students are expected to participate as group tutors.

9. Proposals for new or revised Disciplinary Communication courses will be considered within the context of the approved DC plan for the relevant major(s). If applicable, please complete and submit the new proposal form (http://reg.ucsc.edu/forms/DC_statement_form.doc or http://reg.ucsc.edu/forms/DC_statement_form.pdf) or the revisions to approved plans form (http://reg.ucsc.edu/forms/DC_approval_revision.doc or http://reg.ucsc.edu/forms/DC_approval_revision.pdf).
This course is not expected to contribute to any major’s disciplinary communication requirement, though it will include feedback on writing design reports so that students are better prepared for writing in upper-division technical courses.

10. If you are requesting a GE designation for the proposed course, please justify your request making reference to the attached guidelines.
This course is a group design effort, in which students agree on an overall design project, split into teams to prototype different approaches to the design, and work cooperatively both within the teams and in the class as a whole.  The course matches the Practice: Collaborative Endeavor (PR-E code): “Students learn and practice strategies and techniques for working effectively in pairs or larger groups to produce a finished product. For example, students might learn specialized practical information such as how to use change-management software to monitor and manage changes initiated by multiple group members. Alternatively, they might learn basic information about leadership, teamwork, and group functioning, which they can incorporate into their own group process. What is common to all courses is that some instruction regarding the process of collaboration is provided, in addition to instruction specific to the academic discipline and the products being produced.”

11. If this is a new course and you requesting a new GE, do you think an old GE designation(s) is also appropriate? (CEP would like to maintain as many old GE offerings as is possible for the time being.)
As this is a 2-unit course, the old GE designations, which were reserved for 5-unit courses, are not applicable.

Yesterday (Friday), BMES met with me to discuss whether the course description met their goals and how to get sufficient enrollment in the course. (I’d had to file the paperwork in a hurry, hoping to catch the last Committee on Educational Policy meeting of the year—we may still have missed it, in which case the course won’t be approved until the fall.)  The students who read the course description seemed to think that the course was what they were looking for.  I’m a bit worried about whether it can be kept to the workload of a 2-unit course.

We also talked a bit about possible projects for the first offering.  Two have been discussed so far:

  • A low-cost optical density meter for continuous monitoring of OD 600 (with an LED light source) or OD 650 (with a narrower-spectrum laser-diode light source) of cultures on a shaker table.
  • A pulse oximeter for measuring blood oxygenation.

Both of these projects have minimal analog electronics (basically just an LED or two and a phototransistor, with associated resistors).  The challenging parts are the mechanical design for the density meter (how do the sensor and shaker flask interact?  submersible sensor? culture pumped through a tube? waterproofing? autoclavable?) and the programming for the pulse oximeter (I think that most of the usual analog electronics can and should be replaced by programming, but is the Arduino powerful enough?  do we need a Raspberry Pi instead?).

We’ll be encouraging the members of BMES to come up with other project ideas, so that there can be a different project every year.  Another possibility that was mentioned is to build a thermal cycler for PCR, like the OpenPCR project, but the design work there has already been done, and the parts are more expensive.

The two projects we’ve been thinking of so far use only a few dollars worth of parts and a re-usable $22 Arduino board, so I don’t see any problem in just having students buy the components themselves.  It would be good for them to learn how to find and order parts from companies like DigiKey (though they are an expensive source for 650nm laser diodes: $9 vs. 5 for $10 at other suppliers).

Unless we get some corporate sponsorship, we’ll have to run this design seminar on a shoestring, as the School of Engineering relies on student lab fees for consumable parts, and those fees have to be approved about a year in advance. Anyone know a company interested in making a small donation to support such a freshman design seminar?  (It is not worth my time to go looking for a sponsor, but I’d be glad to put anyone who wants to make a donation in touch with the University Development people working with the School of Engineering.)


Filed under: freshman design seminar Tagged: Arduino, Biomedical Engineering Society (BMES), curriculum design, design project course, engineering education, prototype

New freshman design seminar

This week I filed paperwork for yet another new course for bioengineering majors: a freshman design seminar.  The course idea was started by the Biomedical Engineering Society (BMES), a student club at UCSC.  They were seeing a lack of engineering in the first couple of years of the bioengineering major.  The first two years at UCSC usually have 12 technical courses and 6 general-education courses, but the bioengineering major has 16 required lower-division courses, mostly science and math.  That means that most students don’t get any engineering design courses in their first two years.

The BMES officers brought the idea of a lower-division project first to the dean of the School of Engineering, who encouraged them to get it created as a permanent course in the department.  They then brought the idea to David Bernick and me, and we brainstormed how to convert the project idea into a workable course that has no prerequisites.  We decided to go with a 2-unit course (about 60 hours total work) rather than a standard 5-unit course (about 150 hours) or a 7-unit lecture plus lab (about 210 hours), because bioengineering students can’t really afford to delay any of their technical coursework, so the design seminar has to be handled as overload.

We decided on winter quarter to offer the seminar.  Fall quarter was rejected, since students will need to be advised to take it and summer advising sessions do not really provide much opportunity for peer advising by fellow engineering students. Spring quarter was rejected, because I’ll have the circuits course (with 12 hours a week in lab, plus 3.5 hours a week in lecture, plus grading), so won’t have the time to do the freshman seminar as well.  David could probably do it in Spring, but it would be best if there were more than one possible instructor available.  It’s not clear who would teach the course the first year—I would have to take it on as overload if I did it, and money would have to be found to hire David to do it, as the course wasn’t even thought of when the curriculum leave plan was written for the next fiscal year.

The class is limited to freshmen and sophomore bioengineering majors (or premajors), but upper-division bioengineers will be encouraged to volunteer as mentors (and some may be paid as group tutors).

Here is the catalog copy I submitted (limited to 40 words):

A first course in engineering design for bioengineers. In co-operation with the Biomedical Engineering Society (BMES).  Students choose a design project and work on it in competitive and cooperative teams. Covers team building, design, prototyping, and report writing.

And here is the more detailed “supplemental sheet” that has the actual course description:

Undergraduate Supplemental Sheet

Information to accompany Request for Course Approval


Sponsoring Agency: Biomolecular Engineering
Course #: 88A
Catalog Title: BMES freshman design seminar
Please answer all of the following questions using a separate sheet for your response.


1. Are you proposing a revision to an existing course? If so give the name, number, and GE designations (if applicable) currently held.
This is not a revision to any existing course.

2. In concrete, substantive terms explain how the course will proceed. List the major topics to be covered, preferably by week.
This course is a project course for freshmen, done in conjunction with the Biomedical Engineering Society (BMES), a student organization on campus.

  1. The class will choose a project for the quarter, with advice from BMES and the instructor.  Lab and fabrication facilities will be toured.
  2. Instructor and reference librarians will introduce students to finding detailed information in the library and on the web relevant to the course (finding data sheets for parts, finding tutorials on relevant theory, searching for survey articles and application notes, using EndNote or BibTeX to maintain a bibliography, …).  Students will choose topics relevant to the project to research.
  3. Students will present the results of background research and brainstorm approaches to the design problem.  Students will be assigned the task of finding and reading data sheets for components they might need.  Students will write a clear set of design goals for the project.
  4. Teams will be formed to prototype different approaches. Dynamics of team formation and functioning will be discussed.  Procedures will be determined for abandoning unpromising approaches, merging teams, and starting new ones.
  5. Weeks 5–8 will involve prototyping projects, with instruction in prototyping technologies and tools (laser cutter, soldering, drill press, glass bending, … ) as needed.  Written drafts of design reports will be required every 2 weeks—these are cumulative reports, not just what has been done since last time.
  6. Weeks 9 and 10 will involve testing and comparison of the different design approaches and a collaborative final design report from the entire class that includes an analysis of all the different designs—their strengths and their weaknesses.  The final design report will be given as a public oral presentation, as well as in a written report.

3. Systemwide Senate Regulation 760 specifies that 1 academic credit corresponds to 3 hours of work per week for the student in a 10-week quarter. Please briefly explain how the course will lead to sufficient work with reference to e.g., lectures, sections, amount of homework, field trips, etc. [Please note that if significant changes are proposed to the format of the course after its initial approval, you will need to submit new course approval paperwork to answer this question in light of the new course format.]
Students will spend 3.5 hours a week in lab/lecture and about 3–6 hours a week in reading, writing, and group design meetings, depending on level of commitment to the course, making this course 2–3 units of effort.

4. Include a complete reading list or its equivalent in other media.
The students will be reading primarily about the background and components for the particular project they are doing, which will most likely be different each year.  For example, if students do a project on building a device to continuously monitor optical density in a liquid culture, they will be reading about the theory of optical density measurements, how liquid cultures are grown, light sources (LEDs, laser diodes, and incandescent lights), photo detectors (photodiodes, phototransistors, and photoresistors), and whatever other knowledge they need to design and build their prototypes.  Most of this reading will be from the internet and books or journal articles from the library.
Discussions on team formation may be based on a book like Teamwork and Project Management, 3rd edition by Karl A. Smith and P.K. Imbrie, but a shorter, more readable presentation is probably needed.  Short articles like http://www.mindtools.com/pages/article/newLDR_86.htm (“Forming, Storming, Norming, and Performing”) or http://www.clemson.edu/OTEI/documents/teamwork-handbook.pdf‎ (“Successful Strategies for Teams”) may be more appropriate.

5. State the basis on which evaluation of individual students’ achievements in this course will be made by the instructor (e.g., class participation, examinations, papers, projects).
Students will be evaluated primarily on design reports and participation in project design.

6. List other UCSC courses covering similar material, if known.
This course is similar to capstone design courses and senior theses, but on a much smaller scale.  It is intended to be a first introduction to engineering design for bioengineering majors.

7. List expected resource requirements including course support and specialized facilities or equipment for divisional review. (This information must also be reported to the scheduling office each quarter the course is offered.)
Students will need access to a lab where they can use both electronic equipment and standard molecular biology equipment.  Baskin 287 has all the molecular biology equipment, but lacks a multimeter, bench power supply, oscilloscope, function generator, and soldering station.  Several of the electronics labs have the electronics equipment, but lack water, sinks, and biomolecular lab equipment.  A Bunsen burner for shaping glass tubes would be useful for some projects.
Students may also need access to the laser cutter and other fabrication tools in Baskin Engineering 138.

8. If applicable, justify any pre-requisites or enrollment restrictions proposed for this course. For pre-requisites sponsored by other departments/programs, please provide evidence of consultation.
There are no prerequisites for the course, as it is intended as a freshman seminar.  Enrollment is limited to bioengineering majors and pre-majors who are freshman or sophomores, to keep the freshmen from being overwhelmed by upper-division students.  A small number of upper-division students are expected to participate as group tutors.

9. Proposals for new or revised Disciplinary Communication courses will be considered within the context of the approved DC plan for the relevant major(s). If applicable, please complete and submit the new proposal form (http://reg.ucsc.edu/forms/DC_statement_form.doc or http://reg.ucsc.edu/forms/DC_statement_form.pdf) or the revisions to approved plans form (http://reg.ucsc.edu/forms/DC_approval_revision.doc or http://reg.ucsc.edu/forms/DC_approval_revision.pdf).
This course is not expected to contribute to any major’s disciplinary communication requirement, though it will include feedback on writing design reports so that students are better prepared for writing in upper-division technical courses.

10. If you are requesting a GE designation for the proposed course, please justify your request making reference to the attached guidelines.
This course is a group design effort, in which students agree on an overall design project, split into teams to prototype different approaches to the design, and work cooperatively both within the teams and in the class as a whole.  The course matches the Practice: Collaborative Endeavor (PR-E code): “Students learn and practice strategies and techniques for working effectively in pairs or larger groups to produce a finished product. For example, students might learn specialized practical information such as how to use change-management software to monitor and manage changes initiated by multiple group members. Alternatively, they might learn basic information about leadership, teamwork, and group functioning, which they can incorporate into their own group process. What is common to all courses is that some instruction regarding the process of collaboration is provided, in addition to instruction specific to the academic discipline and the products being produced.”

11. If this is a new course and you requesting a new GE, do you think an old GE designation(s) is also appropriate? (CEP would like to maintain as many old GE offerings as is possible for the time being.)
As this is a 2-unit course, the old GE designations, which were reserved for 5-unit courses, are not applicable.

Yesterday (Friday), BMES met with me to discuss whether the course description met their goals and how to get sufficient enrollment in the course. (I’d had to file the paperwork in a hurry, hoping to catch the last Committee on Educational Policy meeting of the year—we may still have missed it, in which case the course won’t be approved until the fall.)  The students who read the course description seemed to think that the course was what they were looking for.  I’m a bit worried about whether it can be kept to the workload of a 2-unit course.

We also talked a bit about possible projects for the first offering.  Two have been discussed so far:

  • A low-cost optical density meter for continuous monitoring of OD 600 (with an LED light source) or OD 650 (with a narrower-spectrum laser-diode light source) of cultures on a shaker table.
  • A pulse oximeter for measuring blood oxygenation.

Both of these projects have minimal analog electronics (basically just an LED or two and a phototransistor, with associated resistors).  The challenging parts are the mechanical design for the density meter (how do the sensor and shaker flask interact?  submersible sensor? culture pumped through a tube? waterproofing? autoclavable?) and the programming for the pulse oximeter (I think that most of the usual analog electronics can and should be replaced by programming, but is the Arduino powerful enough?  do we need a Raspberry Pi instead?).

We’ll be encouraging the members of BMES to come up with other project ideas, so that there can be a different project every year.  Another possibility that was mentioned is to build a thermal cycler for PCR, like the OpenPCR project, but the design work there has already been done, and the parts are more expensive.

The two projects we’ve been thinking of so far use only a few dollars worth of parts and a re-usable $22 Arduino board, so I don’t see any problem in just having students buy the components themselves.  It would be good for them to learn how to find and order parts from companies like DigiKey (though they are an expensive source for 650nm laser diodes: $9 vs. 5 for $10 at other suppliers).

Unless we get some corporate sponsorship, we’ll have to run this design seminar on a shoestring, as the School of Engineering relies on student lab fees for consumable parts, and those fees have to be approved about a year in advance. Anyone know a company interested in making a small donation to support such a freshman design seminar?  (It is not worth my time to go looking for a sponsor, but I’d be glad to put anyone who wants to make a donation in touch with the University Development people working with the School of Engineering.)


Filed under: freshman design seminar Tagged: Arduino, Biomedical Engineering Society (BMES), curriculum design, design project course, engineering education

Physics Lab 2

The Physics Lab 1 post described a first experiment using ultrasonic rangefinders.  The students have not really done the Wikipedia-style writeup of how an ultrasonic rangefinder works that I wanted.  I’m not sure whether to push for that or to let it slide—it is important to develop technical reading and writing skills, but they have not yet gotten to the point in the physics course where they could actually derive the speed of sound equation.  The speed of sound in a gas is only vaguely referred to in Chapter 12 of Matter and Interactions, though there is quite a bit on the speed of sound in a solid.

I ended up buying two different ultrasonic rangefinders:

Both of these rangefinders provide a pulse-width output that can be measured with the Arduino pulseIn function call.  The measurement is provided in microseconds, but seems to have a slightly coarser resolution, with measurements spaced about 5 microseconds apart.  To convert round-trip time into round-trip distance, we have to multiply the time in seconds by the speed of sound in meters/second.

There is an online calculator for the speed of sound as a function of temperature, pressure, and humidity, which gives a citation for the calculation (from the Journal of the Acoustical Society of America), but does not give a clear statement of calculation actually used.  The same calculator (at least citing the same source) is also available from UK’s National Physical Lab.  I used a simpler approximation (without humidity or pressure corrections) from Wikipedia’s Speed of Sound article:

On Friday, we did the lab itself:

  1. Hook up the rangefinder to the Arduino and program the Arduino to keep taking measurements and reporting them to the serial line. (I wrote the Arduino program myself, but my son is working on a Python program to record a series of measurements from the Arduino, which will be needed for the next lab.)

    The setup for Lab 1. The Ping sensor is plugged directly into the Arduino, which sits on top of a copy of the OED, to get it far enough from the floor that we don't detect the floor rather than the wall.

  2. Calibrate the sensor by placing it at carefully measured distances from a hard wall and recording the readings.  Repeat at several different distances.  (Record temperature, humidity, and barometric pressure, if possible.)  Here are the measurements made by the students, taking just the midpoint of the range observed:

# MaxBotix LV-MaxSonar-EZ Calibration
# Distance (centimeters)    Delay Time (microseconds)
10                818
20                1075
30                1515
40                2299
50                2887
60                3470
70                4060
80                4645
90                5231
100               5815

# Parallax Ping))) Sensor Calibration
# Distance (centimeters)    Delay Time (microseconds)
10                735
20                1215
30                1800
40                2405
50                3015

They had a lot of trouble getting consistent readings for the Ping))) sensor.  I think that this may have been due to trying to take the measurements without pausing enough between them, so I added an extra millisecond delay after each Ping))) measurement, and my son and I collected new data today.  We modified the setup slightly, so that instead of using a tape measure on the floor, we measured from the wall to the front of the Ping))) sensor with a steel tape measure.  Here are the measurements we made:

# Ping))) calibration data
# 1 October 2011
# Arduino report several (usually 6) measurements for each distance
# We recorded the actual distance, the minimum and maximum reported time of flight,
# and the minimum and maximum distance reported by the Arduino.
# The reported distance assumed 343.21m/sec speed of sound, and that the time of flight
# was twice the distance.
#distance(cm)  min_tof(usec) max_tof(usec) min_cm max_cm
10    616    624    10.57    10.71
20    1225    1230    21.02    21.11
30    1786    1818    30.65    31.20
40    2385    2391    40.93    41.03
50    2939    2962    50.44    50.83
60    3540    3542    60.75    60.78
70    4065    4089    69.76    70.17
80    4610    4729    79.11    81.15
90    5240    5265    89.92    90.35
100    5833    5858    100.10    100.53
110    6444    6446    110.58    110.62
120    7018    7050    120.43    120.98
130    7575    7582    129.99    130.11

These measurements were fairly consistent (though the variation is larger than I’d like).  I did notice that the Ping))) sensor could get fooled rather badly when an object disappeared from its field of view.  For example, when pointing the sensor at the ceiling from my benchtop, the distance is reported as a fairly consistent 177±0.5cm.  Waving an object in front of the sensor got reasonable readings, but removing the object caused the sensor to get stuck reporting 50.5±1cm, though there was nothing at that distance.  Sometimes the sensor returned to the 177cm reading, sometimes to the 50cm reading, and I’ve not been able to figure out what causes the difference.  The MaxBotix sensor has different dropout problems, sometimes missing the echo and reporting a very long distance, but generally seems to be a little more stable.

 

What to do before next week’s lab

  1. Plot the sensor readings vs. the actual distance.
  2. Do linear regression to get a predictor of actual distance given sensor reading.  (Caveat: need to plot distance vs. readings rather than readings vs. distance to get best fit for calibration.)  What is the relationship between the speed of sound and the slope of the line?
  3. What is the accuracy and precision of the measurements?  What range of distances can be measured? Is the accuracy better expressed in terms of absolute error (±5mm, for example) or relative error (±1%, for example)?
  4. Fix the Arduino program to get better estimates of the distances from the sensors, if possible.
  5. Get a recording program working to record a series of measurements of a moving object.

What to do in next week’s lab

  1. Redo the Maxbotix calibration the same way we redid the Ping))) calibration, collecting min and max time of flight and using better distance measurements.
  2.  Use either the Ping))) or the Maxbotix sensor to record the movement of a simple object away from the sensor and plot the motion.
  3. Write a Vpython program that simulates the motion, using only a few constants, not a table of positions or velocities (that is, approximate the motion as constant velocity or constant acceleration).  The simple object could be a small vehicle made from Lego (motorized or not), a mousetrap car, a rolling ball, a falling ball, or whatever else is easy to measure.

Other homework

  • Read Chapter 2.
  • Work problems 2P38, 2P40, 2P62, 2P63, 2P66, and 2P69.
  • Do computational problem 2P72.

Tagged: Arduino, engineering education, Matter and Interactions, physics, rangefinder, science education, ultrasonic sensor

Physics Lab 1: ultrasonic rangefinders

We had the first official meeting of the home-school physics class today.  It was just my son and me. Originally we were going to have a second student, but he was busy with college application essays, and asked if he could start next week instead.  My son compared his and my solutions to problems 1P89, 1P97, 1P98, and 1P117 (all the non-computational problems from Chapter 1 of Matter and Interactions).  We got all the same results, but I had left out the units on one of the intermediate steps on one problem—a bad habit that I will try to break, as I agree with John Burk that one should tell the full story of the number, throughout a computation.

In Physics Lab 1, I outlined the first experiment for my home-school physics students and me to do, using an ultrasonic rangefinder.

Here is what I proposed:

  1. Hook up the rangefinder to the Arduino and program the Arduino to keep taking measurements and reporting them to the serial line.
  2. Calibrate the sensor by placing it at carefully measured distances from a hard wall and recording the readings.  Repeat at several different distances.  (Record temperature, humidity, and barometric pressure, if possible.)
  3. Plot the sensor readings vs. the actual distance.
  4. Do linear regression to get predictor of actual distance given sensor reading.  (Caveat: need to plot distance vs. readings rather than readings vs. distance to get best fit for calibration.)
  5. Modify Arduino code to use the calibration parameters to provide better distance measurements.
  6. Re-calibrate using new code.  What is the accuracy and precision of the measurements?  What range of distances can be measured? Is the accuracy better expressed in terms of absolute error (±1cm, for example) or relative error (±5%, for example)?
  7. Open-ended: Experiment with detecting different targets (maybe flat targets from wall size down to the size of a quarter, maybe targets of different materials, maybe spherical targets).  What effect does target size, shape, material,  … have on range and accuracy of the measurement?

What we actually did:

My son and I each picked one of the rangefinders (I bought a Maxbotix LV-MaxSonar-EZ2 and a Ping))) sensor), and separately wrote Arduino code to read them. He chose to use the Maxbotix in the pulse-width mode, which is uncalibrated, but which has the greatest resolution.  I used the Ping))) sensor, which has a similar pulse-width mode.  The biggest difference is that the Ping))) needs to be triggered, while the Maxbotix repeats the measurement several times a second.  He had to solder a header onto the Maxbotix in order to connect it up, while I could cheat a little and plug the Ping directly into the Arduino board.  We could probably arrange to have both sensors on the Arduino at once, but have not tried that.

Both of us failed to get busy-wait loops with digitalRead() to work, but we both managed to get pulseIn() to work.  He just reported time in microseconds (then he had to go off to his improv class).  I spent a little more time adding a computed speed of sound (with temperature correction, but not humidity correction), to report distances in cm.  The repeatability of the Ping))) seems pretty good: about ±1mm, but I’ve not tried to calibrate the accuracy yet.  I don’t know whether the limit on the resolution is the coarseness of the pulseIn() measurement of time or variation in the pulse width output by the sensor.

For next week:

My son still needs to do more work on the prelab writeup about how an ultrasonic rangefinder works, so I hope that both students will have drafts of that for next week.  Also assigned for next week is a Vpython programming assignment (Exercise 1p123).

In lab next week we’ll compare our programs for 1p123, then do some calibration experiments with the rangefinder, or try using it to record a series of time and distance measurements for a moving object, or try learning to use Tracker to do video analysis.


Tagged: Arduino, engineering education, Matter and Interactions, physics, rangefinder, science education, Tracker, ultrasonic sensor

Physics Lab 1

I asked physics teacher John Burk for advice on putting together labs for homeschooling my son in calculus-based physics using the Matter and Interactions book (see School decisions part 3 on the decision to homeschool).  He was kind enough to pass on my request to the readers of his Quantum Progress blog: The ideal lab experience for a homeschooled student.  He also gave me a suggestion for a piece of lab equipment we could use for a number of experiments in Newtonian mechanics: an ultrasonic rangefinder.

This post is my first attempt at a physics lab assignment for my son. (Note: we are also hoping to use tech writing this year to satisfy some of his English requirements, so the assignment is a bit heavier on the writing than might otherwise be appropriate for a physics class.)  The exploration in this lab is more engineering than physics, but familiarity with measuring tools is a good place to start, I think.

I welcome feedback and suggestions, particularly from those who have taught physics!

Lab 1: ultrasonic range finder

Prelab

Research how an ultrasonic range finder works (note: as of 25 Aug 2011, the Wikipedia article is a terrible stub—other sources will be needed).

Write: Write a paragraph or two explaining how an ultrasonic rangefinder works.  This should be at a reading level and level of detail suitable for replacing the current Wikipedia stub. Explain what determines the precision, accuracy, and range of the range finder.  How frequently can it measure the range? How is the speed of sound involved?  What does that depend on … ? Why do some have one transducer and others have two?  Audience: new robotics club members (technically interested high school students without prior knowledge of physics or electronics).

Bonus audience: if the writeup is good, it can replace the current Wikipedia stub.

Read the product information (and data sheets when possible) for at least 3 different (cheap) range finding modules like the following three four (added one more 1 Sept 2011):

Choose one of the range finders for us to buy.

Write: justify the choice in writing, doing a comparison of the advantages and disadvantages of each choice.  Give URLs as citations for data used in making the choice.

Sketch out in pseudocode the program needed to read the sensor on the Arduino using a simple busy loop.  What will determine the precision and sampling rate of the measurements?  What will the code do if there is no object in range of the sensor?

Advanced option: sketch out pseudocode for using interrupts instead of a busy loop.

The Lab Proper

  1. Hook up the rangefinder to the Arduino and program the Arduino to keep taking measurements and reporting them to the serial line.
  2. Calibrate the sensor by placing it at carefully measured distances from a hard wall and recording the readings.  Repeat at several different distances.  (Record temperature, humidity, and barometric pressure, if possible.)
  3. Plot the sensor readings vs. the actual distance.
  4. Do linear regression to get predictor of actual distance given sensor reading.  (Caveat: need to plot distance vs. readings rather than readings vs. distance to get best fit for calibration.)
  5. Modify Arduino code to use the calibration parameters to provide better distance measurements.
  6. Re-calibrate using new code.  What is the accuracy and precision of the measurements?  What range of distances can be measured? Is the accuracy better expressed in terms of absolute error (±1cm, for example) or relative error (±5%, for example)?
  7. Open-ended: Experiment with detecting different targets (maybe flat targets from wall size down to the size of a quarter, maybe targets of different materials, maybe spherical targets).  What effect does target size, shape, material,  … have on range and accuracy of the measurement?

Tagged: Arduino, engineering education, Matter and Interactions, physics, rangefinder, science education, ultrasonic sensor