Drehgeber im BCR

Hallo Andreas,

ich habe das auch schon versucht mit Timer zu entprellen, mit nur mässigen Erfolg. Die beste Lösung ist die HW-Entprellung, man darf nur nicht den Kondensator direkt an den Drehgeber montieren. Der Kondensator wird über PIN/PORTB/10k_intern aufgeladen (Kontakt offen) und anschliessend kurzgeschlossen (Kontakt geschlossen). Diesen Kurzschlussstrom muss man mit einem Widerstand 100 Ohm reduzieren, sonst hält der Drehgeber nicht sehr lange. Ich mache das jetzt immer so wie in der PDF zu sehen (Kombination 100 Ohm/100nF). Das funktioniert bestens. Im Datenblatt ist auch ein Schaltbild für die Entprellung zu sehen. Die Widerstände sind aber für den BCR zu hochohmig.

HPSDR_Remote.pdf

Meine Lösung funktioniert auch mit der Schrittverdopplung sehr gut.

vy 73 Andreas, DL4JAL

Hallo die Runde

Ich kann hier noch meine Erfahrungen aus einem Kalibrierlabor kundtun.

Wir habe sehr viele Gerät wie z.B. 34970 von HP, Agilent, Keysight oder wie immer die in dieser Sekunde gerade heissen, sowie etliche KO's von allen namhaften Herstellern, welche genau dieses Problem haben.

Wir kennen nur eine nicht so langanhaltende Lösung: Drehgeber öffnen, Kontakte gaaaaanz vorsichtig reinigen wieder zumachen. Hält eine Weile aber auch nicht ewig.

Dann noch die länger anhaltende: Austauschen was aber nicht immer so einfach geht.

Wirklich lange halten nur die optischen Drehgeber.

Der im BCR ist qualitativ sicher gut und kostet ja nicht wirklich Geld. Also würd ich den kompromisslos austauschen wie das jetzt ja auch gemacht wurde.

vy 73 Mark

Hallo Miteinader,

hallo Andreas,

ich habe den Artikel mal heraus gesucht zur Drehencoder im Poll-Modus per Timerinterrupt.

Alle 1 kHz oder wie beim Jörn seinem Spezial Encoder auch mit 3 kHz

Der original Code von Peter Dannegger (peda) ist dieser:

# https://www.mikrocontroller.net/topic/drehgeber-auslesen#new

# https://www.mikrocontroller.net/topic/112603#new

Alles in einem Artikel gibt es hier:

# https://www.mikrocontroller.ne…B6sung:_Beispielcode_in_C

Unter LunaAVR ist dieses Basiscode im RotaryEncoder.interface mit Hilfe von AVR Assembler implementiert worden.

Da der AVR AssemblercCode effizient ist, kann man über MultiRotaryEncoder.interface auch gleich 4 Drehgeber auswerten.

Danke für die Beiträge!

Ich hab inzwischen ein bisschen herumgesucht. Hier ein paar Rechercheergebnisse:

Im BCR gehen die beiden Drehreglerdrähte laut Manual an die Pins 36 und 37 des PIC16F877PLCC. Das sind die Anschlüsse RB0 und RB1.

RB0 ist ein flankengesteuerter Interrupt. Irgendwo auf dem Weg zwischen Pin und Interruptlogik ist ein Schmitt-Trigger. Über die Größe der Hysterese sagt das PIC-Datenblatt leider nichts, aber es gibt sie. Dagegen ist RB1 einfach nur ein Input-Pin mit einem TTL-Input, ohne Schmitt-Trigger.

Das Datenblatt des PIC sagt außerdem, dass die (im BCR benutzte) interne Pull-Up Stromquellen sind, die irgendwas zwischen 50µA und 400µA liefert, typisch 250µA.

Der Drehgeber von meinem BCR hat 30 Rastungen pro Drehung. Beim Hersteller Alps finde ich auf der Webseite derzeit vier Drehregler mit 30 Rastungen ("Detents"). Bei jedem dieser vier steht im Datenblatt, dass man den Regler mit mindestens 1 mA Durchflussstrom betreiben soll. Wir betreiben nur mit einem Bruchteil davon.

Bei uns im OV war im Zusammenhang mit Relaiskontakten gelegentlich von "alten Hasen" zu hören, dass man die nicht mit zu wenig Strom betreiben soll. Im Laufe der Zeit hören die Relais sonst auf, sauber zu funktionieren. Der Strom "putzt" die Kontakte, wenn man ihn nur lässt. Auch bei Morsetasten hört man gelegentlich den Rat, genug Strom drüber laufen zu lassen. Ob es bei Drehgebern einen ähnlichen Zusammenhang gibt? Wenn ja, könnte ein Widerstand von je 4,7 kΩ nach +5V ein Teil der Lösung sein...

Und alle vier Datenblätter warnen einstimmig davor, dass man die ersten drei Millisekunden nach der Schaltflanke mit Prellen rechnen muss. Das verstehe ich schon so, dass der Hersteller eine Timer-gesteuerte Software-Entprellung empfiehlt.

Andreas - welche schlechten Erfahrungen hast Du damit gemacht? Es ist lange her... Aber erinnerst Du Dich noch an Einzelheiten?

Ich habe schon überlege, mir einen neuen Drehregler zu besorgen und den mit größeren 4,7 kΩ Widerständen nach +5V einzubauen. Aber wenn ich dann mit einem Kondensator für 3 ms Ruhe erzwingen wollen würde statt mit Software, bräuchte ich einen Kondensator bei 3 µF. Da habe ich dann wieder Angst vor zu viel Kurzsschlussstrom. Bei den 250µA typischen Strom aus dem PIC bräuchte man übrigens über den Daumen gepeilt immer noch einen Kondensator von 500 nF, wenn der 3 ms brauchen soll, um sich auf nicht mehr als 1,5 V aufzuladen.

Dass unsere BCRs überhaupt so gut funktionieren, wie sie es tun, spricht wirklich für die Qualität der Drehregler! - Die wir komplett außerhalb dessen betreiben, was das Datenblatt rät.

Es grüßt (etwas ratlos, was nun tun)

Andreas, DJ3EI

Alle Schalter prellen, der eine etwas mehr und der andere etwas weniger...

Der Vorschlag von Uwe mit der Software-Entprellung ist zielführend und sehr ausgereift. Ich wage mal zu behaupten, dass er narrensicher ist und damit alle Probleme der Vergangenheit angehören sollten, die mit Prellen zu tun haben. Der Nachteil ist, dass man sich mit dem Algorithmus beschäftigen muss

Hallo OMs,

ich möchte die Drehgeber nicht im Polling betreiben. Ich muss in der Hauptscheife zu viel erledigen, da funktioniert eine flüssige Bedienung nur mit Interrupt. An der SW kann ich keine Änderungen mehr machen, da ich die HW BCR nicht mehr habe. Dann kommt noch dazu, dass der PIC etwas älter ist (ROM-Bänke müssen umgeschaltet werden, usw). Warum probiert nicht einfach meine Notlösung mit den 100 Ohm in beide Verbindungen Drehgeber <--> RB0, RB1 und direkt am PIC RB0 und RB1 100nF gegen GND. Das funktioniert gut. Die echte HW-Lösung hat DL2AVH, Helmut in seinem neuen Fuchjagt-RX genau nach Datenblatt realisiert. Das funktioniert auch 100-prozentig. Im Anhang habe ich mal die PDF dazu. Seite 1 oben rechts. Die SW für den FjRX habe auch geschieben. Deshalb kann ich sagen, dass es gut funktioniert. Im Bild sind beide Drehgeber zu sehen.

vy 73 Andreas, DL4JAL

FjRx.pdf

Zitat von dl4jal

Hallo OMs,

ich möchte die Drehgeber nicht im Polling betreiben. Ich muss in der Hauptscheife zu viel erledigen, da funktioniert eine flüssige Bedienung nur mit Interrupt.

Moin, naja, dass ist ja wohl eher ein Problem des Konzeptes. Das Prellen löst ja unendlich viele Interrupts aus, die dann entsprechend ausgewertet werden müssen.

Grundsätzlich gehe ich wie folgt vor.

- Wertige Encoder verwenden. Die Teile für zweimarkfuffzich funktionieren. Aber es kommt der Tag, wo die mechanisch auf sind. Daher optische oder mit Hal-Sensoren. Kosten, haben aber eine tolle Haptik und halten ewig. im übrigen scheinen die mechanischen im Laufe der Zeit auch ihr Prellverhalten zu ändern, so dass eine Hardwareentprellung nicht immer wirken wird.

- Programmierung bisher in Assembler. AVR, 8051. Steige gerade auf STM32 und C um.

