In today’s lab we derived the formula for the period of a simple pendulum (assuming the small-angle approximation), , then measured both circular and simple pendulums.  For the circular pendulum we measured the radius of the cone on the first orbit and the last orbit, the length of the string (the slant height of the cone), and approximated the period by timing 10 or 20 periods and dividing.  For the simple pendulum, we used the photogate setup described in More on pendulums, to get very precise and repeatable measurements of the period.  The hardest part for us was measuring the length of the pendulums, since the center of mass for the bob was not obvious and the exact position of the pivot was not obvious—these uncertainties probably resulted in length measurements being ±5mm, making a large contribution to inaccuracy.

Here is a table of the measurements (and calculated g) we made for the circular pendulum:

The range of estimates for g is larger than I would like.  I think that the decay of the oscillation of the pendulum makes quite a difference.  The average of all the estimates of g is 967 gm/sec^2, which is rather low.

And for the simple pendulum:

The pendulum ticked reliably for quite a while, and the periods were remarkably consistent.  The estimates of g from the simple pendulum are good to about 0.5%, which is the limitation of accuracy on our pendulum length measurements and close to the limit of the accuracy of the small-angle approximation.  The average of the 5 measurements looks good to about 0.2%, which seems pretty good to me, since we certainly weren’t measuring the lengths that accurately.

I looked up the gravitational field in Santa Cruz on Wolfram Alpha’s gravitational fields widget:

total field | 9.7995 m/s^2  (meters per second squared)
angular deviation from local vertical | 0.00322°  (degrees)
down component | 9.79945 m/s^2  (meters per second squared)
west component | 3.4×10^-4 m/s^2  (meters per second squared)
south component | 0.0316 m/s^2  (meters per second squared)
(based on EGM2008 12th order model; 11 meters above sea level)

While the lab was running, one of the students wrote a Python script (using numpy for mean and standard deviation) to read the data and compute the numbers in the table.  We could have talked directly to the Arduino, but it was simpler to cut the numbers from the Arduino serial monitor and paste them into a file for the script to read. That allowed us to keep the Arduino running throughout, and just cut and paste the good numbers, discarding the junk from starting or stopping the pendulum.

I’m quite pleased with the photogate setup, which was very simple to build and worked reliably during the experiment. Crudely wrapping tape around the string made a lumpy opaque object, whose rotation probably contributed to the standard deviation of the  period—having a smoother cylinder for the optical blocker would probably make the period measurement much more consistent.  But that would not improve the mean estimates much since errors in adjacent period measurements cancel.  I believe that our mean periods are much more accurate than the standard deviations suggests, with errors less than 1 per thousand.

I had to make one change in the Arduino code during the lab to accommodate all the different pendulum lengths—I had a dead time before recognizing the next pulse, to prevent getting 2 pulses per period as the string passed through the beam twice.  I started with a dead time of 1 second, which as a bit too long for the smallest pendulum.  Reducing the dead time to 500 msec for that pendulum made it count reliably.  Note that for the 2nd and 3rd pendulum, we measured for about 3 minutes without a bad time measurement, and could have gone longer if we had had the patience.

In Newton’s measurement of g, I described a failed experiment to measure g with a motorized circular pendulum. Further experimentation on my own lead me to adopt for this week’s lab the standard approach using an unpowered circular pendulum.  The cone formed by the string can be described as having height , base radius , and hypotenuse , the length of the string.  If the circular pendulum has period , then (derived in the Newton post).  If we make the string long and push the pendulum with the right speed to get a nearly circular (rather than elliptical) motion, then is nearly constant for many orbits, and we can estimate the period with just a stopwatch by counting 20 or 30 periods.  Using a large enough mass means that neglecting air resistance is now reasonable (which it was not for the tiny mass I started with).

Thanks to John Burk for suggesting that I forget about the motor—that seems to be the best approach, even though I then can’t use the photogate to time the period.  I’m hopeful that we can measure the height and the period accurately enough to get within about 2% of the right value for .

This week in addition to doing the circular pendulum right, I wanted to do simple pendulums.  I’ve assigned problem 4.P.89 in Matter and Interactions, which seems to be the only place in the book that simple pendulums are done.  It is a computational problem, since there isn’t an analytic solution (though the small-angle approximation works pretty well up to about 45°).  I hope the students have done that by tomorrow!

I wanted to measure the period of the pendulum directly (not averaging over many periods), to demonstrate that the amplitude does not matter much.  Unfortunately, I’ve not yet built a sensor that works for this. I tried using the photogate, but I could not hit the 1 cm gap consistently, even with a shorter pendulum.

I also tried using a magnetic sensor (using the circuit I used for the speed-of-sound lab) with a magnet for the pendulum weight, but that triggered at random times as the magnet came close.  Even 20cm away the field was enough to trigger the detector, and I got almost random timings.  A magnetometer was no better than the coil and comparator, as the magnetic field varied chaotically (from movements of the magnet other than the simple pendulum swing, such as twirling on the string).  The magnetometer was usable as a compass, though, which is good, because I originally bought it for the robotics club to use as a compass.  There are some tricky points to using it as a compass, which I’ll talk about in a different post.

I then tried marking the top of the string with a bit of electrical tape and using the photogate there.  That was the most successful so far—if I hold the photogate steady enough, I can get readings repeatable to ±20msec, which is much better than I can do with any other approach I’ve tried.  For one pendulum hanging from the edge of my desk, I either got  two pulses at about 1.11 and 0.45 seconds or one pulse every 1.56 seconds, depending on whether the marker on the string passes all the way through the beam or blocks it continuously at the end of the swing. The random variation I get is probably because of holding the sensor by hand (to align with the string).

If I had a more rigid way to mount the sensor, I should be able get more consistent readings, so my main engineering task was to get a rigid pivot point on the ceiling beam (without making any holes) and mount the photogate in a rigid, but adjustable, way.  Of my two standard mechanical engineering techniques, duct tape and Lego, I chose Lego:

A view of the photogate mounted on the Lego beam next to the pendulum string.

Closeup of the photogate, showing the breakout board and sensor wedged between a plate and a beam, with a 2-plate spacer.

Having come up with a nice way to grip the photogate and still be able to swing a pendulum string into the gap, I connected the beam holding the photogate to the same right-angle platform that we had used last week for the motorized pendulum. This left a little gap that I could rest the Arduino board in, so that there was no tension on the wires to the photogate.

I was a bit worried that I might have to put my laptop on top of a ladder, since the USB cord is not very long, but I have a spare pair of USB-to-Cat5 converters (one set is for the robotics project), so I was able to make an extension cord out of a flexible Cat-5 Ethernet cable, giving me enough length to put my laptop safely on the desk.

The same Lego that holds the photogate can also support the Arduino, so I don't need to hold anything in my hands.

I had two other ideas I haven’t tried: using one of the ultrasonic range finders to track the pendulum motion and using a video camera to time the motion.  These require interpolation of position data to estimate the period, so I’d rather avoid them for now. The top-of-string photogate will work (I think) for the simple pendulum, and the circular pendulum can be timed with a stopwatch averaged over many periods.  (I could even use the photogate timer as a stopwatch, though the resolution of the stop watch on my Casio wristwatch is 0.01 seconds, and human reflexes make anything less than 0.1 second pretty much noise.)

The speed-of-sound lab we did on 30 Dec 2011 went pretty well after all.

Coil (about 0.5H) with refrigerator magnet on top. Magnet is stuck to the core of the coil just by its own magnetism.

I used a setup inspired by the one in the Chapter 4 Lecture 3 video at http://courses.ncsu.edu/py581/common/podcasts/.  That is, a long metal bar tapped with a metal striker at one end.  A clock is started when the tap is made (a simple electrical connection), and stopped when the wave is detected at the other end.  As mentioned in my earlier post More on the slinky and the speed of sound, I used an electromagnet and a small refrigerator magnet to detect the sound wave.  The coil has a  68.3 Ω resistance and a laminated iron or steel core, and I estimated the inductance at about 0.5 Henry (the estimate  may easily be off by a factor of 2—I should measure it better some day when it matters). When I rested a piece of aluminum bar stock on the magnet and tapped the other end, I got a signal of about 0.3 v, which I could see clearly on my oscilloscope.  (Note: the analog view of the signal was not done in the lab with the students, because we were pressed for time and moving the analog oscilloscope out to the room worked in and setting it up would have taken too long.)

