Martin Kirk wrote some days ago:

> Hi all,
>         I have been off the air for a few days.  First I will respond to
> S_GROB's question:
>
> By the way, what exactly does the TSL213?
>
>         The TSL213 is a 64x1 pixel sensing array.  It comes in an 8-bit
> package with a long window exposing the 64 pixels.  When given the SI
> (start integration?) signal it ends the previous integration and
> transfers the accumulated charge from pixel #1 to the output buffer.  65
> successive clocks will step the output through all 64 pixels and get
> ready for the next sweep.  The output is analog but when the integration
> time and light intensity are selected correctly the output meets digital
> 1/0 specifications.
>
If I understand you right, the TSL213 is some sort of CCD array, or a kind
of analog shift register of 64 pixels. You can shift out each pixel sequen-
tially and convert its analogue value into a digital bit. So you get a
sequence of 64 bits representing 64 (bright or dark) pixels?

you continued:
(...)
>         One thing to keep in mind.  The 64x1 array will be used to
> oversample the coded strips.  I figure I can use a 3-bit Binary Chain
> Code which gives 8 (2^3) bits in the code.  Precisely the code I will use
> is:
>
>                 00010111
>                 ^^^
>                 [ ] <-- first window
>
>         There are exactly six 3-bit windows on to this pattern:
>
>         000
>         001
>         010
>         101
>         011
>         111
>
>         It works out that one gets 2^n - n + 1 distinct windows on any n
> bit code.

and if you add '00' (or in general the first n-1 bits) you get a full range
of 2^n patterns:
                  0001011100
                          ~~
000,001,010,101,011,111,110,100  :-)


continuing:
>
>         If I oversample at 16 pixels per bit I can detect the starting
> position of the 3-bit code to within one of 16 positions.  That give a total
> of 96 (6x16) positions I can resolve.  I only need about 70.  If my edge
> detection is a little too noisy I can go to a 4-bit code and get greater
> resolution.

again, if I understand you right, one bit of the Binary-Chain-Code is
represented by 16 pixels?
I. e. the pattern '000' is equal to 3*16=48 zeroes in the pixel array.
And as an 48-pixel-array can be positioned at 16 locations in a 64
full-array, you think to resolve these 16 locations?

In your example you thought to find one of your six patterns in the pixel
array to get a rough position, and to locate this pattern inside its
16-location-bandwith to get the exact position!?

------------------------

You said, that you need a resolution of about 70 positions. But what is the
unit, in which you need your position? Do you need to know the position
as exactly as one pixel width or is your position-unit a multiple of pixels?
As I thought to read out of your lines, you want the maximum possible reso-
lution, based on a single pixel.
If yes, then it is a hard job to do! Theoretically, one bit of the binary-
chain-code is represented by 16 pixels, but reality will not be as digital
as you like it, it tends to be `fuzzy'. What I want to say is, that a bit can
be read as 15 or 17 pixels, too, which must not confuse your position-
calculation-routine!

So I would suggest one of the two following methods, based on the calculation
of random numbers I described earlier:


the unit: 1 position unit = 8 pixels
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
resolution: 8 bit = 255 (or 256) positions.
divide the 64 pixel array into 8 pieces of 8-pixel-groups.
one 8-pixel-group represents one bit (8-times-oversampling).
the 64 pixel array is declared valid, if the middle five pixels of an
  8-pixel-group are the same. (the change between a 1- and a 0-bit occurs in
  the outer area of an 8-pixel-group, so no error will occur, if a bit is
  represented by 7 or 9 pixels instead of 8)
if the 64 pixel array is valid, you get an 8-bit-position-code out of the
  8 pieces.
now calculate your position out of this position-code (trial-and-error or
look-up-table)

example:
an 'x' as well as an 'o' represents a pixel. Just to show 8-pixel-groups.
pixel array: xxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxoooooooo
valid pattrn: ########      ################                 #########
             \______/\______/\______/\______/\______/\______/\______/\______/
read as:        1       0       1       1       0      0        1       0

inval. patt.:    ########      ################                 #########
             \______/
              ^^^^^ the middle four pixels are not the same



the unit: 1 position unit = 1 pixel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
this is max. resolution unit, resolution: 7 bit = 127*8 positions
again, one 8-pixel-group represents one bit (8-times-oversampling).
if pixel00..pixel04, pixel08..pixel12 and so on are equal each (no change
  inside a 5-pixel-group) then FineResolution:=0
else if pixel01..pixel05, pixel09..pixel13 and so on are equal each (no change
  inside a 5-pixel-group) then FineResolution:=1
else if pixel02..pixel06, pixel10..pixel14 and so on are equal each (no change
  inside a 5-pixel-group) then FineResolution:=2
...
else if pixel 07..pixel10 ... then FineResolution:=7
now build up a 7-bit-position-code out of the valid nibbles and calculate
the RoughResolution out of it.
ExactPosition:=RoughResolution*8 + FineResolution

(same) example:
pixel array: xxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxooooooooxxxxxxxxoooooooo
valid pattrn: ########      ################                 #########
1. run:      \______/\______/\______/\______/\______/\______/\______/
result:      ^^^^^ pixel00..pixel04 are not the same => invalid
2. run:       \______/\______/\______/\______/\______/\______/\______/
result:       ^^^^^ pixel01..pixel05 are equal => FineResolution:=1
position-code:   1       0       1        1      0       0       1
exact position := RoughResolution (1011001)*8 + FineResolution


Ist doch ganz einfach, oder?  [really simple, isn't it?]


I am sure that not everybody has understood this possible solution of a really
fascinating problem, but it is sufficient if at least Martin has :-)

I think, that my method elliminates all problems, which can occur due to
errors at the edge from a 1-bit and a 0-bit. The solution is a question of
resolution and algorithm and not really a problem of hardware, I think.
But if you have a fast and "tough" PIC, this should not be a big problem, too.

My 16C84 also survived after a rotated insertion into its socket.
So it is almost unbelievable, that a fried of mine killed his 16C84.
Maybe some 16C84 are tougher than others?

Siggi


Siegfried Grob,                                   |
student of electrical engineering,                |
university of ulm, germany                        |
e-mail:  siegfried.grob@student.uni-ulm.de        |
tel&fax: +49 731 25148                            |
--------------------------------------------------'