Not all projects are made equal. Some are designed to solve a problem while others are just for fun. Entering the ranks of the most useless machines is a project by [Vladimir Mariano] who created the 3D Printed Dancing Springs. It is a step up from 3D printing a custom slinky and will make a fine edition to any maker bench.

The project uses 3D printed coils made of transparent material that is mounted atop geared platforms and attached to a fixed frame. The gears are driven by a servo motor. The motor rotates the gears and the result is a distortion in the spring. This distortion is what the dancing is all about. To add to the effect, [Vladimir Mariano] uses RGB LEDs controlled by an ATmega32u4.

You can’t dance without music. So [Vladimir] added a MEMs microphone to pick up noise levels which are used to control the servo and lights. The code, STL files and build instructions are available on the website for you to follow along. If lights and sound are your things, you must check out the LED Illuminated Isomorphic Keyboard from the past.

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