View Single Post
  #6   Spotlight this post!  
Unread 06-09-2016, 09:32
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,620
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: How much PPR do you use on your encoders?

Quote:
Originally Posted by Ether View Post
I think you have that backwards.


How people define CPR can depend on whether the decoder can do 4x decoding. In short if a decoder can count on rising/falling edges. So it is possible CPR to be higher than PPR by as much as 4x. Still changing direction requires a quick transistion of phase which makes this less than 4x.

Link:
https://granitedevices.com/wiki/Quadrature

Picture the function of the 4x decoder design like this:

1. Build a high speed asynchronous binary up/down counter.
2. Determine the minimum reliable pulse length to move the counter reliably.
3. Create a circuit that makes pulses of that minimum length on the rising edge and falling edge of the channel A/B encoder inputs (R/C time delay or even better a good crystal based TTL oscillator).
4. Logical OR the Channel A pulses to the Channel B pulses.

The resulting count will be 2X for each pulse of the encoder and 2X higher than expected because of the logical OR.

5. Now build a circuit to detect the leading phase and toggle the up/down count.
Interface to that whole thing how you like (SPI, I2C, parallel bus, RS232...)

Mind you the duty cycle of what you are counting (pulses on channel A/B of the encoder) is not 50% if you change direction of rotation or speed of rotation; and the duty cycle of the pulses you are creating on rising and falling edge are either extreme of duty cycle (depends on perspective).

Note: if you gate a crystal based TTL oscillator with a one-shot circuit you can turn the steady free-run pulses into the pulse for your counter on the input edges. Using RC time constants has all the same issues as a simple 555 timer pulse generator.

Note: I had to do this years ago in CUPL for an Altera CPLD.

Last edited by techhelpbb : 06-09-2016 at 12:05.
Reply With Quote