I wouldn’t reread that whole thread but rather try some detuning of the line. If that doesn’t work then reflections/termination isn’t the root cause.
Maybe take another 'duino or PIC or whatever (555???) and simulate those interrupt inputs with that rather than the IR sensor.
I would think that would surely rule in (or out) the circuitry itself and rule out (or in) the code itself.
Thinking along the lines of an interrupt flag not being reset within a certain required period and causing the extra counts…
So I already duplicated this problem with another Arduino (Uno) using a different variant of the Atmel chip. I could try to duplicate on something else (PIC, MSP, …) but I see little point.
What I do plan to do (after reading the BB gun thread) is remove the opto sensor and replace it with a 15 turn precision potentiometer. On the wiper I plan on adding capacitors in every decade from 100uF to 10pf. Now I will slowly ramp up the voltage and measure the voltage when the ISR triggers. Rinse and repeat to get the rising edge voltage. Next I plan to switch to a falling edge trigger and repeat but working downwards. This should give me an idea what the hysteresis is.
Next will be to look at pin cross coupling between the various ports. Does a pulse on port B only effect port B pins or does it affect fort C and D as well?
Then I will monitor the voltage rail at the chip power pin to see if that is affected. I see no glitches at the regulator, but close to the chip that might be a different issue.
I will then let this data decide what I want to do next.
Using a potentiometer I found that an input signal must first drop bellow 2.255 volts and then above 2.355 to cause a rising edge interrupt on an UNO. That is only 100mv of hysteresis. This was with no IO going except a serial transmission. Edge triggering was solid with no double interrupts.
Next I used digitalWrite to pulse pin 10 for as long as it takes to increment a long. When doing so, the voltage on the pin 2 interrupt pin has 40 mv of ringing for about 100ns. Now I adjusted the pot wiper looking for that sweet spot where I might get multiple interrupts. But i was not able to find that spot. Makes sense since the input has 100mv of hysteresis and i was only proving 40mv of jitter.
So next I went to look at the power rail. And that is when I discovered that even when the scope probe was connected to the same ground pin as its ground lead, I was getting 40mv of ring! What??? And then it dawned on me. I clipped the ground lug to the scope probe and now had a one turn loop antenna. Bring that close to the pulsing pin and you get the jitter. But only if another scope probe is connected to the pulsing pin.
One scope probe with its small capacitance was creating EMI that was picked up by the other scope probe. So I think the long leads on the photo sensor are acting like an antenna picking up the pulse i was generating in the ISR to feed on itself.
Time to clean up the wiring and see if that fixes the problem.
So next I went to look at the power rail. And that is when I discovered that even when the scope probe was connected to the same ground pin as its ground lead, I was getting 40mv of ring! What??? And then it dawned on me. I clipped the ground lug to the scope probe and now had a one turn loop antenna. Bring that close to the pulsing pin and you get the jitter. But only if another scope probe is connected to the pulsing pin.
Twisting the wires should be more than enough to fend off errant signals on your leads, assuming you are running both power and ground to your sensor.
Further experimentation shows that pin2 (IRQ0) on the UNO behaves the same if it is in digital input or rising edge trigger mode. In both cases the hysteresis on the Schmidt trigger shown in the datasheet is a near 60-80mV. Never heard of such a small dead band on an input. Working on a comparator circuit to fix this correctly. When I do, I will use twisted wires to minimize EMI.
I think I found the graph you were looking at. Kinda tough to see anything on it. About the only useful point I found to work with is along the 4.6v vertical line…and there’s the ~60mV you’re talking about.
Have you tried something even simpler, like putting a 7404 inverter, or better yet, a 7414 hex inverter with schmidt trigger inputs, or an other 7400 series logic gate with schmidt trigger inputs, in front of the pin?
I just looked at the datasheet for the National Semiconductor DM7414. Says it’s got a nominal .8v hysteresis (.4v minimum).
Just a thought…
Where did you find the graph? Was it in the 32U4 datasheet? And if so, on what page?
Still working on a comparator (only thing I could get on short notice) circuit with adjustable hysteresis. Seems to mostly work but has some strange behavior I am trying to sort out. Had to stop last night to join the family in social activities!
So I think I have a handle on this issue and we can close out this thread.
The Atmel 32U4 does indeed have a very small hysteresis on its digital input pins. Something around 60 to 100mv. The transition is around 2.3V. I am sure there is a part to part variation on these values, but the basics is a very small hysteresis centered about the mid point of Vcc.
What does this mean for the average Arduino user? Probably not much unless you are using interrupts and have a slow changing signal with more than 60mV of noise on it. In that case, you will not get one interrupt, but a whole slew of them as all the noise ripples get counted as individual interrupts.
What can be done? Well, you could de-glitch the interrupts in software. Using similar if not identical methods as switch debouncing, you could remove the extra interrupts. The other choice is to add a circuit before the interrupt pin to add significantly more hysteresis. In my case I used a comparator with a feedback resistor, but adding a Schmidt trigger buffer, or a low pass RC filter might be other possibilities.
Interestingly, I get get a reply back from Atmel on this issue but they completely missed the mark. The suggestion was that I probably had my scope probe set to 10X when I thought is was set to 1. I suspect we would have had another two rounds of emails before they came to the same conclusion I did from a weekend of testing.