High-Altitude Muon Detector

The problem

Cosmic rays hitting the upper atmosphere produce showers of secondary particles, and muons make up most of what reaches the ground. A first-principles model predicts how the muon rate should change with altitude. It should rise as the detector climbs toward the region of peak shower development (the Pfotzer maximum) and then fall above it. Our team wanted to measure that profile directly by carrying a detector through the atmosphere on a high-altitude balloon.

Starting point: CosmicWatch, and what I changed

The detector is an adaptation of Dr. Spencer Axani’s (MIT) CosmicWatch desktop muon detector, an open-hardware design that pairs a plastic scintillator with a silicon photomultiplier (SiPM) and an Arduino. We worked with Dr. Axani to adapt his design to our mission. My contributions:

• PCB re-engineering. I made minor modifications to the board design for our application, then had the boards fabricated.
• SMD assembly. I hand-assembled the surface-mount electronics on the fabricated PCBs.
• Firmware. I adapted the CosmicWatch Arduino code to log the specific quantities our analysis needed.
• Analysis code. I wrote Python to parse the detector’s SD-card event logs (event number, timestamp, ADC value, SiPM pulse amplitude, dead time) and plot count rate over time.
• Flight packaging and testing. I packaged the detectors to survive a stratospheric flight and tested them before launch.

The biggest hardware fix: data logging. During testing, the detectors couldn’t reliably write data to the microSD interface on the original board. On a balloon flight, the on-board card is the primary record of the data, so this had to be fixed. We designed an additional SD-card board built around a different interface IC and wired it into the detector: the blue board in the photos. That gave us dependable logging for the flight.

System architecture

The reference CosmicWatch circuit (microSD version) by S. Axani, MIT, which our boards were adapted from. I no longer have the modified design files.

Each detector is a self-contained signal chain:

1. Scintillator + SiPM. A muon passing through the plastic scintillator produces a flash of light, which the silicon photomultiplier on its own small board turns into a current pulse.
2. SiPM bias. An LT3461 DC-DC boost converter generates the SiPM’s high bias voltage from the board supply, with RC filtering on the SiPM board to keep it quiet.
3. Amplifier. The first half of an LT1807 op-amp amplifies the fast, small SiPM pulse.
4. Peak detector. The second half of the LT1807, with a diode and hold capacitor, stretches the pulse’s peak long enough for the microcontroller to sample it.
5. Digitization and logic. An Arduino Nano reads the held peak on its ADC, timestamps the event, and applies the trigger threshold.
6. Logging and display. Events are written to a microSD card through a level-shifting buffer and 3.3 V regulator. A small OLED shows the live count, and a TMP36 sensor records board temperature.
7. Coincidence link. A 3.5 mm cable connects two detectors, so each can flag the events that fire both at once.

In flight, power was deliberately simple: the detectors ran directly from a USB battery pack.

Why coincidence? A single scintillator also triggers on radioactive background and SiPM noise. Requiring two stacked detectors to fire within a short time window selects particles that pass through both, which strongly favors penetrating muons over local background.

Flight packaging

The payload had to survive the cold, stay light, and protect the data even in a hard landing.

• Thermal. Both detectors rode inside a foam cooler, which was the simplest and lightest insulation we could use, with hand warmers placed around the inside. We predicted the interior would bottom out near 0 °C, even though the outside air in the stratosphere drops far lower. The battery pack had its own temperature management.
• Alignment. Foam spacers (the white pieces in the photos) hold the two scintillator plates in a fixed, aligned stack. Because the geometry is known, the coincidence rate can be converted into a flux per steradian.
• Mass. The detector payload had a 750 g budget. We brought it in at 642 g, not counting the battery.
• Impact and data safety. Instead of armoring the payload, we designed it to come apart on impact, and the firmware wrote data to the card every minute. A power loss or a hard landing would cost at most the last minute of data. Because of that design, we didn’t drop-test it.

Parameter	Value
Mass budget	750 g
Flight mass (without battery)	642 g
Predicted minimum internal temperature	≈0 °C
Cold testing	down to 0 °C
Data write interval	1 min

Testing and validation

Before flight we did extensive ground testing and calibration, including cold testing down to the predicted 0 °C. These runs confirmed that the detectors were recording the correct muon flux at ground level, which is the baseline the flight profile would be measured against.

The key validation used coincidence mode. When we rotated the detector stack away from vertical, the coincidence count rate dropped as expected: muons arriving at an angle travel through more atmosphere (a larger airmass) before reaching the detector, so fewer survive. The detector was responding to real cosmic-ray muons, not noise.

A sample coincidence-mode ground log from one flight unit (Detector 2) recorded 194 events in about 14 minutes (≈0.23 events/s), with SiPM pulse amplitudes of roughly 40–110 mV.

The flight, and what went wrong

The payload reached a peak altitude of 93,000 ft (~28 km), above the expected Pfotzer maximum. We never recovered it.

What happened. On launch day, the order of operations broke down. Someone cycled the GPS tracker’s power, switching it on and then back off, so the payload launched with no GPS tracking. Telemetry still came down for roughly the first two hours of the flight, until the link was lost. Without a position fix, there was no way to find the payload after landing.

What came back. For those two hours, telemetry reported altitude, temperature, and the power status of each detector, confirming the detectors stayed powered through the ascent. The muon data itself was logged to the on-board SD cards, which were lost with the payload.

Root cause. Nothing in the detectors failed. The failure was procedural: one uncoordinated action on the tracker, with no final check to catch it before release.

What I’d change.

• A written launch checklist with an independent “tracker is live” confirmation as the very last step before release.
• A second, independent tracker, so a single failure or mistake can’t cost the payload.
• Muon counts in the telemetry. Sending a running count down with the altitude and temperature data means the science survives even if the payload doesn’t.

What I learned

• Recovery is part of the instrument. The detectors did their job, and we still came home with no muon data, because the recovery chain failed. Getting the data back has to be designed and checked as carefully as the sensor that collects it.
• Build on proven designs and change only what you need. Starting from CosmicWatch meant our effort went into the problems specific to our mission, like the unreliable SD logging, instead of reinventing a working detector.
• Validate on the ground before you fly. The coincidence rotation test and calibration runs gave us confidence that the detector measured real muon flux before it ever left the ground.
• Operations matter as much as hardware. A single uncoordinated action on launch day cost us the payload. Clear roles, a written launch sequence, and a final verification step would have prevented it.