Interesting! And thanks for the fast response.
I think with a very slight variation on your system it looks like a winner. Which is to increase the number of 1 bits each block;
On a smaller scale of N=4 that would be;
0001 0011 0111 0000 1111
which is logical, but unfortunately still has repeats?
Code:
N=4, seems to have repeats;
00010011011100001111
0001
0001
0111
0111
N=4, but ending after 16bits total;
0001001101110000
0001
000
0111
0
(no repeats!)
That looks pretty good! It has a beautiful simplicity that should be easy to design for any amount of bits) and easy to decode as well. I like the fact that the number of 1 bits inthe 4bit sample tells you roughly how far left the sample is on the strip... Cool.
I just had a nightmarish hour of wading through Wiki pages on binary sequence algorithms, looking at every one and finally found the one I originally thought of using;
https://en.wikipedia.org/wiki/De_Bruijn_sequence (1946)
It gives the same sequences as I posted in post#1, (so my system was DeBruijn) and the DeBruijn's N=4 solution looks like this;
0000 1111 0110 0101
which can be repeated circularly, so will give all possible 16 samples along the machine travel.
so max samples is (2^N) = 2^4 = 16
Your sequence (which I did not find on Wiki by the way!) is;
0001001101110000
0000 (last possible sample)
which only gives 13 samples as; max samples = (2^N)-(N-1)
But even with the limitation that your system has a few less samples total for N, so yours would give 249 positions for an 8bit encoder rather than DeBruijn's 256 positions for an 8bit encoder, I still like the bulletproof ease of generating the encoder data for your system.
Also I like the fact that the number of 1's in your system tells the rough left/right position, that is nice and might be good for error detecting. With DeBruijn as it goes left->right the bits just get more random looking which would not be easy to detect and won't help much for error checking... And DeBruijn is a bit of a pain to generate the data for...
Anyway thanks Crutschow, it looks like you hit the nail on the head!
I can live with a few less counts on the encoder and go with the ease of generating the 8bit data like this;
00000001
00000010
00000100 (etc)
which suits me fine as it will go in a lookup table in C code.
(edit) Whoops! Darn it I just realised your system will only give 57 positions for 8bits, as I just tested and it gives; max samples = Nsquared-(N-1) = 8*8 -7 = 57
That hurts! To get the 200+ samples I need will require 15bits to get me 211 samples...