aber ist ein tick der radsensoren nicht schon 3 mm wert? dass heisst aber, dass ich dicke und dünne striche auf jeden fall stark unterschiedlich machen würde, zB 3 ticks für dünn und 6 ticks für dick, was dann immerhin 1 und 2 cm bedeuten würde. dünne striche dürften dann 2-4 ticks lang sein, und dicke striche 5-7 ticks. so könnte man trotz der (für diesen zweck eingentlich wohl zu) geringengen aufösungen der encoder die striche halbwegs sicher erkennen.

bei deinen überlegungen gibts einen gravierenden fehler: es können niemals zwei weisse oder zwei schwarze striche aufeinanderfolgen ("WW oder SS).

vermutlich meinst du jedoch die abstände bzw breiten, und nicht die farben =)
folhgendes fällt mir ein um ein byte zu kodieren:

jede lücke und jeder strich kann schmal (S) und breit (B) sein.

ich nehme jetzt schmal als 0, und breit als 1 an.

für ein byte, also 8 bit braucht man also 4 striche und 4 lücken.

wenn man das ganze etwas sicherer machen will, könnte man so beginnen:

SBSB - startcode (zwei schmale striche und zwei breite lücken)
xxxxxxxx (4 striche und 4 lücken, ein byte kodiert nach obigem massstab)
a (ein strich für die befehlsart: 1=befehl, 0 = daten)
p (prüfsumme (eine lücke, kein strich! schön mitzählen =), 1 wenn anzahl der einsen ungerade, 0 wenn anzahl der einsen gerade)
SBB - endcode (schmaler strich-breite lücke-breiter strich. das letzte zeichen ist ein strich, denn eine lücke wäre ja unendlich lang... =)

start- und endcode sollten verschieden sein, damit der asuro merkt dass er in die falsche richtung drüber fährt, und den code dann entsprechend umrechnet oder es eben von der anderen seite versucht.

um also den befehl 11001100 zu kodieren würde das ganze so aussehen:
(großbuchstaben: strich, kleinbuchstabe: lücke

SbSbBbSsBbSsBbSbB

Code:
#   #   ###   # ###   # ###   #   ###