For CosmicWatch in hardware coincidence mode, the criterion is actually very simple and quite tight:
Hardware coincidence (detector-to-detector cable)
- The firmware opens a coincidence gate of about 2.3 µs after a trigger.
- During that window, it repeatedly checks the coincidence input (~32 polls).
- If the second detector produces a logic HIGH at any point in that window, the event is flagged as coincident.
👉 So the effective “limit” is:
Two pulses must occur within ~2.3 microseconds of each other
What that means physically
- A relativistic muon crossing both detectors separated by, say, tens of cm arrives within nanoseconds, so it easily satisfies this.
- The 2.3 µs window is much wider than the physical time-of-flight, and is chosen to:
- tolerate electronic delays
- ensure you don’t miss true coincidences
Accidental coincidence rate (why that window matters)
Typical single-detector rates are ~1 Hz.
For CosmicWatch-like setups:
- Using a 30 µs window, you already get a few accidental coincidences per day
- With 2.3 µs, accidentals are proportionally lower (roughly an order of magnitude smaller)
So the firmware window is a compromise:
- Wide enough to catch real events robustly
- Narrow enough to suppress random coincidences
Software coincidence (for comparison)
If you’re correlating two independent units via timestamps:
- Typical recommendation: ~10 ms window (limited by clock precision and serial timing)
That’s vastly looser than hardware coincidence, and dominated by timing uncertainty rather than physics.
Bottom line
- Hardware coincidence threshold: ~2.3 µs window
- Condition: second detector pulse occurs within that window → coincidence flag = 1
- This is intentionally much larger than the true muon transit time, but small enough to keep accidental rates low.