User:Matthew Cordova/Notebook/Physics 307L/2010/09/29

From OpenWetWare
Jump to: navigation, search
Owwnotebook icon.png Speed of Light Lab Report.pngMain project page
Next entryResultset next.png


Safety

SJK 18:45, 28 October 2010 (EDT)
18:45, 28 October 2010 (EDT)
This is a very good primary lab notebook. Very easy to understand your analysis. Take a look at Sebastian's notebook: I really like his discussion of the difficulties you had with the triggering. That is really good information that is missing from your notebook. That could be due to the fact that you're duplicating entries, which isn't strictly necessary--I only require you to have a non-shared notebook once the analysis starts. Thanks for the hard work to get good data!
  • There will be a voltage source being used for this lab. Don't mishandle equipment/wires.
  • The PMT receiver is sensitive. Do not expose it to room light when it is operational or it will be damaged.

Equipment

  • PMT (photomultiplier tube)
  • LED
  • Oscilloscope TDS Tektronix 1002
  • Bertan Power Supply Model 313B
  • Canberra Delay Module NSEC 2058
  • Ortec TAC/SCA Model 567 (time-to-amplitude converter)
  • Harrison Laboratories Power Supply model 6207A
  • Multiple BNC Cables
  • Long Carboard Tube

Set Up

  • A detailed set up procedure can be found in Prof. Gold's lab manual(Ch 10). Basically, we connected the PMT to the TAC in order to read the time delay between when the LED sent out a pulse of light and when the PMT received this pulse as a voltage on the oscilloscope.

Procedure

SJK 18:22, 28 October 2010 (EDT)
18:22, 28 October 2010 (EDT)
This is a very good description. I like the photos in Sebstian's notebook, you could copy or link to those: here

After set up, Sebastian and I found our 'zero' point where our last measurement would be made. The closer the LED is to the PMT, the better (the reason will be mentioned momentarily). Our zero was 150 cm from the end of the push-stick, measured at the entrance of the cardboard tube. From this point, we measured 100 cm farther down the meter stick (i.e. our first measurement was at our 100 cm). We took our first measurement at the farthest distance due to the fact that we must achieve the same light intensity when taking measurements (the intensity is manipulated by polarizers), and the most accurate reading is obtained when the intensity the PMT receives is large. So why not use the highest intensity from the closest point? Because you can not achieve this value from farther distances. We achieved our max amplitude measured through channel 1 on the oscilloscope (directly related to the light intensity) and made note of the value. We also measured the peak to peak value on channel 2 (related to time of flight). We then decreased the distance between the PMT and the LED by 10 cm, returned to the same channel 1 amplitude, and made note of the peak to peak value on channel 2. This process was repeated until we returned to our zero. This concluded one trial of data. We completed three 'good' trials, two 'unsatisfactory' trials, and one trial which was not worth recording due to incoherent data. The first two trials of data were taken left to our own devices, and contained large amounts of systematic error. With some help from Prof. Koch, our last three trials contained some worthy data.

  • Note: The reason we must return to the same amplitude for the channel 1 amplitude is due to 'time walk', probably the greatest contributor to systematic error in this lab. The TAC triggers off of the same value for each pulse. If we have a different amplitude (different shape), the TAC would trigger either before or after we want it to.
  • Note: The reason that the first couple of trials were so bad were for a couple of reasons. One, the amplitude measured by channel 1 was low, and the oscilloscope triggered on a noisy part of the graph. The other was due to the fact that the time delay was set too low, making the amplitude measured by channel 2 very low and inconsistent.
Sebastian Oscilloscope Display.JPG
  • Note: To achieve the graph on the oscilloscope, do the following: Double check your connections and make sure they are secure and in the right location. With all devices on, push the 'auto set' button to obtain the general graph. You may have to 'zoom in' to get a good looking graph. Now set the oscilloscope to obtain an average. This should greatly reduce the noise visible. A picture is provided for our o-scope graph.

Calculations and Results

The measurements for our lab are enclosed in the following spreadsheet.

The value located in the top left cell of the LINEST function represents the slope of the adjacent set of data, and the top right cell represents the uncertainty.SJK 18:24, 28 October 2010 (EDT)
18:24, 28 October 2010 (EDT)
This is a typo, uncertainty is 2nd row, left--you used the correct uncertainty, just have typo here.

{{#widget:Google Spreadsheet

key=0AmM4ABQqnjT9dG43MWRXNkY4eDhQckJXbmpXSU1mTnc= width=950 height=600

}}


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_{calculated}=\frac{1}{slope}*\frac{1mV}{10^{-2}ns}}

  • We use 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 \frac{1}{slope}} because the slope of this data yields 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 \frac{mV}{cm}} , and we need 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 \frac{cm}{mV}} . We then convert 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 \frac{cm}{mV}} into 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 \frac{cm}{ns}} using the conversion listed below.

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 1V=10ns}

  • From this we can get

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 1mv=10*10^{-3}=10^{-2}ns}

Using these basic equations, I will provide 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_{best}} , 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_{low}} , and 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_{high}} , which correspond to 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 slope} , 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 slope+uncertainty} , and 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 slope-uncertainty} , respectively.

  • Note: The uncertainty I will be using is .03242, located in the LINEST function for the 'Average' plot (cell 2,1 of the function). I will be achieving my final results using the 'Average' plot as opposed to finding three different c values and the taking the average of those. I'm not entirely sure if the way I'm doing it is more accurate or not (shouldn't be too bad, since I can see no drift in our data), but this seems to be the standard way of doing it from what I have seen while looking at other notebooks.SJK 18:29, 28 October 2010 (EDT)
    18:29, 28 October 2010 (EDT)
    I don't know the answer for sure either. I'm leaning slightly towards computing the slope of each run independently and then computing the mean slope later. Just in case there is some kind of drift, it would have less effect in this manner.


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_{best}=\frac{1}{slope}\frac{1}{10^{-2}}=31.26\frac{cm}{ns}}

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_{low}=\frac{1}{slope+uncertainty}\frac{1}{10^{-2}}=30.95\frac{cm}{ns}}

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_{high}=\frac{1}{slope-uncertainty}\frac{1}{10^{-2}}=31.58\frac{cm}{ns}}

The accepted value of c, according to Wikipedia is 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=29.98\frac{cm}{ns}} , which is not within our range. We can say with a good amount of confidence that there was some systematic error. This could contribute to the fact that we were measuring the fastest quantity known in physics, which would require very accurate equipment. Also, although we accounted for time walk, it is still a possibility that this effected our results. All in all, however, we achieved a fairly accurate measurement of the speed of light, with a %error of less than 5%.
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 %error=\frac{calculated-actual}{actual}*100=4.27%}

References

SJK 18:31, 28 October 2010 (EDT)
18:31, 28 October 2010 (EDT)
Good acknowledgements. Sebastian also credited Alex Andrego, assuming you should also.

Wikipedia for values.
Thanks goes to David Weiss and Brian Josey for help with calculation results and general notebook formatting.