# Ping Pong Ball Bounce Redux

Long ago (2007) Bryan Cooley and I wrote a set of physics labs; in one of them we had students bounce a ping-pong ball. You know the sound; it’s like this:

For the lab, we had students record the sound at 1000 points per second using a Vernier microphone. Using the resulting data, students could identify the times of the “pocks” and then see how the times between the pocks — the “interpock intervals” — decreased exponentially. This is a cool take on the old Algebra 2/Precalculus activity about bouncing balls where you measure drop heights; using sound and the technology, you can get more bounces and more accuracy.

A typical graph of the sound looks like this:

And a graph of the interpock intervals looks like this:

A couple years later, I realized that this activity is not just about exponential functions, but also about infinite series. For how much time does the ball bounce? Suppose (this is a model, wrong but useful, thanks, George Box!) the ball bounced perfectly mathematically. It would bounce an infinite number of times, each 0.9451 shorter than the last. But would it bounce for an infinite time? No. We can sum that infinite series; and we get

$\displaystyle \sum_{n=0}^\infty Ab^n = \frac{A}{1-b} \approx 3.4 \text{ seconds}$

Which matches the total duration of the actual sound remarkably well. Infinite bounces, finite time. How cool!

It seemed as if it was time to write a paper about this, but there was a problem: it would be great to let readers hear the sound, but the Vernier data, at 1000 points per second, is not an audio file, and to record an audio file at exactly the same time was a huge hassle.

The solution—for the paper, not the classroom—was to eliminate the Vernier sensors. I figured out how to record the bounces as an audio file and then extract the data and average it over one-millisecond intervals. That’s what you see here: the audio at the top of this post is a .wav file: CD-quality, 44100 16-bit samples per second. The data in the graphs are from means taken over every millisecond.

There is a great deal more to say, and a lot of that will go into the paper. But one thing to note here is yet another cool discovery:

We don’t use the original, CD-quality data because at 44,100 points per second, the 159,154 points in the data file are too much for CODAP or Desmos. But the audio program (I’m using Audition for this) of course had them all. So here is the first bounce in the CODAP (1 kHz) data:

And here it is in the raw, un-averaged data:

Besides having a cool color scheme, you can see that the raw data shows more noise. But it also shows a second peak, about 10 milliseconds after the first peak. This is not really visible in the CODAP data; there is no new peak there at about 140 ms. (The one at 170 ms is not present in the raw data; I bet if I averaged the absolute values, or used a mean square value as a measure of energy, it would go away.)

And that second peak appears after every bounce in the raw data. Hmmm. A hundredth of a second. Speed of sound is about 1100 feet per second. Eleven feet? That’s about the distance from my kitchen counter, to the ceiling, and back.

P.S. Anybody wanting to check out the data and the code can find them here: https://github.com/eepsmedia/ping-pong-bounce.

### Tim Erickson

Math-science ed freelancer and sometime math and science teacher. Currently working on various projects.

## 5 thoughts on “Ping Pong Ball Bounce Redux”

1. Cool, but you really need a log scale for the y-axis, to make the exponential into a straight line.

2. Of course transforming the interval to log(interval) is a possibility. I do it this way because I think [most high-school] students, on seeing the curved data and manipulating the curve directly, get a better gut understanding of what an exponential is like than if they see the curved data transformed into a straight line—and have to understand logs and how the transformation works.

By the way, anybody who wants to play with the sliders in Desmos to explore fitting that exponential is welcome to do so: https://www.desmos.com/calculator/jupr1sltrz

1. The problem is that people only understand straight lines visually—all curved plots get lumped together, and people don’t distinguish between a parabola and an exponential decay.

3. I agree when people are faced with data and have to choose. However, in this context, they have a reason to believe it’s exponential and are interested in the values of the parameters. By playing with the curve, they develop some (albeit imperfect as you point out) understanding about how the curve is shaped and, importantly, what effect the parameters have on it. If for some reason they are wrong about the form, they can find that out by trying: if you try to put some other decreasing, concave-up curve on these data, you can tell it doesn’t fit.

4. The fitting should properly be done by fitting the log of the model to the log of the data, at least if you want good estimates of the decay parameter. I don’t think that Desmos does that on a linear graph.

My comment was mainly about students never learning the point of logarithmic scales, because they only ever see linear scales in class, even when a logarithmic scale is a natural choice. I have a lot of college seniors in engineering majors who have never learned the point of log scales (along with so many other things that you would expect them to know by then: complex numbers, using derivatives for optimization, how to write, how to plot data, … ).