The signal is not large enough to be measured by a digital input on the Arduino that we used for timing, and the Arduino analog-to-digital converter (accessed with analogRead()) is a very slow one, that would limit our time resolution to about 100 µsec, rather than 4 µsec as we can get with the “micros()” function call. I happened to have an LM311 comparator chip from about 30 years ago, so I made a comparator circuit to convert the analog signal to a clean digital signal.

Comparator circuit used to convert the small electrical signal induced in the coil to digital levels for input to the Arduino. The pair of 15kΩ resistors serve as a voltage divider to set the bias voltage for the inputs to about 2.5 volts, in the middle of the range. The output pull-up resistor provides a load for the comparator. The two capacitors filter out high frequency signals picked up by the coil—they were not part of the circuit provided in the LM311 datasheet, but turned out to be essential.

I did have to modify the circuit a little from the one for a magnetic pickup given in the data sheet, as the output remained high with that circuit.  Adding small capacitors to the input and output seemed to fix things.  I arbitrarily used 47000pF capacitors, because I happened to have several of them, but I also experimented with some other sizes (560 000 pF and 1000pF) which did not work.  One effect of the capacitor on the input is to make a resonant circuit that rings with a period of about 800 µsec (eyeballed from the oscilloscope trace), which would make the inductance of the coil about 0.34H.  This ringing has a couple of consequences: 1) if the magnet is the wrong way around, the polarity of the impulse is reversed and the comparator will detect the impulse half a cycle later, adding about 400 µsec to the reading, and 2) the signal ramps up slowly in response to an impulse, and the delay in the comparator circuit is dependent on the magnitude of the input signal.  This will add noise to the timing measurements.

Because the magnet we used had residues of paper and glue on one side, it was easy to check that it was oriented correctly.  For one set of measurements, the coil and magnet had to be moved, and the magnet may have been upside down for that set of measurements, resulting in a different offset for those measurements.

To keep the noise from differences in amplitude to a minimum, we took several measurements (generally 10 or 20) of each time, discarding obviously bogus numbers (like 8 µsec when the comparator had already detected something before the strike, or > 10 msec, when an impulse had been missed).

On the Arduino, the following program was used measure times.  Pin 2 of the Arduino was connected with a long wire to a metal striker, with the object being struck connected to Arduino’s GND with another wire.  Contact between the two metal objects pulled pin 2 down (overpowering the 20kΩ pull-up in the Arduino), recording the time in start_1. As soon as the comparator detects the sound, pin 3 is pulled down, and the time is recorded on stop_1.  The resolution of the timer is about 4 µsec, but the repeatability of the times varied more, depending in part on how consistently the strikes were made (one of us appeared to have much more consistent technique than the others, and the times from his strikes had lower spread—we did not record who did the strikes on our data log, and so we can’t quantify this observation).

void setup()
{
  //  put a 20k pullup resistor on pin 3 (sound detector)
  pinMode(3,INPUT);
  digitalWrite(3, HIGH);
  //  put a 20k pullup resistor on pin 2 (striker)
  pinMode(2,INPUT);
  digitalWrite(2, HIGH);

  Serial.begin(115200);
}

void loop()
{
  Serial.println("Ready");

  // wait for pin 2 to go low (contact with striker)
  while (digitalRead(2)>0) {}
  long start_1=micros();

  // wait for pin 3 to go low (sound detected)
  while (digitalRead(3)>0){}
  long stop_1=micros();
  long diff = stop_1-start_1;
  if (diff > 10000)
  {   Serial.print(F("rejecting large delay: "));
  }
  Serial.print(diff);
  Serial.println(F(" microseconds"));
  delay(200);  // wait 200 msec

  // wait some more if the striker still in contact
  while (digitalRead(2)==0) {}

}

