Jorijn worked out the technique and it changes what every number in this project
means: "press and LIFT (quick tap) is wrong, holding the sensor until it gives
the result is a 100% success rate."
The logs agree, on a properly controlled comparison. Same template, same
session, learning off for all four blocks, only the technique differing: tapped
4/15 and 3/15, held 15/15 and 15/15.
The frame data says why. Over every frame this project has a verdict for, split
at 2.5x the idle floor:
full contact, interrupt settled 78/175 = 45% match
full contact, interrupt asserted 28/142 = 20%
partial, interrupt settled 1/9 = 11%
partial, interrupt asserted 0/53 = 0%
A tap is caught while the finger is still arriving or already leaving. Such a
frame is not a hard verdict waiting to happen, it is a wasted one: with the
rescan budget at 0 every frame is terminal, so its rejection ends the press. 62
partial frames produced exactly one match between them.
So the tracker becomes a Schmitt trigger. A press now STARTS on settled contact
and ENDS on the finger leaving, which means a frame taken mid-landing produces
no event at all rather than a false rejection. A press that never settles simply
yields no verdict and the loop waits for the next one, which is an honest try
again. Enrolment is untouched: it passes one threshold for both and keeps its
own sample-quality gate inside the trustlet.
fptrial.sh now says hold, and defaults to fifteen presses. Instructing a tap for
its whole life is what quietly made every rate this project has quoted a worst
case, and a tap is not a case the product has -- nobody taps a phone sensor and
walks away, they rest a finger until it unlocks.
Jorijn van der Graaf
284282350b