Gas station without pumps

2012 January 3

Speed of sound lab writeup

Filed under: Data acquisition,home school — gasstationwithoutpumps @ 00:38
Tags: , , , , , ,

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

 

2011 December 28

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

2011 December 4

Slinky lab

Filed under: home school — gasstationwithoutpumps @ 20:54
Tags: , , , , , ,

In the Physics homework (Chapter 4) post, I mentioned one lab I wanted to do:

Compression waves in a Slinky.  We want to measure stiffness and mass as well as the speed of compression waves.  That way we can compare our simulation to real measurements.

Well, my wife was downtown today and bought us a Slinky in the toy store, so the lab is on for this Friday.  Here are some things we should do:

  • Determine the mass of the Slinky.
  • Determine the number of turns of the helical coil (and hence get mass per turn).
  • Determine the stiffness of the spring.  Since the Slinky has a low stiffness and a fairly high mass, it might be good to do this by measuring the stretch of the slinky under its own weight.  Note that the top of the Slinky stretches much more than the bottom, so it is necessary to come up with the proper model for how a spring stretches under its own weight (a fairly simple thing, but a good test of understanding).
  • Come up with some other way of measuring the stiffness of the Slinky, and compare it with the self-weight estimate.
  • Estimate the stiffness for each turn of the Slinky, so that we can model it as a stack of many identical 1-turn springs.
  • Write a Vpython 1D simulation of the Slinky, using the mass and stiffness of each turn of the helix a separate object.  (This is essentially 4.P.90, but using measured mass and spring constants, rather than estimates of atomic masses and metal-lattice bond stiffness.)
  • Videotape compression waves in the spring, and estimate their speed (the “speed of sound” in the spring).
  • Compare the measured speed of sound with the Vpython computation.

If the 1D simulation does a good job, we can look into doing a full 3D simulation of a Slinky, and see if we can simulate it walking down stairs.

Unfortunately, I’m probably going to have to use the same household computer than my son uses for the Vpython programming.  I had to break Vpython on my  laptop, so that I could run a different Python package that I needed for work.  Unfortunately, Vpython only runs on the obsolete 32-bit Python, because it is tied to the obsolete Carbon framework on the Mac.  This means that Vpython will be dead within 5 years, unless the developers can figure out how to run it under Cocoa (they claim there is a thread priority problem in Cocoa that they don’t know how to work around), or go back to running under X Windows.  Actually, there is an X Windows version of Vpython that supposedly can be compiled for the Mac, but I read the installation instructions for it, and decided that Vpython was simply not worth that much hassle—if I wanted to spend all my time figuring out arcane installation techniques I would have bought a Linux box, not a Mac..  If they rewrote the Mac installer so that you had the choice of 32-bit Python and Aqua windows or 64-bit Python and X windows, I’d do it.

%d bloggers like this: