Posts with «physics» label

Dirt Cheap Muon Detector Puts Particle Physics Within DIY Reach

Subatomic physics is pretty neat stuff, but not generally considered within the reach of the home-gamer. With cavernous labs filled with racks of expensive gears and miles-wide accelerators, playing with the subatomic menagerie has been firmly in the hands of the pros for pretty much as long as the field has been in existence. But that could change with this sub-$100 DIY muon detector.

[Spencer Axani] has been fiddling with the idea of a tiny muon detector since his undergrad days. Now as an MIT doctoral candidate, he’s making that dream a reality. Muons are particles that are similar to electrons but more massive and less likely to be affected by electromagnetic fields. Muons rain down on the Earth’s surface at the rate of 10,000 per square meter every minute after being created by cosmic rays interacting with the atmosphere and are capable of penetrating deep into the planet. [Spencer]’s detector is purposely kept as low-budget as possible, using cheap plastic scintillators and solid-state photomultipliers hooked up to an Arduino. The whole project is as much STEM outreach as it is a serious scientific effort; the online paper (PDF link) stresses the mechanical and electronics skills needed to complete the build. At the $100 price point, this build is well within the means of most high school STEM programs and allows for a large, distributed array of muon detectors that has the potential for some exciting science.

We’ve covered quite a few subatomic detection projects before, from the aforementioned large-scale builds to more modest efforts. But we like this project because it has the potential to inspire a lot of citizen scientists.

Thanks for the tip, [deralchemist]


Filed under: misc hacks

Arduino data logger at Global Physics Department

My son presented the Arduino Data Logger he wrote for my circuits class to the Global Physics Department on 2013 May 15.  The sessions are recorded, and the recording is available on the web (though you have to run Blackboard Collaborate through Java Web Start to play the recording).

I thought he did a pretty good job of presenting the features of the data logger.

Now that school is beginning to wind down, he’s started looking at making modifications to the data logger code again, and has updated it at https://bitbucket.org/abe_k/arduino-data-logger/

He’s down to only three classes now (US History, Physics, and Dinosaur Prom Improv), though he still has homework to catch up on in Dramatic Literature and his English class.  He’s still TAing for the Python class also.

On Thursday and Friday this week, he’ll be taking the AP Computer Science test and the AP Physics C: Electricity and Magnetism test.  He’s having to take both tests in the “make-up” time slot, because we couldn’t get any local high school to agree to proctor the tests for him during the regular testing time.  Eventually his consultant teacher convinced the AP coordinator to let her proctor the tests, but by then it was too late to register for anything but the makeup tests. We’re way behind schedule on the physics class, so he’s just going to read the rest of the physics book without working any problems before Friday’s exam—we’ll finish the book in a more leisurely fashion after the exam. He won’t be as prepared for the physics exam as I had hoped, but at least the CS exam looks pretty easy to him.

One thing I didn’t realize is that schools can charge homeschoolers whatever the market will bear for proctoring the tests:

  • Depending on the reasons for late testing, schools may be charged an additional fee ($40 per exam), part or all of which the school may ask students to pay. Students eligible for the College Board fee reduction will not be charged the $40-per-exam late-testing fee, regardless of their reason for testing late.
  • Schools administering exams to homeschooled students or students from other schools may negotiate a higher fee to recover the additional proctoring and administration costs.

