User:Paul V Klimov/Notebook/JuniorLab307L/2008/11/10

From OpenWetWare
Jump to: navigation, search
Owwnotebook icon.png Project name Report.pngMain project page
Resultset previous.pngPrevious entry      Next entryResultset next.png
SJK Incomplete Feedback Notice
Incomplete Feedback Notice
My feedback is incomplete on this page for two reasons. First, the value of the feedback to the students is low, given that the course is over. Second, I'm running out of time to finish grading!


SJK 16:58, 17 December 2008 (EST)
16:58, 17 December 2008 (EST)
Excellent data and analysis notebook.

Speed of Light

Data gathered by Paul Klimov and Garrett McMath

Lab Summary

Introduction

SJK 15:43, 17 December 2008 (EST)
15:43, 17 December 2008 (EST)
Excellent intro and procedure...although missing I think is a description of how you viewed the signals on the oscilloscope and produced numerical values from the waveforms.

The speed of light is an important fundamental constant in nature. The constant forms the framework of special relativity, and plays a huge role in electrodynamics, arising naturally from Maxwell's equations. Proper measurement of the constant is an important goal in physics.

In this lab, we will be sending light pulses from a light emitting diode (LED) towards a photomultiplier tube (PMT). Both components will be housed in a card-board tube in attempt to shield them from ambient light, which could give us bad data and even destroy the PMT. To measure the speed of light, we will be measuring the time of light emission by the LED and the subsequent absorption by the PMT. The time difference between these two events will be converted into a voltage signal, using a time-amplitude converter (TAC), which we will be able to interpret using an oscilloscope.

The LED will send out light pulses whose rate of emission will be determined by the voltage across the device. Although I am not certain of the mode of operation, I suspect that the pulses are generated by a charge-discharge mechanism, governed by capacitors embedded in the LED. Once the photon enters the PMT, it strikes a photocathode, emitting an electron by the photoelectric process. By virtue of an electric field, the emitted electron is accelerated towards a metal 'fin', called a dynode. The extra kinetic energy allows each colliding electron to dislodge several electrons. The chain reaction continues until the electrons reach the anode at the end of the tube, at which point the charge is converted into a voltage signal, and absorption is signaled.

Equipment

  • Tektronix TDS 1002 Digital Oscilloscope
  • Bertan Associates Inc. No.75 Model 315 DC Power Supply
  • Photo-multiplier tube
  • Light Emitting Diode
  • Canberra NSEC Delay
  • EG&G Ortec Model 567 Time Amplitude Converter
  • Harrison Labs Model 6207A DC PSU

Procedure Overview

First, the above components were all wired in a circuit. The PMT was connected to the oscilloscope in channel 1, so that we could monitor the incoming light pulses. As the PMT and LED move with respect to one another, the PMT signal will grow or shrink. Because the TAC likely triggers at a set voltage, changes in the size of the PMT signal will definitely give us bad data. Luckily, polarizers were attached to both the LED and the PMT, which will allow us to maintain the pulse at the same 'intensity' in order to avoid this source of systematic error. The PMT to a time delay box, which eventually led to the TAC. The time delay box will allow us to delay the PMT signal as we feel necessary. And finally, the PMT was connected to a PSU which generated an electric field within the tube. Next, the LED was connected to a PSU which was ramped to 180V. The rate of light emission will be determined by this voltage setting. The same PSU was then wired to the TAC to receive the emission signal. To monitor the time delay between the PMT and LED signals, we hooked up the TAC output to channel 2 of the oscilloscope. Channel 1 and channel 2 were monitored simultaneously on the oscilloscope at all times.

  • DC PSU set to 1800V, to power the electric field in the PMT.
  • We will start off by moving the LED a known distance from the PMT. Each successive measurement will be taken after moving the LED a fixed distance (10cm as we decided).
  • To avoid 'time walk', the polaroid on the PMT will be adjusted for each measurement. Because we cannot take the PMT out of the tube, we will just rotate it, thereby rotating the polarizer. For this to have any effect, of course, we will have a second polaroid in front of the LED. If we didn't do this, light intensity could not be controlled, as the PMT would receive half intensity no matter what rotation it has undergone.
  • The voltage amplitude will be measured on the oscilloscope, which will be receiving data simultaneously from the PMT and TAC in separate channels. We will have the oscilloscope average over time, so that we can get a steady readable signal.

Data

Trial 1 Day 1

Dx measured relative to the point where the diode and PMT are touching. Min on channel 1 to max on channel 2

Conversion factor for the TAC: V=GT, G=1/10 Volts per nanosecond

Channel 1: Min -618±8mV

Dx=60cm Max=1.64 Time=16.4ns

Dx=70cm Max=1.66 Time=16.6ns

Dx=90cm Max=1.72 Time=17.2ns

Dx=100cm Max=1.75 Time=17.5ns

Dx=110cm


Dx=120cm


Dx=130cm

Trial 1 Day 2

Procedure: The PMT was first brought to the end of the cardboard tube. It was then moved outwards through the tube, a distance of 60cm. From there, we took our first measurement. Each successive measurement was obtained after moving the PMT outwards an additional 10cm. The PMT pulse was adjusted for each measurement to avoid time walk by rotating it (and thus the polarizer).

Channel 1 Min (PMT): -488mV

Dx=.60m V=2.35V

Dx=.70m V=2.60

Dx=.80 V=2.68

Dx=.90 V=2.82

Dx=1.00 V=2.76

Dx=1.10 V=2.74

Dx=1.20 V=2.84

Dx=1.30 V=2.92

Dx=1.40 V=2.98

Dx=1.50 V=2.92

Dx=1.60 V=2.96

Dx=1.70 V=3.04

Dx=1.80 V=3.08

Dx=1.90 V=3.14

Dx=2.00 V=3.18

Dx=2.10 V=3.18

Dx=2.20 V=3.24

Dx=2.30 V=3.26

Dx=2.40 V=3.30

Trial 2 Day 2

Now, starting from the fully extended end, we started bringing the LED closer to the PMT. Once again, we moved in 10cm at a time, correcting for time walk. The same general procedure was carried out until we reached the start point of the first trial.

Channel 1 Min: -488mV Dx=2.40 V=3.30

Dx=2.30 V=3.26

Dx=2.20 V=3.22

Dx=2.10 V=3.16

Dx=2.00 V=3.06

Dx=1.90 V=3.12

Dx=1.80 V=3.06

Dx=1.70 V=2.94

Dx=1.60 V=3.00

Dx=1.50 V=2.94

Dx=1.40 V=2.84

Dx=1.30 V=2.80

Dx=1.20 V=2.72

Dx=1.10 V=2.80

Dx=1.00 V=2.78

Dx=.90 V=2.72

Dx=.80 V=2.72

Dx=.70 V=2.62

Dx=.60 V=2.64

Trial 3 Day 2

Here we repeated the exact same procedure as in trial 1 with one exception -- this time we added a 10ns time delay to the PMT signal.

Channel 1 Min: -488mV Points marked with asterisk were obtained without run-stop (first 3 points).

Dx=.60m V=3.80*

Dx=.70m V=3.90*

Dx=.80 V=3.85*

Dx=.90 V=3.90

Dx=1.00 V=3.92

Dx=1.10 V=3.96

Dx=1.20 V=3.98

Dx=1.30 V=4.06

Dx=1.40 V=4.06

Dx=1.50 V=4.14

Dx=1.60 V=4.10

Dx=1.70 V=4.12

Dx=1.80 V=4.18

Dx=1.90 V=4.22

Dx=2.00 V=4.32

Dx=2.10 V=4.28

Dx=2.20 V=4.32

Dx=2.30 V=4.36

Dx=2.40 V=4.42

Possible Sources of Error

  • Time Walk: As the distance between the LED and PMT is varied, the PMT signal changes in width and height (as seen on the oscilloscope) due to changes in light intensity. Because the TAC is likely set to trigger the signal at a fixed voltage, such a growth in the PMT signal would undoubtedly produce bad data. In attempt to avoid this error, we monitored the PMT input signal with an oscilloscope. As the PMT signal changed size, we rotated the PMT, effectively polarizing the incident light until the signal intensity returned to its initial state. This procedure was repeated with each measurement. Such a source of systematic error would likely cause a trend in our data, returning persistently more inaccurate voltage readings as each trial progressed. Fortunately such a trend was not seen in any of our data sets, suggesting that we sidestepped this source of error (within the resolution of the oscilloscope, of course).
  • Cable Length The PMT-TAC and LED-TAC cables used in this lab were of different lengths. While this would not be a huge problem if we were measuring something slow, where slight differences in travel times would be negligible, this was clearly not the case here. This could become an especially large problem if the PMT and LED were very close together, which could result in the TAC receiving the PMT signal too soon after, or even before, the LED signal. A possible way to counteract this effect would be to use the time-delay box to add an effective cord length to the shorter cable (the PMT-TAC cable in this case). To do this well one would have to measure the lengths of each individual cord; and unfortunately this was not possible in this lab given the setup. I believe that this could be the greatest source of error in this lab, and I will surely discuss it more later.
  • Bent Tube: One thing that Dr.Koch noticed was that the cardboard tube housing the LED and PMT was bent slightly in the middle. A bend could cause at least two problems, if the bend occurs between the PMT and LED. First and foremost, this could cause the intensity of light reaching the PMT to be lower. A perhaps less obvious source of error could involve the reflection of light on the cardboard, which could give us a brief time delay. Although it is not likely that this is a major error, it might be interesting to ponder the possibilities. Invoking Fermat's principle, we know that the path followed by a light ray will be a 'stationary' one. That is -- the path followed by light between two points will be either the longest or shortest. The shortest will be the straight line, and the longest will be the reflected ray (incidentally the law of reflection can be derived form Fermat's principle). If the shortest path was obstructed by the bend, the light hitting the PMT would have taken a longer path, thus taking a longer time to get there. It is unlikely that this could have occurred, given that the bend was fairly insignificant in magnitude. And in addition, air molecules would likely scatter the light into the PMT long before reflection could occur. Furthermore, this is an unlikely source of error, though an interesting possiblity.

Post Experimental Data Analysis

Data Selection

Although we have 4 sets of data in total, I have chosen to throw out the set taken on the first day. The reason is that we were still getting used to the device, and I believe our measuring techniques were not well established at that point. In addition, we were able to take only several measurements on the first day which would give us huge uncertainty, both statistically and by personal discretion.

My lab partner and I also chose to throw out the first two points in our first trial on the second day. The reason we chose to do so was because the voltage reading on the oscilloscope was fluctuating much more than it was for later measurements. This could have something to do with signal overlaps at the TAC, which could happen if the PMT and LED signals were received too soon after one another. This effect could happen if the PMT and LED were too close together, which could have been reasonable for these two data points. This is even more plausible given that these fluctuations were not evident in the third trial, where a 10ns time delay was given to the PMT signal. Such a time delay would likely spread the signals out enough to prevent overlaps.

Because each data set was obtained after some experimental modifications, I will not be combining the data points from the different trials. Instead I will try to reason later if there is a data set that best represents the physical system of interest. Data analysis will be performed using MATLAB and some excel. MATLAB will be responsible for producing all plots and finalized data. Excel will be used to compute the uncertainty in the slopes of the presented least squares lines.

Error Propagation

Figure 1: Distance traveled versus time. The speed of light, as calculated from the slope, is given in the title of each figure. The least squares line is not constrained to go through the origin because we are dealing with changes in distances.

We had uncertainty in our measurement of the voltage, due to reading fluctuations in the oscilloscope. Because we converted this voltage to a time reading, we must propagate this error. Conveniently, the conversion is linear, making the propagation straight-forward. The conversion ratio is given by 'eta', and it is the dimensionless number 10. This was chosen by us on the TAC during our experiment.

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle t=\eta V \Rightarrow \delta t = \eta \delta V }

