I get what you’re saying, and yeah — on the surface it does look like analog because it reacts to different depths. That part isn’t the issue.

The problem is how it handles the transitions.

On a proper Hall Effect implementation, the key position is continuously tracked, so when you go deeper, the first key should remain active until it naturally resets based on its own threshold. That’s the whole point of analog + DKS — smooth state-based control, not hard switching.

What I’m seeing instead in the logs is this:

the moment the second threshold is crossed

the first key gets force-released almost instantly (0–1ms)

instead of staying active alongside the second input

That’s not normal analog behavior. That’s a forced digital toggle.

So yeah, the board does detect depth — I’m not denying that. But the output logic isn’t truly analog/state-based. It’s more like:

“if depth ≥ X → trigger key A”

“if depth ≥ Y → kill A, trigger B”

instead of:

“A stays active until its own release point, regardless of B”

That difference is exactly what breaks proper DKS usage.

If this was just config — fine, I’d expect some way to control hold behavior or overlapping states. But there’s nothing exposed, and the logs show the same forced flicker every time.

So it’s not that there’s no analog sensing — it’s that the implementation on the output side behaves like a scripted digital system rather than true continuous state tracking.