Sometimes I do tests watching youtube or something. I use my peripheral vision to tell when to press/release and I miss the new max record.

update

I ran a bunch more exhaustive tests over night. No issue found. I believe my original test setup for observing the problem may have been flawed. Closing until we have a better test methodology.

TLDR

We may occasionally log an extra pulse. It seems rather rare at this point unless you connect a 200+ kHz self generated signal.

I'm not overly concerned about it. It would be nice to fully understand or have another person help test/validate.

More details

It's difficult to know exactly how the AVR architecture works regarding the edge counting peripheral and digital input synchronization/sampling. Some things in the datasheet seem to contradict others and also earlier tests.

This simulation is my current understanding.

The problem still doesn't quite make sense to me. If my simulation/model is accurate, then there should be certain times when we sample the pin as low and the next CPU instruction, we sample the rising edge count as increased. This does happen if I self test with a frequency between 210 kHz (gen a37) and 381 kHz (gen a20). How often we see it drops off as frequency decreases.

If it is a simple lining up issue, we should see it happen with a probability of roughly 1/40. However, when I test with frequencies slower than gen a37, it runs a lot without detecting any issue.

I'm also running a frequency sweep with my picoscope and an NPN (and external 1k pullup). It started at 100 kHz (the fastest it can) and has run for hours already. I modified code to not wait for stable or even detect initial change so it would go faster and hopefully remove any factors preventing reproducing the 1/40 issue. gen a30 does reproduce the issue right away even with the modifications.

More

Interesting that gen a38 gives a period of almost 2x constant logging speed of around 40 instruction cycles. Perhaps this issue is related to that.

Should try pattern generator that can vary spacing between pulses.

Could be useful to have timestamps. Initially, we should just ignore them in the browser if they are present.

21:42:02.547 -> #################### Test #1 ####################
21:42:02.547 -> Section count: 1, type: "Normal"
21:42:02.581 -> Waiting for stable input... good.
21:42:03.091 ->           _ 
21:42:03.091 ->          | | 
21:42:03.091 ->  _ __ ___| | ___  __ _ ___  ___ 
21:42:03.091 -> | '__/ _ \ |/ _ \/ _` / __|/ _ \
21:42:03.091 -> | | |  __/ |  __/ (_| \__ \  __/
21:42:03.091 -> |_|  \___|_|\___|\__,_|___/\___|
21:42:03.091 -> Release the button (it is currently pressed == logic low)
21:42:03.091 -> <test>

Test in chrome and firefox. Assume edge is same as chrome.

each chart/graph should be on its own page. table should start on its own page
https://developer.mozilla.org/en-US/docs/Web/CSS/break-after

gg - Glitch Guard. Useful with 'dtg'. Marks data to here as good.
dtg - Delete To last Glitch Guard 'gg'. Useful if wires glitch and a bunch of bogus data is recorded.