@Idocull, I would like to understand this further.
I have a hypothesis that there are positioning errors that come from missed encoder pulses, or falsely detected encoder pulses.
I understand that the speed and sensitivity of the Due highlighted this as an issue. However, I am wondering how likely this is as an issue with the stock Arduino. In your opinion, is it likely that the stock Arduino suffers from this issue? If so, to what extent?
Thanks. I appreciate your effort and expertise.
Absolutely. The Due just really makes the problem 80x bigger. : )
Adding 0.01uf caps from each encoder phase to ground reduces the noise ingress lowering the chances of a spurious count every now then (which adds up over time).
This confirms my suspicion. I want to notify @theHipNerd and @NewGuy, because they both had some kind of drift issue on the Z-axis of their machines. Has anyone else had an issue with drift that could be attributed to missed, or false-positive pulses?
My real question is: what is the permanent fix for this. Do we need to have a 0.01 uf capacitor on the pins where these signals connect? Do we need to specify shielded, twisted cables for these connections?
I would be surprised if this was the case, if you have a false pulse happen on a
wire, arduino will think that the encoder moved one step and then moved back.
the faster response of the due may make this happen a bit more frequently, but
that doesnāt hurt anything.
you would have to have a false pulse on one wire at the same time as a real
pulse on the other wire (or a second false pulse on the other wire) before your
count would be off.
Adding a cap to the wire will reduce false pulses but it will also slow down
real pulses, so Iām not sure how much it will help vs hurt. I would shield the
wires first.
David Lang
great idea. Is there a person or company that can make this happen? Iād like to offer it as an add on to the kits we will sell. Be willing to pay for the time. I know very little about electronics and something tells me desiging a board like this would take years of study.
That is not true.
I am not so sure that this is such an infrequent thing. The processor operates at a 16 megahertz rate. That means there is the potential for 16X10^6 false positives/negatives every second. The probabilities donāt have to be very high for this to happen on a regular basis. It is not a question of -if- it happens, but how frequently.
Further, the external circumstances that cause false-positives and false-negatives happen very similarly for both encoder lines. In other words, both encoder wires are subject to the same EMF noise that causes voltage deviations. If there is a positive voltage deviation on one line, the other line is subject to the same environment, and likely experiences the same positive voltage deviation. So, if one encoder line experiences a false-positive pulse, it is very likely the other encoder line will, too, because they are run in parallel and receive the same ambient noise.
I agree with as a potential issue. However, if we appropriately size the capacitors, this wonāt happen.
I like the idea of shielding the wires, and I think it is a very good step. However, capacitors cost something like $.01, which is a really cheap and easy modification. I would like to do both, because I see this as an unknown. I would really like to see some community members do some work to analyze this; both the effect of the capacitor and the shielded wire.
a faster CPU means the false pulses are less likely to be a problem. having
either line toggle up then down is a non-event, itās only if the other line
changes between the first line changing from the noise and it dropping back down
that there is a problem. A faster CPU means that it is more likely to detect the
end of the noise pulse before anything else happens.
The Z axis should be the biggest problem (longest wires, frequently grouped with
the power for the router). so letās get someone with a dial indicator to set it
up and do a bunch of moves back and forth with the router running to see how
much error accumulates.
I expect that if this was a big problem, it would have shown up by now, but it
could be that we are not just getting accurate enough to be able to notice it.
David Lang
Pretty sure this is incorrect. This problem was highlighted here partially because of the faster clock speed of the Due.
I suspect itās more a matter of the Due being 3.3v so the threshold for a pulse
is lower.
David Lang
Who here has hooked up a Due and tested what actually happens?
We (Harry and I) are currently testing this.
Thank you
Iāve got a due and the level shifters, waiting on delivery of the EEPROM
David Lang
I donāt have a due, but have been using a teensy 3.5 (3.3V but tolerant of 5V inputs) and connected my usb oscope to the encoder output (just opened box on it and havenāt used any oscope in years) but this is what my encoder waveform looked like. The ānoiseā you see is present without anything connected so I didnāt worry about itā¦ what should we be looking for?
sorryā¦ forgot the imageā¦ made another reply for those email-centric people that donāt see edits 
Was that taken while actually cutting?
No, sitting at my desk. Also, my motor cables are maybe 9-10 inches long. Might have an impact i guess.
itās a good baseline to see what happens with a long cable next to the noise router cord
is this with the resister/cap added or the original 5v signal?
try doing this on the Z axis with the router running (and run the router power
cable along with the Z axis cable for a worst-case example)
David Lang
I read via a text-only mail client, so I have to go to the link in any case 
David Lang
This is just a straight connection between motor controller and teensy
My Maslow is a bit torn apart at the momentā¦ but tomorrow I might be able to try something like you said.
Things donāt have to be mounted, just lay the parts out, a coiled cable will be
even more likely to pick up noise,so a better āworst caseā test.
David Lang