The vertical rod is the one being measured. The sensor is on the floor and the rod is struck at the top end. The breadboard has the comparator circuit connected to the Arduino, which in turn is connected to a laptop (not in the photo).

The setup for most measurements was simple: the coil was put on the floor with the magnet resting on top. A rod was held vertically on top of the magnet and struck at the far end with another rod. Initially, we used a small screwdriver as the striker, but this turned out to be hard to hold, and so we switched to using a foot-long piece of ¼” steel rod, which was also used for some of the timing tests.

Because the delay in the comparator is unknown, but likely to be substantial compared to the time of flight, we tried to measure the same material at different lengths, and do a straight-line fit of the data to estimate the offset. By doing many measurements at each length, we could average out a lot of the noise. We could also see how well the data fitted a model that assumed that the time delay for the sound arriving would be proportional to length—that is, does the speed-of-sound model make sense for this data?

The simplest set of data was for 3 rods ¼” in diameter, made of hot-rolled weldable steel (that’s all the information about the material that the hardware store had on the tag). I’ve put the data in a page on the blog: Steel rod speed of sound lab data.

We also measured one aluminum bar (Aluminum bar speed of sound lab data), one long copper tube (Copper tube speed of sound lab data), and two wood dowels (Wood speed of sound lab data).  Because wood is not conductive, we added a washer on the striking end of the dowel, to provide a conductive contact. The copper tube was about 3m (10′) long and very soft, so we laid it on the floor and duct-taped the sensor to one end.

Perhaps the most interesting data set comes from an aluminum ladder (Aluminum ladder speed of sound lab data).  We removed one foot from the ladder and duct-taped and bungey-corded the sensor to the bottom of the ladder.  We then struck the ladder inside the hollow rungs, providing a nicely spaced series of different ten different lengths.  Because of the difficulty in getting the duct tape to stick to the ladder, the magnet fell off and was replaced a few times in setting up the sensor.  The final orientation was not checked, but I believe that it was backwards, so that the delays of the sensor were substantially larger for the ladder than for the other measurements.  Luckily, there are enough different lengths that we can get a very good linear fit even with a large offset.

I did a fit for the steel-rod data using the following gnuplot script:

unset key

set title "Time of flight for compression wave in 1/4\" hot-rolled steel rod"
set xlabel "length (meters)"
set ylabel "time (seconds)"

set xrange [0:*]
set yrange [0:*]

fit a*x+c 'steel-rod.txt' using (0.01*$1):(1e-6*$2) via a,c

print "velocity=", 1/a, "m/s"

plot a*x+c, 'steel-rod.txt' using (0.01*($1+2*rand(0))):(1e-6*$2)

which produced an estimate of 5292 m/s for the speed of sound in the steel rod. I was noticing on the web that the speed of sound in thin rods may be a bit different from the speed of a planar wave in bulk steel, so I’m not sure what the “right” value is for this measurement, but it sure seems reasonably close to reported values around 5000–6000 m/s.  I also get from the same fit an estimate of the delay in the sensor and comparator of 33.7 µsec, which I can use for the aluminum bar and copper tube data. How does the fit look?  See for yourself:

The linear model seems like a pretty good fit for the data on the steel rod, but the scatter on the data is a little high. Note: small random jitter was added to the x values, in order to spread the points out.

If I remove outliers (the two largest and two smallest measurements from each length), I get a tighter fit (naturally), but one with is also likely to be more accurate, as outliers have a large influence in linear regression:

After eliminating the outliers, the estimated speed of sound is 5267 m/s and the sensor delay is 31 µsec.

Using a similar script, but with a fixed 31 µsec offset, for the aluminum bar data and the copper tube data (again eliminating the two largest and two smallest measurements), we get 4412 m/sec for the aluminum bar and 3857 m/s for the copper tube. (Of course, we don’t have anywhere near 4 significant figures, so I should probably round these to 4400 m/s for aluminum and 3900 m/s for copper.)

