# Gas station without pumps

## 2014 April 7

### Feedback on first lab report

Filed under: Circuits course,Printed Circuit Boards — gasstationwithoutpumps @ 17:11
Tags: , , , , ,

Most of today’s class was taken up with feedback on the design reports that students turned in by e-mail on Saturday.  Overall the reports were not bad (better than the first reports last year), but I think that the students could do better.  Here are the main points:

• Anyone can redo the report to get it re-evaluated (and probably get a higher grade).
• No one attempted theV1 &V2 problem, so I reassigned it for Wednesday.

The circuit I had given as an exercise, asking them to determine the output voltage V_out.

• A lot of reports mixed together two different problems:the 1kΩ–3.3kΩ problem and the optimization to maximize sensitivity of the thermistor temperature sensor.  I encouraged students to use more section headers and avoid mixing different problems together.
• Figures should be numbered and have paragraph-long captions below each figure.  I reminded students that most engineering reports are not read in detail—readers flip through looking at the pictures and reading the picture captions. If the pictures and captions don’t have most of the content, then most readers will miss it. I also pointed out that many faculty, when creating new journal articles, don’t ask for an outline, but ask for the figures.  Once the figures tell the right story, the rest of the writing is fairly straightforward.
• A lot of the students misused  “would” in their writing, treating as some formal form of “to be”. The main use in technical writing is for contrary-to-fact statements: “the temperature would go down, if dissipating power cooled things instead of heating them”.  Whenever I see “would” in technical writing, I want to know why whatever is being talked about didn’t happen.
• A number of the students had the correct answer for the optimization problem, but had not set up or explained the optimization. Right answers are not enough—there must be a rational justification for them. In some cases, the math was incomprehensible, with things that weren’t even well-formed equations. I suspect that in many cases, the students had copied down the answer without really understanding how it was derived and without copying down the intermediate steps in their lab notebooks, so they could not redo the derivation for the report.
• A number of the plots showed incomplete understanding of gnuplot: improperly labeled axes, improperly scaled axes, plots that only included data and not the models that the data was supposed to match, and so forth. I pointed out the importance of sanity checks—there was no way that anyone ran their recording for 1E10 seconds! I was particularly bothered that no one had plotted the theoretical temperature vs. voltage calibration based on the parameters from their temperature vs. resistance measurements, so I could not tell whether the voltage divider was doing what they expected it to.
• No one really got the solution for the 1kΩ–3.3kΩ problem perfectly. A number of them set up the equations right and solved for R (getting 2.538kΩ), but then not figuring out what Vin had to be.  It turns out that Vin depends strongly on R, so rounding R to 2.2kΩ or 2.7kΩ results in different good values for Vin, and the 2.2kΩ choice gives a more desirable voltage (around 3.3v, which we have available from the KL25Z boards, as it is a standard power-supply voltage).

I also showed the students how I had expected them to setup and explain the optimization to maximize sensitivity at a particular operating temperature.

After that feedback, I started on new material, getting the explanation of amplitude, peak-to-peak, and RMS voltage. I think that the RMS voltage explanation was a bit rough.  I was deriving it from the explanation that we wanted a measurement that represented the same power dissipation in a resistor as the DC voltage, and I got everything set up with the appropriate integrals, but I forgot the trig identity $(cos(\omega t))^2 =\frac{1}{2} (1-cos(2 \omega t))$, and ran out of time before I could get it right.  I did suggest that they look up the trig identity and finish the integration.

I had hoped to get at least partway into Euler’s formula, complex sinusoids, and phasors, but the feedback took longer than I had expected. Those topics will have to wait until Wednesday or even Friday, since Wednesday we’ll want to do the modeling of the DC characteristics of the electret mic, and talk about how the mic works.

## 2014 April 5

### Hysteresis lab on KL25Z

Relaxation oscillator used in the hysteresis lab. The “variable capacitor” in this schematic is a person’s finger and a touch plate made from aluminum foil and packing tape.

I spent today writing code for the KL25Z board to act as a period or frequency detector for the hysteresis lab, where they build a relaxation oscillator using a 74HC14N Schmitt trigger inverter and use it to make a capacitance touch sensor (pictures of last year’s setup in Weekend work). I had written code for the Arduino boards last year, and I started by trying to do the same thing on the KL25Z, using the MBED online development system.  The Arduino code used “PulseIn()” to measure pulse duration, and the MBED system does not have an equivalent function.  I could have implemented PulseIn() with a couple of busy waits and a microsecond-resolution timer, but I decided to try using “InterruptIn” to get interrupts on each rising edge instead.

The basic idea of last year’s code (and the first couple versions I wrote today) was to determine the pulse duration or period when the board is reset, finding the maximum over a few hundred cycles, and using that as a set point to create two thresholds for switching an LED on or off. I got the code working, but I was not happy with it as a tool for the students to use.

The biggest problem is that the touch plate couples in 60Hz noise from the user’s finger, so the oscillator output signal is frequency modulated.  This frequency modulation can be large compared with the change in frequency from touching or not touching the plate (depending on how big C1 is), so setting the resistor and capacitor values for the oscillator got rather tricky, and the results were unreliable.

I then changed from reading instantaneous period to measuring frequency by counting edges in a 1/60th-second window.  That way the 60Hz frequency modulation of the oscillator gets averaged out, and we can get a fairly stable frequency reading.  The elimination of the 60Hz noise allows me to use less hysteresis in the on/off decision for the LED, making the touch sensor more sensitive without getting flicker on transitions. The code worked fairly well, but I was not happy with the maximum frequency that it could handle—the touch sensor gets more sensitive if C1 is small, which tends to result in high frequency oscillations. The problem with the code was that MBED’s InterruptIn implementation seems to have a lot of overhead, and the code missed the edge interrupts if they came more often than about every 12µsec.  Because I was interrupting on both rising and falling edges, the effective maximum frequency was about 40kHz, which was much lower than I wanted.

To fix the frequency limitation, I replaced MBED’s InterruptIn with my own interrupt service routine for PortD (I was using pin PTD4 as the interrupt input). With this change, I could go to about 800kHz (1.6e6 interrupts per second), which is plenty for this lab.  If I wanted to go to higher frequencies, I’d look at only rising edges, rather than rising+falling edges, to get another factor of two at the high end.  I didn’t make that change, because doing so would reduce the resolution of the frequency measurement at the low end, and I didn’t think that the tradeoff was worth it here.

The code is now robust to fairly large variations in the oscillator design.  It needs a 20% drop in frequency to turn on the green LED, but the initial frequency can be anywhere in the range 400Hz–800kHz.

To make it easier for students to debug their circuits, I took advantage of having an RGB LED on the board to indicate the state of the program: on reset, the LED is yellow, turning blue once a proper oscillator input has been detected, or red if the oscillator frequency is not in range. When the frequency drops sufficiently, the LED turns from blue to green, turning back to blue when the frequency goes up again.

For even more debugging help, I output the frequency that the board sees through the USB serial connection every 1/60th second, so that a program like the Arduino serial monitor can be used to see how much the frequency is changing.  I took advantage of that feature to make a plot of the frequency as the touch sensor was touched.

Plot of frequency of hysteresis oscillator, as the touch pad is touched three times. Note that the thresholds are very conservatively set relative to the noise, but that the sensitivity is still much higher than needed to detect the finger touches.

Overall, I think that the code for the KL25Z is better than what I wrote last year for the Arduino—now I have to rewrite the lab handout to match! I actually need to update two lab handouts this weekend, since week 3 will have both the hysteresis lab and the sampling and aliasing lab. Unfortunately, the features needed for those labs (trigger on rising and falling edges and downsampling) are not working in PteroDAQ yet.

Here is the code that I wrote for the frequency detector:

// freq_detector_own_isr
// Kevin Karplus
// 2014 Apr 5

// This program is intended to be used as a "capacitive touch sensor"
// with an external relaxation oscillator whose frequency
// varies with the capacitance of a touch.

// The program expects a periodic square wave on pin PTD4 with a frequency between
// about 400Hz and 800kHz. (LOW_FREQ_LIMIT and HIGH_FREQ_LIMIT).
// On reset, it displays a yellow light, then measures the frequency to store as the "off" frequency.
//
// If the frequency is out of range (say for a disconnected input), then the light is set to red,
//     and the off frequency checked again.
// Otherwise the LED is turned blue.
//
// After initialization, if the program detects a frequency 20% less than the initial freq,
// it turns the light green,
// turning it blue again when the the frequency increases to 90% of the original frequency.
//
// No floating-point is used, just integer arithmetic.
//
// Frequency measurements are made by counting the number of rising and falling edges
// in one cycle of the mains frequency (1/60 sec), giving somewhat poor resolution at lower
// frequencies.
// The counting time is chosen to that frequency modulation by the mains voltages is averaged out.
//
// This version of the code uses my own setup for the interrupt service routine, because InterruptIn has
// too much overhead.  I can go to over 800kHz (1.6e6 interrupts/second) with this setup,
// but only about 40kHz (80e3) interrupts/sec with mbed's InterruptIn.

#include "mbed.h"

#define PCR_PORT_TO_USE (PORTD->PCR[4])   // pin PTD3 is the pin to use

#define MAINS_FREQ (60)     // frequency of electrical mains in Hz
#define COUNTING_TIME (1000000/MAINS_FREQ)   // duration in usec of one period of electrical mains

// off_frequency must be between LOW_FREQ_LIMIT and HIGH_FREQ_LIMIT for program to accept it
#define LOW_FREQ_LIMIT (400)
#define HIGH_FREQ_LIMIT (800000)

// on-board RGB LED
PwmOut rled(LED_RED);
PwmOut gled(LED_GREEN);
PwmOut bled(LED_BLUE);
#define PWM_PERIOD (255)  // for the on-board LEDs in microseconds

// Set the RGB led color to R,G,B  with 0 being off and PWM_PERIOD being full-on
void set_RGB_color(uint8_t R, uint8_t G, uint8_t B)
{
rled.pulsewidth_us(PWM_PERIOD-R);
gled.pulsewidth_us(PWM_PERIOD-G);
bled.pulsewidth_us(PWM_PERIOD-B);
}

// InterruptIn square_in(PTD4);
volatile uint32_t edges_counted;

uint32_t low_freq_threshold, high_freq_threshold;  // thresholds for detecting frequency changes

extern "C"{
// interrupt routine that counts edges into edges_counted
void PORTD_IRQHandler(void)
{
edges_counted++;
}
}

// return the frequency for the square_in input in Hz
uint32_t frequency(void)
{
PCR_PORT_TO_USE &= ~PORT_PCR_IRQC_MASK;  // disable interrupts on pin PTD3
edges_counted=0;
PCR_PORT_TO_USE |= PORT_PCR_ISF_MASK | PORT_PCR_IRQC(11);  // clear interrupt for PTD3, and enable interrupt on either edge
wait_us(COUNTING_TIME);
PCR_PORT_TO_USE &= ~PORT_PCR_IRQC_MASK;  // disable interrupts on pin PTD3
uint32_t freq=edges_counted*MAINS_FREQ/2;
return freq;
}

int main()
{
rled.period_us(PWM_PERIOD);
gled.period_us(PWM_PERIOD);
bled.period_us(PWM_PERIOD);
set_RGB_color(255,255,0);   // set light to yellow

SIM->SCGC5 |= SIM_SCGC5_PORTD_MASK; // make sure port D has clocks on
PCR_PORT_TO_USE &= ~PORT_PCR_MUX_MASK;  // clearing the MUX field
PCR_PORT_TO_USE |= PORT_PCR_MUX(1);     // Setting pin as GPIO
FPTD->PDDR &= ~ (1<<4);  // make sure pin is input pin
NVIC_EnableIRQ(PORTD_IRQn);            // enable interrupts for port D

__enable_irq();

uint32_t off_frequency= frequency();
while ( off_frequency<low_freq_limit ||="" off_frequency="">HIGH_FREQ_LIMIT)
{   // timed out.  set color to red and keep trying
set_RGB_color(255,0,0);
printf("FREQ out of range: %luHz\n", off_frequency);
off_frequency= frequency();
}

uint32_t low_freq= 8*off_frequency/10;  // 80% of off_frequency
uint32_t high_freq= 9*off_frequency/10;  // 90% of off_frequency

printf("off= %luHz lo_thresh=%luHz hi_thresh=%luHz\n",off_frequency, low_freq, high_freq);
while(1)
{   uint32_t freq=frequency();
printf("%lu Hz\n",freq);
if (freq < low_freq)
{   // low_fequency found, turn LED green
set_RGB_color(0,255,0);
}
else if (freq >= high_freq)
{   // high frequency found, turn LED blue again
set_RGB_color(0,0,255);
}
}
}


## 2014 April 4

### Third day of circuits class was low key

Filed under: Circuits course,Printed Circuit Boards — gasstationwithoutpumps @ 21:34
Tags: , , ,

Today’s class was not content-rich, but a low-key decompression after yesterday’s too-long lab.

I started out taking some questions from the class, which were mainly about what to do in the design report.

I then discussed my ideas about what had gone wrong with yesterday’s lab that made it take so long, and both how I planned to fix the problem next year, and what we could do as a class to keep it from happening again this year. I particularly stressed the importance of doing the pre-lab work early, so that they could ask questions in the lecture portion of the class, rather than taking up valuable lab time. I also suggested that they do the writeups for the Tuesday lab before Wednesday’s class, so that they would have much less to write up after the Thursday lab—making the Friday deadline for the writeup feasible.

I asked the students for their ideas about what were problems with the lab, and they agreed that the soldering and installing PteroDAQ software took up almost 2 hours, so it would be best to separate that into its own lab period. They also brought up their frustration with the design problems I had given them: not so much the optimization for the lab, but the design exercise I had added: Design a circuit to convert a 1kΩ–3.3kΩ variable resistance sensor to a 1v–2v voltage output, with 1v for the 1kΩ resistance and 2v for the 3.3kΩ resistance. Use standard resistor values that you have in your kit. They were frustrated because they did not know how they were supposed to approach the problem.

This gave me an opportunity to explain what I was trying to do with problems like that. It was indeed entirely appropriate that they should have been uncomfortable with the problem, because I was trying to push them to think in new ways—to handle problems that were not completely laid out for them ahead of time, but where they had to struggle a bit to figure out how to formulate the problem. This is precisely what engineers have to do—to take problem statements that may be unclear or not precisely solvable, figure out how to formulate them more precisely, set up equations, solve them, check that the design they come up with makes sense, and (often) adjust the problem statement to reflect what is actually doable.  (I didn’t say it, but in this case you have to accept a few percent error in the output voltage or the resistances in order to use standard values.)  I promised them more uncomfortable problems in future, in an attempt to stretch them.  They seemed a little more at ease with the difficulty they’d been having, once they realized that this was expected—I think some had been afraid that they were in over their heads and were panicking.

Another student mentioned having heard of an analogy between programming and engineering. I pointed out that programming was a form of engineering, and that all engineering required identifying problems, breaking them into subproblems, and solving the subproblems.  Programming tends to involve many, many subproblems, with formal interfaces between them, but even the simple hardware we’d do in this course involves breaking problems into subproblems, using block diagrams (which I promised to talk more about later in the course).

Somewhere in the discussion of what engineers do, I brought up the example of the student who had presorted his resistors and taped them into a booklet.  What the student had done was to identify a problem (that it would be hard to find the resistors he needed), come up with a solution, and implemented it. I pointed out that the technology he used (scotch tape) was available to them all, as was the notion of sorting. The engineering thinking comes in looking at something unpleasant (finding a sheet of resistors in a pile of 64 different sizes) as a design problem to solve, rather than something to get irked about or try to avoid. I’m hoping to get them thinking more like engineers during the course of the quarter—anticipating problems and looking for ways to solve them.

Generic voltage divider circuit.

I took more questions from the class—there were a few about voltage dividers, which I explained again in a different way, using analogies to similar triangles and giving them the voltage divider formula in the form $I = \frac{V_{out}}{R_{1}} = \frac{V_{in}}{R_{1}+R_{2}}$.  I did not give the voltage divider in the “ground-reference” format shown to the left, but drew lines out horizontally from the nodes, and had the voltages indicated as distances between the lines (like in a mechanical drawing), to give them a more visual representation of voltages as differences.  I also had them figure out what the voltage across R2 would be and how it would relate to the other voltages.

The more different ways they work with voltage dividers, the better they will internalize the concepts and be able to use them in designs.

The circuit I had given as an exercise, asking them to determine the output voltage V_out.

The circuit with explicit sources and voltmeter implied by the circuit I had given them.

A question also came up about what it meant to have 2 input voltages with no ground shown in a circuit (as I had given them as an exercise in the first lab handout).  That is an excellent question—one that uncovered an assumption I had been making that I had never explained to them! I explained that what an “input voltage” meant was shorthand way of drawing two voltage sources.

