Einfach mal eine theoretische Frage: Warum geben Drehencoder ein Gray-Code Signal aus? Ich habe den Artikel auf http://www.mikrocontroller.net/articles/Drehgeber gelesen, aber nicht wirklich eine Antwort auf diese Frage gefunden. Ich meine, man könnte doch auch einfach wie mit 2 Tastern arbeiten. Wenn A geschlossen, gegen den Uhrzeigersinn, wenn B geschlossen im Uhrzeigersinn. Was für einen Vorteil hat denn dieser Gray Code im Vergleich? Für mich sieht das einfach nur komplizierter aus... Viele Grüße
Weil sich beim Graycode bei der richtigen Reihenfolge sich nur ein Bit ändert. Hat Vorteile beim Fehlerdetektieren. https://de.wikipedia.org/wiki/Gray-Code
1) Denk dir einen Mechanismus aus, der je nach Drehrichtung solche Pulse abgibt. Vergleiche den Aufwand mit dem für Graycode. 2) Mechanische Kontakte prellen. Bei Graycode egal, bei Deinen Tastern fatal.
Sven schrieb: > Was für einen Vorteil hat denn dieser Gray Code im Vergleich? Beim Gray Code führt Prellen eines Kontaktes zum Flackern des letzen Bits, bei deinen Tastern zu wilden Zählersprüngen.
Sven schrieb: > Was für einen Vorteil hat denn dieser Gray Code im Vergleich? Für mich > sieht das einfach nur komplizierter aus... Na ja, bau das mal mit deinen "Tastern". Dann merkst du, daß die Leute schon schlau waren.
Tom schrieb: > 2) Mechanische Kontakte prellen. Bei Graycode egal, bei Deinen Tastern > fatal. Echt jetzt? Egal? Kann mal bitte jemand den Artikel http://www.mikrocontroller.net/articles/Drehgeber überarbeiten und zum Beispiel den Code vernünftig kommentieren? Wäre schön, wenn auch Leute den verstehen würden, die keine AVR Pros sind -.-
Sven schrieb: > Tom schrieb: > 2) Mechanische Kontakte prellen. Bei Graycode egal, bei Deinen Tastern > fatal. > > Echt jetzt? Egal? > > Kann mal bitte jemand den Artikel > http://www.mikrocontroller.net/articles/Drehgeber überarbeiten und zum > Beispiel den Code vernünftig kommentieren? Wäre schön, wenn auch Leute > den verstehen würden, die keine AVR Pros sind -.- Google! Es gibt hervorragende englischsprachige Artikel, die in der Tat wesentlich besser sind.
@ Sven (Gast) >Kann mal bitte jemand den Artikel >http://www.mikrocontroller.net/articles/Drehgeber überarbeiten und zum >Beispiel den Code vernünftig kommentieren? Wäre schön, wenn auch Leute >den verstehen würden, die keine AVR Pros sind -.- Augen auf?! 1. Absatz! "Der Vorteil dieser Codierung ist, dass ein Entprellen deutlich einfacher wird, da dieser Code die Eigenschaft besitzt, dass sich zwischen benachbarten Codes nur jeweils ein Bit ändert. Dies ermöglicht die asynchrone Abtastung, ohne weiter als einen Schritt vom wahren Ergebnis entfernt zu sein, weil ein sich änderndes Bit lediglich verspätet, aber nicht falsch erfasst wird."
Tom E. schrieb: > Beim Gray Code führt Prellen eines Kontaktes zum Flackern des letzen > Bits, bei deinen Tastern zu wilden Zählersprüngen. Quatsch, da wackelt auch nur das letzte Bit.
Ein Inkrementalgeber ist inkrementell, waehrend ein Graygeber absolut ist. Dh allenfalls benoetigt ein Inkrementalgeber noch ein Indexloch.
m.n. schrieb: > Quatsch, da wackelt auch nur das letzte Bit. Oh Mann, m.n., immer mit seiner Unkenntnis dabei wenn es um Drehencoder geht. Svens Vorstellung ist ein Taster, der schliesst, wenn sich die Achse im Uhrzeigersinn bewegt. Logischerweise muss er sich aber auch gleich wieder öffnen, damit sie sich gleich wieder schliessen kann. Er hat also vor, Impulse eines Tasters mit einem UP Eingang zu zählen. Und den DOWN Eingang mit einem anderen Taster zu bestücken für die Drehrichtung gegen den Uhrzeigersinn. Damit ist überhaupt nicht erkennbar, ob das Schliessen und Öffnen des Tasters wegen der Achsenbewegung erfolgt, oder wegen des Prellens der Kontakte, der Zähler würde munter vorwärts zählen. So wie in Zähler, dessen UP-Eingang man mit einem einfachen Taster zum druafdrücken versieht. Der zählt bei jedem Tastendruck auch nicht +1, sondern um einige Impulse weiter, eben so viel wie der Taster prellt. Man müsste die Tasterkontakte entprellen. Das geht natürlich nur, wenn Prellzeit und maximale Drehrate ausreichend unterschiedlich sind. Ganz nebenbei wäre so ein Drehencoder, der direkt UP und DOWN liefert, schwer zu konstruieren.
Michael B. schrieb: > Svens Vorstellung ist ein Taster, der schliesst, wenn sich die Achse im > Uhrzeigersinn bewegt. Nee, die Frage steht in der Überschrift. Und die Antwort ist, man braucht keinen Gray-Code zu beachten.
@ Uups (Gast) >Ein Inkrementalgeber ist inkrementell, waehrend ein Graygeber absolut >ist. Quark. Es gibt keine Graygeber. Es gibt aber Inkrementalgeber mit Graycode, das sind gefühlt 99,9% ;-) > Dh allenfalls benoetigt ein Inkrementalgeber noch ein Indexloch. Du verwechselst Inkrementalgeber mit Absolutwertgebern. Auch die arbeiten meist mit GRaycode, dann natürlich mit mehr Bits.
m.n. schrieb: > Quatsch, da wackelt auch nur das letzte Bit. Das möchte ich mal sehen. Uups schrieb: > Ein Inkrementalgeber ist inkrementell, waehrend ein Graygeber absolut > ist Wo hast du denn diese Weissheit aufgegabelt. Inkrementalgeber verwenden einen Gray-Code mit 2 Bit, d.h. die zählen Modulo 4. Der Code wurde explizit designed, um mit prellenden Schaltern klar zu kommen. (s. z.B. engl. Wikipedia, 2ter Satz).
Schau Dir einmal den Wechsel bei binärem Code an: (Beispiel 4 Bit)
Stellung 1111 dazwischen, möglich: Stellung 0000
1 1 1 0
1 1 0 0
1 0 0 0
1 1 0 0
Beim Übergang von 1111 auf 0000 müssten alle 4 Stellen gleichzeitig
springen.
Das ist gerade bei langsam drehender Scheibe garnicht möglich.
Es werden beim Übergang von 15 auf 0 also Pseudopositionen ausgegeben,
die in Wirklichkeit an ganz andrer Stelle der Scheibe auftreten
In einem Regelkreis kann das tödlich sein: der Regler bleibt auf einer
Zwischenzahl hängen anstatt an der wirklich erstrebten Zahl. Wenn sich
die Scheibe langsam dreht und etwa 1101 als Sollpisition erreicht werden
soll.
Deshalb darf beim Übergang von einer Position auf die nächste nur ein
Bit umschalten. Diese Eigenschaft, einschrittiger Code, ist beim
Gray-Code vorhanden, es gibt übrigens auch andre einschrittige Codes.
Sven schrieb: > Für mich > sieht das einfach nur komplizierter aus... Das sind die fifty shades of gray encoding.
Das Problem dieser Pseudowerte tritt ganz besonders bei langsam drehender Scheibe auf, hat also mit Prellen garnichts zu tun.
Sven schrieb: > Ich meine, man könnte doch auch einfach wie mit 2 Tastern arbeiten Könnten ja auch ein paar mehr sein, wenn du z.B. eine volle Umdrehung in 4096 Schritte auflöst. Bei linearen Maßstäben können noch ein paar Bits mehr anfallen. Prellen ist gar nicht nötig und tritt bei optischen Abtastern auch nicht auf, aber der Graycode hilft vor allem schwere Fehler durch eine geringe Schiefstellung des Abtasters zu vermeiden.
Hp M. schrieb: > Prellen ist gar nicht nötig und tritt bei optischen Abtastern auch nicht > auf Dann guck dir mal eine drehende Welle mit Wechsellasten und elastischem Antriebsstrang an. Prellen muss nicht unbedingt Relaiszungenklappern sein.
@ Hp M. (nachtmix) >Prellen ist gar nicht nötig und tritt bei optischen Abtastern auch nicht >auf, aber der Graycode hilft vor allem schwere Fehler durch eine geringe >Schiefstellung des Abtasters zu vermeiden. Ja, das auch. Aber auch sonst gibt es keine perfekte ASYNCHRONE Abtastung. Denn die Bewegung des Encoders ist zum Abtasttakt asynchron. Damit können die mehreren Bits des Positionscodes auch nie perfekt gleichzeitig den Zustand wechseln. Und in asynchronen FIFOs mit 2 Takten muss man auch die Schreib- und Lesezeiger per Graycode in die andere Taktdomäne übertragen.
Angehängte Dateien:
-
Geber.png
5,8 KB
Ich möchte an dieser Stelle den Beitrag 'Drehgeber' diskutieren: https://www.mikrocontroller.net/articles/Drehgeber 1. Die Überschrift lautet: Drehgeber (auch Inkrementaldrehgeber, ............. genannt) dienen... 2. Das erste Bild unter 'Funktion' zeigt richtigerweise die beiden um 90° versetzten Spuren A und B eines Inkrementalgebers. 3. Der direkt nachfolgende Satz lautet: Drehgeber erzeugen bei Drehung der Achse an zwei Datenleitungen am Ausgang ein sogenanntes Gray-Code-Signal. Diese Aussage, bezieht man sie auf die Abbildung, ist falsch. Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild). Mag sein, dass in der Elektronik des Drehgebers ein Wandler auf Gray-Code enthalten ist und dieser am Ausgang zur Verfügung steht. Aber das geht aus dem Beitrag nicht hervor; statt dessen ist etwa im Text ca. ein Dutzend mal von 'Code' die Rede anstatt von 'Spur A und B'. Möglicherweise ist das auch das Verständnisproblem vom TO.
Bernd K. schrieb: > Mag sein, dass in der Elektronik des Drehgebers ein Wandler auf > Gray-Code enthalten ist Dieser „Wandler“ sind einfach nur die Kontakte. Reiß mal so'n Teil auf, du wirst dich wundern, wie wenig da drin ist. :) Sven schrieb: > und zum Beispiel den Code vernünftig kommentieren? Was genau fehlt dir an meiner kürzlich hinzgefügten Erklärung (etwas unterhalb des C-Codes)?
:
Bearbeitet durch Moderator
Bernd K. schrieb: > Diese Aussage, bezieht man sie auf die Abbildung, > ist falsch. Der Gray-Code sieht - selbst auf 2 Bit > bezogen - anders aus (mein Bild). Äähh...?! Wenn Du Dir bitte mal die Spuren 2 und 3 Deines Bildes (oberes Diagramm "Gray-Code (Absolutwertgeber)") genau anschauen würdest? Das sieht verdächtig nach zwei um 90° versetzen Spuren aus, findest Du nicht?
@ Bernd K. (bmk) >1. Die Überschrift lautet: >Drehgeber (auch Inkrementaldrehgeber, ............. genannt) dienen... Wo ist das Problem? >Diese Aussage, bezieht man sie auf die Abbildung, ist falsch. >Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild). Nö, es ist Graycode. >Mag sein, dass in der Elektronik des Drehgebers ein Wandler auf >Gray-Code enthalten ist Nö. Der Code wird direkt erzeugt. >und dieser am Ausgang zur Verfügung steht. >Aber das geht aus dem Beitrag nicht hervor; statt dessen ist etwa >im Text ca. ein Dutzend mal von 'Code' die Rede anstatt von >'Spur A und B'. Was denn sonst? Spur A und B sind gray codiert.
Interessant. Weil ausgerechnet die Bits 2 und 3 des Gray-Codes dem Bild der beiden Spuren A und B eines Inkrementalgebers entsprechen, handelt es sich natürlich und selbstverständlich um den Gray-Code. NAK. Meine These: Um bei Inkrementalgebern eine richtungsabhängige Erkennung zu ermöglichen, hat man zur Spur A eine um 90° versetzte Spur B eingerichtet. Hierdurch kann man durch relativ einfache Logik die Richtung erkennen und auswerten. Dass die beiden Spuren mit den Bits 2 und 3 des Gray-Codes übereinstimmen, war nie beabsichtigt und ist rein zufällig.
Bernd K. schrieb: > Weil ausgerechnet die Bits 2 und 3 des Gray-Codes dem Bild der beiden > Spuren A und B eines Inkrementalgebers entsprechen, handelt es sich > natürlich und selbstverständlich um den Gray-Code. NAK. Nein, das ist eher Zufall. Keine Ahnung, wo das Bild herkommt. Der obere Teil zeigt einfach einen der 24 möglichen 4-bittigen Gray-Codes. Der untere Teil einen der 2 möglichen 2-bittigen Gray-Codes.
Jörg W. schrieb: > Sven schrieb: >> und zum Beispiel den Code vernünftig kommentieren? > > Was genau fehlt dir an meiner kürzlich hinzgefügten Erklärung (etwas > unterhalb des C-Codes)? Einfach mal den Code durchspielen. Was passiert da? main(). Okay, was ist PHASE_A und PHASE_B? Sehe, dass die oben definiert sind, aber kann nix mit anfangen - natürlich ohne kommentar. Die kryptischen Zeilen unter enc_delta mit den genauso kryptischen Kommentaren. Dafuq? Weiter im Programm. sei(); cli(); ?!
Sven schrieb: > Weiter > im Programm. sei(); cli(); ?! Der Artikel heißt "Drehgeber". Nicht "C-Tutorial für absolute Anfänger mit kleinem angehängten Beispiel 'Drehgeber am AVR'" Den hier zuerst lesen: AVR-GCC-Tutorial
m.n. schrieb: > Quatsch, da wackelt auch nur das letzte Bit. m.n. ist immer sooo Hilfreich bei Fragen zu Drehencodern. Zeit für eine Belohnung! Hier sind die Lottozahlen der Ziehung am nächsten Samstag. Mit einem Drehgeber nach deiner Logik eingegeben. Einfach durch deine Auswertung jagen, es wackelt ja nur das letzte Bit. Ausgangswert 0 453 UP 111 DOWN 745 UP 55 DOWN 183 DOWN 489 UP Sorry, der UP-Taster ist etwas labbriger als der DOWN-Taster. Macht deinem Algorithmus aber sicher nix, denn der ist ja genauso gut wie ein Gray Code.
Sven schrieb: > Kann mal bitte jemand den Artikel > http://www.mikrocontroller.net/articles/Drehgeber überarbeiten und zum > Beispiel den Code vernünftig kommentieren? Wäre schön, wenn auch Leute > den verstehen würden, die keine AVR Pros sind -.- Dafür muß man kein AVR Pro oder Contra sein, normale Internetskills reichen (google, Wikipedia). Ok, man hat vergessen dran zu schreiben, daß man im Internet bei Bedarf noch mehr Info findet. Schon der deutsche Wikipedia-Eintrag erklärt doch schön die Problematik mit normaler Binärcodierung, bei dem sich mehrere Bits gleichzeitig ändern können, und daß man das mit Graycode wunderbar umgeht indem dort immer nur ein Bit kippt.
Angehängte Dateien:
-
Gray_vs_Ink_.png
6,4 KB
Possetitjel schrieb: > Wenn Du Dir bitte mal die Spuren 2 und 3 Deines Bildes > (oberes Diagramm "Gray-Code (Absolutwertgeber)") genau > anschauen würdest? Wenn man sich das genau ansieht, dann erkennt man, dass Spur 3 falsch gezeichnet ist und doppelt so lange "High" sein müsste. Beim Graycode halbiert sich die Frequenz von jeder Spur zur Nächsthöheren. Bei Inkrementalgebern hingegen haben beide Signale die gleiche Frequenz mit lediglich unterschiedlicher Phase. Bernd K. hat schon richtig erkannt, dass die Signale eines Inkrementalgebers kein Graycode, im Gegensatz zum Absolutwertgeber, welche i.d.R. Graycode ausgeben. Insofern ist das im Artikel falsch, Edit: Hab das Bild mal korrigiert
:
Bearbeitet durch User
Angehängte Dateien:
-
gray.png
34 KB
Bernd K. schrieb: > 3. Der direkt nachfolgende Satz lautet: > Drehgeber erzeugen bei Drehung der Achse an zwei Datenleitungen > am Ausgang ein sogenanntes Gray-Code-Signal. > > Diese Aussage, bezieht man sie auf die Abbildung, ist falsch. > Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild). Vielleicht wird's aus dem Bild im Anhang klarer. Michael K. schrieb: > Wenn man sich das genau ansieht, dann erkennt man, dass Spur 3 falsch > gezeichnet ist und doppelt so lange "High" sein müsste. Doch, das stimmt schon. Da, wo diese Signal wieder auf Low geht, beginnt die nächste Periode des Zählers, wo er wieder bei 0 beginnt zu zählen. Michael K. schrieb: > Beim Graycode halbiert sich die Frequenz von jeder Spur zur > Nächsthöheren. Richtig, mit einer Ausnahme: Die höchstwertige Spur hat die gleiche Frequenz wie die zweithöchste, da sich die Frequenz innerhalb der Periodendauer des gesamten Zählers nicht nocheinmal halbieren kann. Edit: Die in unterschiedlichen Grüntönen hinterlegten Flächen sind die Perioden eines 2-Bit-, 3-Bit- und 16-Bit-Gray-Code-Zählers. Würde man beim 16-Bit-Zähler einfach nur die Spuren 3 und 2 weglassen, Spur 1 aber unverändert übernehmen, würde der Zähler immer abwechselnd aufwäsrts und abwärts zähle: 0-1-2-3-3-2-1-0-0-1-2-3-3-2-1-0. Das ist aber nicht das, was man normalerweise möchte.
:
Bearbeitet durch Moderator
Und wenn Du Dir mal eine Periode des Drehgeber-Signals ansiehst, ist die Bitfolge: 00 -> 01 -> 11 -> 10 -> 00 was mit einem 2-Bit-Gray-Signal identisch ist. Vielleicht kommt das Mißverständnis daher, daß die letzten beiden Stellen eines periodischen 4-Bit-Gray-Signals mitnichten einem periodischen 2-Bit-Signal entsprechen, sondern die ersten?
:
Bearbeitet durch User
Planlos schrieb: > m.n. ist immer sooo Hilfreich bei Fragen zu Drehencodern. Zeit für eine > Belohnung! Vielen Kank! Als Dankeschön erhälst eine Dose Greykot. Wie schaffen es eigentlich die Hersteller von ICs/µCs Quadraturdekoder aufzubauen, denen der Gray-Code völlig schnuppe ist? Es sind sicherlich nur Spinner und Idioten.
Man kann ein Brötchen und noch eines in die Tasche stecken, und hat dann zwei - auch ohne Addition zu kennen, kommt man auf die 2.
Yalu X. schrieb: >> Beim Graycode halbiert sich die Frequenz von jeder Spur zur >> Nächsthöheren. > Richtig, mit einer Ausnahme: Aargh, stimmt. Ich nehm alles zurück :-) Für das Verständnis ist es dann trotzdem ziemlich unglücklich, dass sich die Bezeichnung Graycode im Artikel wegen der nur 2 Spuren genau auf diese Ausnahme bezieht, denn das ist ja nicht, was den Graycode eigtl. ausmacht.
:
Bearbeitet durch User
@ Bernd K. (bmk) >Weil ausgerechnet die Bits 2 und 3 des Gray-Codes dem Bild der beiden >Spuren A und B eines Inkrementalgebers entsprechen, handelt es sich >natürlich und selbstverständlich um den Gray-Code. NAK. Hää? >Meine These: >Um bei Inkrementalgebern eine richtungsabhängige Erkennung zu >ermöglichen, hat man zur Spur A eine um 90° versetzte Spur B >eingerichtet. Hierdurch kann man durch relativ einfache Logik >die Richtung erkennen und auswerten. Dass die beiden Spuren >mit den Bits 2 und 3 des Gray-Codes übereinstimmen, war nie >beabsichtigt und ist rein zufällig. Unfug^3. Es IST Graycode, nur halt mit 2 Bit, der minimalen Bitbreite, die für so einen Code möglich ist. Das war/ist volle Absicht! Es gibt nicht DEN Graycode, denn bei >2 Bits kann man verschiedene Abfolgen konstruieren, bei der sich immer nur ein Bit ändert, trotzdem bleibt es einschrittiger Graycode.
m.n. schrieb: > Wie schaffen es eigentlich die Hersteller von ICs/µCs Quadraturdekoder > aufzubauen, denen der Gray-Code völlig schnuppe ist? In dem sie einen Gray-Code verwenden, ohne es zu merken? > Es sind sicherlich nur Spinner und Idioten. Glaube ich nicht. Aber wenn du ein Quadraturdecoder-IC kennst, dass ohne Gray-Code auskommt, bitte Datenblatt-Link hier posten.
Sven schrieb: >> Was genau fehlt dir an meiner kürzlich hinzgefügten Erklärung (etwas >> unterhalb des C-Codes)? > > Einfach mal den Code durchspielen. Was passiert da? main(). Okay, was > ist PHASE_A und PHASE_B? Wenn du dir das Datenblatt eines Drehgebers mal anschaust, dann werden die beiden Spuren im Englischen in der Tat häufig genau so bezeichnet (Phase A/B). Ansonsten bezog ich mich ausdrücklich nicht auf den Quellcode, sondern auf meine kürzlich hinzugefügten Erläuterungen zwei Absätze tiefer. Hast du dir diese denn überhaupt durchgelesen?
Michael K. schrieb: > > Für das Verständnis ist es dann trotzdem ziemlich unglücklich, dass sich > die Bezeichnung Graycode im Artikel wegen der nur 2 Spuren genau auf > diese Ausnahme bezieht, denn das ist ja nicht, was den Graycode eigtl. > ausmacht. Genau das meine ich. In der Tat sind die um 90° versetzten Spuren A und B eines Imkrementalgebers mit den beiden höchstwerigen Bits eines Gray Codes mit einer Bitzahl >=2 identisch. Aber ein 'Code' steht für etwas anderes. Wikipedia: Ein Code oder Kode, deutsche Aussprache [koːt],[1] ist eine Abbildungsvorschrift, die jedem Zeichen eines Zeichenvorrats (Urbildmenge) eindeutig ein Zeichen oder eine Zeichenfolge aus einem möglicherweise anderen Zeichenvorrat (Bildmenge) zuordnet.[2] Und da hört es mit der Gemeinsamkeit auf; ein Inkrementalgeber will sicherlich nicht bestimmte 'Zeichen eines Zeichenvorrats' übertragen.
Michael K. schrieb: > Für das Verständnis ist es dann trotzdem ziemlich unglücklich, dass sich > die Bezeichnung Graycode im Artikel wegen der nur 2 Spuren genau auf > diese Ausnahme bezieht Das kommt, wie so oft, darauf an. Ich selber sehe in so einer Inkrementalgeberausgabe auch erst einmal zwei phasenversetzte Rechtecksignale und nichts weiter. Ich habe vor vielen Jahren ein Praktikum bei einem Hersteller von Drehgebern gemacht, und dort hat es jeder genau so gesehen. Den Begriff Gray-Code hat man ausschließlich in Verbindung mit Absolutgebern mit mehr als zwei Spuren benutzt. Das war nicht nur in dieser Firma so, sondern auch anderswo. Die beiden Bits werden herstellerseitig meist auch nicht als Bit 0 und Bit 1 bezeichnet, sondern fast immer als A und B. Auf die Interpretation der Inkrementalgeberausgabe als 2-Bit-Gray-Code bin ich das erste Mal vor ein paar Jahren in Hobyelektronikforen gestoßen. Vielleicht kommt demnächst ein IC-Hersteller auf die Idee, ein Toggle-Flipflop als einen 1-Bit-Gray-Code-Zähler aufzuwerten ;-) Es ist aber keineswegs falsch und in mancher Hinsicht auch durchaus sinnvoll, die A- und B- Signale als Gray-Code zu sehen. So gibt es Auswerteverfahren, die tatsächlich die beiden Leitungszustände als Gray-Code in einen Zahlenwert von 0 bis 3 dekodieren, um anschließend die Differenz zum letzten Zahlenwert (die immer -1, 0 oder +1 und nicht -2 sein sollte, dewegen kann man damit auch Fehlerzustände erkennen) zu einer Zählvariable hinzuzuaddieren. Wer den Gray-Code kennt, versteht dieses Verfahren sofort, alle anderen sehen darin erst einmal schwarze Bitmagie.
Planlos schrieb: >> Es sind sicherlich nur Spinner und Idioten. > > Glaube ich nicht. Aber wenn du ein Quadraturdecoder-IC kennst, dass ohne > Gray-Code auskommt, bitte Datenblatt-Link hier posten. Na gut, dann gebe ich Dir eine 2. Chance ;-) Beitrag "mini Quadraturdekoder + 32 Bit Zähler + TWI, Attiny25"
Yalu X. schrieb: > Michael K. schrieb: >> Für das Verständnis ist es dann trotzdem ziemlich unglücklich, dass sich >> die Bezeichnung Graycode im Artikel wegen der nur 2 Spuren genau auf >> diese Ausnahme bezieht > > Das kommt, wie so oft, darauf an. > Das kann man wohl sagen. :-) Es gibt eine ganze Reihe von Beispielen für solche "Definitions-Ungereimtheiten", die sich bei längerer Betrachtung als notwendig und sogar "elegant" herausstellen - jedenfalls aber die scheinbare "Un-Ästhetik" gar nicht besitzen. Das wird unscharf, aber warum das Beispiel wie von Michael K. geschrieben "unglücklich" ist, ist ja auch nicht scharf definiert und bezieht sich konkret nur auf das Wort "Ausnahme" - das wie gezeigt, ja selbst "unglücklich" ist, da es eine klare Regel gibt. Schaut man sich die rekursive Definition des Gray-Code auf der englischen Wikipedia-Seite an, so ist der Zwei-Bit-Fall keine Ausnahme sondern die Regel. In diesem Sinne sehe ich das Verständnis weder eines Encoders noch des Gray-Codes in irgendeiner Weise als gefährdet.
Bernd K. schrieb: > Ich möchte an dieser Stelle den Beitrag 'Drehgeber' diskutieren: > https://www.mikrocontroller.net/articles/Drehgeber Dazu hättest du besser einen neuen Thread aufgemacht. > 1. Die Überschrift lautet: > Drehgeber (auch Inkrementaldrehgeber, ............. genannt) dienen... > > 2. Das erste Bild unter 'Funktion' zeigt richtigerweise die beiden > um 90° versetzten Spuren A und B eines Inkrementalgebers. > > 3. Der direkt nachfolgende Satz lautet: > Drehgeber erzeugen bei Drehung der Achse an zwei Datenleitungen > am Ausgang ein sogenanntes Gray-Code-Signal. > > Diese Aussage, bezieht man sie auf die Abbildung, ist falsch. > Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild). Falsch. Du hast einfach nicht begriffen was ein Graycode ist. Die Hervorhebung von ein ist wichtig. Es gibt nämlich nicht den Graycode, sondern viele [1]. Die wesentliche Eigenschaft eines Gray-Codes ist, daß sich zwischen zwei aufeinanderfolgenden Codes immer nur genau 1 Bit ändert. Oder etwas wissenschaftlicher ausgedrückt: die Hamming-Distanz zwischen aufeinanderfolgenden Codes ist genau 1. Diese Definition eines Gray-Codes sagt insbesondere gar nichts über die Anzahl Bits die so ein Code haben muß. Und da du einen Gray-Code mit 4 Bit (dein oberes Bild) mit dem vom Inkrementalgeber gelieferten Gray-Code mit 2 Bit vergleichst, kommt da natürlich Unsinn raus. Du vergleichst Äpfel mit Birnen. [1] obwohl es viele verschiedene Gray-Codes gibt, wird meistens der Standard-Code verwendet, der sich aus der Standard-Konstruktion ergibt. Die Konstruktion ist rekursiv: 1. der Gray-Code mit 1 Bit ist {0, 1} 2. ein Gray-Code der Länge n+1 ensteht aus dem Gray-Code der Länge n indem man den kürzeren Code einmal vorwärts und ein ein zweites Mal rückwärts aufschreibt und das zusätzliche Bit in der ersten Hälfte auf 0 und in der zweiten Hälfte auf 1 setzt.
Yalu X. schrieb: > So gibt es > Auswerteverfahren, die tatsächlich die beiden Leitungszustände als > Gray-Code in einen Zahlenwert von 0 bis 3 dekodieren, um anschließend > die Differenz zum letzten Zahlenwert (die immer -1, 0 oder +1 und nicht > -2 sein sollte, dewegen kann man damit auch Fehlerzustände erkennen) zu > einer Zählvariable hinzuzuaddieren. Letztendlich gibt es eigentlich nur ein Verfahren, AB-Signale auszuwerten: Aktuellen Zustand betrachten und gültige Folgezustände sind der aktuelle oder die beiden benachbarten. Da es vier Zustände gibt, kann man diese mit 0..3 bezeichnen und die Auswertung als -1,0,+1-Operation betrachten, damit komm ich auch "hintenrum" auf den Graycode, was ja logisch ist, da für den Spezialfall 2 Spuren die Signale eben identisch sind. Insofern stimmen wir überein, anders geht es auch nicht. Klaus schrieb: > warum das Beispiel wie von Michael K. geschrieben "unglücklich" ist, ist > ja auch nicht scharf definiert Sicher ist es unscharf, aber ich bleibe dabei, dass es eine unglückliche Bezeichnung ist, denn wenn man Yalus Gedankengang fortgesetzt: > Auf die Interpretation der Inkrementalgeberausgabe als 2-Bit-Gray-Code > bin ich das erste Mal vor ein paar Jahren in Hobyelektronikforen > gestoßen. Vielleicht kommt demnächst ein IC-Hersteller auf die Idee, ein > Toggle-Flipflop als einen 1-Bit-Gray-Code-Zähler aufzuwerten ;-) könnte man damit einen Inkrementalgeber auch als Absolutwertgeber bezeichnen. Das ist rein technisch sicher auch richtig, aber praktisch und vom Verständnis her wenig sinnvoll und sicher die wenigsten würden das als eine "elegante" Bezeichnung verstehen. So gesehen kann ich dann auch einen Taster (oder wenigstens eine Kodierung mit nur einem Strich) als Absolutwertgeber bezeichnen, da er ja eine absolute 0 und eine absolute 1 ausgibt.
:
Bearbeitet durch User
Michael K. schrieb: > könnte man damit einen Inkrementalgeber auch als Absolutwertgeber > bezeichnen Das ist absurd. Ein Inkrementalgeber gibt über seinen gesamten Meßbereich ein periodisches Signal ab, ein Absolutgeber ein nicht-periodisches.
Michael K. schrieb: > Klaus schrieb: >> warum das Beispiel wie von Michael K. geschrieben "unglücklich" ist, ist >> ja auch nicht scharf definiert > Sicher ist es unscharf, aber ich dabei, dass es eine unglückliche > Bezeichnung ist, denn wenn man Yalus Gedankengang fortgesetzt: >> Auf die Interpretation der Inkrementalgeberausgabe als 2-Bit-Gray-Code >> bin ich das erste Mal vor ein paar Jahren in Hobyelektronikforen >> gestoßen. Vielleicht kommt demnächst ein IC-Hersteller auf die Idee, ein >> Toggle-Flipflop als einen 1-Bit-Gray-Code-Zähler aufzuwerten ;-) > > könnte man damit einen Inkrementalgeber auch als Absolutwertgeber > bezeichnen. Wenn man auf die Weise weiter denkt, dann ist ein Inkrementalgeber auch eine Banane. Entschuldige, die launige Ausdrucksweise, aber so langsam habe ich den Eindruck, dass Du nur unbedingt recht haben willst.
Bernd K. schrieb: > Weil ausgerechnet die Bits 2 und 3 des Gray-Codes dem Bild der beiden > Spuren A und B eines Inkrementalgebers entsprechen, handelt es sich > natürlich und selbstverständlich um den Gray-Code. NAK. > > Meine These: > Um bei Inkrementalgebern eine richtungsabhängige Erkennung zu > ermöglichen, hat man zur Spur A eine um 90° versetzte Spur B > eingerichtet. Hierdurch kann man durch relativ einfache Logik > die Richtung erkennen und auswerten. Dass die beiden Spuren > mit den Bits 2 und 3 des Gray-Codes übereinstimmen, war nie > beabsichtigt und ist rein zufällig. Na ja, das liegt wohl daran, daß beide dasselbe Problem haben: Wenn sich von einer Position zur nächsten nicht nur ein Signal ändern muss sondern mehrere, wie stellt man sicher, daß sie sich auch exakt gleichzeitig ändern damit es keinen Zeitpunkt gibt in der Zwischenzustände auftreten ? Richtig, gar nicht. Also bleibt nur eine Codierung, bei der sich beim Überganz von einem zum nächsten Codepunkt nur ein Signal ändert. Eine davon ist der Gray-Code. Bei 2 bit gibt es überhaupt nur eine Möglichkeit der codierung, bei 2 bit hat man also zwangsweise einen Gray Code. Ob man den nun mit 2 bit für relative Erfassung oder mit (16) bit für absolute ocdierung baut, kann sich dann der Benutzer nach seinen Erfordernissen aussuchen.
Walter T. schrieb: > Michael K. schrieb: >> könnte man damit einen Inkrementalgeber auch als Absolutwertgeber >> bezeichnen > > Das ist absurd. Aber technisch gesehen ist es richtig: Ein 2-Bit-Absolutwertgeber liefert exakt 2^2 Werte und umfasst damit einen Bereich von 0-3, also nicht periodisch. Da das trotzdem noch ein üblicherweise als Inkrementalgeber bezeichneter Geber ist merkt man, dass die Aussage >Ein Inkrementalgeber gibt über seinen gesamten Meßbereich ein periodisches >Signal ab, falsch ist
@ Michael K. OK. So lakonisch sollte ich einen Menschen lieber nicht abspeisen: Yalu hat davon geschrieben, dass Dein Postulat, dass sich die Frequenz jeweils verdoppelt, eine Ausnahme in dem Fall von nur zwei Bit breiten Gray-Codes hat. Das heisst, die Frequenzverdoppelung ist, Ockhams Messer angesetzt, "komplizierter" als die rekursive Definition, die völlig ohne Ausnahme auskommt. Ergo ist die Bezeichnung des Encoder-Codes als Gray-Code in keiner Weise unglücklich - nur dann wenn man an der Frequenzverdoppelungs-These festhält. Das kann man machen - muss man aber nicht. :-)
Klaus schrieb: > Wenn man auf die Weise weiter denkt, dann ist ein Inkrementalgeber auch > eine Banane. Sorry, aber während ich mich lediglich Yalu's Gedanken fortgesetzt habe bleibt mir unschlüssig, wie du auf eine Banane kommen willst.
Michael B. schrieb: > Wenn sich von einer Position zur nächsten nicht nur ein Signal ändern > muss sondern mehrere, wie stellt man sicher, daß sie sich auch exakt > gleichzeitig ändern damit es keinen Zeitpunkt gibt in der > Zwischenzustände auftreten ? > > Richtig, gar nicht. > > Also bleibt nur eine Codierung, bei der sich beim Überganz von einem zum > nächsten Codepunkt nur ein Signal ändert. > > Eine davon ist der Gray-Code. Falsch! Jede solche Codierung ist ein Gray-Code. Zum wiederholten Male: es gibt nicht den Gray-Code. Es gibt lediglich Codes die Gray-Codes sind und welche die das nicht sind.
Michael K. schrieb: > Klaus schrieb: >> Wenn man auf die Weise weiter denkt, dann ist ein Inkrementalgeber auch >> eine Banane. > Sorry, aber während ich mich lediglich Yalu's Gedanken fortgesetzt habe > bleibt mir unschlüssig, wie du auf eine Banane kommen willst. Weil Du von gewissen Eigenschaften eines Inkrementalgebers abstrahieren musst um ihn als Absolutgeber bezeichnen zu können. Wenn Du diese Eigenschaften nicht nennst, dann wird eine Diskussion beliebig, weil Du nämlich von so vielen weiteren Eigenschaften absehen könntest, dass jedes beliebige Objekt von einer Banane ununterscheidbar wird - also auch der Inkrementalgeber. Insbesondere begründet aber eine Abstraktion an sich nicht warum eine Darstellung "unglücklich" ist. Das Problem liegt doch darin, dass diese "unglücklich" eben kein klar definiertes Wort ist. Ich gestehe Dir zu, - soweit ich dazu überhaupt eine Berechtigung habe, dass Dir die Erklärung nicht gefällt. Aber für eine sachliche, irgendwohin führende Diskussion ist das nicht hinreichend. Für solche gibts hier Karl Bindl.
Walter T. schrieb: > Das ist absurd. Ein Inkrementalgeber gibt über seinen gesamten > Meßbereich ein periodisches Signal ab, ein Absolutgeber ein > nicht-periodisches. wenn du weiter drehst, siehst du bald, daß auch ein Absolutwertgeber ein periodisches Signal hat. Sinnvollerweise hat man auch beim Übergang von einer Periode zur nächsten nur ein Bit, das wechselt.
Klaus schrieb: > Weil Du von gewissen Eigenschaften eines Inkrementalgebers abstrahieren > musst um ihn als Absolutgeber bezeichnen zu können. Und die wären? Ich befürchte eher, du verstehst den Gedankengang nicht und unterstellst mir daher eine Abstraktion, die nicht stattgefunden hat. Ein Inkrementalgeber liefert zwei um 90° versetzte Rechtecksignale, die Einzelschritte in beliebige Richtung anzeigen, aber (eigentlich) keine absolute Position. Ein Absolutwertgeber hingegen liefert, i.d.R. graycodiert, einen Wert, der einer absoluten Position entspricht. Jetzt habe ich analog zur oben durchgeführten Spurreduzierung am Graycode das ganze auf Absolutwertgeber angewandt: Ein 16-Bit Absolutwertgeber hat 16 Spuren und kann 65536 Absolutpositionen ausgeben. Ein 12-Bit Absolutwertgeber hat 12 Spuren und liefert 4096 Absolutpos. Ein 12-Bit Absolutwertgeber hat 12 Spuren und liefert 4096 Absolutpos. Ein 8-Bit Absolutwertgeber hat 8 Spuren und liefert 256 Absolutpos. Ein 4-Bit Absolutwertgeber hat 4 Spuren und liefert 16 Absolutpos. Ein 3-Bit Absolutwertgeber hat 3 Spuren und liefert 8 Absolutpos. Ein 2-Bit Absolutwertgeber hat 2 Spuren und liefert 4 Absolutpos.* Ein 1-Bit Absolutwertgeber hat 1 Spuren und liefert 2 Absolutpos. Und der 2-Bit-Absolutwertgeber ist zufällig unser Inkrementalgeber :-) Und so wie jeder eine Bezeichnugn eines Inkrementalgebers als Absolutwertgeber als "unglücklich" oder "abstrus" bezeichnen würde halte ich die Bezeichnung einen Inkrementalcodes als Graycode für unglücklich - auch wenn es technisch betrachtet richtig sein mag. Und für die Textfragmentpicker: Ich würde nir einen Inkrementalgeber als Absolutwertgeber bezeichnen, ich sage nur, man könnte. > Aber für eine sachliche, irgendwohin führende Diskussion ist das nicht > hinreichend. Fass dir ersmtal an die eigene Nase, weil Hinweise auf Bananen sind weder sachlich noch zielführend :-) > aber so langsam habe ich den Eindruck, dass Du nur unbedingt recht haben > willst. Stimmt ... erwischt ... deshalb schrieb ich oben auch: Michael K. schrieb: > Aargh, stimmt. > Ich nehm alles zurück :-)
:
Bearbeitet durch User
Michael B. schrieb: > Wenn sich von einer Position zur nächsten nicht nur ein Signal ändern > muss sondern mehrere, wie stellt man sicher, daß sie sich auch exakt > gleichzeitig ändern damit es keinen Zeitpunkt gibt in der > Zwischenzustände auftreten ? > > Richtig, gar nicht. Man könnte noch ein weiteres Signal einfügen das die Gültigkeit der Daten anzeigt wie man das auch bei parallelen Bussen macht. Aber die Lösung mit dem einschrittigen Code ist da eleganter und spart auch dieses zusatz Signal.
Heizer schrieb: > Man könnte noch ein weiteres Signal einfügen das die Gültigkeit der > Daten anzeigt wie man das auch bei parallelen Bussen macht. Dann weiß man zwar, dass das Signal ungültig ist/war, aber ggfs. nicht, wie es richtig ist. Gerade bei Positionsgebern wäre es fatal, wenn Schritte nicht erkannt werden, da die Synchronität verloren geht und dann ggfs. erst eine Referenz neu angefahren werden muss. Und das zweite Problem: Wie bastelt man das Kontrollsignal bzw. welche Kriterien? Hier steht man dann wieder vor den gleichen Problemen wie beim entprellen.
m.n. schrieb: > Na gut, dann gebe ich Dir eine 2. Chance ;-) > Beitrag "mini Quadraturdekoder + 32 Bit Zähler + TWI, Attiny25" Kein Quelltext dabei, aber anhand der Beschreibung, die dein Großer Bruder ("M.N" statt "m.n") geliefert hat: Gray Code. Kleiner Tipp: "90° phasenverschobene(n) Eingangssignale" Sind ein Gray-Code. Du kriegst also auch eine zweite Chance.
Planlos schrieb: > Du kriegst also auch eine zweite Chance. Gut, hier ist Quelltext dabei. Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" Wer keine Flankenerkennung per Interrupt mag/versteht, legt PD5 auf '0'. Damit wird dann zyklisch per T0 ausgewertet. *.a90 ist die Hex-Datei.
Was für eine schrecklich unsinnige Diskussion. Aber es sind wohl Herbstferien und der eine oder andere Schüler hat Langeweile. Auch wen ich den Mikrocontroller Drehgeber Artikel aus diversen Gründen persönlich auch für nicht besonders gelungen halte, so muss man dennoch zugestehen das hier Leute unentgeltlich zumindest den Versuch unternommen haben etwas lehrreiches zu schreiben, Wem es nicht gefällt, der muss es ja auch nicht lesen. Wer meint es besser zu können und die Zeit und Lust hat, der kann ja jederzeit selber etwas schreiben. Das Prinzip der Auswertung des für den gemeinen "Hobbybaster" interessanten Drehgeber's ist eben so simpel wie Tasten zu entprellen, oder ein "Hello World" zu programmieren. Man kann es auf die Handinnenfläche schreiben. (1) Man liest in kurzen Zeitabständen die Encodersignale A u B ein. Macht man das mehr als einmal hat mein jeweils immer einen Zustand (A u B) neu und einen Zustand (A u B) vorher, vorausgesetzt man speichert die eingelesenen Werte irgendwo zwischen. (2) Jetzt wertet man aus: Ist A-neu ungleich B-vorher zählt man z.B. eine Variable hoch. Ist B-neu ungleich A-vorher zählt man die selbe Variable runter. Das war es. In Assembler sind das vielleicht 10, 15 Instruktionen, auch die kann man sich mal eben in der Handinnenfläche notieren. Das sollte jeder umsetzen können der es schafft einen Timer nebst ISR ans laufen zu bringen. Warum man dafür seitenweise Tutorials benötigt mit diversen bunten Bildern ist mir schleierhaft.
Michael K. schrieb: > Und der 2-Bit-Absolutwertgeber ist zufällig unser Inkrementalgeber :-) Das geht nur fuer einen Inkrementalgeber welcher 4 Positionen pro Umdrehung hat. Genauso wie ein 2-Bit Absolutwertgeber wird der sehr schwer zu finden sein. > Und für die Textfragmentpicker: Ich würde nir einen Inkrementalgeber als > Absolutwertgeber bezeichnen, ich sage nur, man könnte. Fuer die Marktueblichen Inkrementalgeber kann man das nicht, da das '4-Bit Quadratur-Muster' mehrfach pro Umdrehung vorkommt. Cheers, Roger
Da es sowieso nur eine theoretische Betrachtung ist... Zumindest sind mir aber schon (ältere) Inkrementalgeber mit lediglich 4 Impulsen pro U als Bedienelement begegnet.
m.n. schrieb: > Planlos schrieb: >> Du kriegst also auch eine zweite Chance. > > Gut, hier ist Quelltext dabei. > Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" > > Wer keine Flankenerkennung per Interrupt mag/versteht, legt PD5 auf '0'. > Damit wird dann zyklisch per T0 ausgewertet. > *.a90 ist die Hex-Datei. Ups. Der wertet auch einen Gray-Code aus. Du brauchst wohl noch einen Dritten Versuch. Tipp: Der Grund warum die Auswertung über die Flanken (ob mit oder ohne Interrupt) funktioniert, ist dass der Drehgeber einen Gray-Code ausgibt.
Michael K. schrieb: > Klaus schrieb: >> Weil Du von gewissen Eigenschaften eines Inkrementalgebers abstrahieren >> musst um ihn als Absolutgeber bezeichnen zu können. > Und die wären? Das musst Du doch wissen, denn Du führst die Abstraktion ja durch. > Ich befürchte eher, du verstehst den Gedankengang nicht und unterstellst > mir daher eine Abstraktion, die nicht stattgefunden hat. Das scheint mir mittlerweile auch so. > Und für die Textfragmentpicker: Ich würde nir einen Inkrementalgeber als > Absolutwertgeber bezeichnen, ich sage nur, man könnte. > >> Aber für eine sachliche, irgendwohin führende Diskussion ist das nicht >> hinreichend. > Fass dir ersmtal an die eigene Nase, weil Hinweise auf Bananen sind > weder sachlich noch zielführend :-) Genau. Fass Dir mal an die eigene Nase, Textfragmentpicker. Und da wundern sich die Leute warum sie hier so unhöflich behandelt werden ... Sehr merkwürdig. Also: Willkommen in meinem CSS-File und ein schönes Leben noch.
Planlos schrieb: > Ups. Der wertet auch einen Gray-Code aus. Das kann ja garnicht sein, schließlich habe ich ja noch ein drittes Signal (Index); das paßt nicht in das Schema (!Schaltplan). Ferner würden Deine obigen Lottozahlen nicht mehr stimmen. Und überhaupt bin ich doch hier der Böse, dem jeder Hund ans Bein pinkeln kann, weil der Hund dadurch erhofft, nicht mehr Hund sein zu müssen. Das sagt mein großer Bruder immer ;-)
m.n. schrieb: > Das kann ja garnicht sein, schließlich habe ich ja noch ein drittes > Signal (Index); das paßt nicht in das Schema (!Schaltplan). Welches? Dass das du mit "PHASE_A" beschriftet hast oder das mit "PHASE_B"? Sorry, aber mit deinem 2013er Projekt kommst du nicht weiter. Das ist für Drehgeber mit Gray-Code-Ausgang ausgelegt. Wenn du dich selbst (oder deinen großen Bruder) also als "Hersteller von Quadraturdekoder" siehst, stimmt meine Aussage von heute Morgen: Planlos schrieb: > m.n. schrieb: >> Wie schaffen es eigentlich die Hersteller von ICs/µCs Quadraturdekoder >> aufzubauen, denen der Gray-Code völlig schnuppe ist? > > In dem sie einen Gray-Code verwenden, ohne es zu merken? Ich zitiere aus deinem Quellcode-Kommentar: [c] /* Die um 90° phasenverschobenen Eingangssignale werden an INT0 (PD2) und INT1 (PD3) angelegt. Jede Flankenänderung wird mit einer schnellen Interruptroutine erfaßt. */ Also: Gray-Code-Auswertung. Kann dir aber völlig schnuppe sein. Ob deine Auswertung funktioniert, hängt nicht davon ab ob beim Programmieren explizit "Yay! Gray-Code!" oder "Hey! Flankenwechsel! Da ist was passiert!" gedacht hast.
@ Planlos (Gast) >Kann dir aber völlig schnuppe sein. >Ob deine Auswertung funktioniert, hängt nicht davon ab ob beim >Programmieren explizit "Yay! Gray-Code!" oder "Hey! Flankenwechsel! Da >ist was passiert!" gedacht hast. Das ist das Hummelparadoxon! Eine Hummel hat keine Ahnung von Aerodynamik und nach deren Gesetzen kann sie auch nicht fliegen! Sie tut es trotzdem!
Planlos schrieb: > Sorry, aber mit deinem 2013er Projekt kommst du nicht weiter. > Das ist für Drehgeber mit Gray-Code-Ausgang ausgelegt. Jetzt ist aber Schluß mit lustig: http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm Hier werden sin/cos-Signale ausgewertet, was nun kein Gray mehr sein kann, da sich die analogen Spannungen immer gleichzeitig verändern.
@ m.n. (Gast) >Hier werden sin/cos-Signale ausgewertet, was nun kein Gray mehr sein >kann, da sich die analogen Spannungen immer gleichzeitig verändern. Das ist ein QAM Demodulator ;-)
Michael K. schrieb: > Wenn man sich das genau ansieht, dann erkennt man, dass Spur 3 falsch > gezeichnet ist und doppelt so lange "High" sein müsste. > Beim Graycode halbiert sich die Frequenz von jeder Spur zur > Nächsthöheren. Du vergleichst zwei ziemlich verschiedene Gray Codes miteinander. Da darfst du nicht erwarten dass zufällig zwei Spuren gleich sind. Und nein - da ist nichts falsch gezeichnet. Gray Code ist die Bezeichnung für eine ganze Klasse von binären Codes ist, nämlich von Codes, bei denen sich aufeinanderfolgende Code-Worte nur in einem Bit unterscheiden. Der Hamming-Abstand ist genau 1. Dafür wurden die Codes entwickelt und später nach Herrn Gray benannt. Die reflektierten Binärcodes sind eine Untermenge der Gray Codes.
Falk B. schrieb: > Eine Hummel hat keine Ahnung von Aerodynamik und nach deren Gesetzen > kann sie auch nicht fliegen! Sie tut es trotzdem! Alter Witz mit 100-Jahre-Bart, und sachlich 100% falsch. Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.