The ladder data used essentially the same script as the steel-rod, but even after censoring the data had a pretty wide spread:

The ladder data, after removing the two largest and two smallest times at each data point, got an estimated speed of sound in aluminum of 3955 m/s. The offset was 256.6 µsec, confirming that the magnet had been reversed. (It also implies that one period of the ringing is about 450 µsec, which is shorter than the period I thought I saw on the oscilloscope.)

If I fit the data from the wood dowel using the 31 µsec offset, the line does not fit the data at all well. If I fit with a 2-parameter model, I get an offset of 162.6 µsec (between the ones for the steel rod data and the ladder data), and a velocity of 6150 m/s, which is unusually high for wood. It is a very light wood, so perhaps the number is reasonable, but I’d be more comfortable if we had had more different lengths to test. The difference in the delay introduced by the sensor suggests to me that I should have used multiple lengths for each of the materials, despite the inconvenience (I only had one piece of aluminum bar and did not want to cut it—similarly, I did not want to cut the copper tube.)

Comparing our speeds with typical speeds from engineeringtoolbox.com:

The best match is for the copper, with our aluminum alloys having a much lower speed of sound than typical for pure aluminum (does our alloy have higher mass? lower stiffness?), and our wood dowel having a much higher speed of sound than typical for wood. The steel rod was a little low, but within the range of reported speeds of sound in steel.

This report took me several hours to write, in part because producing the graphics took a while, and in part because I fussed around a lot with seeing if removing outliers from the data helped get better results.  My son produced a substantially similar lab report, with graphs but no pictures or schematic of the comparator, in 2–3 hours.  He did not play with removing outliers.  He also correctly reported the velocities with only 2 significant figures (in cm/µsec).

The Slinky Lab post got an interesting pingback from Engineering Failures » Secrets of the ‘Levitating’ Slinky, which describes the curious phenomenon that happens when you suspend a slinky vertically, then release the top end. The bottom end does not move for about 0.3 seconds, when the compression wave from the top reaches it. It might be worth videotaping that phenomenon in this week’s lab.

I think it might be interesting to try to calculate (either analytically, or as part of the VPython simulation) the movement of Slinky as you drop it. In particular, I’m curious at what point the compression wave becomes a shock wave (that is, when does the top of the slinky start moving faster than the speed of sound in the slinky). Note that the speed of sound in the slinky is best expressed as “coils per second” rather than m/s, in order to get a constant speed of sound in the non-uniformly stretched slinky.

The other lab/demo I was thinking of doing this week, measuring the speed of sound in a metal bar, is not going so well.  I was planning to use a setup similar to that in the Chapter 4 Lecture 3 video at http://courses.ncsu.edu/py581/common/podcasts/.  That is, a long metal bar, with a microphone at one end, tapped with metal striker at the other end.  A clock is started when the tap is made (a simple electrical connection), and the waveform is recorded at the other end.

The first problem was that I did not have a suitable microphone.  I found a quick workaround for that problem, as just last week my wife had given me a fine electromagnet that she had found in the street (we have a lot of “found objects” at our house).  The coil has a 68.3 Ω resistance and a laminated iron core, so waving a magnet around near the pole piece results in a fairly substantial electrical signal across the ends.  So I made my own “microphone” with the coil, a refrigerator magnet, and a folded piece of paper as a spring.  If I rest a piece of aluminum bar stock on it and tap the other end, I get a signal of about 0.3 v, which I can see clearly on my oscilloscope.  If it was a storage scope, I’d be almost done, since I could trigger on one channel and record on the other.  I might still have to do something like that with my analog scope.

What I had hoped to do was to use an Arduino to measure the time it took from the tap to the signal arriving at the other end. Using the micros() subroutine provides timing with a resolution of about 4 microseconds, and starting it on electrical connection from the tap is pretty easy.  I had initially thought to use the analogRead() function, but it is too slow: each analog-to-digital conversion takes about 100 microseconds, and the speed of sound in aluminum is about 6400 m/s, or about 150 μsec to go a meter.  I don’t think I can do speed measurements with that low a time resolution unless I had a bar of aluminum 100s of meters long.  That means that to use the Arduino for timing, I have to convert the analog signal to a digital one by some other means.  The most obvious method is to use a comparator chip, such as an LM339.  I looked through the spare chips I have from 30 years ago, and found one LM311-N14A chip, which has a comparator that takes only a +5v supply.  The data sheet even has a circuit for a “magnetic transducer”.  I tried the circuit, and found that  I needed to add capacitors across the input and the output to reduce noise that otherwise kept the comparator triggered.

