Ethan C

Journal entries imported from the previous iteration of wisrd.org

ETHANC

Manuals for cosmic ray detection, a flowchart for plateauing the counters, and other resources can be found in: \192.168.168.40\assets\Cosmic_Ray

10/2/19

Muons are extremely small particles moving at extreme speeds that are coming from outer space. Using a cosmic ray detector, muons can actually be detected despite their speed and size. EQUIP is a program that can help us to document the data

To find the speed of a muon, the the formula for speed, which is Speed = Distance/Time, would need to be used. Distance does not need to be found since this is something set up in advance. By setting the detectors up at a fixed distance, that fixed distance can be used in the formula. This means that when the experiment is set up, the detectors would need to be set up accordingly.

Time is more difficult to get. If the point in time when muon hit one detector can be measured, then the time difference between when a muon hits one detector and when it hits the other to find the time it takes for a muon to travel a set distance can be measured.

For my experiment, 2 detectors were set up vertically so that they were 1 meter apart. EQUIP was set up so that it only documented an event (data entry) every time both detectors recieved a signal. This was done by checking the boxes corresponding to the detectors used and setting the coincidence level to 2. A txt file was created to store this data. All other EQUIP settings can be left at their default state.

EQUIP collected data for 30 minutes (this can be any amount of time, but a greater amount will always be better). This data was then uploaded to quarknet under the cosmic ray E-lab section. Quarknet has a tool that interprets the data and converts it into a graph. This tool can be found in the ToF study under the Data section. To use this tool, the uploaded data must be found using specifications such as location. The

10/7/19

I set up the horizontal paddles for the direction test for the cosmic ray detector. To do this, I had to saw a piece of wood that fit in between the two paddles used. In doing this, I learned how to use a circular saw.

10/15/19

Direction test for paddles 0 and 1 started at 2:24:10 PM. This test will measure how many events were recorded when there was a coincidence between paddles 0 and 1. This test ran for 10 minutes. A similar test for paddles 2 and 3 will be conducted in the future.

10/17/19

Direction test for paddles 2 and 3 started at 11:25:00 AM. This test was identical to the previous test. This test ran for 10 minutes.

10/21/19

The data for the direction test was collected. However, there was an irregularity in the data. The paddles received a wildly different number of events. This means that there was an error in the data collection process.

10/22/19

The paddles on the alternate Cosmic ray Detector are 11×15 centimeters. This means that the paddles are 165 square centimeters.

After running a test run with horizontal paddles, the top paddle returned roughly 41.5 counts per second. Another similar test run showed that the bottom paddle returned roughly 34 counts per second. Both tests ran for one minute. Another top test gave a result of 47.4 counts per second.

10/23/19

A spreadsheet was setup for the data in the direction test. It can be found here. Date was included because certain factors that effect the readings change over time such as solar activity. I tested the effect of a 45 degree angle, a 60 degree angle, and a 30 degree angle. Each test ran for exactly 5 minutes.

11/5/19

Work on plateauing the cosmic ray detector has started.

11/6/19

Data collection for plateauing paddle 0 was completed.

11/8/19

Data collection for plateauing paddle 1 was completed. Work on changing the orientation of paddles 3 and 4 started. This will be done due to it making plateauing counters 3 and 4 easier. This is because direction would skew the results as seen in previous experiment.

11/12/19

Reorientation of paddles 3 and 4 was completed.

Data collection for paddle 3 was completed as well.

11/13/19

Data collection for paddle 4 was completed.

The data collected for plateauing was supposed to be uploaded to Quarknet, but Quarknet returned an error when the data was being uploaded.

11/15/19

Work on recollecting the data for plateauing the counters started. Simultaneously, research on how to distinguish different types of particles in data started. This will be useful when data is looked at.

11/18/19

Despite efforts to fix the issue on 11/13/19, the same error occurred. Despite troubleshooting attempts, no solution was found. A Quarknet HelpDesk ticked was sent for this reason.

The flowchart for plateauing the counters was started. This will be useful for future plateauing.

11/22/19

Response from Quarknet received. The reason why the upload failed was that EQUIP was set to reset the scalars every 5 minutes. The issue is that the plateau runs lasted 3 minutes each. To remedy this, EQUIP was set to reset the scalars every 3 minutes instead.

Quarknet Response:

Hi Ethan,
If you have a short file, you could send me a section and I can look at the output to see if we can find the problem.
The upload error message states that  ST/DS output lines are not found for each day defined by universal time (UT).  Most of the time that is actually the cause of the upload failure.  
The first thing to check is that you issued the ST 3 5 command (Status line output 3 – with scaler rests – every 5 minutes) at the beginning of your run and that the run lasted more than 10 minutes, to guarantee that you got 2 ST output lines.Often if you are doing plateau runs the runs are short and you may not have gotten an ST output line at all.
A second issue might arise if some of the raw data has a bad date (perhaps the first raw data lines).  If that happens, the software looks for an ST line with that date and can’t find it.
Let me know what you find.”
Regards,Mark

New data collection for counter 0 was completed. Instead of creating a test file for for each voltage, a file for each counter was created. To differentiate between the different voltages, the reset board command was used. Also, instead of uploading the data to Quarknet, the data files will be interpreted manually.

The whole purpose of plateauing is to find the voltage that will maximize cosmic ray readings while also minimizing background noise. This produces the most accurate results in experiments.

Response from the Quarknet HelpDesk ticket asked for the data that failed the upload, so said data was sent to Quarknet via email.

Work on the plateau flowchart was done. The flowchart can be found here.

12/2/19

Flowchart for plateauing the counters was completed. It can be found in the server. This flowchart will be helpful to people plateauing the counters in the future.

12/4/19

Since the method for interpreting the plateau data does not look at coincidence of counts, but instead looks at individual counts, there is potential to collect data for multiple counters at once. This would speed up the plateauing process greatly. Changes to the flowchart would be made accordingly.

A first test of simultaneous plateau data collection was done. It was done between counters 2 and 3. For an unknown reason, no data was collected even though the DAQ board noted events from counters 2 and 3. This does not mean that simultaneous plateauing is not possible.

Changes to the flowchart were made to properly reflect the plateau process.

12/6/19

An attempt at plateauing counters 1, 2, and 3 simultaneously was made.

12/10/19

It was discovered that the wire connecting the DAQ board to the power distribution box had broken. It was then fixed.

After sending data collected when the counters were set to a common voltage, an error message popped up. This is the error message:

This error message indicates that there was an issue with the hardware. It is likely that the error was due to the wire connecting the DAQ board to the computer because the DAQ board was recieving events but the computer was not.

1/7/20

There was an issue with data interpretation. It is much more effective to get the coincidence of multiple counters when plateauing or doing any data collection. Unfortunately, the location of the coincidence count could not be found in EQUIP or the manuals. A QuarkNet HelpDesk ticket was sent for this reason.

Response from QuarkNet:

Hi Ethan,
I’ll try to answer your question below.  Give me more details if my explanation is not what you are looking for.
EQUIP lists counts in one line for 5 scalers when a DS command is issued. Those represent the singles rates of channel 1, 2, 3, 4, and the number of triggers.  You can reset the scalers with a control button (RB command).
The definition of the coincidence count is how many channels are required to fire at the same time within a time window defined by the trigger gate to satisfy the processor’s requirement to save the data (TRIGGER).  For example, if you require 2 counters – hits occurring in only 1 counter do not fire the trigger.  Counts in any combination of 2 or more counters will fire the trigger and save the data.
I’ve attached a draft of the EQUIP instructions that might be useful to you.
Regards, Mark

1/8/20

The location of the coincidence count was found. Because of this, proper plateauing is possible.

Counter 0 plateauing began.

1/10/20

Counter 1 plateauing began. The plateauing process has gone much more smoothly due to the information provided by Quarknet.

Some work on revising the flowchart to more accurately reflect the plateau process was started as well.

3/10/20

Tests on the effects of lead on cosmic ray readings began. The plan is to put 3 lead bricks on the detector and compare data values. The tests will run for 10 minutes each, and 5 tests will be taken. There will also be 5 control runs.

Unfortunately, no data was able to be collected. The first run failed due to the 2nd counter not being fully plugged into the power box. At that point, it was too late to start a new run.

3/11/20

It has been decided that the length of the lead test runs should be 5 minutes instead of 10. This would make entire experiment take half as long to complete. It would also make it so that there is less time when a run could not be completed before the WISRD period ends.

3/17/20

Using TeamViewer, the cosmic ray detector is running even though there is nobody at the WISRD space. There are limitations such as not being able to modify the detector setup for tests such as the one with lead.