Gas station without pumps

2014 August 14


Filed under: Uncategorized — gasstationwithoutpumps @ 11:42
Tags: , , ,

If you’ve been wanting to teach your child to program, but found Scratch too complicated for your 5-year-old, there is a new option: ScratchJr.

On the  ScratchJr – About page, the developers say

What is ScratchJr?

ScratchJr is an introductory programming language that enables young children (ages 5-7) to create their own interactive stories and games. Children snap together graphical programming blocks to make characters move, jump, dance, and sing. Children can modify characters in the paint editor, add their own voices and sounds, even insert photos of themselves—then use the programming blocks to make their characters come to life.

ScratchJr was inspired by the popular Scratch programming language (, used by millions of young people (ages 8 and up) around the world. In creating ScratchJr, we redesigned the interface and programming language to make them developmentally appropriate for younger children, carefully designing features to match young children’s cognitive, personal, social, and emotional development.

ScratchJr is now available as a free iPad app. We expect to release an Android version later in 2014 and a web-based version in 2015.

Unfortunately, I can’t give you a review of the program, as I don’t have an iPad to check it out on (nor do I have easy access to 5-year-olds, now that my son has grown up).  They did a great job on Scratch, though, so I would hope that ScratchJr has extended the concepts to a lower age group appropriately.

2014 May 7

Quiz corrections

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

As I reported last week, students did poorly on the first quiz, which came as no surprise to me.  I had the students redo the quizzes as homework, allowing collaborative work (as long as they acknowledged the collaboration in writing).  They turned in the homework on Monday, a week after the quiz, and I returned them today.  No one aced the redo, with the top score being still only 25/33 (which would have been an A on the first pass, on a redo maybe a B+).

A lot of the students still seem to be having trouble with complex numbers—they got the formulas right when working symbolically, but then the exact same question with numbers instead of letters (which could be done by just plugging into the formulas) came out with real numbers when complex impedances were asked for.  Also, a lot of sanity checked were skipped (several people reported a battery as doubling in voltage when hooked up to a resistor, for example).

These students are not major mathphobes (they’ve all passed a couple of calculus classes and most have done more math past that), but they don’t seem to have any sense for reasoning with or about math—they just want to plug in and grind, even on simple problems like ratios in voltage dividers. This class has almost no memory work (I gave them a one-page handout at the beginning of the year with all the math and physics I was expecting them to memorize), but relies heavily on their being able to recognize how to apply those few facts.  This often requires subdividing a problem, like recognizing that a Wheatstone bridge is the difference between two voltage dividers, or that a 10× oscilloscope probe is a voltage divider with R||C circuits for each of the two impedances.

I spent the entire class today working through each problem in the quiz, to make sure that everyone in the class could understand the solution, and (more importantly) see that they did actually have enough knowledge and math skill to do the questions. Some of the students were feeling overwhelmed on the quiz, because they are not used to doing anything more than 1-step pattern matching for problems, and some of the quiz problems required two steps.  None of the quiz problems were as hard as the prelab they had to do this week, which involved 8 or more steps to get the resistor values to set the gain of the amplifier:

  1. Determine the pressure level of 60dB sound in Pa.
  2. Determine the sensitivity of the microphone in A/Pa:
    1. Convert -44dB from spec sheet to a ratio
    2. Get V/Pa sensitivity for microphone for circuit on spec sheet
    3. Convert to A/Pa given resistance of I-to-V conversion resistor on spec sheet.
  3. Determine voltages needed for op amp power supply.
  4. Determine I-to-V resistor needed to bias microphone in saturation region.
  5. Convert A/Pa sensitivity, RMS pressure level, and I-to-V resistor to RMS voltage out of microphone.
  6. Determine corner frequency and R, C values for DC-blocking filter.
  7. Determine maximum output voltage range of the amplifier as the most limiting of
    1. Voltage range of op amp outputs
    2. Power limits of loudspeaker (10W)
    3. Current limit of op amp (which is a function of the power-supply voltage) into 8Ω loudspeaker
  8. Determine max gain as ratio of RMS voltage into op amp and RMS voltage out of op amp (I’m allowing them to be a bit sloppy about RMS voltage vs amplitude, since we are not looking just at sine waves—the amplitude of a symmetric square wave is the same as the RMS voltage.)
  9. Choose resistor values to give the desired gain.

I’m hoping that pushing them go through these multi-step designs in the lab will give them more practice at decomposing problems into smaller pieces, so that two-step problems on a quiz no longer seem daunting, but routine.

I’m going to be giving them another quiz in about a week, covering op-amp basics and the amplitude response of RC filters.  I’ve got to figure out the best time to do this—possibly a week from Friday, after they’ve done another op-amp lab (using a phototransistor to make a pulse monitor, using this handout).  I think I’ll reorder the labs after that, doing the pressure sensor instrumentation amp lab, then the class D power amp, then the EKG.



2014 April 26

As expected, students did poorly on the quiz

Filed under: Circuits course — gasstationwithoutpumps @ 15:43
Tags: , ,

I gave about the same quiz as I did last year,  changing the numbers, removing one of the harder questions, and making sure that some of the other questions reflected worked examples we had done in class. The quiz was again on the 12th day of instruction. I had intended to move it to the 10th day, but one of the students was called out of town, so I rescheduled it so that everyone could take it at the same time.

I expected similar distribution to last year’s (last year the range was 3/32 to 12/32), but was hoping for slightly better.  I saw a distinct bimodal distribution this year, with half the class getting scores from 0/33 to 6/33 and the other half getting 11/33 or 12/33. This is a little clearer distribution than last year’s, which spread the students out more uniformly. I was still hoping that some of the better students would get over half the points on the quiz, but they seemed to top out at 36%.

I worked this year’s quiz myself in about 24 minutes (which means the quiz was a little too long still—I want about a 3:1 ratio on time, and the students had only 70 minutes).

I was really depressed after last year’s quiz, because I had not been expecting such dismal performance. This year I was braced for it, but still hoping for better.  Still there were some surprises:

  • There were a few questions that should have been free points (like asking for the impedance of a resistor with resistance R)—I was disappointed that some students missed even the trivial questions.
  • I had a pair of questions which were identical, except that one asked for algebraic formulas for impedance and the other gave component values and asked for numbers. I put the algebraic ones first this year, so the numeric ones were just a matter of plugging the numbers into the algebraic ones (and doing a sanity check).  The algebraic ones had a mean score of 2/4 with a standard deviation of 1.2, while the numeric ones had a mean of 1.22/4 and a standard deviation of 1.2.  I had not expected a drop in performance on the numeric ones, since the received wisdom in the physics education community is that students do better with numeric examples than algebraic ones.
  • No one got any points on the oscilloscope probe example, even though it was identical to an example we had worked in class.
  • The average score on a load-line problem was 1/6 with a standard deviation of 1.3.  This did not look like a normal distribution, but an exponential one, with half the class getting no points.
  • I had two low-pass RC filter questions. One asked for algebraic formulas; the other used the same circuit but asked for numeric answers using specific component values, voltages, and frequencies. The algebraic one was bimodal, with 2/3 of the class getting 0 and 1/3 getting the answers completely right. The numeric one was significantly worse, with only 2 out of 9 students getting any points (1/6 and 3/6).
  • I asked a couple of voltage divider questions that required applying the voltage divider formula circuits in which the voltmeter was connected between two nodes, neither of which was ground.  One asked for an algebraic results (a Wheatstone bridge), the other for a numeric result (voltage across the middle resistor of three in series. Students did very poorly on both,  with only one person getting the voltage for the middle resistor (one got half credit for setting it up right, but computing wrong), and no one getting more than 1/5 for the Wheatstone bridge.

Last year I suggested several ways to handle the poor performance on the first quiz:

  1. I could tell them to study and give them another quiz.  That would be totally useless, as it would just repeat the problems on this quiz.  They don’t know what it is that they need to know, and vague exhortations to study are pointless.  I don’t think the problem is lack of effort on their part, and that’s the only problem for which pep talks are a potential solution.
  2. I could go over the quiz question by question, explaining how I expected students to solve them.  This is classic lecture mode and the approach I used to use. It would be easy to do, but I doubt that it would help much.  I already did an interactive lecture on the material, and another approach is now needed.
  3. The students could get the quiz back and be told to go home and look up in their notes and on-line anything they did not get right.  They would find and write down the right answers, as if this were homework.  (This “quiz correction” is a standard strategy in high school teaching, but not common in college teaching.)  One difficulty here is that they might be able to find answers (say by copying from other students in the class) without understanding how to do the problems.  It is probably a better approach than yet another lecture, but I’m not sure it will work well enough.  If the students were trying to get from 80% understanding to 95%, it might be fine, but to get from 30% to 80%, something more directed is needed.  More time and open notes would help, but maybe not enough.
  4. I could break them into groups and give each group a couple of the problems to work on together in class. This peer instruction technique would be a good one if about 1/2 the students were getting the problems right, but with the top of the class getting only 1/3 right, I may need to give them more guidance than just setting them loose.  For example, on some of the problems there was a fundamental misreading of the circuit schematics that was very common. I could clear up that misunderstanding in a minute or so and have them rework the problems that depended on it.  Then I could send them home to write correct solutions.
  5. I could give out lots of problem sets to drill them on the material.  Of course, since it took me more than all day Sunday to make an 8-question quiz, it would take me forever to generate enough drill problems to be of any use.

I feel the same way this year about the possible teaching strategies, but this year I’m going to try a mix of methods 3 and 4, asking them to redo the quizzes at home, working with others until they are satisfied that they can now do the problems and other similar problems when asked.  I’ll have them hand it in this year as a homework, but not go over it in class until after they turn it in.  They need to take a more active role in trying to master the material, and not rely so much on my telling them what to do.

Monday we’ll cover inductors and loudspeakers, in preparation for the Tuesday measurement lab.

On Wednesday I was planning to do gnuplot analysis of the loudspeaker data, but I think I’ll keep that fairly short, so that we can get an intro to sampling and aliasing also before Thursday’s lab.  I have to decide whether to bring in my son’s stroboscope and a moving object to demonstrate aliasing.

Friday, I’ll introduce op amps, with the intent of developing the block diagram in class on Monday for a simple op amp microphone circuit for the Tuesday lab.  This weekend I need to rewrite that lab from last year—I decided last year to use the dual power supply with a center ground for their first op-amp design, rather than having them build a virtual ground (we’ll get that in the next lab assignment).



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.

    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.

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.

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)

// 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) 

// 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
    PCR_PORT_TO_USE |= PORT_PCR_ISF_MASK | PORT_PCR_IRQC(11);  // clear interrupt for PTD3, and enable interrupt on either edge
    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() 
    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

    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
        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);
    {   uint32_t freq=frequency();
        printf("%lu Hz\n",freq);  
        if (freq < low_freq)
        {   // low_fequency found, turn LED green
        else if (freq >= high_freq)
        {   // high frequency found, turn LED blue again
Next Page »

The Rubric Theme. Blog at


Get every new post delivered to your Inbox.

Join 266 other followers

%d bloggers like this: