EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

Position Encoding.

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Electronics Design - Position Encoding.

Goto page 1, 2, 3 ... 36, 37, 38  Next

Tim Wescott
Guest

Thu Dec 22, 2011 12:13 am   



So, I'm working on an interesting problem. It's somewhat self-assigned,
but it'll make it's way into some customer equipment. It's not quite DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is. There are some tried-and-true methods, but I want to do better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel. Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that any
consecutive string of N positions is unique.

And I figured out one such scheme! Take the output of an N-bit LFSR, and
lay it down in order. If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.

Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction. Use the
looked-up bits to determine the position (which you can, because they're
unique), and voila! You have the absolute position and can now just use
the relative encoder.

So my question is: has anyone seen this done? Are there better
variations? Is there anyone who makes some sort of off-the-shelf
solution that does all that, but cheaper than I could ever roll my own
from individual components? My ideal would be a sensor that I could buy
off the shelf, and specify to my customer how their code disk would have
to be made, and have everything just work.

(Note that if you had the freedom to roll your own silicon you could make
a system that would register a code word, look it up for the absolute
position, then figure out its offset within the sensor. This would give
you oodles of precision and an immediate answer -- but it'd be
ridiculously expensive to roll one from scratch).

Thanks in advance.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Jon Elson
Guest

Thu Dec 22, 2011 12:29 am   



Tim Wescott wrote:


Quote:

And I figured out one such scheme! Take the output of an N-bit LFSR, and
lay it down in order. If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.

Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction. Use the
looked-up bits to determine the position (which you can, because they're
unique), and voila! You have the absolute position and can now just use
the relative encoder.
This still requires the encoder to move a small amount before the

position is known. But, it does require only a very SMALL amount of
movement. I would not be astonished to find out somebody already
does this, there are a RAFT of absolute or pseudo-absolute encoder
schemes out there that use the relationship between several tracks
to provide absolute position with just a small movement.

Jon

Tim Williams
Guest

Thu Dec 22, 2011 12:32 am   



There's a Hardware Hacker on this -- Don?

As long as direction is known (I suppose you could use something like
Manchester encoding, so it always produces a direction on top of the
serial bit pattern you're computing against), you should be able to
up/down shift it into a register and predict the next step, or compare, or
etc. I know LFSRs can be used as counters (modulo 2^N-1, kind of
inconvienient, solvable as you note), but it's my recollection that, for
obvious reasons, decoding them is nontrivial, so converting that to a
positional count is hard (i.e., just look it up in RAM, instead of
synthesizing logic to do it from scratch).

Tim

--
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms

"Tim Wescott" <tim_at_seemywebsite.com> wrote in message
news:Ha-dnZCw_aKf9W_TnZ2dnUVZ_omdnZ2d_at_web-ster.com...
Quote:
So, I'm working on an interesting problem. It's somewhat self-assigned,
but it'll make it's way into some customer equipment. It's not quite
DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is. There are some tried-and-true methods, but I want to do
better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel. Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that
any
consecutive string of N positions is unique.

And I figured out one such scheme! Take the output of an N-bit LFSR,
and
lay it down in order. If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.

Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction. Use the
looked-up bits to determine the position (which you can, because they're
unique), and voila! You have the absolute position and can now just use
the relative encoder.

So my question is: has anyone seen this done? Are there better
variations? Is there anyone who makes some sort of off-the-shelf
solution that does all that, but cheaper than I could ever roll my own
from individual components? My ideal would be a sensor that I could buy
off the shelf, and specify to my customer how their code disk would have
to be made, and have everything just work.

(Note that if you had the freedom to roll your own silicon you could
make
a system that would register a code word, look it up for the absolute
position, then figure out its offset within the sensor. This would give
you oodles of precision and an immediate answer -- but it'd be
ridiculously expensive to roll one from scratch).

Thanks in advance.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com


robert bristow-johnson
Guest

Thu Dec 22, 2011 2:13 am   



piling on...

On 12/21/11 6:13 PM, Tim Wescott wrote:
Quote:
So, I'm working on an interesting problem. It's somewhat self-assigned,
but it'll make it's way into some customer equipment. It's not quite DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is. There are some tried-and-true methods, but I want to do better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel. Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that any
consecutive string of N positions is unique.

And I figured out one such scheme! Take the output of an N-bit LFSR, and
lay it down in order. If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.


so what's the advantage of this over gray code? i can think of a
serious disadvantage.


--

r b-j rbj_at_audioimagination.com

"Imagination is more important than knowledge."

Tim Wescott
Guest

Thu Dec 22, 2011 2:42 am   



On Wed, 21 Dec 2011 16:56:13 -0800, Bill Sloman wrote:

Quote:
Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction.  Use the
looked-up bits to determine the position (which you can, because
they're unique), and voila!  You have the absolute position and can now
just use the relative encoder.

They aren't actually unique. Look at the example here

http://en.wikipedia.org/wiki/Linear_feedback_shift_register

amd note that 0001 reappears - in the the overlap of 0100 and 0010,
which you can rewrite as 010 0001 0 - a couple of cycles later. You need
more than N bits of context before you can determine an absolute
position.

I said the _output_, which goes 000100110101111 and then repeats, or if
you insert the zero, 0000100110101111. Not the _state_.

Please show me the repeat in the above.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Tim Wescott
Guest

Thu Dec 22, 2011 2:43 am   



On Wed, 21 Dec 2011 20:13:54 -0500, robert bristow-johnson wrote:

Quote:
piling on...

On 12/21/11 6:13 PM, Tim Wescott wrote:
So, I'm working on an interesting problem. It's somewhat
self-assigned, but it'll make it's way into some customer equipment.
It's not quite DSP, not quite circuits, but I'm posting it to these
groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is. There are some tried-and-true methods, but I want to do
better.

I want to be able to use an encoder to rapidly -- but not immediately
-- figure out the absolute position of a wheel. Sort of a hybrid
absolute/ relative encoder, that's not as expensive as using N strips
to get the 2^N precision of an absolute encoder, but that gets you an
absolute position quicker than the "go around until you see an index
pulse" that you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure
out the relative motion of the wheel, and then back that up by a strip
that is encoded in binary (dark = 0, light = 1) with some scheme such
that any consecutive string of N positions is unique.

And I figured out one such scheme! Take the output of an N-bit LFSR,
and lay it down in order. If the idea of having 2^N - 1 bits bothers
you, then augment the LFSR such that it has one string of N zeros on
its output, giving you a nice even 2^N positions.


so what's the advantage of this over gray code? i can think of a
serious disadvantage.

Assuming you're getting differential from a quadrature (2-bit gray code)
it means that you only need three tracks for any resolution of encoder.
An N-bit absolute encoder with gray code still needs N tracks.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Bill Sloman
Guest

Thu Dec 22, 2011 2:56 am   



On Dec 22, 12:13 am, Tim Wescott <t...@seemywebsite.com> wrote:
Quote:
So, I'm working on an interesting problem.  It's somewhat self-assigned,
but it'll make it's way into some customer equipment.  It's not quite DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is.  There are some tried-and-true methods, but I want to do better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel.  Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that any
consecutive string of N positions is unique.

And I figured out one such scheme!  Take the output of an N-bit LFSR, and
lay it down in order.  If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.

What's so special about a linear feed-back shift register?

Quote:
Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction.  Use the
looked-up bits to determine the position (which you can, because they're
unique), and voila!  You have the absolute position and can now just use
the relative encoder.

They aren't actually unique. Look at the example here

http://en.wikipedia.org/wiki/Linear_feedback_shift_register

amd note that 0001 reappears - in the the overlap of 0100 and 0010,
which you can rewrite as 010 0001 0 - a couple of cycles later. You
need more than N bits of context before you can determine an absolute
position.

Serial communications codes deal with this problem by including unique
framing synch sequences which you can use to identify how to break up
the serial bit stream into multi-bit chunks, which is exactly
equivalent to your "index pulse".

http://en.wikipedia.org/wiki/Bit_stuffing

The HDLC-style solution - where N+1 successive zeros is always and
only a frame synch sequence - could let you synchronise after reading
only 2N+1 bits if you alternated the 2^N-1 possible n-bit numbers
(excludng N zeros) between frame synch sequences, or you could use
2N-1 index pulses to do the frame synch job, but that would require
two extra parallel tracks and two extra detectors.

--
Bill Sloman, Nijmegen

John Larkin
Guest

Thu Dec 22, 2011 2:57 am   



On Wed, 21 Dec 2011 20:13:54 -0500, robert bristow-johnson
<rbj_at_audioimagination.com> wrote:

Quote:

piling on...

On 12/21/11 6:13 PM, Tim Wescott wrote:
So, I'm working on an interesting problem. It's somewhat self-assigned,
but it'll make it's way into some customer equipment. It's not quite DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is. There are some tried-and-true methods, but I want to do better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel. Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that any
consecutive string of N positions is unique.

And I figured out one such scheme! Take the output of an N-bit LFSR, and
lay it down in order. If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.


so what's the advantage of this over gray code? i can think of a
serious disadvantage.

He'd only need three tracks, the quadratures and the PRBS one. The
PRBS would replace the index track, but find the absolute position in
a much smaller rotation. Cute idea.

John

langwadt@fonz.dk
Guest

Thu Dec 22, 2011 3:22 am   



On 22 Dec., 00:32, "Tim Williams" <tmoran...@charter.net> wrote:
Quote:
There's a Hardware Hacker on this -- Don?

As long as direction is known (I suppose you could use something like
Manchester encoding, so it always produces a direction on top of the
serial bit pattern you're computing against), you should be able to
up/down shift it into a register and predict the next step, or compare, or
etc.  I know LFSRs can be used as counters (modulo 2^N-1, kind of
inconvienient, solvable as you note), but it's my recollection that, for
obvious reasons, decoding them is nontrivial, so converting that to a
positional count is hard (i.e., just look it up in RAM, instead of
synthesizing logic to do it from scratch).

Tim


I guess the brute force approach is to put N bits in an identical
lfsr
and count how many steps it takes to get to a known value

a quadrature decoder done right is pretty robust with regards to
noise
and contact bounce, I think you'd lose that if you do it in other ways

-Lasse


Guest

Thu Dec 22, 2011 4:46 am   



On Dec 21, 6:13 pm, Tim Wescott <t...@seemywebsite.com> wrote:
Quote:
So, I'm working on an interesting problem.  It's somewhat self-assigned,
but it'll make it's way into some customer equipment.  It's not quite DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is.  There are some tried-and-true methods, but I want to do better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel.  Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that any
consecutive string of N positions is unique.

And I figured out one such scheme!  Take the output of an N-bit LFSR, and
lay it down in order.  If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.

Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction.  Use the
looked-up bits to determine the position (which you can, because they're
unique), and voila!  You have the absolute position and can now just use
the relative encoder.

So my question is: has anyone seen this done?  Are there better
variations?  Is there anyone who makes some sort of off-the-shelf
solution that does all that, but cheaper than I could ever roll my own
from individual components?  My ideal would be a sensor that I could buy
off the shelf, and specify to my customer how their code disk would have
to be made, and have everything just work.

(Note that if you had the freedom to roll your own silicon you could make
a system that would register a code word, look it up for the absolute
position, then figure out its offset within the sensor.  This would give
you oodles of precision and an immediate answer -- but it'd be
ridiculously expensive to roll one from scratch).

Thanks in advance.

You've described a single-track encoder (or code+clock track) where
the position track is coded with a non-repeating sequence, and
absolute position can be known, for example, in m bits for a 2^m-1
maximal length sequence.

http://www.freepatentsonline.com/4628298.html
http://www.freepatentsonline.com/4947166.html
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.6922

Older tech was a conductive Gray-coded track, with multiple pickup
contacts spaced one bit's distance apart.

--
Cheers,
James Arthur

Bill Sloman
Guest

Thu Dec 22, 2011 5:29 am   



On Dec 22, 2:57 am, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
Quote:
On Wed, 21 Dec 2011 20:13:54 -0500, robert bristow-johnson

r...@audioimagination.com> wrote:

piling on...

On 12/21/11 6:13 PM, Tim Wescott wrote:
So, I'm working on an interesting problem.  It's somewhat self-assigned,
but it'll make it's way into some customer equipment.  It's not quite DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is.  There are some tried-and-true methods, but I want to do better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel.  Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that any
consecutive string of N positions is unique.

And I figured out one such scheme!  Take the output of an N-bit LFSR, and
lay it down in order.  If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.

so what's the advantage of this over gray code?  i can think of a
serious disadvantage.

He'd only need three tracks, the quadratures and the PRBS one.

Two tracks. You get quadrature out of a single track - it takes two
detectors looking at the same (moving) track through separate parts of
a static mask. Some primitive optical position-sensing systems didn't
work this way, but they were hard to align and prone to fall out of
alignment - Lintech in Cambridge were dumb enough to buy such a system
back in the early 1980s, but Cambridge Instruments dumped it when they
bought the company from the receiver, making the service engineers
much happier.

Quote:
The PRBS would replace the index track, but find the absolute position in
a much smaller rotation. Cute idea.

If it actually works for N>4.

--
Bill Sloman, Nijmegen

Bill Sloman
Guest

Thu Dec 22, 2011 5:30 am   



On Dec 22, 2:42 am, Tim Wescott <t...@seemywebsite.com> wrote:
Quote:
On Wed, 21 Dec 2011 16:56:13 -0800, Bill Sloman wrote:
Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction.  Use the
looked-up bits to determine the position (which you can, because
they're unique), and voila!  You have the absolute position and can now
just use the relative encoder.

They aren't actually unique. Look at the example here

http://en.wikipedia.org/wiki/Linear_feedback_shift_register

amd note that 0001 reappears - in the the overlap of 0100 and 0010,
which you can rewrite as 010 0001 0 - a couple of cycles later. You need
more than N bits of context before you can determine an absolute
position.

I said the _output_, which goes 000100110101111 and then repeats, or if
you insert the zero, 0000100110101111.  Not the _state_.

That's not a maximal length sequence. If I parse your first sequence
into four bit chunks 0001,0011,0101,111(1) it looks like 1,3,5,15/F,
while the second one comes out as 0000,1001,1010,1111 or 0,9,10/A,15/
F.

Linear feedback shift registers are traditionally configured to cover
the 2^N-1 possible states of the N-bit long shift register, which is a
(2^N-1).N length bit sequence. Are you claiming to have found a
feedback network that generates a shorter sequence, only 2^N-1 bits
long, where each N-bit chunk is unique?

If you have it's not something I've heard about before - which doesn't
mean all that much, since I've never got deeply immersed in that kind
of maths.

--
Bill Sloman, Nijmegen



--
Bill Sloman, Nijmegen

Tim Wescott
Guest

Thu Dec 22, 2011 7:17 am   



On Wed, 21 Dec 2011 19:30:03 -0800, Bill Sloman wrote:

Quote:
On Dec 22, 2:42 am, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 21 Dec 2011 16:56:13 -0800, Bill Sloman wrote:
Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction.  Use the
looked-up bits to determine the position (which you can, because
they're unique), and voila!  You have the absolute position and can
now just use the relative encoder.

They aren't actually unique. Look at the example here

http://en.wikipedia.org/wiki/Linear_feedback_shift_register

amd note that 0001 reappears - in the the overlap of 0100 and 0010,
which you can rewrite as 010 0001 0 - a couple of cycles later. You
need more than N bits of context before you can determine an absolute
position.

I said the _output_, which goes 000100110101111 and then repeats, or if
you insert the zero, 0000100110101111.  Not the _state_.

That's not a maximal length sequence.

Well, I find that astonishing, given that I generated it from the
polynomial x^5 + x + 1 (seeded with 0001), and that it's 15 bits long,
and that it repeats just as you'd expect.

Quote:
If I parse your first sequence
into four bit chunks 0001,0011,0101,111(1) it looks like 1,3,5,15/F,

Why do that? The important thing (to me) is that if you parse it into
_any_ consecutive four bits, the answer is unique compared to any _other_
consecutive four bits.

Quote:
while the second one comes out as 0000,1001,1010,1111 or 0,9,10/A,15/ F.

Linear feedback shift registers are traditionally configured to cover
the 2^N-1 possible states of the N-bit long shift register, which is a
(2^N-1).N length bit sequence.

Oh really? That's not how I've seen it in any of the comms systems I've
worked on. The sequence that's generated by a LFSR is the sequence of
bits you get by picking off the state of one bit (or some linear
combination of bits) in the register for each of the 2^N-1 states, to get
a sequence of length 2^N-1.

But apparently you know more than the folks who invented CDMA phones.

Quote:
Are you claiming to have found a feedback
network that generates a shorter sequence, only 2^N-1 bits long, where
each N-bit chunk is unique?

Yes. Furthermore, I suspect that it is a property of any maximal-length
LFSR.

Quote:
If you have it's not something I've heard about before - which doesn't
mean all that much, since I've never got deeply immersed in that kind of
maths.

Indeed, apparently you have not.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com


Guest

Thu Dec 22, 2011 7:29 am   



On Dec 21, 9:46 pm, dagmargoodb...@yahoo.com wrote:
Quote:
On Dec 21, 6:13 pm, Tim Wescott <t...@seemywebsite.com> wrote:



So, I'm working on an interesting problem.  It's somewhat self-assigned,
but it'll make it's way into some customer equipment.  It's not quite DSP,
not quite circuits, but I'm posting it to these groups anyway.

The application is an optical encoder -- shine light through a disk at
some photosensors, look at the result, and tell the processor where the
disk is.  There are some tried-and-true methods, but I want to do better.

I want to be able to use an encoder to rapidly -- but not immediately --
figure out the absolute position of a wheel.  Sort of a hybrid absolute/
relative encoder, that's not as expensive as using N strips to get the
2^N precision of an absolute encoder, but that gets you an absolute
position quicker than the "go around until you see an index pulse" that
you get from a pure relative encoder.

My thought is to use a quadrature encoder in the usual way to figure out
the relative motion of the wheel, and then back that up by a strip that
is encoded in binary (dark = 0, light = 1) with some scheme such that any
consecutive string of N positions is unique.

And I figured out one such scheme!  Take the output of an N-bit LFSR, and
lay it down in order.  If the idea of having 2^N - 1 bits bothers you,
then augment the LFSR such that it has one string of N zeros on its
output, giving you a nice even 2^N positions.

Then, to figure out the absolute position of the wheel, use the
quadrature encoder to to run by N bits in either direction.  Use the
looked-up bits to determine the position (which you can, because they're
unique), and voila!  You have the absolute position and can now just use
the relative encoder.

So my question is: has anyone seen this done?  Are there better
variations?  Is there anyone who makes some sort of off-the-shelf
solution that does all that, but cheaper than I could ever roll my own
from individual components?  My ideal would be a sensor that I could buy
off the shelf, and specify to my customer how their code disk would have
to be made, and have everything just work.

(Note that if you had the freedom to roll your own silicon you could make
a system that would register a code word, look it up for the absolute
position, then figure out its offset within the sensor.  This would give
you oodles of precision and an immediate answer -- but it'd be
ridiculously expensive to roll one from scratch).

Thanks in advance.

You've described a single-track encoder (or code+clock track) where
the position track is coded with a non-repeating sequence, and
absolute position can be known, for example, in m bits for a 2^m-1
maximal length sequence.

<...>

P.S. -- here's an actual implementation, with parallel bit readout by
a linear photodiode array:
http://www.taosinc.com/getfile.aspx?type=press&file=encoderdesign4b.pdf

--James

Tim Wescott
Guest

Thu Dec 22, 2011 7:43 am   



On Wed, 21 Dec 2011 21:29:02 -0800, dagmargoodboat wrote:

Quote:
You've described a single-track encoder (or code+clock track) where the
position track is coded with a non-repeating sequence, and absolute
position can be known, for example, in m bits for a 2^m-1 maximal
length sequence.

...

P.S. -- here's an actual implementation, with parallel bit readout by a
linear photodiode array:
http://www.taosinc.com/getfile.aspx?type=press&file=encoderdesign4b.pdf

That's actually close to what I'd like, except they're peddling just the
light sensor, while I'd like to have a chip that just reads out the right
answer if you give it a code wheel that's laid out correctly.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Goto page 1, 2, 3 ... 36, 37, 38  Next

elektroda.net NewsGroups Forum Index - Electronics Design - Position Encoding.

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map Opony