Once I got the comparator circuit working, it was fairly trivial to hook everything up to the Arduino and write the following program:

void setup()
{
  //  put a 20k pullup resistor on pin 3
  pinMode(3,INPUT);
  digitalWrite(3, HIGH);
  //  put a 20k pullup resistor on pin 2
  pinMode(2,INPUT);
  digitalWrite(2, HIGH);

  Serial.begin(115200);
}

void loop()
{
  Serial.println("Ready");

  // wait for pin 2 to go low
  while (digitalRead(2)>0) {}
  long start_1=micros();
  while (digitalRead(3)>0){}
  long start_2=micros();
  Serial.print(F(" start_1="));
  Serial.print(start_1);
  Serial.print(F(" start_2="));
  Serial.print(start_2);
  Serial.print(F(" diff="));
  Serial.println(start_2-start_1);
  delay(100);

}

I tried it out with a piece of aluminum about 1.026m long, and got numbers in the range 272μsec to 304μsec, which would be speed of sound of 3380 m/s to 3780 m/s. That is a little slower than I expected. One possibility is that the comparator is not responding to the movement of the magnet toward the coil, but the rebound as it moves away. If I flip the magnet over, I get even longer times (784μsec to 884μsec), so I suspect the first orientation was the correct one, and the speed of sound in this aluminum alloy is a little lower than I expected, or the comparator circuit is adding some delays.

I’ll have to make a bit more robust way of holding the magnet and stuff, before Friday’s lab/demo, since everything is currently rather wobbly (the magnet is held to the coil with a PostIt note to act as the spring).

The Physics Lab 2 post and Physics class progress described some experiments we were going to do this week with the ultrasonic range finder(s).

