Another frequency question: Quad decode

Mickster

Maximum quadrature counts/sec =?

Based on running @ 180MHz

ManAtWork

I see no reason why it should be limited to less than 1 count per sysclock. So, it's 180 million counts/s, I guess.

Mickster

IIRC, we have filtering, right? So I guess that this will be a factor, depending on the level of filtering.

ManAtWork

What filtering? You mean the global digital filters for smart pins which are configured by the HUBSET instruction? I wouldn't use them. They have only up to 8 flipflops so if longer time constants (higher pre-dividers) are used they add jitter to the encoder signal making the velocity information jerky. They are really only good for very simple de-bouncing of mechanical switches.

Quadrature signals are not sensitive to bouncing. If multiple signal changes occur (due to wave reflection in the cable or noise at the optical sensor) where in theory only one edge should show up then the counter temporarily changes back and forth but no mis-count happens like with a single clock or step/dir signal pair.

If your signal is so noisy that a "phantom pulse" occurs in the middle of a quadrature state then you have a problem anyway and filtering (inside the P2) does not help. You have to get better shielding or use differential signals and twisted pair cable.

If you want to reduce aliasing effects or cogging by uneven distribution of quadrature states (not perfect 90° phase shift or not perfect 50% duty cycle) then use software low pass filtering after the counter.

Mickster

It's been a few years, now but I remember pointing-out something like this to Chip:

From the LS7366R datasheet:

A (Pin 12) B (Pin 11)
Inputs. A and B quadrature clock outputs from incremental
encoders are directly applied to the A and B inputs of the
LS7366R. These clocks are ideally 90 degrees out-of-phase
signals. A and B inputs are validated by on-chip digital filters
and then decoded for up/down direction and count clocks.
In non-quadrature mode, A serves as the count input and B
serves as the direction input (B = high enables up count,
B = low enables down count). In non-quadrature mode,
the A and B inputs are not filtered internally, and are instan-
taneous in nature.

And yeah...my thoughts exactly are that I'd prefer no noise rather than have to filter it. I always use the MC3486 differential line receiver.

evanh

Yep, max of one quadrant per sysclock, so 180 million counts per second in the above case.

There is an input deglitch circuit, normally off, that could be used. It's a unanimous voting circuit, like full scale hysteresis if you treated time as the level. Each A and B smartpin input has a deglitcher. Selectable using the %FFF pin config bits of WRPIN. 128 deglitchers in total.

The deglitchers select from four global timing taps, and therefore sample in sync with each other. The timing of the four taps, and also the number of deglitch votes, are a hub configuration with HUBSET %0100_xxxx_xxxx_xxxx_xxxx_xxxR_RLLT_TTTT
Having the hub manage both considerably reduces the number of config bits needed.

R = The tap number to config: One of four.
L = Votes to use with this tap: 2, 3, 5, or 8.
T = This tap's bit position, tapping, of the CT counter: bit 0, every sysclock, right up to bit 31, every 2^31 sysclocks.

evanh

Interestingly, T = 0 and L = 0 (Two votes) doesn't restrict max count rate while still providing a slight filter effect.

PS: Here's a guessed functional schematic I made of the deglitchers in front of each smartpin. What I've called the F-block:


The E inputs at the bottom left are from the four global taps. I labelled them E because they act as enables for the bit shifters.

And a link to the conversation - https://forums.parallax.com/discussion/comment/1495168/#Comment_1495168

Mickster

Many thanks....wow that's an awful lot of logic and no-wonder you dubbed it F-block because that was pretty much my reaction

evanh

Enjoy.

Funnily that block was the first I attempted because I thought it would be the easiest. As I fleshed it out and learnt the Logisim tool it did evolve a little but was still roughly what I was expecting even if it ended up bigger than expected.

Looking at it now I see I have an extraneous gate. The AND used for passing on the mux select when F = %0xx isn't achieving anything. The following mux deals with deselecting that path when F = %1xx. Not sure why I ever put that AND in there. This is simpler: