Muons detected

Picking up where the last post left off; I got the two-tube coincidence detection working. After reworking the pulse stretcher timing and tuning the AND gate window, the coincidence output started firing at a rate that made sense for sea-level muons. Not zero, not 100/minute, but exactly what the documentation suggests, 3-5 for a vertical tube pair.

That was a good day,

Then I tore it all down

The original design called for two tubes, but I have decided to move to four tubes (six pairs) for a few reasons. First, the main oracle experience, of press a button and wait, is magical if it's 10 seconds. If it's 30 seconds it stops being fun and exciting. Doubling the amount of tubes (and tripling channels) will massively increase the detection rate. At two tubes, the 90% wait could be as long as a minute, but with four tubes and six channels 90% wait is under 30 seconds, and average wait is under ten, which is a much better user experience. 

One other advantage of four tubes, is the ability to have a unique angle for each pair, which turn into natural rarity tiers, because a vast majority of muons are traveling vertically, and the more extreme angle the more rare of an event it is. This combined with the pressure/temp/humidity readings gives a multi-dimensional space of event combinations that can be used to trigger experiences on the clock face. Think rare enemies in a tower defense game, or unique farm visitors.

I laser-cut an acrylic scaffold that holds all four tubes with each pair relationship fixed and repeatable. The soak test data from this rig will give me baseline coincidence rates for every angle, which feeds directly into how the rarity tiers get calibrated in firmware.

Going from two working tubes to four meant rebuilding the entire analog front end. Two more pulse conditioning channels, two more stretcher networks, and expanding from one coincidence gate to six — one for every tube pair. That took about a week and a half and it was the hardest stretch of the project so far.

Everything that went wrong

My spare HV boost modules got lost in the mail, so I'm sharing one booster per two tubes instead of one per tube. This works, but it means the tubes on a shared supply interact with each other. When one tube fires, the voltage sags briefly and the other tube sees it. With uncalibrated J305s that already have different individual characteristics, this made the count rates confusing to interpret. Is tube 3 reading 40% lower because the tube is weak, because the conditioning circuit is wrong, or because it's sharing a supply with a tube that's hogging current? Hard to tell when three variables are moving at once.

I lost a full day to my cheap USB logic analyzer. I was using it to monitor signals on the breadboard and was getting unexplainable voltage into the chip it was monitoring. Turns out it was backfeeding power through its input pins;  it wasn't just monitoring, it was supplying voltage to parts of the circuit that should have been off. Once I figured that out I had to go back and manually test every channel on both 74HC14s and the 74HC08 gates to make sure nothing had been damaged by the phantom power and that there was no signal leakage between channels.

Then tube 4's 74HC14 channel mysteriously died. Just stopped responding. Replaced the IC, verified the new one, moved on.

At this point tubes 1 and 2 were counting reliably and their coincidence channel looked clean. But tube 3 was still reading about 40% lower than the other three, and tube 4 would randomly get overwhelmed with noise bursts with counts shooting up to nonsense levels for a few seconds before settling back down.

I spent days checking and rechecking. Swapped components, reflowed solder joints, traced every wire. Eventually I documented the coordinates the full breadboard layout and asked Claude Opus 4.7 and GPT 5.5 to look at it. They both identified the same problem: tubes 2 and 3 were getting stuck in logic feedback loops because of a misplaced jumper that was creating a path between two channels that should have been isolated. I'll do a separate post on using AI for hardware debugging because it turned out to be genuinely useful in a way I didn't expect.

Soak test

After fixing the jumper issue, all four tubes came online and all six coincidence channels started producing data. I set up an overnight soak test to collect baseline rates for every tube pair at every angle. Seeing six channels and four tubes working smoothly was like a weight off my shoulders. I've been glowing since. This whole project had a question mark above it until that was solved. Everything else after this has error bars squarely in acceptable outcomes.

Results are mostly encouraging. Five of the six channels look stable. But tube 4 had a noise burst in the middle of the night;fd a spike in counts that doesn't correlate with any of the other tubes, so it's not a real radiation event. And tube 3 sagged back down to about 40% of the count rate of the other tubes over the course of the run. So I'm not done yet. Something is still not right with those two channels and I need to go back through the analog front end again.

This is the reality of working with four analog channels sharing two HV supplies on a breadboard. Every time you fix one thing, you find out something else was being masked by the first problem. I'm getting close but I'm not there yet.

(I'm a teacher building this in my school's maker space so students can see)

Other updates

The e-ink display is still in transit. Once it arrives I'll start building out some features I'm excited about, slow-burn games that live on the e-ink screen and use muon detections as event triggers. Think tower defense or a homestead sim where a couple of things happen each day, driven by cosmic rays. More on that when there's something to show.

I've also started working with a designer on the aluminum enclosure. We're currently evaluating folded sheet aluminum versus an extruded profile, both with different trade-offs in cost, finish quality, and internal layout flexibility. Not my area of expertise but it's moving forward. Updates on that as the design solidifies.