I’ll have to fix the handout next year to include this explicit explanation of a common shorthand—I’ve used it for so many decades that it simply hadn’t occurred to me that it wasn’t obvious. I apologized to the class for having skipped the explanation, and pointed out the importance of them asking questions, because otherwise I would never know where some omission like this was confusing them unnecessarily.

When they ran out of questions, I got in some new material, explaining the difference between “precision”, “repeatability”, and “accuracy”. The digital thermometers they used in lab were a good example—they had a precision of 0.1°C, were repeatable within a single thermometer to about ±0.2°C, but between thermometers were repeatable only to about ±2°C. The accuracy is unknown, since we did not have anything traceable to a temperature standard, but the ice water baths should have been close to 0°C, so the thermometers we used on Thursday were probably less than 1°C off, but the larger set we used on Tuesday included some that were 3°C or 4°C off. In the repeatability part of the talk, I managed to bring in the biologists’ notion of technical replicates (different measurements of the same sample) and biological replicates (different cultures or tissue samples), and why biological replicates show less repeatability.

I also used this as a chance to talk about the uselessness of ±0.1°C or error bars without an explanation of what the range means (standard deviation, 90% confidence interval, 3σ, 5σ, observed range, …), and the even greater uselessness of “significant figures” as a way of expressing uncertainty.  I told them that I’d rather see 1.031±0.2 than 1.0 as a way of expressing the uncertainty in a measurement.

Towards the end of the 70-minute period, I got in a little discussion of AC voltages as time-varying voltages, and that we usually did analysis in terms of simple sinusoids, rather than the complex waveforms that we’d actually be measuring. I did assure them that, though there was a lot of mathematical machinery (Fourier analysis) that justified this way of doing things, the math was outside the scope of the class and I’d only be giving them intuitive ways of working with AC. I only got as far as giving them amplitude—telling them that I’d start with RMS voltage next time. (I’d originally hoped to explain RMS voltage today, but that would have taken another five minutes, and we were already 3 minutes over.)

Overall, I was fairly pleased with how today’s class went—the students are getting more comfortable asking questions and I’m getting a better sense of what they already know and what they need explained.  Undoubtedly I’ll make more mistakes like not explaining the “hidden voltage source at inputs” convention, but I think we’ll recover from such mistakes a little quicker each time, as the students get more confident in asking for clarification.

## 2014 March 31

### First day of S14 circuits class went ok

Filed under: Circuits course — gasstationwithoutpumps @ 21:21
Tags: , , , , , ,

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 $V=IR$:  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 $V_{out} = V_{in} \frac{R_{down}}{R_{up}+R_{down}}$.
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.

## 2014 March 16

### New phototransistor lab

Filed under: Circuits course — gasstationwithoutpumps @ 00:54
Tags: , , , , , ,

In Phototransistor I talked about one possible phototransistor lab, that looked at the response speed of a phototransistor, as a function of the load resistor.  I rejected that last year as insufficiently interesting for bioengineers.

The lab for phototransistors that I used last year was a “tinkering” lab, where I tried to get the students to play with the hysteresis oscillator that they had built, modulating it with light (see Idea for phototransistor/FET lab). I didn’t think that it was a very successful lab (see Tinkering lab reports show problems), and I’d rather have a lab that seems more directly “bio” oriented.

One lab I’ve not given in class, but have played with a lot at home, trying to find something that works at the right level of complexity for the students is an optical pulse monitor:

Scott Prahl’s estimate of oxyhemoglobin and deoxyhemoglobin molar extinction coefficients, copied from http://omlc.ogi.edu/spectra/hemoglobin/summary.gif
The higher the curve here the less light is transmitted. Note that 700nm has very low absorption, but 627nm has much higher absorption.

I played around with the idea some more last week, using a transimpedance amplifier to convert current to voltage (as in Colorimeter design—weird behavior). I can easily get enough gain to see pulse for a 700nm LED shining through a finger, but I listed the “brighter” LED red diffuse 3mm 625nm WP710A10ID part for this year’s parts kit, so I need to test with it (or with LED IR emitter 5mm 950nm SFH 4512). Because I’ll be making the mechanical part of the pulse monitor for the students, I have to know whether a 5mm or 3mm LED will be used.

Because oxyhemoglobin has its lowest absorbance near 700nm, I expect that switching to either 950nm or 627nm will greatly reduce the signal, needing an extra gain of 5.

The mechanical design I’m thinking of using is a simple one: a 3/4″ diameter hole drilled 2″ deep into a 3″-long block of wood that is 1.5″ by 1.5″, with a 1/8″ hole drilled at right angles to accommodate the LED and phototransistor. Carving out a small channel allows the block to sit flat on the tabletop.

The block with LED in the top hole and the phototransistor in the bottom hole. The phototransistor has a bit of rim, necessitating a shallow 5/32″ drill allow the phototransistor to go deep enough into the block for the block to sit flush on a tabletop.

Block viewed from end with 3/4″ hole. The cross hole for the LED (or phototransistor) and the channel for its wires can be seen on the front.

To connect the LED and phototransistor to a breadboard, the leads need to be extended:

I added color-coded leads to the phototransistor and LED, making sure that the negative lead (the cathode for the LED and the emitter for the NPN phototransistor) were given the black wire.
Careful folding and crimping with long-nose pliers gives a good mechanical connection.

Next the connections are soldered to make good electrical connections. It will be good for students to do a little freehand soldering, as their other soldering projects use PC boards.

Finally, one or both of the connections should be covered with electrical tape, so that the wires don’t short. (The students don’t have electrical tape in their kits—I’ll have to remember to bring some in.)

In order to help me remember which side has the phototransistor and which the LED, I color-coded the leads differently (yellow wire for LED anode, green wire for phototransistor collector), and used colored electrical tape to hold the optoelectronic parts in the block (red tape for the LED, blue tape for the phototransistor—matching their package colors).

I did manage to get  the pulse monitor working sometimes, but it seems to be excessively finicky—I need very high gain with careful setting of the bandpass filter parameters to get a signal. The biggest problem is that the second stage of the amplifier, where I do the high-pass filtering to remove the DC component and slow drift, can end up getting saturated.  Because of the high impedance of the feedback resistor, the output stage takes a long time to recover from being saturated. Saturation is a frequent problem with high-gain amplifiers, but I’m not sure I want students dealing with it on this lab.

Initially, the light is bright and the amplifier saturates at one rail. When a finger is inserted in the sensor, the light drops enormously, and the amplifier output swings to the other rail. It takes a very long time (about 30 second here) before the limited current through the feedback resistor can charge the capacitor in the high-pass filter enough to restore the op-amp inputs being the same voltage.

The combined gain of the two stages at 1Hz (about the frequency of my pulse) is around 132MΩ, and the output is still only about 0.25V, so the fluctuation in the input current must be around 2nA. That’s not as small as the signals in a nanopore, but it is small enough to be troublesome.

I tried a different set of components that gave me a gain of about 240MΩ at 0.9 Hz, and that amplifier started clipping the output, swinging from around -0.8v to +1.6v.

After the first stage (with a gain of about 1.7MΩ at 0.9Hz and 5.6MΩ at 0Hz), I see about a 10mV swing on top of a DC signal of 0.6 to 0.8v (with considerable drift). That implies about a 6nA signal at 0.9Hz, while the DC signal is about 125nA.  The magnitude of both the DC and the AC component varies a lot, depending on which finger I use and how firmly I press the finger against the sensor.  I can pretty consistently get 2–9nA of AC on top of 100–150nA DC.  I think that good corner frequencies for the low-pass and high-pass filters are around 0.3Hz and 30Hz. By making the gain of the transimpedance amplifier as high as I can (without saturating with the DC signal), I can keep the gain of the second amplifier low enough to avoid the problem of saturation in the second stage, and the pulse monitor can detect the pulse within 5 seconds.

Another option is to make the first-stage amplification be a logarithmic transimpedance amplifier, rather than linear one, by using a Schottky diode as the feedback element instead of a resistor.  But that is getting well outside what I’m comfortable assigning as a design exercise to the Applied Circuits class. I tried it anyway, but the signal from the log amplifier was too small:  a 10% variation in current only results in a 2.4mV change in the output of the log amplifier, needing a much higher gain than my second stage currently provides.

While the 700nm LED provides a stronger signal, the 627nm LED works well enough, and a 2-stage transimpedance amplifier is reasonable for the students to design.  I probably want it to be a 2-day lab, though, with the low-pass first stage designed and tested for the first day, then the high-pass second stage added to solve the problem of DC offset and drift.  That will require reworking my schedule, as I only allowed one day for the lab in the current schedule.

Next Page »