Why fast coins get missed

The boundary is silence

Nothing in the pulse train says "this coin is finished". The library infers it: once no pulse has arrived for 250 ms, the group is closed and its pulse count is handed to your loop.

That works because a coin's own pulses are much closer together than 250 ms — 50 ms apart at the Medium switch position. It stops working when the next coin starts before the silence has elapsed.

Drag the gap below 250 ms and the two bursts become one group whose count is the sum.

Two failures, and one of them is silent

With a 5c at one pulse and a 25c at three, a merged pair makes four pulses. Four is not a coin in that table, so hasError() goes true and you know something went wrong. You lose both coins, which is bad, but you find out.

Now suppose you had also mapped a coin at four pulses. The same merge is reported as that coin, with no error, and there is no test anywhere in your sketch that could tell the difference — because on a single wire carrying a pulse count, there genuinely is no difference. The wire said four pulses both times.

What actually helps

Lower the pulse values. This is the lever with the most travel in it. A dollar at 5 pulses takes about a quarter of a second at Medium; at 20 pulses it takes about a second. Shorter bursts mean the silence arrives sooner and the window in which a second coin can collide is smaller.

Use Fast if you have already done that. 20 ms a pulse instead of 50 shrinks every burst by more than half.

Renumber so no two coins sum to a third. If 1, 3 and 5 are your counts, 1 + 3 = 4 and 1 + 5 = 6 and 3 + 5 = 8 — none of which is a coin, so any pair that merges becomes a detectable error rather than a wrong answer. Three coins in a row can still land on a real count, but two is the case that actually happens, and it is worth laying the numbers out deliberately.

Or use value mode. This is the real escape. Value mode does not recognise coins; it multiplies pulses by a rate. Two coins merging into one group of the summed count still adds up to exactly the right amount of money, because the pulses are all still there. The event count is wrong and the money is right, and for most projects the money is what matters.

What does not help

A faster loop(). It is worth keeping fast for other reasons — in polling mode a slow loop loses pulses outright — but that is a different fault. Here every pulse was counted correctly. The question was only where one coin ended and the next began, and no amount of processor time answers it.

The library holds up to eight completed groups while your loop is busy, so a slow reaction does not lose coins that were properly separated. It just delays them.