Drehgeber-Dekoder arbeitet unerwartet

[Daniel V. (danielv2)]

Beim Testen des Drehgeber-Dekoders von Peter Dannegger 
(https://www.mikrocontroller.net/articles/Drehgeber#Solide_L%C3%B6sung:_Beispielcode_in_C) 
ist mir ein unerwartetes Verhalten aufgefallen.

Konkret geht es um die Dekodierung eines Drehgeber mit Rastpunkten bei 
den Schaltkontaktzuständen offen-offen und bei 
geschlossen-geschlossen. Für den step-Parameter bei encode_read() wäre 
demnach 2 zu wählen.

Im Anhang befindet sich ein Bild, das die encode_read(2)-Werte bei 
künstlichen Schaltkontaktdaten zeigt. Die Rastpunkte sind durch blaue 
vertikale Linien markiert und die Position wird von der horizontalen 
blauen Linie angezeigt. Die rote (step=1) und grüne Linie (step=4) 
zeigen zum Vergleich die Position bei anderen Step-Werten.

Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die 
Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim 
anschließenden Schließen des ersten Kontakts (Störung) springt die 
Position wieder zurück - das ist unerwartet. Aus meiner Sicht hätte das 
nur beim Zustand geschlossen-geschlossen passieren dürfen.

Warum ist das Verhalten korrekt? (Oder verwende ich den Dekoder falsch?)

[Ob S. (Firma: 1984now) (observer)]

Daniel V. schrieb:

> Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die
> Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim
> anschließenden Schließen des ersten Kontakts (Störung) springt die
> Position wieder zurück - das ist unerwartet. Aus meiner Sicht hätte das
> nur beim Zustand geschlossen-geschlossen passieren dürfen.
>
> Warum ist das Verhalten korrekt?

Weil das genau das ist, was bei einem Richtungswechsel des Encoders 
tatsächlich passiert und auch passieren muss.

> (Oder verwende ich den Dekoder falsch?)

Ja. Du musst einfach dafür sorgen, dass es keine Störungen gibt, bzw. 
sie nicht den Eingang erreichen. Das ist Hardware. Pullup-Widerstände 
verringern und/oder mit einem kleinen Kondensator nach Masse abblocken.

[Daniel V. (danielv2)]

Ob S. schrieb:
> Weil das genau das ist, was bei einem Richtungswechsel des Encoders
> tatsächlich passiert und auch passieren muss.

Der Zustand offen-offen und der Zustand geschlossen-geschlossen 
definieren eine Rastenposition. Die beiden anderen Zustände definieren 
keine Position.

[Rainer W. (rawi)]

Ob S. schrieb:
> Ja. Du musst einfach dafür sorgen, dass es keine Störungen gibt, bzw.
> sie nicht den Eingang erreichen. Das ist Hardware.

Warum ist das unbedingt Hardware?
Der Geber hat definierte Rastpunkte und dort ist alles gut. Der Rest 
kann herausgefiltert werden, bevor der Zustand weitergereicht wird.

[Ob S. (Firma: 1984now) (observer)]

Rainer W. schrieb:
> Ob S. schrieb:
>> Ja. Du musst einfach dafür sorgen, dass es keine Störungen gibt, bzw.
>> sie nicht den Eingang erreichen. Das ist Hardware.
>
> Warum ist das unbedingt Hardware?

Weil Störungsbursts den Decoder durcheinander bringen können. Nur 
Einzelstörungen kann man per Software filtern. Aber: wo eine 
Einzelstörung herkommt, kann auch ein Burst herkommen. Also sorgt man 
sinnvollerweise dafür, dass sowas den Pin erst garnicht erreicht.

> Der Geber hat definierte Rastpunkte und dort ist alles gut. Der Rest
> kann herausgefiltert werden, bevor der Zustand weitergereicht wird.

Die Elektronik weiß rein garnichts von irgendwelchen Rastpunkten. Und 
auch die Software weiß das nicht wirklich. Sie hat keine Möglichkeit zur 
Erfassung der Rastpunkte.

[Michael B. (laberkopp)]

Daniel V. schrieb:
> Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die
> Position sobald beide Kontakte geöffnet sind - das ist korrekt.


Die rote sum Linie sieht sehr gut aus.

> Beim
> anschließenden Schließen des ersten Kontakts (Störung) springt die
> Position wieder zurück - das ist unerwartet

Unerwartet ?

Natürlich muss die Position zurückspringen sonst würde sie beim erneuten 
öffnen des Kontakts schon um 2 weiter schalten.

Die Rasten sind dort, wo es ungestört ist, damit die angezeigte Zahl 
nicht flattert.

[Daniel V. (danielv2)]

Michael B. schrieb:
> Die rote sum Linie sieht sehr gut aus.

Das sehe ich auch so. Bei step=1 ist es wie von mir erwartet.

Michael B. schrieb:
> Natürlich muss die Position zurückspringen sonst würde sie beim erneuten
> öffnen des Kontakts schon um 2 weiter schalten.

Wenn sich die Position auf Raste 3 geändert hat, dann kann sie sich nur 
beim Zustand geschlossen-geschlossen wieder ändern. Ein erneutes 
offen-offen beim Kontaktzustand hätte keine fehlerhafte Wirkung, 
weil der Rastenzustand bereits offen-offen ist.

Aus Anwendersicht erwarte ich innerhalb einer Rastenstellung keine 
Änderung vom Positionswert. Aus Entwicklersicht definieren die Zustände 
geschlossen-offen und offen-geschlossen keine Rastenposition. Das 
lässt sich auch kodieren ("Hysterese").

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Daniel V. schrieb:
> Aus meiner Sicht hätte das nur beim Zustand /geschlossen-geschlossen/
> passieren dürfen.
Jede Pegeländerung (sei es durch Prellen oder einen Störimpuls) an einem 
der beiden Eingänge **muss** eine Änderung des Zählerstandes bewirken. 
Also alles im grünen Bereich, du musst nur noch ein paar Minuten länger 
drüber nachdenken und dabei im Kopf behalten, dass die Software die 
blauen Linien nicht kennt, sie sieht nur die Pegel auf den beiden 
Spuren. Und da musst du einfach mal weiter reinzoomen, dann wird dir 
schnell klar, dass das Verhalten genau so sein muss.

Michael B. schrieb:
> Die rote sum Linie sieht sehr gut aus.
Das ist das einzige, was hier zählt: es gibt keine "Verzähler" oder 
"Überseher" oder gar Sprünge.

[Daniel V. (danielv2)]

Lothar M. schrieb:
> Michael B. schrieb:
>> Die rote sum Linie sieht sehr gut aus.
> Das ist das einzige, was hier zählt: es gibt keine "Verzähler" oder
> "Überseher" oder gar Sprünge.

Die rote Linie zählt hier aus meiner Sicht nicht. Nach den Rasten ist 
doch für step 2 zu verwenden - also die blaue Linie.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Daniel V. schrieb:
> Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die
> Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim
> anschließenden Schließen des ersten Kontakts (Störung) springt die
> Position wieder zurück
Dann zeichne diese fragliche Stelle und eine Vergleichsstelle mal 
deutlich in das Bild ein.

> Die rote (step=1) und grüne Linie (step=4) zeigen zum Vergleich die
> Position bei anderen Step-Werten.
Offenbar kann man mit "step" die Art der Auswertung beeinflussen:
- 1 Zählerschritt pro komplettem Qadratursignaldurchlauf (00, 01, 11, 
10),
- 2 Zählerschritte pro Signaldurchlauf und
- 4 Zählerschritte pro Signaldurchlauf.

Bei der Version mit 2 Zählerschritten wird eben nur auf die 
Flankenwechsel der oberen Spur reagiert. Aber: der Zählerstand (an der 
jeweiligen Raste) sieht bei jeder der vier Kurven nachvollziehbar und 
gut aus.

Daniel V. schrieb:
> Die rote Linie zählt hier aus meiner Sicht nicht.
Naja, dort wird halt die übliche 4-fach Auswertung verwendet: bei jeder 
Raste hat sich der Zählerwert geändert.

[Rainer W. (rawi)]

Ob S. schrieb:
> Die Elektronik weiß rein garnichts von irgendwelchen Rastpunkten.

Du siehst doch in deinem Zeitdiagramm, dass die Zeiten zwischen den 
Schleiferkratzereien (oder worin auch immer diese Störungen ihre Ursache 
haben), viel kürzer sind, als die Änderungen auf Grund der Kodierung der 
Geberscheibe. Da ist also schon viel Platz für Filterung.

[Daniel V. (danielv2)]

Lothar M. schrieb:
> Dann zeichne diese fragliche Stelle und eine Vergleichsstelle mal
> deutlich in das Bild ein.
Siehe Bild im Anhang. Die Linie in Magenta zeigt die fragliche Stelle 
und die Linie in Türkis zeigt die aus Anwendersicht relevante Mitte 
zwischen zwei Rasten. Der Dekoder liefert an der fraglichen Stelle die 
Position von Raste 2, obwohl diese nicht vorliegt.

Lothar M. schrieb:
> Offenbar kann man mit "step" die Art der Auswertung beeinflussen:
> - 1 Zählerschritt pro komplettem Qadratursignaldurchlauf (00, 01, 11,
> 10),
> - 2 Zählerschritte pro Signaldurchlauf und
> - 4 Zählerschritte pro Signaldurchlauf.
In meinem Fall sieht der Anwender zwei Zählerschritte pro 
Signaldurchlauf. Die anderen beiden gibt es nur für den Entwickler.
Peters Dekoder-Software liefert bei realen Kontakten grundsätzlich ein 
Springen zwischen zwei Zuständen. Wenn sich der Dekoder (bei step=2) so 
wie von mir erwartet verhalten würde, dann wäre das Ergebnis auch bei 
realen Kontakten einwandfrei.
Der step-Parameter in encode_read() macht für mich keinen Sinn, da er 
ein Springen der Position nicht verhindert und eine anschließende 
Korrektur sogar unmöglich macht.

[Thorsten O. (Firma: mechapro GmbH) (ostermann)]

Da muss nichts korrigiert werden. Die Auswertung zeigt das, was 
physikalisch da ist. Wenn der Encoder prellt, dann prellt er. Die 
Auswertung zählt trotzdem richtig.

Wenn du das Signal glätten oder filtern willst, mach es hinter der 
Auswertelogik.

Mit freundlichen Grüßen
Thorsten Ostermann

[Daniel V. (danielv2)]

Nächste Versuch... :-)