- Zwei Encoder rufe ich inklusive der Schalter 1000x pro Sekunde ab. Da bekommt man dann auch eine ordentliche Softwareentprellung. Man kann die Encoder derart schnell drehen, wie es von Menschenhand nicht möglich ist (Akkuschrauber) und die Auswertung funktioniert ohne Sprünge.

73, Holger

Hallo OMs,

und ich bleibe dabei. Wird am VFO-Knopf gedreht muss sich sofort die Frequenz ändern. Das geht nur mit Interrupt, ohne dass man das Gefühl hat, hier hackt etwas. Wenn jemand das besser bringt, kann er sich mit Peter in Verbindung setzen und die SW neu schreiben. Dann kommt noch hinzu das zum Zeitpunkt der Entwicklung der SW (2004) die Erkenntnisse und Schwierigkeiten mit mechanischen Drehgebern mir noch nicht so bekannt waren. Ich hatte bisher nur optische Drehgeber verwendet.

Dieses "Tot disktutieren" nervt mich. Ich werde nicht mehr antworten.

vy 73 Andreas

Jede Lösung hat ihre Vor und Nachteile und bei jedem Projekt muss man sich neu entscheiden. Bestehende Geräte lassen sich meist nicht mit der sehr mächtigen (und genialen) Softwareentprellung, wie Uwe sich vorgeschlagen hat, nachrüsten da man oft keinen Zugang zur Software hat. Peter Dannegger hat mit seiner trickreichen Routine enormes geleistet. Da steckt einen Menge "Gehirnschmalz" drin und sie benötigt nur extrem wenig Rechenpower und Kapazität. Wenn man diese Routine für sich aufgearbeitet hat (was etwas dauert), kann sie bei jedem neuen Projekt wieder neu verwenden und muss nie wieder über Probleme mit Drehgebern und deren Altersproblemen nachdenken.

Ich habe es bisher sehr interessant gefunden, wie ihr bei euren Drehgebern die Probleme kreativ gelöst habt.

Zitat von dl4jal

Dieses "Tot disktutieren" nervt mich. Ich werde nicht mehr antworten.

vy 73 Andreas

Moin,

das finde ich nicht ok. Wenn hier Behauptungen aufgestellt werden, die leicht widerlegbar sind, dann hat das nichts mit "Tot diskutieren" zu tun. Und die Behauptung, dass man Drehencoder für einen VFO nur per Interrupt auslesen kann, ist nicht korrekt.

73, Holger DL9HDA

Hallo Holger

Ich finde Deine letzte Antwort und den Umgang mit Andreas, DL4JAL schade. Ich kann persönlich "nachvollziehen", weshalb er den Ausdruck "totdiskutieren" verwendet. Ich kann auch nicht herauslesen, dass er "grundsätzlich und für alle Fälle gültig" geschrieben hat, dass ein Polling nicht möglich ist. Die ganze Diskussion steht im Zusammenhang mit einem konkreten (alten) PIC mit einer konkreten (alten) Soft- und Hardware-Umgebung. Und da schreibt er vorher sogar: (ZITAT!!) "ich möchte die Drehgeber nicht im Polling betreiben." (ENDE ZITAT!!)

Also er MÖCHTE es nicht (weil......)

Und darauf antwortest Du dann: "...das ist ... ein Problem des Konzeptes..."

Willst Du damit allen Ernstes ein vor 15 Jahren festgelegtes Konzept kritisieren und eine Überarbeitung einfordern ??? So kommt das bei mir zumindest an.

Für mich ist wichtig, dass wir uns innerhalb unserer QRP-Gemeinschaft mit einem grundsätzlichen Wohlwollen begegnen. Ich ziehe vor allen Entwicklern unserer QRP-Gemeinschaft innerlich den Hut für ihr Engagement. Ohne sie könnte ein nennenswerter Teil unserer Gemeinschaft wohl nicht am schönen Bereich Selbstbau teilhaben. Von daher bitte ich Dich, in Zukunft mit öffentlicher Kritik vorsichtig umzugehen. Ich kann nämlich nachvollziehen, dass man da irgendwann die Lust verliert. Und die Reaktion "ich werde nicht mehr antworten" ist da ja noch sehr milde.

Martin

Hallo Martin,

nun schreibe ich doch noch einmal. Du hast es genau auf den Punkt gebracht. Der Block heist "Drehgeber im BCR". Das bedeutet für mich ein Lösung aufzuzeigen, wie man am einfachsten das Prellen des mechanischen Drehgebers im BCR verhindern kann und dabei aber auch darauf zu achten, dass der Drehgeber nicht zu schnell verschleist. Und ich denke das kann einfach mit 100Ohm + 100nF als Tiefpass realisiert werden und der BCR arbeitet wieder korrekt mit dem Drehgeber. Ich denke Peter hat ziemlich viele BCRs verkauft und diese kleine HW-Korrektur hilft allen Nutzern des BCR.

Ich schaue mir auf alle Fälle den Assemblercode an (Links von DC5PI). Eventuell kann ich das für die Zukunft verwenden. Vielen Dank für die Hinweise.

vy 73 Andreas, DL4JAL

- ich war wütend und wollte eigentlich mehr schreiben, aber Andreas und Martin haben es auf den Punkt gebracht!!!

Ich lebe mit dem "Drehgeber im BCR", es ist der damaligen Zeit geschuldet und eine heutige Entwicklung würde anders aussehen.

Warum also sich erheben über einen vergangenen Stand der Software??? Wäre nicht ein gezielter Verbesserungsvorschlag nach

heutigem Erkenntnisstand (für diejenigen die es brauchen) der richtigere Weg gewesen?

Denkt mal nach: Niemand verlangt von einem heute 15 Jahre alten Fernseher, dass er nach heutigem technischen Stand funktioniert,

aber ein Selbstbau-Kit soll eine Software verpasst bekommen, die bereits die Erkenntnisse der zukünftigen 15 Jahre beinhaltet.

Leute, bleibt auf dem Teppich.

Ich komme mit meinem BCR trotz der gelegentlichen Einschränkungen durch den Drehgeber gut klar und funke nach wie vor

gerne damit.

Danke an die Soft- und Hardware-Entwickler...

Moin,

Zitat von dl9hda

Und die Behauptung, dass man Drehencoder für einen VFO nur per Interrupt auslesen kann, ist nicht korrekt.

Polling fuer Drehencoder ist ganz schlechtes Design (Polling ist eigentlich immer schlechtes Design). Entweder mit Interrupt von einem Port oder in einem Timerinterrupt, der so haeufig ausgeloest wird, dass keine Impulse verloren gehen koennen. Du wirst in Deiner Loesung fuer die Abfrage in jeder Millisekunde ja wohl auch kaum die Takte ausgezaehlt haben, sondern einen Timerinterrupt verwenden. Und die zuverlaessigste Entprellung ist immer noch per Hardware, ob schon bereits die Schalter ab Werk entprellt sind oder man mit einer RC Kombination dafuer sorgt, ist egal. Dann gibt es auch keine massenhaften Interrupts durch das Prellen.

73, Tom

Zitat von DL7BJ

Timerinterrupt, der so haeufig ausgeloest wird, dass keine Impulse verloren gehen koennen

Moin,

genau so kann man das machen, wenn z.B. die kleinen µC keine externen Interrupts haben. Eigentlich wertet man aber keine impulse sondern Zustandsänderungen aus. Und was macht die Timer-Interruptroutine? Natürlich ein Polling der Pin-Zustände. Soviel zum schlechten Design

Und Leute Leute,

ich will doch nicht, dass jemand an einem Uraltprojekt rumschraubt oder gar die Software ändert. Mich störte doch nur, dass gesagt wird, dass die Interruptlösung (also mit PIN-Auswertung, Hardware) das Mittel der Wahl sein sollte.

Jeder der sich schon einmal damit auseinander gesetzt hat, weiß, dass eine Softwareentprellung bei interruptgesteuerter Encoderauswahl nicht trivial ist. Pro ms gibt es verdammt viele Impulse. Und wenn es damals nicht anders ging, dann lag es eben auch am Konzept. DL4JAL schrieb ja selber, dass er schon Versuche mit Timern unternommen hat. Seine Lösung war damals OK.

Mich störte auch etwas, dass folgendes postuliert wird und dann die Diskussion beendet wird. "und ich bleibe dabei. Wird am VFO-Knopf gedreht muss sich sofort die Frequenz ändern. Das geht nur mit Interrupt, ohne dass man das Gefühl hat, hier hackt etwas."

Warum man da gleich wütend werden muss ...?

73, Holger

Moin,

Zitat von dl9hda

genau so kann man das machen, wenn z.B. die kleinen µC keine externen Interrupts haben. Eigentlich wertet man aber keine impulse sondern Zustandsänderungen aus. Und was macht die Timer-Interruptroutine? Natürlich ein Polling der Pin-Zustände. Soviel zum schlechten Design