We must now propagate this error to get our uncertainty in our measurement of the speed of light:

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle \delta c = | \frac{\partial}{\partial t}(\frac{d}{t})|= d \frac{\delta t}{t^{2}}=c_{meas}\frac{\delta t}{t}}

SJK 16:55, 17 December 2008 (EST)
16:55, 17 December 2008 (EST)
I'm pretty sure this method is not correct, as you are not actually calculating a velocity from an absolute distance and time. For example, your relative error according to the formula would decrease with increasing time (since your time error is fixed). The LINEST method below seems good. You could also use the delta t errors explicitly in the linear regression.

where I have denoted our measured speed of light as Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle c_{meas} } to make sure that this c is not mistaken for the actual value of the speed of light. Because c cannot be calculated from a single data point, it seems most reasonable for me to propagate the error on the value of c as calculated from the slope of the least squares line (as I discuss in the next section). The uncertainty obtained by using this method is most close to .006e8 m/s, which is surprisingly small.

Least Squares Line

The most convenient way to determine the speed of light from our data is to make a least squares line of the traveled distances versus the time elapsed. The speed of light will simply be the slope of the line, which can be easily obtained:

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle v(t)=c t \Rightarrow Slope = c }

While the above relationship suggests that the line must travel through the origin, this is in fact not the case since we will be dealing with changes in distances. Therefore, the data points will be plotted in arbitrary distance vs. time space where the origin is not the obvious physical analog (although it exists of course, and I'm quite sure that we could measure it if we were interested in doing so for whatever reason).

An uncertainty for each slope will be calculated using excels 'linest' function. Each point will be weighed equally, due to the fact that each point was prescribed the same uncertainty, given by the oscilloscopes voltage resolution. The result of this calculation will be reported as the final uncertainty because I believe that it best represents the actual SEM.

Results

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle c_{1}: 2.54(13) \cdot 10^{8} m/s}

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle c_{2}: 2.56(13) \cdot 10^{8} m/s}

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle c_{3}: 2.99(11) \cdot 10^{8} m/s}

Discussion

SJK 16:58, 17 December 2008 (EST)
16:58, 17 December 2008 (EST)
Very good discussion of the discrepancy & I agree that redoing the measurements would be very appropriate. Based on what I've seen from others, I think the delay is correct, and probably you're correct about there being some problem with some stop signals arriving at the TAC too soon.

Very clearly there is significant discrepancy between our first two and our last measurements of the speed of light. The reason is that for the last run, we delayed the PMT signal by 10ns using the delay box. However, without invoking the actual value of c, we must reason what effect such a delay would have on our final measurement, and whether such a delay should improve or worsen our results.

Adding a 10ns time delay adds an effective cord length of about 10 ft to the PMT (we cannot be too accurate here because we do not know the exact rate of signal transmission through the wires). Clearly such a difference would have an effect on our results because it would cause the TAC to register a different time difference between LED emission and PMT reception. Due to the fact that our LED cord was significantly longer than our PMT cord, it is reasonable to believe that such a time delay could improve our results. However, it is hard to reason just how much of an improvement this modification would offer -- and after all, too great of a time delay would start causing problems also.

Furthermore, I feel like our current results put us in a position where we need to go back to the lab and take more data. I believe that we need to figure out how we can compensate for the exact difference in cord lengths. This would require us to either measure each cord, or come up with something more clever. Without doing so, our results are simply an approximation of the speed of light. In the real world, we would not be in a position to submit any data because I believe our data here is still rather inconclusive.

If, however, I was in a position where I had to report some value I would take the mean of the three trials and stretch the 68% confidence interval. As was mentioned at the very end of lecture, this is a reasonable thing to do in a similar situation. If I were to do this, I would end up reporting the following value: Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle 2.7(4) 10^{8}m/s } . However, given that this is an informal setting, I will report all of my measurements.

Improvements for Future

  • Cord Length: As discussed extensively, differences in cord lengths could cause problems in this lab. If I were to redo this lab, I would focus my attention on figuring out a way to reduce this error as much as possible.

MATLAB Code

Speed of Light MATLAB Code