Der Ausgangspunkt für folgendes ist ein losgelassener Drehgeber. Der 
Geber befindet sich also auf einem Rastpunkt.

Was in Ordnung ist:
Wenn ich nach rechts drehe, dann gibt die Decoder-Software nicht in 
Mitte zwischen zwei Rastpunkten einen Impuls, sondern erst wenn etwas 
weiter gedreht wird.

Was fraglich ist:
Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in 
Mitte zwischen zwei Rastpunkten einen Impuls, sondern bevor die die 
Mitte überschritten wird.

Was ich erwartet hätte:
Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in 
Mitte zwischen zwei Rastpunkten einen Impuls, sondern erst wenn etwas 
weiter gedreht wird. -> Analog zur Rechtsdrehung. Ich finde das logisch 
und ein Prellen gibt es so auch nicht.

[Thomas F. (igel)]

Daniel V. schrieb:
> Was fraglich ist:
> Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in
> Mitte zwischen zwei Rastpunkten einen Impuls, sondern bevor die die
> Mitte überschritten wird.

Daran ist doch nichts fraglich. Die Rastpunkte stellen eine eindeutige 
Position dar. Was dazwischen passiert ist mehr oder weniger 
unspezifiziert.

> Was ich erwartet hätte:
> Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in
> Mitte zwischen zwei Rastpunkten einen Impuls, sondern erst wenn etwas
> weiter gedreht wird.

Hast du vielleicht eine falsche Erwartungshaltung?
Dein Encoder mit Rastpunkten hat an den Rastposition einen eindeutigen 
Zustand und die Auswerteroutine von Peter dann einen eindeutigen Wert.

Ob der Wert während der Drehbewegung zwischen den Rastpunkten durch 
Prellen hin- und herspringt ist doch völlig egal wenn in der 
Ruhestellung dann der Wert immer eindeutig ist.
Die Routine von Peter macht das.

[Daniel V. (danielv2)]

Thomas F. schrieb:
> Ob der Wert während der Drehbewegung zwischen den Rastpunkten durch
> Prellen hin- und herspringt ist doch völlig egal wenn in der
> Ruhestellung dann der Wert immer eindeutig ist.

Wenn während des Vorwärtsdrehens vom Mausrad der Text vor und zurück 
springt, dann stört mich das extrem. Bei anderer Auswertung würde das 
nicht passieren.

[Daniel V. (danielv2)]

Egal, ich beuge mich mal der Mehrheit. Ich gebe auf. Danke.

[Falk B. (falk)]

Daniel V. schrieb:
> Wenn während des Vorwärtsdrehens vom Mausrad der Text vor und zurück
> springt, dann stört mich das extrem.

Zu Recht.

> Bei anderer Auswertung würde das
> nicht passieren.

Nö. Wenn dein Drehgeber bzw. Mausrad nicht total kaputt ist, passiert 
das nicht. Das Prellen eines Kanals führt nicht direkt und automatisch 
zum Springen des Textes. Denn man muss zwischen der direkten Dekodierung 
des Drehgebers und dessen Nutzung des Signals unterscheiden. Und gerade 
wenn man einen Dregeber mit x2 oder x4 Auflösung / Rastpunkten nutzt, 
passiert das an sich nicht, denn das Prellen wird in der höheren 
Auflösung "geschluckt" bzw. gefiltert. Klingt komisch, ist aber so.

[Michael B. (laberkopp)]

Daniel V. schrieb:
> Was in Ordnung ist:

Alles.

Daniel V. schrieb:
> Was fraglich ist:

Deine Auffassung.

[Thomas F. (igel)]

Daniel V. schrieb:
> Wenn während des Vorwärtsdrehens vom Mausrad der Text vor und zurück
> springt, dann stört mich das extrem. Bei anderer Auswertung würde das
> nicht passieren.

Ein Prellen der Kontakte bewirkt erstmal nur eine Änderung von enc_delta 
innerhalb der ISR. Und auch nur wenn die ISR oft genug aufgerufen wird.

Erst wenn die main dann encode_read aufruft wird der Wert von enc_delta 
in val übernommen. Für eine Anzeige reicht es völlig dies 5 bis 10 mal 
pro Sekunde zu tun. Und dann springt da üblicherweise auch nix.
Been there - done that. Mehrfach...

[Hippelhaxe (hippelhaxe)]

Daniel V. schrieb:

> Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht
> sich die Position sobald beide Kontakte geöffnet sind - das
> ist korrekt. Beim anschließenden Schließen des ersten
> Kontakts (Störung) springt die Position wieder zurück - das
> ist unerwartet. Aus meiner Sicht hätte das nur beim Zustand
> geschlossen-geschlossen passieren dürfen.

Berechtigter Einwand.

Der Kanal, der sich als erstes ändert, definiert die
Richtung (delta:=+1 bzw. delta:=-1); der andere Kanal
addiert das delta zum Zählerstand und setzt delta:=0.

Man müsste mal einen Automatengraphen zeichnen...

[Hippelhaxe (hippelhaxe)]

Daniel V. schrieb:

> Aus Anwendersicht erwarte ich innerhalb einer
> Rastenstellung keine Änderung vom Positionswert.
> Aus Entwicklersicht definieren die Zustände
> geschlossen-offen und /offen-geschlossen/
> keine Rastenposition. Das lässt sich auch
> kodieren ("Hysterese").

„Eine neue [wissenschaftliche] Wahrheit pflegt sich
nicht in der Weise durchzusetzen, daß ihre Gegner
überzeugt werden und sich als belehrt erklären,
sondern vielmehr dadurch, daß die Gegner allmählich
aussterben und daß die heranwachsende Generation von
vornherein mit der Wahrheit vertraut gemacht ist. “

Max Planck

[Yalu X. (yalu) (Moderator)]

Daniel V. schrieb:
> Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die
> Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim
> anschließenden Schließen des ersten Kontakts (Störung) springt die
> Position wieder zurück - das ist unerwartet.

Peter hat sein Augenmerk darauf gerichtet, dass die Werte jeweils im
eingerasteten Zustand korrekt sind. Das Zappeln zwischen zwei Rastungen
lag offensichtlich nicht in seinem Fokus. Bei einschrittigen Encodern
lässt sich das ohnehin nicht vermeiden, für zwei- und vierschrittige
Encoder hingegen schon, wie du richtig erkannt hast:

Daniel V. schrieb:
> Das lässt sich auch kodieren ("Hysterese").

Füge doch einfach die paar zusätzlichen Codezeilen (wahlweise in
TIMER0_COMP_vect oder in encode_read) hinzu, und der Käse ist gegessen.

[Günter L. (Firma: Privat) (guenter_l)]

von Hippelhaxe schrieb:
>Der Kanal, der sich als erstes ändert, definiert die
>Richtung (delta:=+1 bzw. delta:=-1);

Sehe ich nicht so, egal was sich ändert, jede Änderung
hat eine Richtungsinformation. Die neuen zwei Bit
werden verglichen mit den vorherigen zwei Bit,
daran erkennt man die Richtung.

 00 10 11 01 00 10 11 und so weiter

 00 01 11 10 00 01 11 und so weiter,
 ist entgegengesetzte Drehrichtung

[Falk B. (falk)]

Yalu X. schrieb:
> Peter hat sein Augenmerk darauf gerichtet, dass die Werte jeweils im
> eingerasteten Zustand korrekt sind. Das Zappeln zwischen zwei Rastungen
> lag offensichtlich nicht in seinem Fokus. Bei einschrittigen Encodern
> lässt sich das ohnehin nicht vermeiden,

Doch, indem man die Rastpunkte mechanisch zwischen die Codewechsel legt. 
Auch wenn das einige reale Drehgeber NICHT machen, warum auch immer.

[Teo D. (teoderix)]

Jehova Jehova... Ähh Polling Polling Polling...  :DDD

[Yalu X. (yalu) (Moderator)]

Falk B. schrieb:
> Yalu X. schrieb:
>> Peter hat sein Augenmerk darauf gerichtet, dass die Werte jeweils im
>> eingerasteten Zustand korrekt sind. Das Zappeln zwischen zwei Rastungen
>> lag offensichtlich nicht in seinem Fokus. Bei einschrittigen Encodern
>> lässt sich das ohnehin nicht vermeiden,
>
> Doch, indem man die Rastpunkte mechanisch zwischen die Codewechsel legt.

Damit verlagert man das Gezappel in einen Bereich, wo es weniger stört,
es ist aber immer noch vorhanden (s. rote Linie im ersten Screenshot des
TE). Der TE möchte es aber auch an diesen Stellen eliminieren. Das geht
softwaremäßig nur dann, wenn zwischen zwei Rastpunkten mindestens ein
weiterer Zustand liegt, was bei einschrittigen Encodern eben nicht der
Fall ist.

[Jobst M. (jobstens-de)]

Wie wäre es mit einem Filter?

Die Bewegung des Drehgebers landet irgendwann in einem Zähler.
Den Wert dieses Zählers liest man (am besten direkt nachdem dieser neu 
gesetzt wurde) aus und führt dann folgendens aus:

if (zähler != germerkter_wert) {
    ausgabe = (zähler + gemerkter_wert)>>1;
    gemerkter_wert = zähler;
}

Gruß
Jobst

[Uwe K. (ukhl)]

Daniel V. schrieb:
> Egal, ich beuge mich mal der Mehrheit. Ich gebe auf. Danke.

Nicht aufgeben.

Versuche das mal, und berichte:

Beitrag "Re: Drehgeber/Encoder 1-, 2- oder 4-schrittig"

Das ist ideal für die Abtastung im höchster Auflösung. Oder einem 
Umschalter auf dem Rastpunkt. Da zappelt dann nichts mehr.

Entscheident ist die Funktion "encode".

Bitte erst ausprobieren, dann über das Ergenis berichten.

Bin gespannt...

[Ob S. (Firma: 1984now) (observer)]

Uwe K. schrieb:

> Versuche das mal, und berichte:
>
> Beitrag "Re: Drehgeber/Encoder 1-, 2- oder 4-schrittig"
>
> Das ist ideal für die Abtastung im höchster Auflösung. Oder einem
> Umschalter auf dem Rastpunkt. Da zappelt dann nichts mehr.

Das ist die berühmte Umkehr-Hysterese. Genau die hatte ich auch in 
meinem interruptgetriebenen Assembler-Code implementiert. Die ich hier 
zwar mal gepostet hatte, die ich aber dank der lausigen Suche einfach 
nicht wiederfinden kann, deswegen muss ich den Link schuldig bleiben.

> Was man wissen muss: Dir geht ein Impuls verloren, wenn man rückwärts
> dreht (nur bei der höchsten Auslösung). Der wird beim vorwärtsdrehen
> wieder aufgeholt.

Ganz genau das ist der Nachteil dieser Umkehr-Hysterese. Jede 
Fehlauslösung auf einem Kanal (egal ob durch ESD oder Kontaktprellen) 
sorgt für einen Schritt in die falsche Richtung. Muss sie auch, das 
liegt in der Natur der Sache, denn es könnte ja tatsächlich ein 
Richtigungsänderung erfolgt sein, die Software kann das erst mal nicht 
entscheiden. Sie kann das erst abschließend entscheiden, wenn sich auch 
auf dem anderen Kanal was bewegt hat. Dann muß man halt ggf. die 
vorherige Fehlinterpretation als Richtungswechsel kompensieren, indem 
man zwei Schritte in der korrekten Richtung ausführt.

Das Problem ist nun: für eine Anwendung, die wirklich jeden Schritt 
nutzen will, führt das eben für jedes Prellen und jeden ESD-Störpuls zu 
der Folge vorwärts-ein Schritt zurück-zwei Schritte vor.

Es gibt (scheinbar) zwei Lösungen zur Abhilfe:
1) In der Anwendung nur die halbe Zählerauflösung verwenden. Dann 
wackelt nix mehr. Nachteil: die Auflösung wird halt halbiert.
2) Die Rückmeldung eines Umkehrschrittes an die Anwendung verzögern, bis 
er "committed" ist, also sich auch auf dem anderen Kanal was bewegt hat. 
Leider führt aber auch das genauso dazu, dass effektiv nur die halbe 
Auflösung nutzbar ist. Der Schritt ist zwar physisch schon passiert und 
auch registriert, kommt aber bei der Anwendung noch nicht an.
Effektiv sind also die beiden Lösungen von der Implementierung her 
durchaus verschieden, aber im Endergebnis equivalent.

Beide Ansätze ergeben bei einer kontinuierlichen Erhöhung oder 
Verringerung aus Anwendungssicht jedenfalls ein sehr viel gefälligeres 
Bild, aber halbieren halt effektiv auch die Auflösung.

Sprich: eine "perfekte" Lösung für volle Auflösung ist nur möglich, wenn 
Prellen und ESD schon vorher bekämpft werden (oder erst garnicht 
vorhanden sind). Bei einer nötigen Bekämpfung hat diese dann aber 
wiederum andere Nachteile durch die dann zwangsäufig zu verwendenen 
Zeitkonstanten.

[Uwe K. (ukhl)]

Ob S. schrieb:
> Uwe K. schrieb:
>
>> Versuche das mal, und berichte:
>>
>> Beitrag "Re: Drehgeber/Encoder 1-, 2- oder 4-schrittig"
>>
>> Das ist ideal für die Abtastung im höchster Auflösung. Oder einem
>> Umschalter auf dem Rastpunkt. Da zappelt dann nichts mehr.

>> Was man wissen muss: Dir geht ein Impuls verloren, wenn man rückwärts
>> dreht (nur bei der höchsten Auslösung). Der wird beim vorwärtsdrehen
>> wieder aufgeholt.
>
> Ganz genau das ist der Nachteil dieser Umkehr-Hysterese. Jede
> Fehlauslösung auf einem Kanal (egal ob durch ESD oder Kontaktprellen)
> sorgt für einen Schritt in die falsche Richtung...

In der höchsten Auflösung schon. Wenn man rückwärts dreht, ist der Wert 
um eins zu hoch. Beim vorwärts drehen, ist alles wieder gut. Das ist bei 
Handdrehgebern meist unproblematisch. Dafür flattert da nichts.

Das passiert aber nur in der höchsten Auflösung, und die ist hier nicht 
gefordert.

Bei der halben Auflösung, wie es hier gewünscht ist, funktioniert es 
ohne Probleme. Und es geht auch nichts verloren. Und flattern tut es 
auch nicht.

Erst ausprobieren, und dann schreiben.

[Uwe K. (ukhl)]

Daniel V. schrieb:

> Warum ist das Verhalten korrekt? (Oder verwende ich den Dekoder falsch?)

Das Verhalten habe ich auch festgestellt:

Ich versuche es mal grafisch darzustellen. Die halbe Sequenz:

Vorwärts:

Rastung  |       |       |       |       |
A       ---|___|___|---|---|___|___|---|---|
B       ---|---|___|___|---|---|___|___|---|
Peter          |       |       |       |
Uwe            |       |       |       |

Das ist identisch und sieht gut aus. Jetzt rückwärts:

Rastung  |       |       |       |       |
B       ---|---|___|___|---|---|___|___|---|
A       ---|___|___|---|---|___|___|---|---|
Peter      |       |       |       |
Uwe            |       |       |       |