Ich war bei Polling davon ausgegangen, dass die Abfrage immer zwischen anderen Aktivitaeten erfolgt und eben nicht zyklisch in einem Timer-Interrupt. Definitionsfrage Aber die Abfrage im Timer-Interrupt hat Nachteile, richtig sauber ist das leider auch nicht. Denn es kostet immer Rechenzeit, egal ob eine Aenderung des Zustandes vorhanden ist oder nicht, es wird abgefragt und evtl. muss man sogar nur fuer diese Abfrage noch einen "schnellen" Timer nehmen, den man sonst gar nicht benoetigt. Wenn es gar nicht anders geht, okay, dann kann man das machen. Eine Hardware-Entprellung dagegen kann man noch anpassen, wenn man die Software nicht mehr aendern kann und den Schalter, Drehencoder oder sonstigen Impulslieferanten an einem Eingang austauschen muss. Man benoetigt keinen Timerinterrupt und Interrupts werden nur ausgeloest, wenn wirklich was zu tun ist.

Das ist zumindest fuer mich die sauberste Loesung und so praktiziere ich sie seit Jahrzehnten. Und frueher waren Bytes, Zeit und Timer kostbar

73, Tom

Hallo, Ihr Lieben,

ich bin ja ein neugieriger Mensch und habe noch ein bisschen weiter darüber nachgedacht, was mit meinem BCR eigentlich los ist.

Das nervige, nervige Symptom: Ich drehe etwas, und die Frequenz springt (gelegentlich) blitzartig. Ich erlebe es (zu) oft, dass sie um zum Beispiel 200 kHz weiter gesprungen ist. Übrigens immer nach oben, nie nach unten.

Wie kann das passieren?

Wenn der gerade schaltende Kontakt einfach nur prellt? Das reicht nicht.

Da springt die Frequenz in die eine Richtung und anschließend wieder zurück in die andere Richtung. 200 mal meinetwegen, obwohl ich 200 Prellvorgänge schon ziemlich unplausibel finde. Aber die Frequenzverstellung bei diesen ganzen Prellvorgängen ginge immer vor und sofort wieder zurück. Am Ende des Prellens wäre die Frequenz genau um das eine kHz (oder um 100 Hz oder 10 Hz je nach Einstelllung) weiter, wo sie hin soll. Nur zwischendurch halt Wackelei. Damit könnte man ja noch leben.

Wie ich die Sache verstehe: So lange eines der beiden Signal konstant ist, kann die Frequenz gar keine 200 kHz weiter springen. Da kann das andere Signal herumtanzen, wie es will.

Ein derartiges Frequenzhopsen kann ich mir aber anders erklären: Wenn da zwischendurch etwas ins Schwingen gerät.

Ich meine, etwas gelesen zu haben, dass TTL-Buffer im PIC zu Instabilitäten neigen, wenn man langsam steigende oder fallende Signale an die Pins gibt. (Ich habe dazu aber keine Quelle. War das hier im Forum irgendwo?)

Ein Frequenzsprung, wie ich ihn erlebe, kann dann entstehen, wenn die Elektronik hinter dem einen Pin schwingt und die Schwingungen auf den anderen Pin koppeln. Hinter dem anderen Pin steckt ja dieselbe Elektronik, die also mit der selben Frequenz grundsätzlich schwingungsbereit ist. Und das erklärt auch die hohe Zahl, dass die Frequenz (manchmal) 200 kHz weiterrutscht (ist mir vorgestern noch passiert).

Das kann ich mir das dann vorstellen, wenn beim Drehregler selbst beide Kontakte gerade offen sind. Dann liefert der Drehregler selbst keine geordneten Verhältnisse mehr, sondern lässt das Potential in der Luft hängen.

Es grüßt Euch

Andreas

Ihr Lieben!

Zitat von DH4NWG

Willst Du damit allen Ernstes ein vor 15 Jahren festgelegtes Konzept kritisieren und eine Überarbeitung einfordern ???

Ich beantworte diese (rhetorischen) Fragen mal, als wären sie ernst gestellt. Aber natürlich tue ich das nicht für Holger, sondern nur für mich selbst.

Kurzversion: Ja und Nein.

Langversion: Ich habe Spaß an meinem BCR und würde es gerne noch viele Jahre weiter benutzen können.

"Einfordern" will ich aber gar nichts. Schon gar nicht von Andreas (dl4jal).

Einschub direkt an Andreas: Du hast das Ding damals programmiert und dafür herzlichen Dank! Du lieferst hier (für mich) wertvolle Informationen und Ratschläge und dafür gleich nochmal herzlichen Dank! (Dass ich Deinem Hardwareerweiterungsvorschlag gegenüber etwas skeptisch bin, tut dem keinen Abbruch.) Wenn Du nicht außerdem nach Jahren das Programmierfass wieder neu aufmachen magst und kannst, das kann ich gut verstehen.

Aber "ist so und da kann man nix machen"? Mag ich auch nicht akzeptieren. Die Hardwarelösung, die Andreas vorschlägt, ist mir suspekt - für meinen Geschmack eher eine Notlösung. Nennt er ja auch selbst so. Eine Softwarelösung wäre mir lieber. Dass ich damit ein Konzept kritisiere, nehme ich billigend in Kauf, ja. Dass das Konzept 15 Jahre alt ist, stört mich nicht. (Übrigens kann man das BCR auch heute noch kaufen im QRP-Shop.)

Frage an Peter, DL2FI: Unter welchen Umständen wärst Du bereit, den alten Sourcecode heraus zu geben, damit man die Software verbessern kann? Ich kann programmieren, auch µC und Assembler, und würde mir die Sache mal anschauen wollen. Das geht also jetzt weniger in die Richtung "Überarbeitung einfordern" als "Überarbeitung anbieten". (Obwohl ich dieses Jahr ziemlich garantiert nicht dazu kommen werde, dazu habe ich schon zu viel anderes laufen.)

Kurzfristig habe ich vor, verschiedene Hardwareerweiterungen so lange auszuprobieren, bis ich eine finde, die für mich gut funktioniert. Die von Andreas ist ein Kandidat. Ich will aber anfangen mit einen einfachen Widerstand von 4,7k zwischen Pin RB1 und +5V. Wenn meine These stimmt, dass eine Kombination von Schwingen und Übersprechen das Problem verursacht, reicht das vielleicht schon.

Es grüßt Euch alle herzlich

Andreas

Guten Morgen Andreas,

Peter, DL2FI, hat im Mai in einem anderen Thread geschrieben, dass der Source Code zur Verfügung steht:

Es ist so ruhig um das BCR geworden....

73!

Peter DL3NAA

Zitat von dj3ei

Wenn der gerade schaltende Kontakt einfach nur prellt? Das reicht nicht.

Da springt die Frequenz in die eine Richtung und anschließend wieder zurück in die andere Richtung. 200 mal meinetwegen, obwohl ich 200 Prellvorgänge schon ziemlich unplausibel finde. Aber die Frequenzverstellung bei diesen ganzen Prellvorgängen ginge immer vor und sofort wieder zurück. Am Ende des Prellens wäre die Frequenz genau um das eine kHz (oder um 100 Hz oder 10 Hz je nach Einstelllung) weiter, wo sie hin soll. Nur zwischendurch halt Wackelei. Damit könnte man ja noch leben.

Wie ich die Sache verstehe: So lange eines der beiden Signal konstant ist, kann die Frequenz gar keine 200 kHz weiter springen. Da kann das andere Signal herumtanzen, wie es will.

Moin,

es kommt darauf an, wie die Programmierung umgesetzt wurde. Grundsätzlich ändern sich beim Weiterschalten von den Signalen A und B immer nur ein Signal. Es gibt aber Encoder, die machen pro Rastung 1, 2, 3 und sogar vier Zustandsänderungen. Ich weiß nun nicht, was im BCR verbaut wurde. Ich nehme mal an, dass der nur eine Zustandsänderung pro Schritt macht. Aber vielleicht kann ja hier jemand den genauen Typ nennen.

So wie ich es hier herauslese, wird mittels externer Interrupterkennung der Pegelwandel eines der beiden Spuren zum Auslösen eines Interrupts verwendet. Wenn dann nur der Zustand der anderen Spur ausgewertet wird, dann kann es bei prellenden Kontakten zu Problemen kommen. Wie ich ja schon schrieb, gibt es zig Zustandsänderung bei prellenden Kontakten und damit eben auch eine Vielzahl von Interrupts.

Ich würde nun durchaus einmal die Hardwaremodifikation durchführen oder den defekten Geber austauschen. Bourns EM14-Serie oder ALPS EM20 -Serie sind da zu nennen.

73, Holger - DL9HDA