Jon Elson wrote: > OK, things look worse, and obvious noise is showing in the A and B > traces when you do this. > I think it shows that the sampling was being done at the faster rate > before. OOps, I misread what you had changed. Chris said it right. This is allowing you to see what is actually being seen by the base thread sampling, and why the velocity estimation is noisy. I think if you blow up the position trace with the AC coupled selection of the offset button, you will see incorrect counts due to the noise in the encoder signals. You may have electrical interference, these encoders may need a pull-up resistor to +5 V on the A and B lines. Or, the LED may be fading, throwing off the duty cycle of the A, especially. Something is dreadfully wrong. It is typical to see some dither right at the transition point of the signal, but you have pulses right in the middle of the high parts. MOST notably, they are ONLY present when the A or B are high, NEVER when they are low! This is a BIG hint that the drive strength of the encoder's output driver might be insufficient, and is barely pulling up above the threshold of the parallel port's input. I would think a 1 K Ohm resistor from +5 V to the A and B would make a big difference. You can get +5 V from the game port or a hard drive plug. Yup, also looking closer, I see COORDINATED spikes in both A and B on a number of cycles. That reinforces my suspicion of the above.
Jon ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
