??? 03/01/05 16:17 Read: times Msg Score: +1 +1 Good Answer/Helpful |
#88787 - Peter is right! Responding to: ???'s previous message |
His solution is bullet-proof (no accumulating error), as long as one condition is met: there must be always be at least one sample between the edges. This condition is met, if the "plateau" (clear of any transition) between the edges is long enough (> period of sampling) - this is given by the encoder rotation speed and its construction.
This has nothing to do with the frequency of eventual oscillation when the encoder stops at an edge; this can be arbitrarily high or low. The fact of periodical sampling together with the existence of the "clean areas" is the filtering itself. Note, that it is sampled by a periodical clock, not the inputs' edges - Peter stressed this. ![]() For example, let the encoder stay between state 1 and 2. It has seen state 1 at the last moment of sampling. It the next sampling sees state 2, OK, let it be 2. If the next is 1 again, OK, let it be 1. And so forth, until the encoder starts moving. The design ensures, there is at least one sample in the "clear" area, either 1 or 2, depending on the direction of the movement. And so it does not lose a single step. The only uncertainty is the +- 1 step while it is sitting at the edge wiggling, this error is not accumulating. Of course, anything similar in CPLD/FPGA/DSP/silicon will work, too. Jan Waclawek PS. Sorry, I am not able to read vhdl so I don't understand, how Jez's solution works - is it similar or not. |
Topic | Author | Date |
Digital position encoder | 01/01/70 00:00 | |
Dont do this. | 01/01/70 00:00 | |
Signals are not connected directly | 01/01/70 00:00 | |
Is assembly ok? | 01/01/70 00:00 | |
For Mehdi | 01/01/70 00:00 | |
its easy in software | 01/01/70 00:00 | |
but | 01/01/70 00:00 | |
same resolution | 01/01/70 00:00 | |
But...what if ? | 01/01/70 00:00 | |
So what is the solution? | 01/01/70 00:00 | |
absolutely no problem | 01/01/70 00:00 | |
Thank you | 01/01/70 00:00 | |
PLEASE not again | 01/01/70 00:00 | |
Sorry | 01/01/70 00:00 | |
list.hw.cz | 01/01/70 00:00 | |
thank you | 01/01/70 00:00 | |
Re: PLEASE not again | 01/01/70 00:00 | |
Re frequency | 01/01/70 00:00 | |
So what frequency do we sample at? | 01/01/70 00:00 | |
I try to explain Peter's idea again | 01/01/70 00:00 | |
We know it ! | 01/01/70 00:00 | |
Nothing ??? | 01/01/70 00:00 | |
it takes time | 01/01/70 00:00 | |
Code doesn't function | 01/01/70 00:00 | |
reverse direction ! | 01/01/70 00:00 | |
This is not a problem | 01/01/70 00:00 | |
incorrect operation? | 01/01/70 00:00 | |
right connection ? | 01/01/70 00:00 | |
I dunno | 01/01/70 00:00 | |
Now... | 01/01/70 00:00 | |
check the sample condition ! | 01/01/70 00:00 | |
clarify | 01/01/70 00:00 | |
@Erik | 01/01/70 00:00 | |
@Peter | 01/01/70 00:00 | |
Grey code | 01/01/70 00:00 | |
Grey code more | 01/01/70 00:00 | |
Grey INCREMENTAL ? | 01/01/70 00:00 | |
I guess 98 | 01/01/70 00:00 | |
Gray code | 01/01/70 00:00 | |
Not a gray code | 01/01/70 00:00 | |
Grey | 01/01/70 00:00 | |
Yes of course its Grey code | 01/01/70 00:00 | |
Absolute Vs Incremental | 01/01/70 00:00 | |
So now... | 01/01/70 00:00 | |
Yes it can but only... | 01/01/70 00:00 | |
Peter is right! | 01/01/70 00:00 | |
Lover not a fighter :-) | 01/01/70 00:00 | |
Lover of software | 01/01/70 00:00 | |
steps lost or not | 01/01/70 00:00 | |
Determining direction | 01/01/70 00:00 | |
Its not Grey, its Gray !![]() | 01/01/70 00:00 |