AndyMark SuperShifter Encoders
 

Has anyone actually tested the encoders that come shipped on the AndyMark SuperShifters? They're made by US Digital (US Digital E4P-250-250 ). They have a rate of 250 cycles per revolution, or because they're quad encoders, 1000 pulses (interrupts?) per revolution.

Everything I've read says that this interrupt rate is pushing the upper limits of the RC, especially if you are using multiple encoders (we're planning to use two). The trick is that since they are mounted to the final output drive shaft, there is no opportunity to reduce this rate. On the other hand, knowing that AndyMark always optimally engineers their products for use in FIRST competitions, I would think that they picked this particular encoder for a reason.

Should I be concerned? Do I need to look into some kind of divider card as well?

Thanks for any info.

Re: AndyMark SuperShifter Encoders
 

Only one phase of the encoder output causes an interrupt, so you're off by a factor of two at the start. Digital inputs 1 and 2 trigger on only one edge of the signal, so there's another factor of two.

We used those encoders on our 2007 drivetrain. Even at top speed, interrupts were not an issue.

Re: AndyMark SuperShifter Encoders
 

The answer is it depends on which implementation for counting and for interrupt handling you plan to use.

If you use and follow the methods by this white paper:
http://www.chiefdelphi.com/media/papers/1490
(we've done this in the past for lower count encoders ex.. H1-50 from USDigital)

Then yes your are going to be "pushing" the limits" and a line/signal divider might be wise. That is because your code will be interrupting on both the rising and falling edges of both the "A" and "B" phase, so you will get 1024 interrupts per revolution per encoder, yielding 2048 interrupts for two encoders per a single revolution.

If you use "Kevin Watson's" encoder code, the caveat is (as I understand it) that if the encoder is spinning at a high enough rate of speed it is possible for his routines to incorrectly interpret the direction and thereby mis count. (See his FAQ). Which is why we don't use it. But this method will give you only 256 interrupts per revolution and under those conditions there shouldn't be any issue. 512 is significantly lower than 2048.


I do hope this helps.

Re: AndyMark SuperShifter Encoders
 

Actually, this has little to do with my code. The problems really are interrupt latency and line capacitance. The latency is due to having to manually save a lot of contextual informaton before the actual ISR gets to execute (this much less of a problem with the 3.1 compiler). Capacitance is a problem because encoders generally have fairly weak drive capabilities, which makes it hard for them to drive the capacitance of the cabling and that 0.01uF capacitor IFI hangs off of the upper twelve digital inputs. This has the effect delaying the arrival of the phase b logic state to the PIC. I haven't done the calculation, but I imagine if you spin an encoder fast enough, the phase b signal will never settle to a valid logic voltage level because it spends all of its time transitioning between the two! I'm not sure which is the dominant effect, but I do know that the flip-flop solution mentioned in the FAQ goes a long way to negating these effects because it captures the state of phase b before it can transition to the other state and it provides much more drive current to drive the line capacitance. I should point out that the flip-flop should only be used with interrupts 1 and 2 of my code as it will cause ploblems with ISRs that use a state machine to track the encoder state, like the upper four inputs of my code or Dan's code that you mentioned. In these cases, a good alternative to the flip-flop is a 74xxx244 line driver, where xxx can be ACT, LS, etc.

-"Kevin"