What we actually did, after spending a fair amount of time discussing the schedule for the year and expectations (one of the students has not started yet, because of the amount of time he was putting into his Stanford essays—I hope he gets in after all the effort he has expended, was to drop balls and try measuring the drop with both the Maxbotix sensor and a video camera.

We tried both a ping-pong ball and a slightly larger plastic ball.  With both of them the Maxbotix sensor only detected them intermittently, and we go no useful data from the rangefinder.

The HD video from the camera was more usable, but I was not aware that Tracker could use MTS (AVCHD format) files, since it greyed them out. I wasted a lot of time converting the movies to .mov format using iMovie, a piece of software that I have come to hate for its slowness, inefficient use of disk, rigid insistence on a specific directory structure, and generally unfriendly and unintuitive user interface. I’ve gone so far as to buy Premiere Elements, with the hope that it is not so awful (but I’ve not tried to use it yet, so it might be just as bad).

It turned out that my son had not installed the Tracker software on the desktop machine, so we had to get out my laptop and try analyzing the frames there.  I remembered how to calibrate and get the autotracking set up, but I forgot how to specify the beginning and ending frame (I eventually figured it out, but only after some false starts).  The data was pretty clean, though autotracking did lose the ball at one point because of some really stupid projections about where it ought to be.  Redoing the autotracking fixed that problem.  The errors in the tracking due to motion blur were not noticeable in the position plot, made small wiggles in the velocity plot, and made huge wiggles in the acceleration plot.  We did get a chance to talk about how a ±1mm error in position results in a ±3 cm/sec error in velocity and a ±90 cm/sec² error in acceleration, when using 30 frames per second.

I tried redoing the autotracking using the AVCHD format directly from the camera, but it turns out that AVCHD uses interlaced images, so one gets two pictures of the ball in each frame. When the ball is motionless, this makes a nice circle, but when the ball is moving fast, you get two striped circles that may overlap. Tracker has trouble handling the interlacing, though a really clever algorithm could take advantage of it to get effectively double the frame rate when tracking large objects moving with reasonably constant acceleration.

Bottom line was that neither the ultrasonic rangefinder nor Tracker resulted in fast, painless measurement. We’ll have to try again next week, perhaps with bigger targets for the rangefinder. I initially thought that brighter light for the video would reduce motion blur by reducing shutter time, but it seems that the motion blur is due to interlacing, not to a slow shutter, so changing the lighting won’t help. Algorithmic changes to Tracker would be needed.

What to do in next week’s lab

1. Analyze the balldrop clips (in .mov format). For calibration, the distance we measured between the top and bottom stile of the file cabinet was 112cm. Since the ball was a few cm in front of the file cabinet, there may be some perspective error in using that measurement to calibrate the drop. Get Tracker to give you position, velocity, and acceleration plots. Use the fluctuation in the acceleration estimates to estimate the errors in the velocity and position measurements.
2. Write a Vpython program that simulates the motion of the falling ball including the initial pause before dropping, but not including the bounces.

Other homework

• Read Chapter 3.
• Work problems 3.P.36, 3.P.40, 3.P.43, 3.P.46, 3.P.52, 3.P.65, 3.P.72.
• Do computational problem 3.P.76. Note that the computational problems for Chapter 3 are not independent of each other, and you should read all the preceding problems to get hints for this problem.

The physics class that I’m doing with my son and another home schooler is going a bit slowly.  The other student couldn’t make it again this week (Stanford early admission deadlines, and he needed the time to polish his application essays).

My son and I compared answers to the Chapter 2 problems I’d assigned (see Physics Lab 2).  We’d each made some careless errors (in one, I’d neglected to take a square root, though I’d written the right formula, in another, I’d forgotten to add the sideways movement during acceleration, in a third, my son had forgotten to divide by 2 at one point).  In short, neither of us were doing “A” work—we knew what we were doing, but were being inexcusably sloppy in the computations (me more so than my son). I’ll have to do better on Chapter 3.

I think that I won’t assign any exercises in Chapter 3 this week, to give the other student a chance to catch up.  Instead, I’ll ask my son to finish the data-acquisition code for the ultrasonic rangefinder.  I wrote some simple code running on the Arduino for gathering the data, and he was going to write a Python program (using PySerial) to record the data and output it in a format suitable for plotting with gnuplot.

Our goal is to finish at least the Newtonian mechanics (Chapters 1–13 of Matter and Interactions) before the AP Physics C exam (afternoon of 14 May 2011), which gives us time for a little over 2 weeks per chapter.  That seems like a fairly leisurely pace right now, but perhaps the chapters get harder.  If we finish earlier, it might be worthwhile to do some timed practice with released tests, which are available at AP Central – The AP Physics C: Mechanics Exam. The Mechanics part of the exam is only 90 minutes (it is followed by the other half of Physics C, which we probably will not get to, unless we double our pace). I think that I’ll take the exam along with the two students, risking the embarrassment of them doing better than me.

Assignment for this week:

• Finish the assignments from the previous posts (the text about how ultrasonic rangefinders work, the problems and program from Chapter 1, the problems and program from Chapter 2).
• For my son only: get the data acquisition program working, so that we can do a lab recording something actually moving.  (We might try video recording it at the same time and comparing Tracker with the ultrasonic rangefinder as a data source.)
• Read Chapter 3.

Arduino code for recording from rangefinders:

// Kevin Karplus
// 30 Sept 2011
//  Using the Ping))) or maxbotix ultrasonic rangefinder
//  to acquire (time_stamp, time_of_flight) pairs and send them over a
//  serial line to a laptop.

// From the documentation:
//   Bidirectional TTL pulse interface on a single I/O pin
//    can communicate with 5 V TTL or 3.3 V CMOS microcontrollers
//   Input trigger: positive TTL pulse, 2 μs min, 5 μs typ.
//   Echo pulse: positive TTL pulse, 115 μs minimum to 18.5 ms maximum.

// As a kluge, the Ping))) is plugged into pins GND,13,12.
// The output pin 13 can provide 40mA of current to the Ping))),
// which only requires about 35mA.

const uint8_t Ping_pin=12;
const uint8_t Vdd_pin=13;

const uint8_t Maxbotix_pin=2;

// speed of sound in air in m/s, as a function of temperature
// in degrees Celsius.
// BUG: currently humidity is ignored, but the speed of sound
//      is higher in more humid air.
inline float speed_sound_t(float temp_C, float relative_humidity=0.0)
{
  // return 331.3 + 0.606 *temp_C; // linear approx
    return 20.0457 * sqrt(temp_C+273.15);
}

float temp=20.0;  // temperature in degrees Celsius
float speed_sound;  // estimated speed of sound in meters/sec
float half_speed_cm_microsec;  // half the speed of sound in cm/microsecond

void setup()
{   pinMode(Vdd_pin, OUTPUT);
    digitalWrite(Vdd_pin, HIGH);
    pinMode(Ping_pin, OUTPUT);
    digitalWrite(Ping_pin, LOW);

    pinMode(Maxbotix_pin, INPUT);
    Serial.begin(115200);

    speed_sound=speed_sound_t(temp);
    half_speed_cm_microsec = speed_sound *0.5 * 100. * 1.e-6;
    Serial.print("Assuming temperature of ");
    Serial.print(temp);
    Serial.print(" gives speed of ");
    Serial.print(speed_sound);
    Serial.println("m/s");

    Serial.println("Arduino Ready");

}

// read_ping returns the time in microseconds for one echo pulse
// There seems to need to be a 1 msec delay needed between read_ping()
// calls (200 microseconds does not seem to be enough).
//
// Reads are very unreliable if the target is close than about 8cm.
unsigned long read_ping(void)
{   // request a reading
    digitalWrite(Ping_pin, HIGH);
    delayMicroseconds(10);
    digitalWrite(Ping_pin, LOW);
    // Now there is a 750 microsecond hold off
    pinMode(Ping_pin, INPUT);

    unsigned long tof= pulseIn(Ping_pin, HIGH);
    pinMode(Ping_pin, OUTPUT);
    digitalWrite(Ping_pin, LOW);
    return tof;
}

// read_maxbotix returns the time in microseconds for one echo pulse
//
// Reads are very unreliable if the target is close than about 16cm,
// but seem more consistent than the Ping))) for longer distances.b

unsigned long read_maxbotix(void)
{
    return pulseIn(Maxbotix_pin, HIGH);
}

bool send_Ping_data=0;
bool send_Maxbotix_data=0;
void loop()
{
     if (Serial.available())
     {  char c=Serial.read();
        switch(c)
        {  case 'b':
            send_Ping_data=1;
            send_Maxbotix_data=0;
            break;
           case 'm':
             send_Ping_data=0;
             send_Maxbotix_data=1;
             break;
           case 'e':
             send_Ping_data=0;
             send_Maxbotix_data=0;
             break;
        }
     }

     // For both sensors, report when the measurement was made,
     // the time of flight for the pulse to go and return,
     // and the computed distance for
     // Both are reported in milliseconds.
     // The time of measurement is corrected by half the time of flight,
     // so that it approximates the time at which the pulse bounced off the object.
     if (send_Ping_data)
     {   unsigned long time_of_flight=read_ping();
         unsigned long when_measured=micros();
         delay(1);   // wait a millisecond to let sensor recover
         Serial.print(when_measured-time_of_flight/2);
         Serial.print("\t");
         Serial.print(time_of_flight);
         Serial.print("\t");
         Serial.println(time_of_flight*half_speed_cm_microsec);
     }
     if (send_Maxbotix_data)
     {   unsigned long time_of_flight=read_maxbotix();
         unsigned long when_measured=micros();
         Serial.print(when_measured-time_of_flight/2);
         Serial.print("\t");
         Serial.print(time_of_flight);
         Serial.print("\t");
         Serial.println(time_of_flight*half_speed_cm_microsec);
     }

}