Hier sieht man, dass bei Peter der Schritt schon beim ersten Impuls
gemacht wird. Idealerweise sollte es beim zweiten Impuls erfolgen. Damit
reduziert man die Wahrscheinlichkeit beim Drücken des Drehgebers weiter
zu drehen.

Ist ein Ausschnitt aus dem Link, und da ist auch die Lösung enthalten:

Beitrag "Re: Drehgeber/Encoder 1-, 2- oder 4-schrittig"

[Daniel V. (danielv2)]

Jobst M. schrieb:
> Wie wäre es mit einem Filter?
>
> Die Bewegung des Drehgebers landet irgendwann in einem Zähler.
> Den Wert dieses Zählers liest man (am besten direkt nachdem dieser neu
> gesetzt wurde) aus und führt dann folgendens aus:
> if (zähler != germerkter_wert) {
>     ausgabe = (zähler + gemerkter_wert)>>1;
>     gemerkter_wert = zähler;
> }

("Filter" sind eigentlich ein neues Thema.)
Ich habe den Filter mal getestet:
Der Effekt ist gut, aber leider hinkt die Position beim Richtungswechsel 
hinterher - bei mir zumindest. Es gibt quasi einen Leerschritt, was in 
Regel nicht akzeptabel ist.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Daniel V. schrieb:
> Der Effekt ist gut, aber leider hinkt die Position beim Richtungswechsel
> hinterher
Das ist der Sinn dieses Filters: es soll eben gerade **nicht** auf jeden 
einzelnen "Umkehrschritt" reagiert werden. Und dabei ist es der Software 
dann egal, ob dieser Schritt vom lausigen Geber oder von einer 
Bedienereingabe kommt. Sie kann das ja auch gar nicht unterscheiden.

> Es gibt quasi einen Leerschritt, was in Regel nicht akzeptabel ist.
Gerade bei Geräten mit Drehgeberbedienung ist die absolute Position des 
Eingsberades völlig irrelevant. Das geht soweit, dass man sogar mit 
Dynamik arbeiten und bei schnell(er)em Drehen mehr als 1 Schritt pro 
Impuls machen kann. Dieses Verhalten ist z.B. auch von Computermäusen 
bekannt.

- 
https://www.lothar-miller.de/s9y/archives/71-Drehgeberauswertung-mit-Beschleunigung.html

[Daniel V. (danielv2)]

Lothar M. schrieb:
> Gerade bei Geräten mit Drehgeberbedienung ist die absolute Position des
> Eingsberades völlig irrelevant. Das geht soweit, dass man sogar mit
> Dynamik arbeiten und bei schnell(er)em Drehen mehr als 1 Schritt pro
> Impuls machen kann. Dieses Verhalten ist z.B. auch von Computermäusen
> bekannt.

Bei schnellem Drehen sehe ich das auch so. Bei langsamen Drehen sehe ich 
das anders. Ich möchte ohne auf ein Feedback warten zu müssen 
gezielt/blind eine Schrittzahl eingeben können.

[Daniel V. (danielv2)]

Ob S. schrieb:
> Das Problem ist nun: für eine Anwendung, die wirklich jeden Schritt
> nutzen will, führt das eben für jedes Prellen und jeden ESD-Störpuls zu
> der Folge vorwärts-ein Schritt zurück-zwei Schritte vor.

Die Anwendung will das hier aber nicht. Hier geht es um einen Geber mit 
vier Zuständen, bei dem es alle zwei Zustandsänderungen eine 
Positionsänderung gibt.

[Daniel V. (danielv2)]

Uwe K. schrieb:
> Daniel V. schrieb:
>> Egal, ich beuge mich mal der Mehrheit. Ich gebe auf. Danke.
>
> Nicht aufgeben.
>
> Versuche das mal, und berichte:
>
> Beitrag "Re: Drehgeber/Encoder 1-, 2- oder 4-schrittig"
>
> Das ist ideal für die Abtastung im höchster Auflösung. Oder einem
> Umschalter auf dem Rastpunkt. Da zappelt dann nichts mehr.
>
> Entscheident ist die Funktion "encode".
>
> Bitte erst ausprobieren, dann über das Ergenis berichten.
>
> Bin gespannt...

Im Anhang das Ergebnis: Es zeigt die Impulse von sechs Dekodern bei 
echten Messwerten.

Messwerte:
Die Messwerte stammen von einer zwei Jahre alten Maus. Der Drehgeber 
liefert ein schlechtes Signal und die Maus sprang bereits im ersten 
Jahr. Zum Teil liegt das an der Firmware, da diese Geschwindigkeiten von 
unter 250µs/Schritt zulässt, obwohl Werte unter 2000 µs/Schritt 
praktisch nicht erreichbar sind.

Man sieht fünf Zeilen mit Messwerten. Bei den ersten beiden Zeilen wurde 
das Mausrad langsam bis normal gedreht. Bei der dritten Zeile sehr 
schnell. Bei den letzten beiden Zeilen wurde die Handfläche "mit Anlauf" 
schnellstmöglich über das Rad bewegt.

Für mich wichtig beim  Mausrad ist:
1. Die Drehrichtung sollte immer stimmen.
2. Beim langsamen Drehen sollte die Position immer stimmen.

[Harald K. (kirnbichler)]

Daniel V. schrieb:
> Bei langsamen Drehen sehe ich
> das anders. Ich möchte ohne auf ein Feedback warten zu müssen
> gezielt/blind eine Schrittzahl eingeben können.

Das ist bei Geräten, bei denen man z.B. ein Menü mit einem Drehgeber 
bedient, wichtig. Da möchte man präzise einen Schritt vor oder 
zurückgehen können, und diese Schritte müssen mit den Rasten zu tun 
haben.

[Daniel V. (danielv2)]

Uwe K. schrieb:
> Bitte erst ausprobieren, dann über das Ergenis berichten.
>
> Bin gespannt...

..ganz vergessen.
Meine Messdaten reichen aus um 645 solcher Screenshots zu erstellen. 
Normalerweise werte ich Daten automatisch aus. Hier habe ich das mit dem 
Auge gemacht. Auf den ersten Blick erreicht er den vierten Platz. Wenn 
man die Einfachheit berücksichtigt, dann sogar Platz 1.

[Uwe K. (ukhl)]

Daniel V. schrieb:

>... Auf den ersten Blick erreicht er den vierten Platz. Wenn
> man die Einfachheit berücksichtigt, dann sogar Platz 1.

Das ist doch garnicht so schlecht.

Diese Auswertung im Grenzbereich, finde ich sehr interessant.
Wir sind uns auch einig, dass man den Drehgeber eindeutig als "Defect" 
bezeichnen darf.

Mein Algorithmus zeigt die wenigsten Fehlimpulse, wenn ich das richtig 
sehe. Problematisch, für deine Anforderung, sind die gelegendlich 
auftretenden rückwärts Schritte.

Folgendes könnte man versuchen:

Man lässt einen Richtungswechsel erst nach eine Pause von 50ms zu.

Dann sollte es bei schneller Betätigung keine Richtungswechsel geben. 
Das dabei immernoch zu viele Impulse erzeugt werden, ist bekannt.

Ich erwarte auch keine Probleme beim langsamen Drehen.

Bin gespannt auf das Ergebnis.

[Daniel V. (danielv2)]

Im Anhang die Signalverläufe an den Kontakten bei unterschiedlichen 
Radgeschwindigkeiten.

Vermutlich (alte Messungen) war am ersten Kanal ein 1M-Pullup mit 
1:10-Tastkopf und am zweiten Kanal ein STM32-Pullup (40k - ?) mit 
1:1-Tastkopf.

[Uwe K. (ukhl)]

Das sieht sehr schlimm aus.

Ein Tiefpass an den Eingängen könnte sich das sehr hilfreich erweisen.

[Daniel V. (danielv2)]

Uwe K. schrieb:
> Wir sind uns auch einig, dass man den Drehgeber eindeutig als "Defect"
> bezeichnen darf.
Da bin ich mir nicht sicher. Die "Menge" der Störungen hängt extrem von 
der Drehgeschwindigkeit ab. Bei normaler Geschwindigkeit ist alles Ok. 
Vielleicht haben mehr Geber ein solches Signal als man glaubt. Außerdem 
wäre zumindest dieser Geber auch bei Extremgeschwindigkeit noch 
verwendbar, wenn der Dekoder robuster wäre.
(Beitrag "Re: Handbetriebenen Drehgeber ohne Timer auswerten")

Uwe K. schrieb:
> Mein Algorithmus zeigt die wenigsten Fehlimpulse, wenn ich das richtig
> sehe. Problematisch, für deine Anforderung, sind die gelegendlich
> auftretenden rückwärts Schritte.
Nee, es ist der erste Dekoder ("Spezialdekoder") mit den wenigsten 
Fehlimpulsen.

Uwe K. schrieb:
> Das sieht sehr schlimm aus.
>
> Ein Tiefpass an den Eingängen könnte sich das sehr hilfreich erweisen.
Ein spezieller Tiefpass wäre besser. Das liegt daran, dass der offene 
Kontaktzustand immer korrekt vom Geber zurückgegeben wird und nur der 
geschlossene Kontakt "manchmal" fehlerhaft als offen zurückgegeben wird.
Ein normaler Filter würde die Kontaktzeiten zu sehr verfälschen.

[Veit D. (devil-elec)]

Hallo,

dann muss Daniel etwas Geld in die Hand nehmen und einen optischen oder 
magnetischen Drehencoder verwenden, der nicht prellt. Dann hat er seine 
hohen Anforderungen erfüllt. Übrigens ist der Verweis auf eine 
Computermaus hier nicht passend, diese verwenden optischen Abtastung vom 
Drehrad.

[Daniel V. (danielv2)]

Veit D. schrieb:
> Übrigens ist der Verweis auf eine
> Computermaus hier nicht passend, diese verwenden optischen Abtastung vom
> Drehrad.

Irrtum. Dieses Signal kommt von einer Cherry-Maus.

[Uwe K. (ukhl)]

Daniel V. schrieb:

> Nee, es ist der erste Dekoder ("Spezialdekoder") mit den wenigsten
> Fehlimpulsen.

Mit Fehlimpulsen sind die vorwärts Schritte gemeint, die nicht wirklich 
da sind.

Und was ist mit dem filtern der Rückwärtsschritte, wenn man einen 
Richtungswechsel erst nach eine Pause von 50ms zulässt?

[Harald K. (kirnbichler)]

Daniel V. schrieb:
> Irrtum. Dieses Signal kommt von einer Cherry-Maus.

Auch viele andere Maushersteller verwende für das Scrollrad einen 
mechanischen Encoder.

Tatsächlich gab es sogar damals(tm) Kugelmäuse, deren Kugelbewegung 
ebenfalls mechanisch abgetastet wurde.

Das war beispielsweise bei der Microsoft InPort-Maus der Fall, in der 
Maus selbst war keinerlei Elektronik untergebracht, alle Taster/Encoder 
wurden an eine PC-Steckkarte geführt und erst dort ausgewertet.

Anschlussbelegung und Bild der Maus hier: 
https://en.wikipedia.org/wiki/Bus_mouse

Semi-OT
Fundstück auf der Seite:
https://www.waitingforfriday.com/?p=827

Das macht aus einer USB-Maus zwei Quadraturencoder ...

[Daniel V. (danielv2)]

Ich habe bei Cherry - diesmal vor dem Kauf - für eine andere teuerere 
Maus nachgefragt, ob die auch mechanisch abgenommen wird. -> "Ja".

[Norbert (der_norbert)]

Daniel V. schrieb:
> Ich habe bei Cherry - diesmal vor dem Kauf - für eine andere
> teuerere
> Maus nachgefragt, ob die auch mechanisch abgenommen wird. -> "Ja".

Hab' 'ne einfache Cherry JF-T03, vierter oder fünfter Links-Switch, 
zweiter Rechts-Switch, Mausrad-Drehgeber immer noch Original. Und das 
(mechanische) Mausrad hat sicherlich mittlerweile die Mille Miglia 
zurück gelegt.

[Daniel V. (danielv2)]

Uwe K. schrieb:
> Daniel V. schrieb:
>
>> Nee, es ist der erste Dekoder ("Spezialdekoder") mit den wenigsten
>> Fehlimpulsen.
>
> Mit Fehlimpulsen sind die vorwärts Schritte gemeint, die nicht wirklich
> da sind.

Was die Drehrichtung angeht, hat nur der erste Dekoder keinen einzigen 
Fehlimpuls. Wenn man nicht zu schnell dreht, dann gibt es außerdem dort 
auch keine Positionsfehler. Nur unten rechts fehlen ein paar Impulse, 
die Richtung wurde (verständlicherweise) nicht erkannt.

Uwe K. schrieb:
> Und was ist mit dem filtern der Rückwärtsschritte, wenn man einen
> Richtungswechsel erst nach eine Pause von 50ms zulässt?
Ein Filter für den Richtungswechsel ist nicht trivial. Bei einfacher 
Umsetzung sieht man vor allem einen unangenehmen Nebeneffekt. Wenn 
beispielsweise der erste Impuls nach einer Pause falsch erkannt wird, 
dann sind alle weiteren Impulse falsch. Unter dem Strich macht es alles 
noch schlimmer. Das war zumindest meine Erfahrung.