[ http://professionals.collegeboard.com/testing/ap/about/fees ]

We’re paying $145 per exam (not just the $89 standard fee and the $40 late fee), but I’m glad he gets to take the exams at all this year.

Tomorrow he and I are doing another campus tour—this time at Stanford. He managed to get an appointment with a faculty member, but we noticed that the faculty member is scheduled to be teaching a class at the time of the appointment—I wonder what is going to happen with that. I’ll report on the visit later this week.


Filed under: Data acquisition Tagged: Advanced Placement exams, Arduino, data logger, Global Physics Department, physics

Arduino data logger at Global Physics Department

My son presented the Arduino Data Logger he wrote for my circuits class to the Global Physics Department on 2013 May 15.  The sessions are recorded, and the recording is available on the web (though you have to run Blackboard Collaborate through Java Web Start to play the recording).

I thought he did a pretty good job of presenting the features of the data logger.

Now that school is beginning to wind down, he’s started looking at making modifications to the data logger code again, and has updated it at https://bitbucket.org/abe_k/arduino-data-logger/

He’s down to only three classes now (US History, Physics, and Dinosaur Prom Improv), though he still has homework to catch up on in Dramatic Literature and his English class.  He’s still TAing for the Python class also.

On Thursday and Friday this week, he’ll be taking the AP Computer Science test and the AP Physics C: Electricity and Magnetism test.  He’s having to take both tests in the “make-up” time slot, because we couldn’t get any local high school to agree to proctor the tests for him during the regular testing time.  Eventually his consultant teacher convinced the AP coordinator to let her proctor the tests, but by then it was too late to register for anything but the makeup tests. We’re way behind schedule on the physics class, so he’s just going to read the rest of the physics book without working any problems before Friday’s exam—we’ll finish the book in a more leisurely fashion after the exam. He won’t be as prepared for the physics exam as I had hoped, but at least the CS exam looks pretty easy to him.

One thing I didn’t realize is that schools can charge homeschoolers whatever the market will bear for proctoring the tests:

  • Depending on the reasons for late testing, schools may be charged an additional fee ($40 per exam), part or all of which the school may ask students to pay. Students eligible for the College Board fee reduction will not be charged the $40-per-exam late-testing fee, regardless of their reason for testing late.
  • Schools administering exams to homeschooled students or students from other schools may negotiate a higher fee to recover the additional proctoring and administration costs.

[ http://professionals.collegeboard.com/testing/ap/about/fees ]

We’re paying $145 per exam (not just the $89 standard fee and the $40 late fee), but I’m glad he gets to take the exams at all this year.

Tomorrow he and I are doing another campus tour—this time at Stanford. He managed to get an appointment with a faculty member, but we noticed that the faculty member is scheduled to be teaching a class at the time of the appointment—I wonder what is going to happen with that. I’ll report on the visit later this week.


Filed under: Data acquisition Tagged: Advanced Placement exams, Arduino, data logger, Global Physics Department, physics

Nerf gun prototype 1

The Santa Cruz Robotics Club met again today, for the first time in over a month.  The current project is not the underwater ROV (we’re all getting very tired of waterproofing problems), but an automated Nerf gun.

The club members came up with some very ambitious plans for the Nerf gun (which included getting a Raspberry Pi and doing image processing to have a self-aiming gun), but I’m making them build quick-and-easy prototypes to try out their ideas one step at a time.  I don’t think I can get an Raspberry Pi this summer—the companies doing the distribution aren’t taking more orders (just expressions of interest) and they don’t expect to clear the current backlog until September at the soonest.  They are doing batches of 100,000 units, and that doesn’t seem to be enough to shrink the lead time—if anything, the lead time is growing.

So, giving up on image processing for this summer, there are still a lot of things to build.  For today’s four-hour meeting (which included a 1-hour trip to the hardware store and a fifteen-minute snack break), the goal was simply to test out the basic launcher concept: an air reservoir pressurized by a bike pump, a solenoid valve, and a barrel.

The first prototype. The air reservoir is about 18″ of 1-½” PVC pipe on the left, and the barrel is about 24″ of ½” PVC pipe on the right.

The biggest problem was that the valve has ¾” male pipe threads, but we wanted 1-½” PVC pipe for the reservoir (because we had a piece handy—we may build a bigger reservoir later) and ½” PVC pipe for the barrel (because Nerf darts just fit inside—probably Nerf guns were prototyped with PVC barrels).  Our hardware store run was to get threaded adapters to make things fit.We wanted everything to be joined with screw threads, so that we could disassemble the components and replace them or add elbows as needed.

Note that the ½” PVC pipe is also a good size for compressed-air paper “rockets”.  The term “rocket” is a misnomer here, as all the acceleration occurs while the rocket is on the launcher—it is modeled more like a gun than like a rocket. (But my soda-bottle rocket simulator can model these paper bullets also.)  It would probably best to have a shorter barrel for doing rocket launching—just the length of the rocket and no more, since the longer barrel results in more pressure loss with no gain in launch speed.

The bicycle valve glued into a ½” female-threaded end cap was one I’ve had for a long time, as part of a soda-bottle rocket launcher. I had two of them, and both failed in testing today (the Barge cement holding the valve stem in failed—we’ve now reglued them with a different cement), though we managed some testing before the failure.

The solenoid valve we used was the same model (sold by Sparkfun) as the one used for the vacuum bottle on the ROV.  It has ¾” male pipe threads on each side.  To make it air-tight we had to disassemble it and grease the rubber membrane thoroughly with vaseline or faucet grease, but we had done that months ago, so it did not need to be done today.  The valve only works in one direction, but the high-pressure side is clearly marked by a metal intake screen, so assembling it the right way around is easy.

I was not sure that the solenoid valve would work in this application. It is not the model of valve that the compressed-air “rocket” people have used—those valves cost about twice as much and have female threaded ends rather than male threaded ends. I think that the mechanism they use may open up a bigger channel for air or water than the cheap solenoid valve sold by Sparkfun.

My first concern was that I did not know whether the valve would open up wide enough and fast enough to let a blast of air through to get a clean launch.  Second, I did not know whether we could open and close the valve fast enough to retain pressure in the reservoir for doing multiple shots.

We controlled the solenoid valve with an Arduino and the Hexmotor motor-control board (which is really overkill for one solenoid—a single power transistor would be enough to interface the Arduino to a solenoid, but I did not have one handy).  My son wrote an Arduino program to allow us to experiment with the duration of the solenoid pulse.  If it were too short, the Nerf dart would not leave the barrel.  If it were too long, air pressure would be wasted.  He allowed for 100 µsec increments in pulse duration, under control from commands on the USB serial line.

Because the glue they used takes 24 hours to set properly, we only tested at low pressure today (20–30 psi).  At those pressures, a 16 msec pulse was not long enough for the dart to clear the barrel, but a 19.2 msec pulse was easily long enough. We were also able to launch a 14g paper “rocket” left over from Maker Faire, though it did not go as high as the approximately 1.6g “Nerf” darts (I think several of the foam darts we have a different brand). We would not have expected it to go as high, since it was only accelerated for its 11″ length, not the 24″ length of the barrel for the darts, and it weighed a lot more.

One thing I thought about was monitoring the air pressure in the reservoir electronically. I doubt that we’ll put a pressure sensor in the reservoir, though, as the sensors I have only go up to 250 kPa absolute (about 21 psi above atmospheric pressure—about as low as we could fire with).  Freescale makes a 145psi (1000 kPa) sensor, the MPX5999D, but it is a differential sensor without port tubes (so would be difficult to mount) and it costs $13.

Perhaps the other thing worth doing today is to analyze how fast the Nerf dart should be going as it leaves the barrel, and how high it should fly if we shoot it straight up.  The physics here is fairly simple, if we assume that opening the solenoid valves connects us to a constant-pressure source. (In practice, we saw about a 10psi or 70kPa drop in pressure after one shot. If the pressure is P, then the force on the dart is P*area.  The cross-sectional area of the foam dart is a little hard to measure, because of the squishiness of the foam, but the inside diameter of the barrel is 1.45cm, for a cross-sectional area of 1.65 cm^2. At 140 kPa (about 20 psi), the force on the dart would be 23 Newtons.  That force is applied for about 60 cm (the length of the barrel), for a total energy of about 14 Joules.

We can use the kinetic energy of the dart to get its speed (E = ½ m v2), so for 140 kPa, the dart should leave the barrel at about 130 m/s or 290 mph. I suspect that we are not getting anywhere near that speed, for several reasons, including leakage of air around the dart, limited speed of air moving through the valve, and friction of the dart in the barrel (mainly from the pressure wave in front of it, but also from rubbing on the sides of the barrel).

We can also use the kinetic energy of the dart to estimate how high it would fly (ignoring air resistance, which is obviously hugely important for a low density object like a foam dart). The potential energy of a mass at height h is , so the height it would go without air resistance is . For 14 Joules and 1.6 grams, that would be almost 900m. I think that 20m is a more reasonable estimate for the height the dart went, though I never could see it near the top of its trajectory.

I tried adding the specs for the Nerf dart and a 60cm barrel to my rocket simulator (to get a crude estimate of the effect of air drag), and for 140 kPa I got an estimated max speed of 132m/s and an estimated max height of 52.6m. I don’t know if that height is reasonable—certainly it is better than the no-air-resistance estimate. The 6.78 second estimated time of flight seems to be fairly reasonable, though we never timed it.

Doubling the pressure increases the maximum velocity by a factor of 1.414, but only increases the maximum height to 60.8 m, a 16% increase. Doubling the barrel length has about the same effect. Air drag is what determines the speed of the dart, and that is the least well-modeled part of my simulation.

On Thursday, when they club meets again, they’ll try experimenting with higher pressures, and see whether 17 or 18 msec pulses are long enough—the shorter the pulse the less air will be wasted, and the more shots they can make from the reservoir.  It may be necessary to design a bigger reservoir or add a compressor to the design, since they eventually want a fully automatic Nerf gun, not the one-shot muzzle-loader that they made as the prototype today.  They’ll also start designing a pan-tilt mechanism for the Nerf gun, probably prototyping it out of Lego Technic components.


Filed under: Robotics Tagged: Arduino, Nerf gun, nerf guns, physics, rocket, simulation, SparkFun Electronics

Pendulum lab went well

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:

Length cm radius cm num orbits period sec g cm/sec^2
 212.4  48.6–46.6 10 2.90  970.8–972.6
 212.4  38–52.4 20 2.601  959.8–974.7
 161.5  58–60.5 20 2.501  938.7–984.2

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:

Length cm num ticks mean period sec standard deviation g cm/sec^2
207.2 47 2.8958 0.0050 975.4
171.3 74 2.6272 0.0065 979.8
95.5 89 1.9565 0.0025 984.9
54.7 58 1.4809 0.0042 984.7
28.7 44 1.0730 0.0019 984.0

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.


Tagged: AP physics, Arduino, circular pendulum, g, gravity, high school, Newton, pendulum, photogate, physics

More on pendulums

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


Tagged: AP physics, Arduino, circular pendulum, g, gravity, high school, Lego, Newton, pendulum, photogate, physics

Speed of sound lab writeup

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:

Material our speed
m/s
typical speed
m/s
steel rod 5292 6100
copper tube 3857 3901
aluminum bar 4412 6240
aluminum ladder 3995 6240
wood 6150 3300–3600

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

 


Tagged: AP physics, Arduino, comparator, high school, physics, speed of sound

More on the slinky and the speed of sound

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


Tagged: AP physics, Arduino, comparator, high school, physics, Slinky, speed of sound, VPython

Physics Lab 3

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/sec2 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.

Tagged: AP physics, Arduino, high school, physics, rangefinder, Tracker, ultrasonic sensor, VPython

Physics class progress

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);
     }

}


Tagged: AP physics, Arduino, high school, physics, rangefinder, Tracker, ultrasonic sensor