By far the most challenging portion of my research centered on the troubleshooting of the straw tube tension test. Before delving into the difficulties in running this portion of the experiment, along with the techniques that I eventually used to overcome these hardships, it is best that I share some of the physics background regarding what exactly I was trying to accomplish.
Technical details aside, the primary purpose of this portion of my research was to design a non-contact setup that would register the tension in one of the straw tubes used in the muon g-2 drift chamber. Considering that the tension could not be measured by a simple force meter once the straws were glued into a place, a process was devised in which a straw was made to vibrate inside of a magnetic field with a loudspeaker and the resulting generated EMF signal digitized by an oscilloscope, thus providing the necessary information to measure the tension.
While the aforementioned process seemed pretty simple on paper, things began to break down during the phase of data collection (i.e. I wasn’t getting a noticeable signal). This issue was fairly serious considering that without any worthwhile data, I would effectively have nothing to show for my entire summer of research. Increasing the gravity of the issue, the lack of signal from my electrical circuit made diagnosing the problem even more troublesome (dead circuit aside, the possible causes for error were many). Finally, making the task seemingly impossible, the lack of a lab manual or previous research to cross-check my setup made things all the more difficult.
Now, considering that this is a blog entry and not a short novel on my many failed attempts to getting my experiment to work, I will skip over the trial and error portion of this story and state that I eventually got the signal and data that I was looking for. None of this, however, would have been possible without the trouble shooting lessons that I picked up along the way.
First, and foremost, speaking to my peers and seeking help from my adviser were instrumental in diagnosing the problem. Although I used to think that working alone was something to be lauded, I quickly learned that in the laboratory setting it is very ineffective. Receiving a different outlook on a problem can be very rewarding even if it doesn’t yield an answer right away as it helps to mitigate the tunnel vision effect that can occur when working alone.
The next troubleshooting practice was more of a lesson in hindsight, but nevertheless a good practice when performing an experiment. When going through the possible causes of your problem it is always helpful to have duplicate parts to check for component malfunctions. As it turned out, the one part of my setup that I did not have a duplicate of (a signal amplifier) had burned an internal battery and was not working properly. Had I acted with a bit more diligence and built my own amplifier (I had the spare parts to do so), as opposed to relying on the fact that the amplifier was working before, the defect in my setup would have been diagnosed much quicker.
Finally, this ordeal further convinced me to the importance of taking proper lab notes. Maintaining a good record of one’s procedure is not only a good organizational tool to conducting an experiment, but also an excellent method of giving insight to other contributing members of the project.