[Veit D. (devil-elec)]

Hallo Daniel,

warum möchtest du in deinem speziellen Fall keinen optischen oder 
magnetischen Drehencoder verwenden? Das erschlägt alle deine 
Anforderungen.

[Daniel V. (danielv2)]

Es geht hier um den Geber in einer Maus. Normalerweise wirft man die 
Maus weg, wenn der Geber nicht mehr anständig funktioniert. Den Geber 
auszutauschen wäre möglich, wenn man anspruchslos ist (Lautstärke, 
Taktilität) oder kein Problem mit Trial-Error-Käufen hat - trifft auf 
mich nicht zu. Aus reiner Spielerei würde ich vielleicht zwischen Geber 
und Hauptplatine einen µC als "Hörgerät" einbauen. Einen anderen 
Gebertyp einzubauen ginge mir viel zu weit. Geht das überhaupt?

[Uwe K. (ukhl)]

Hier mal ein Ausschnitt aus deiner Auswertung.

Der blaue Bereich ist kein prellen, sondern Kontakt Fehler durch 
Verschmutzung. Hier sollten beide Schleifer einen Kontakt haben. Es 
sollte idealerweise nichts passieren, da es vorher einen sauberen 
Kontakt gab. Offene Kontakte prellen nicht.

Anzahl der Fehllesungen bei deinem Favoriten: 17

Anzahl der Fehllesungen bei meinem Algo: 4

Muss jeder für sich selbst entscheiden, wer zuverlässiger arbeitet.

Ich muss leider sagen, dass dieser Drehgeber so stark verschmutz ist, 
dass man ihn nicht mehr gebrauchen kann. Es gleicht eher einem 
Zufallsgenerator.

[Teo D. (teoderix)]

Uwe K. schrieb:
> Es gleicht eher einem
> Zufallsgenerator.

:DDD

[Daniel V. (danielv2)]

Uwe K. schrieb:
> Der blaue Bereich ist kein prellen, sondern Kontakt Fehler durch
> Verschmutzung. Hier sollten beide Schleifer einen Kontakt haben.
Nö. Die allermeisten Zustände wurden korrekt erkannt. Der blaue Bereich 
ist keine Störung, es sind lediglich Störungen enthalten. Das kann man 
als Mensch doch klar erkennen. Das meine ich wirklich so.

[Daniel V. (danielv2)]

Nicht vergessen, bei den letzten beiden Meßdatenzeilen wurde die Hand 
extrem schnell über das Rad bewegt. Das ist absolut praxisfern. Die 
mittlere Datenzeile zeigt sehr schnelle aber vorkommende 
Radgeschwindigeiten.

[Daniel V. (danielv2)]

Die Ursache für die Störungen könnten Schwingungen (->Kontaktverlust) 
durch das Reiben sein. Je rauher/abgenutzter die Oberfläche, desto 
schlimmer.

[Uwe K. (ukhl)]

Wenn nur der blaue Bereich eine Drehbewegung darstellt. Und davor und 
danach eine Drehpause.

Dann hast Du das Geschwindigkeits-Limit überschritten. Ein Kontakt 
sollte immer ausgeprellt haben, bevor der nächste aktiv wird. Das sind 
etwa 3ms.

Runter mit der Abtastrate und entspannter kurbeln. Mehr speed geht nur 
optisch. Kein Algo kann ein Prellen an beiden Kontakten sinnvoll 
auswerten.

[Daniel V. (danielv2)]

Geschwindigkeiten wie in der mittleren Zeile kommen schon vor. Dein 
Dekoder würde das nur erlauben (ohne Impulse zu verschlucken), wenn die 
Routine häufiger aufgerufen werden würde. Dann würde aber die 
Fehlerqoute steigen.

[Daniel V. (danielv2)]

Uwe K. schrieb:
> Kein Algo kann ein Prellen an beiden Kontakten sinnvoll
> auswerten.

Naja, das tritt nur bei so hohen Drehzahlen auf, bei denen die exakte 
Impulszahl nicht mehr wichtig ist und die grobe Bestimmung der Impulse 
klappt doch wie man am Screenshot sieht ziemlich gut.

[Uwe K. (ukhl)]

Problem gelöst.

[Veit D. (devil-elec)]

Hallo,

das es sich um eine Computermaus direkt handelt hättest du aber gleich 
von Anfang an sagen können. Dann hätte das Rätselraten nicht sein 
müssen. Ganz ehrlich. Weitermachen...

[Daniel V. (danielv2)]

Das eigentliche Thema ist doch schon lange durch: 
Beitrag "Re: Drehgeber-Dekoder arbeitet unerwartet").

Danach ging es um was anderes. Das hatte ich auch geschrieben: 
Beitrag "Re: Drehgeber-Dekoder arbeitet unerwartet"

Im Thread sind zwei Themen drin -> Rätselraten.

[Mi N. (msx)]

Daniel V. schrieb:
> Bei normaler Geschwindigkeit ist alles Ok.
> Vielleicht haben mehr Geber ein solches Signal als man glaubt. Außerdem
> wäre zumindest dieser Geber auch bei Extremgeschwindigkeit noch
> verwendbar, wenn der Dekoder robuster wäre.
> (Beitrag "Re: Handbetriebenen Drehgeber ohne Timer auswerten")

Ich habe hier nur mit halbem Ohr mitgelesen. Weiter unten zu Deinem Link 
ist ja auch die RC-gefilterte Kurve mit aktiver Hysterese zu sehen.
Wenn Du nicht scheust, zwei Widerstände und zwei Kondensatoren zu 
ergänzen, könnte ich Dir das zugehörige Programm schicken - für Arduino 
oder AVR-Studio.

[Daniel V. (danielv2)]

