Effectively extracting “real” data from a noisy dataset
Judging from your description alone, I'd say an algorithm to find appropriate 3-clusters of timestamps would be something like:

compare the three first elements of your sorted lists. Pick the earliest of the three.
Remove the element from its list.
determine difference of that element to the other two first


If both difference are below a &quot;simultaneity&quot; threshold, register a new &quot;common event&quot;.


return to 1

Often, you'd also remove the two &quot;matches&quot; from the other two list in 3., but that reduces your ability to detect ongoing physical excitation of your sensor as one by post-processing your &quot;common events&quot; list.
Seeing you're only dealing with about a billion timestamps in total, this simplified variation of your distance-limited cluster detector should allow for quick experimentation¹.

But:
Reading through your question, it seems likely that one physical phenomenon can lead to multiple adjacent timestamps in a single list, so that would be another factor that might help to characterize real events vs false alarm. In that case, better modelling might be highly desirable, but as a rough idea:
Imagine your three lists as three parallel lines in three-dimensional space. They are arranged with equal distance to each other, i.e. there's a fourth parallel line in their &quot;middle&quot; that has the same distance to each one of them.
Now, imagine your timestamps are points on the respective lines.
For every point on your magical middle line, you draw a sphere around that point and count the time stamps in that sphere. Setting an appropriate sphere radius and threshold allows for good detection.
If you have a mathematical model for how observed timestamps relate to real phenomena, that can change the shape of your sphere, and make it &quot;fuzzy&quot;, i.e. weighing points further away less than nearby.
In the end, you'd have a function that says &quot;for each time on my middle line, this is the likelihood of a real event having happened&quot;; you can then build a maximum likelihood detector.

¹ hint: This might be a bad stereotype, but you sound like a matlab user. If there's one easy thing matlab is slow at, it's doing actual m-code loops and removing heads from lists; it's always preferable to just work at the end of a contiguous vector of data, since all you need to do to &quot;remove&quot; an element is change your own notion of length.