Der Einbau ist kein Problem, die zusätzlichen Bauteile verändern aber 
das Kontaktsignal. Für andere Algorithmen ist es damit nicht mehr 
verwendbar, was aber für einen objektiven Vergleich nötig wäre. Ein 
subjektiver Vergleich geht praktisch auch nicht, da man über einen sehr 
langen Zeitraum drehen müsste, um Verbesserungen gegenüber dem 
"Spezialdekoder" 
(https://www.mikrocontroller.net/attachment/688014/Gegenueberstellung.png) 
zuverlässig wahrnehmen zu können.

[Ob S. (Firma: 1984now) (observer)]

Uwe K. schrieb:

> Das passiert aber nur in der höchsten Auflösung, und die ist hier nicht
> gefordert.

Ja.

> Bei der halben Auflösung, wie es hier gewünscht ist, funktioniert es
> ohne Probleme. Und es geht auch nichts verloren. Und flattern tut es
> auch nicht.
>
> Erst ausprobieren, und dann schreiben.

Die Tatsache, das ich eine entsprechende Lösung schon vor Jahren hier 
gepostet hatte, sollte klarstellen, dass ich das bereits umfassend 
ausprobiert habe.

Spätestens aber die beiden Lösungsvorschläge in meinem Posting sollten 
das auch ohne umfassende Geschichtskenntnisse klargestellt haben...

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:

> Das ist bei Geräten, bei denen man z.B. ein Menü mit einem Drehgeber
> bedient, wichtig. Da möchte man präzise einen Schritt vor oder
> zurückgehen können, und diese Schritte müssen mit den Rasten zu tun
> haben.

Tja, das Problem ist halt: die Software weiss nichts von irgendwelchen 
(rein mechanischen) Rasten und hat auch keinerlei Möglichkeit, zu 
ermitteln, ob die Mechanik jetzt gerade eingerastet ist oder nicht.

Alles, was man der Software mitteilen kann, ist die gewünschte 
"Untersetzung" ihrer elektrischen Realität. Also effektiv: wieviele LSB 
des Zählerstands sie wegwerfen darf, bevor sie das Ergebnis der Nutzung 
zuführt.

[Uwe K. (ukhl)]

Ob S. schrieb:
> Uwe K. schrieb:

>> Erst ausprobieren, und dann schreiben.
>
> Die Tatsache, das ich eine entsprechende Lösung schon vor Jahren hier
> gepostet hatte, sollte klarstellen, dass ich das bereits umfassend
> ausprobiert habe.

War kein Vorwurf. Wollte nur theoretische Argumente vermeiden, die 
nichts mit der Praxis zu tun haben.

Das eine Abtastung bei der höchsten Auflösung eigentlich keinen Sinn 
macht, ist mir jetzt auch bewusst geworden. Also besser nicht. Da es 
auch einen Drehgeber benötigt, der eine gute Phasengenauigkeit 
bereitstellt. Und dann doch lieber was Optisches.

Das Ergebnis interessiert mich sehr. Ist irgendetwas schlecht an meinem 
Algo ? Für konstruktive Argumente bin ich sehr offen.

[Daniel V. (danielv2)]

Uwe K. schrieb:
> Das Ergebnis interessiert mich sehr. Ist irgendetwas schlecht an meinem
> Algo ? Für konstruktive Argumente bin ich sehr offen.

Der Dekoder erwartet eine exakte Zustandsfolge für einen Schrittimpuls. 
Jede Störung in Abfolge führt dazu, dass kein Schrittimpuls erzeugt 
wird. Auf diese Weise treten Schrittimpulse mit falscher Richtung 
seltener auf, dafür fehlen Schrittimpulse für tatsächlich vorgekommene 
Schritte. Nur wenn das nicht vermeidbar wäre, dann wäre der Dekoder 
sehr gut. (Für die spezielle Anforderung "besser keine als falsche 
Impulse" ist er sehr gut.)

[Uwe K. (ukhl)]

Daniel V. schrieb:

> Der Dekoder erwartet eine exakte Zustandsfolge für einen Schrittimpuls.
> Jede Störung in Abfolge führt dazu, dass kein Schrittimpuls erzeugt
> wird.

Das ist richtig. Eine Störung auf einer Leitung wird dadurch gefiltert. 
Folgt dann ein tatsächlicher Schritt, ist es wieder eine komplette 
Sequenz. Tatsächliche Schritte gehen dann nicht verloren.

Problematisch ist eine Störung auf der zweiten Leitung, wenn die erste 
noch im Störbereich ist. Das erzeugt einen tatsächlichen Schritt, der 
nicht da ist. Dann haben wir zu viele Impulse.

Wenn beide Leitungen gleichzeitig umschalten, geht tatsächlich ein 
Impuls verloren. Bei der Annahme, dass sich die Richtung nicht geändert 
hat, könnte man den fehlenden Impuls rekonstruieren. Ich vermute, dass 
es der Schritt ist, den du vermisst. Es ist aber auch ein Indikator, 
dass man zu schnell gedreht hat. Und es erklärt das Verhalten des 
"Spezialdecoders".

[Daniel V. (danielv2)]

Der Grund ist ein anderer (sorry): Durch einen Programmfehler lieferte 
der "Dekoder von Peter Dannenegger - modifiziert" (siehe 
https://www.mikrocontroller.net/attachment/688014/Gegenueberstellung.png) 
wenn die Richtung widersprüchlich ist, einen Rückwärts-Impuls. Deswegen 
sah es für mich so aus, als ob dein Dekoder zu viele Impulse 
verschluckt. Tatsächlich liefern, solange beim Übergang von Raste zu 
Raste nur auf einem Kontakt Störungen auftreten, beide identische 
Werte. Falls aber beim Übergang mindestens einmalig eine gleichzeitige 
Änderung auf beiden Kontakten stattfand, dann gibt es Unterschiede. Es 
gibt drei Möglichkeiten:
1. immer einen Impuls ausgeben
Das macht (bzw. hätte er machen sollen) der "Dekoder von Peter 
Dannenegger - modifiziert".
2. nur dann, wenn das "nicht zum Schluss" passiert
Das macht dein Dekoder
3. niemals einen Impuls ausgeben
Diese Variante habe ich getestet und die liefert noch seltener eine 
falsche Richtung :-), dafür gehen noch mehr Impulse verloren. :-(

[Uwe K. (ukhl)]

Wenn sich zwei Leitungen gleichzeitig ändern, liegt definitiv ein Fehler 
vor. Das gibt es im Gray Code nicht.

Ich sehe nur zwei Möglichkeiten.

1. Es wird ignoriert, da es fehlerhaft ist.

2. Der fehlende Schritt wird rekonstruiert. Das ist möglich, wenn man 
annimmt, dass sich die Richtung nicht geändert hat und diese auch 
bekannt ist.

Wirklich gleichzeitige Störungen auf beiden Kanälen sind schon sehr 
unwahrscheinlich. Beim zu schnellen Drehen zeigt sich der gleiche 
Fehler.

Ob diese Form der Fehlerkorrektur zu einem besseren Ergebnis führt, muss 
jeder für sich entscheiden.