Drehgeber-Auswertung: Frage zu Syntheseergebnis

[Andreas S. (andreas) (Admin)]

Hallo,

ich habe folgenden Code für die Auswertung eines Drehgebers (2 Bit 
Gray-Code) geschrieben.

-- Eingangssignal vom Drehgeber
signal input: std_logic_vector(1 downto 0);
...
signal state: std_logic_vector(1 downto 0) := (others => '0');
...
if rising_edge(clk) then
  if ce = '1' then
    state <= input;

    case state & input is
      when "0001" => up <= '1';
      when "0010" => down <= '1';
      
      when "0100" => down <= '1';
      when "0111" => up <= '1';
      
      when "1000" => up <= '1';
      when "1011" => down <= '1';
      
      when "1101" => down <= '1';
      when "1110" => up <= '1';

      when others => null;
    end case;
  end if;
  
  -- up und down sollen nur einen Takt lang aktiv sein,
  -- deshalb werden sie hier wieder zurückgesetzt
  if up = '1' then
    up <= '0';
  end if;
  
  if down = '1' then
    down <= '0';
  end if;
end if;

Daraus baut XST die angehängte Schaltung. Meine Fragen dazu:
- Ist es nötig "input" ganz am Anfang noch mal in ein Register zu lesen 
(vermutlich ja), oder ist es ausreichend dass das Signal erst nach der 
LUT registriert wird?
- Wozu sind die Multiplexer vor den Ausgangs-FF gut? Sollte es nicht 
reichen, dass der Reset-Eingang der FF beschaltet ist?

Danke
Andreas

[---- (Gast)]

Hallo

Das erste Register muss schon am Anfang sein, denn die case soll ja die 
Folge von input zu state erkennen.
Was XST genau aus deiner Schaltung macht ist mir auch nicht klar. Auf 
jeden Fall ist das Zurücksetzten von up unnötig (und falsch). Es reicht 
up unterhalb von rising_edge(clk) auf 0 zu setzten, denn state zu input 
ist nur für eine Periode unterschiedlich (siehe case).

if rising_edge(clk) then
  up   <= '0';
  down <= '0';
  if ce = '1' then
    state <= input;

    case state & input is
      when "0001" => up <= '1';
      when "0010" => down <= '1';
      
      when "0100" => down <= '1';
      when "0111" => up <= '1';
      
      when "1000" => up <= '1';
      when "1011" => down <= '1';
      
      when "1101" => down <= '1';
      when "1110" => up <= '1';

      when others => null; -- up <= '0' könnte auch hier stehen.
    end case;
  end if;
end if;

Gruss ----

[Andreas S. (andreas) (Admin)]

---- wrote:
> Das erste Register muss schon am Anfang sein, denn die case soll ja die
> Folge von input zu state erkennen.

Das funktioniert schon so, die Frage ist nur ob es korrekt bzw. guter 
Stil ist, ein externes asynchrones Signal kombinatorisch zu verarbeiten, 
oder ob man es grundsätzlich vorher registrieren sollte.

> Was XST genau aus deiner Schaltung macht ist mir auch nicht klar. Auf
> jeden Fall ist das Zurücksetzten von up unnötig (und falsch).

Ist unnötig umständlich, aber nicht falsch.

Jetzt fällt mir gerade der subtile Unterschied zwischen den beiden 
Varianten auf: wenn CE für zwei Taktperioden high wäre könnte up/down 
mit meiner Variante nicht zweimal hintereinander '1' werden. Bei der 
Default-'0'-Variante legt die Synthese deshalb CE über Inverter an R, 
bei der if-Variante den Ausgang des FF. Den Multiplexer kann ich mir 
aber immer noch nicht erklären.

Gruß
Andreas

[---- (Gast)]

So meinst du das. Das Input Signal muss synchronisiert werden, da es in 
zwei unabhängige Register gespeichert wird (state und up).

Das Falsch habe ich in Klammern geschrieben, da es in deiner Schaltung 
nicht zu einem Fehler kommen kann. Mal Angenommen, up würde in der case 
über mehrer Perioden auf eins gesetzt, weiter unten wird es aber auf 0 
gesetzt, was dazu führen würde, dass es in der case wider auf 1 gesetzt 
würde. Das up würde "Toggeln". Vermutung, die Synthese erkennt nicht, 
dass up nur für eine Periode auf eins gesetzt wird, daher wird der 
Multiplexer für das Feedback von up implementiert (es soll "Toggeln").

Gruss ----

[Fpgakuechle K. (Gast)]

IMHO liegt das Problem im Verständnis der Rangfolge (Prioritäten) in 
einem FF
und im einem Prozeß:

(1) In einem (Xilinx)-FF ist reset (if R = '1' then Q <= '0') 
höherwertige als set (if s = '1' then Q<= '1'),
und set höherwertig als Dataenable (if ce = '1' then Q <= D). Q ist der 
FF Ausgang, R|S|CE die synchronen FF-Eingänge.

(2) In einem Process ist die letzte Zuweisung die höchstwertige, also 
bei

 q <= '0';
 q <= '1';
 q <= '0';

wird die letzte Zuweisung q <= '0' ausgeführt (Synthetisiert).

(3) jede zuweisung in einem getakteten Prozess "wird zu einem FF".

Punkt (3) erklärt warum state zu einen FF mit Ausgang state wird.

Punkt (2) und (3) erklären die LUT vor dem Ausgangs-FF: Das Rücksetzten 
ist hochprior (wird also unabhängig von CE ausgeführt) und damit in das 
R Signal umgeformt, der CE-Zweig ist niedrig-prior wird also zum 
datenenable mit vorgeschalteten Multiplexer.

Mit folgender Beschreibung sollte nur R und S des FF genutzt werden:

--hilfsignale
tmp      <= state & input;
set_up   <= '1' when tmp = "0001" or tmp = "0111" or tmp = "1000" or tmp = "1110" else '0';
set_down <= '1' when tmp = "0010" or tmp = "0100" or tmp = "1011" or tmp = "1101" else '0';

process(clk)
begin
if rising_edge(clk) then
  if ce = '1' then
    state <= input;
 end if;
--
 if NOT ((set_up = '1') and (ce = '1')) then
    up <= '0';
 else
   up <= '1';
 end if;
--
 if NOT ((set_down = '1') and (ce = '1')) then
    down <= '0';
 else
   down <= '1';
 end if;
end if;
end process;

Ich habe dabei das beispiel von Gast ungeformt. Mehr zu "woher kommt der 
(blöde) Mux vor D findet sich in:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=kc_priorities&iLanguageID=1&iCountryID=1

[Andreas S. (andreas) (Admin)]

1, 2 und 3 sind mir klar, wie du auf deine Schlussfolgerung kommst aber 
nicht.

R hat höhere Priorität als D/CE. Q liegt auf R. Sobald also Q aus irgend 
einem Grund high wird (if up = '1') wird das FF resettet (up <= '0'), 
egal was an D/CE passiert (die if-Abfrage kommt nach dem case). Passt 
soweit zu meinem Code. Warum muss Q jetzt noch an den Multiplexer? Habe 
ich da einen Denkfehler, oder XST?

Danke für das Beispiel, ich werde es morgen mal ausprobieren.

Den Artikel von Xilinx kenne ich, hat mir aber nicht weitergeholfen.

[Falk B. (falk)]

Was soll denn das? RS-FlipFlop? Wo leben wir denn?
Für die solide Auswertung eins Drehencoders braucht man 4 D-FlipFlops. 
Zwei um die Eingangssignale zu sampeln und zwei zum Verzögern. Aus 
diesen vier Signalen dekodiert man dann up/down.

Mfg
Falk

[Andreas S. (andreas) (Admin)]

Falk Brunner wrote:
> Was soll denn das? RS-FlipFlop? Wo leben wir denn?
> Für die solide Auswertung eins Drehencoders braucht man 4 D-FlipFlops.

> Zwei um die Eingangssignale zu sampeln

...danke, das beantwortet endlich meine Frage #1.

> und zwei zum Verzögern. Aus
> diesen vier Signalen dekodiert man dann up/down.

Ich möchte dass up/down jeweils nur für einen Takt aktiv ist, auch wenn 
langsamer abgetastet wird, darum der Reset.

[Fpgakuechle K. (Gast)]

OK jetzt verstehe ich besser, dich stört nicht der Mux vor D, sondern 
das der Muxer auch von Q abhängt.
Es liegt am XST, IMHO braucht der unbedingt ein elsif um den das 
resetsignal nicht an D zu legen. Das ist IMHO die Aussage der 
Application Note. "Wenn du einen reset willst, dann schreibe es 
unbedingt so (mit elsif)". Man kann dasselbe verhalten in VHDL auch 
anders beschreiben, aber dann "murkst er mit Multiplexer vor D herum. 
Das ist das übliche problem
mit VHDL Synthese, jeder Hersteller hat seine eigenen festlegungen wie 
der VHDL-code für ein "ordentliches" FF auszusehen hat. Da wird der VHDL 
code nicht groß analysiert, sondern stur nach der Struktur (hier elsif) 
gesucht

Und dann ist es nach meiner Erfahrung für den XST einfacher, wenn jedes 
Q extra geschrieben wird. Folgend eine Beschreibung nach deinem Beispiel

process(clk)
begin

if rising_edge(clk) then
 if ce = '1' then
    state <= input;
 end if;
--
 if up = '1' then
   up <= '0'; 
 elsif ce = '1' then
    case state & input is
      when "0001" => up <= '1';
      when "0111" => up <= '1';      
      when "1000" => up <= '1';
      when "1110" => up <= '1';
      when others => null;
    end case;
  end if;
  
   if down = '1' then
    down <= '0';
   elsif ce = '1'
    case state & input is
      when "0010" => down <= '1';
      when "0100" => down <= '1';
      when "1011" => down <= '1';
      when "1101" => down <= '1';
      when others => null;
    end case;
  end if;

end if;
end process;

Das ist wie gesagt eine codeumformung um die FF Beschaltung zu 
"optimieren". Eine drehgeberumformung schreibt man aber wie falk 
andeutet
anders. Wobei es schön wäre genau zu wissen welchen output der drehgeber 
für up und down erzeugt. Im folgenden Artikel rate ich mal ein bißchen.

[Fpgakuechle K. (Gast)]

Also 2 bit Gray drehgeber. Im Up - Fall sieht die Folge so aus
..
00
01
11
10
..
Die zwei Bit kommen parallel asynchron in den FPGA. Wo kommt CE her?
wenn es vom geber kommt so ist dieses einzusynchronisieren. Un wie lang 
ist es aktiv? und wie oft wechseln die beiden bits?


Wenn wir nur die beiden bits vom geber haben, und diese wechseln sehr 
viel langsamer als unser takt, dann so (CE lasse ich weg, da nix 
bekannt):

Entity dreh_auswert is
 port(clk_i:        in std_logic, 
      count_bits_i: in std_logic_vector(1 downto 0),
       up_oq :      out std_logic := '0',
       down_oq:     out std_logic := '0');
end entity dreh_auswert;

architecture behave of dreh_auswert is
signal bit_sync_0_q : std_logic_vector(2 downto 0);
signal bit_sync_1_q : std_logic_vector(2 downto 0);
signal old_count_q: std_logic_vector(1 downto 0);
signal old_new_q : std_logic_vector(3 downto 0);
begin

old_new_q <=  old_count_q & bit_sync_1_q(1) & bit_sync_0_q(1);
process(clk)
begin
if rising_edg(clk)

--einsynchronisieren und delay für wechselerkennung
  bit_sync_0_q <= bit_sync_0_q(1 downto 0) & count_bits_i(0);
  bit_sync_1_q <= bit_sync_1_q(1 downto 0) & count_bits_i(1);
--erkennung Wechsel counterstand
 if (bit_sync_1_q(2) /= bit_sync_1_q(1)) or  
    (bit_sync_0_q(2) /= bit_sync_0_q(1)) then
  --
  -- sichern counter
   old_count_q <= bit_sync_1_q(1) & bit_sync_0_q(1);
  --Richtung bestimmen
    case old_new_q is
      when "0001" => up_q <= '1';
      when "0111" => up_q <= '1';      
      when "1000" => up_q <= '1';
      when "1110" => up_q <= '1';
      when others => null;
    end case;
  
    case old_new_q is
      when "0010" => down_q <= '1';
      when "0100" => down_q <= '1';
      when "1011" => down_q <= '1';
      when "1101" => down_q <= '1';
    end case;
  else
  --pulsen ausgangsignale 
   down_q <= '0';
   up_q <= '0';  
 end if; --ende wechsel erkennung
end if;
end process;
end architecture behave;

[Andreas S. (andreas) (Admin)]

Danke für den Code. Ich wollte erst mal die einfache Version 
implementieren, die nur zwei Zustände auswertet (C-Code von 
http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29), weil manche 
Drehgeber nur einen Zustandswechsel pro Schritt liefern.

Sorry dass ich das mit dem CE nicht genauer erklärt habe: das wird im 
FPGA erzeugt und sorgt nur dafür dass die Eingänge nicht mit der vollen 
Frequenz von xx MHz abgetastet werden. Das sollte die Auswertung 
störsicherer machen als wenn man jeden noch so winzigen Impuls 
auswertet.

[Falk B. (falk)]

@   Andreas Schwarz (andreas)

>Ich möchte dass up/down jeweils nur für einen Takt aktiv ist, auch wenn
>langsamer abgetastet wird, darum der Reset.

Dazu braucht man keinen Reset, das ergibt sich automatisch!

Mfg
Falk

[Andreas S. (andreas) (Admin)]

Wenn das Flipflop mit dem langsamen CE arbeitet ändert sich up/down nur 
beim CE, es soll aber nach jedem Setzen nur einen Systemtakt lang aktiv 
bleiben (damit man mit dem Ausgang z.B. direkt einen Zähler hochzählen 
kann).

[Falk B. (falk)]

@  Andreas Schwarz (andreas)

>Wenn das Flipflop mit dem langsamen CE arbeitet ändert sich up/down nur
>beim CE,

Ja.

> es soll aber nach jedem Setzen nur einen Systemtakt lang aktiv
>bleiben (damit man mit dem Ausgang z.B. direkt einen Zähler hochzählen
>kann).

Gut, auch das ist kein Problem. Nimm einfach zwei FlipFlops die mittels 
CE die Daten abtasten. Der Dekoder läuft dann mit vollem Takt. Fertig.

Aber was soll das denn am Ende? So ein Dekoder besteht aus VIER 
popeligen FLipFlops und minimaler Logic. Denn kann man problemlos auf 
der vollen Geschwidigkeit laufen lassen, Stromverbrauchs ist da kein 
Thema. Und das Reagieren auf "Störimpulse" wird mit dem langsameren Takt 
auch nicht wirklich besser. Besser ist da eine Filterung per RC-Glied 
oder per "Software" über digitale Mittelwertbildung.

MfG
Falk

[Andreas S. (andreas) (Admin)]

Falk Brunner wrote:
>> es soll aber nach jedem Setzen nur einen Systemtakt lang aktiv
>>bleiben (damit man mit dem Ausgang z.B. direkt einen Zähler hochzählen
>>kann).
>
> Gut, auch das ist kein Problem. Nimm einfach zwei FlipFlops die mittels
> CE die Daten abtasten. Der Dekoder läuft dann mit vollem Takt. Fertig.

Ja, wenn ich das Eingangssignal sowieso gleich registrieren muss ist das 
naheliegend.

> Aber was soll das denn am Ende? So ein Dekoder besteht aus VIER
> popeligen FLipFlops und minimaler Logic. Denn kann man problemlos auf
> der vollen Geschwidigkeit laufen lassen, Stromverbrauchs ist da kein
> Thema. Und das Reagieren auf "Störimpulse" wird mit dem langsameren Takt
> auch nicht wirklich besser.

Je schneller abgetastet wird, desto wahrscheinlicher ist es dass sich 
durch Preller/Störimpulse zufällig eine gültige Gray-Sequenz ergibt, 
also ein Schritt falsch gezählt wird. Und da ein CE nicht viel kostet 
(der 1 kHz-Takt wird sowieso für die Tastenentprellung erzeugt) gehe ich 
lieber auf Nummer sicher.

[Falk B. (falk)]

@  Andreas Schwarz (andreas)

>Je schneller abgetastet wird, desto wahrscheinlicher ist es dass sich
>durch Preller/Störimpulse zufällig eine gültige Gray-Sequenz ergibt,

Ja, aber

>also ein Schritt falsch gezählt wird. Und da ein CE nicht viel kostet
>(der 1 kHz-Takt wird sowieso für die Tastenentprellung erzeugt) gehe ich
>lieber auf Nummer sicher.

Du gibst dich einer Illusion hin. Denn auch wenn die Wahrscheinlichkeit 
sinkt, ist sie immer noch relativ hoch, dass ein Abtastimpuls einen 
Störimpuls einfängt. Wenn schon, dann RICHTIG (tm). Etwa so.

-----------------------------------------------------------------------
--
-- Signale digital entprellen
--
-- Pulse kuerzer als debounce Takte sind werden ignoriert
--
-----------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity debounce is
    Generic (debounce : integer := 5);  -- Entprellzeit in Systemtasten
    Port ( clk   : in std_logic;        -- Systemtakt
           d_in  : in std_logic;        -- Dateneingang
           d_out : out std_logic);      -- entprellter Datenausgang
end debounce;

architecture Behavioral of debounce is

signal cnt : integer range 0 to debounce-1;
signal d_int, d_old: std_logic;

begin

d_out <= d_old;

process(clk)
begin
  if rising_edge(clk) then

    d_int <= d_in;              -- Signal abtasten

    if d_int /= d_old then
      cnt <= cnt-1;             -- count down
      if cnt=0 then
        cnt <= debounce -1;     -- Reset, neue Daten bernehmen
        d_old <= d_int;
      end if;
    else
      cnt <= debounce -1;       -- Reset, war nur ein kurzer Puls
    end if;

  end if;
end process;

end Behavioral;

Frisch aufgeräumt und erweitert

Drehgeber

MfG
Falk

[Andreas S. (andreas) (Admin)]

Falk Brunner wrote:
> @  Andreas Schwarz (andreas)
>
>>Je schneller abgetastet wird, desto wahrscheinlicher ist es dass sich
>>durch Preller/Störimpulse zufällig eine gültige Gray-Sequenz ergibt,
>
> Ja, aber
>
>>also ein Schritt falsch gezählt wird. Und da ein CE nicht viel kostet
>>(der 1 kHz-Takt wird sowieso für die Tastenentprellung erzeugt) gehe ich
>>lieber auf Nummer sicher.
>
> Du gibst dich einer Illusion hin. Denn auch wenn die Wahrscheinlichkeit
> sinkt,

Genau darum geht es doch, die Wahrscheinlichkeit zu reduzieren.

> ist sie immer noch relativ hoch, dass ein Abtastimpuls einen
> Störimpuls einfängt.

Ein einziger Störimpuls den man zufällig bei der Abtastung erwischt 
ändert nichts am Ergebnis. Nach 10 -> 11 -> 10 ist der Zählerstand immer 
noch der selbe. Wenn ich dagegen mit 50 MHz abtaste werte ich GARANTIERT 
jeden Fehler in der Schleiferbahn des Drehgebers aus. Und die 
Wahrscheinlichkeit dass in 50 Millionen Abtastungen irgend eine Sequenz 
enthalten ist die einen Zählfehler ergibt ist höher als bei 1000 
Abtastungen.

> Wenn schon, dann RICHTIG (tm). Etwa so.

Es gibt kein "richtig" und "falsch", es ist alles ein Kompromiss 
zwischen Aufwand und Nutzen. Ein CE an ein FlipFlop zu legen kostet 
weder Zeit noch FPGA-Ressourcen.

[Falk B. (falk)]

@ Andreas Schwarz (andreas)

>Genau darum geht es doch, die Wahrscheinlichkeit zu reduzieren.

Das reicht aber nicht! Statt 10 Fehler pro Sekunde hast du dann immer 
noch 1 Fehler pro Sekunde (als Beispiel).

>Ein einziger Störimpuls den man zufällig bei der Abtastung erwischt
>ändert nichts am Ergebnis.

Ohh doch. Damit kannst du genauso Schiffbruch erleiden, wenn gleich die 
Wahrscheinlichkeit geringer ist. Wasserdicht ist es denoch nicht, erst 
mit RC-Filter oder digitlem Filter.

>Nach 10 -> 11 -> 10 ist der Zählerstand immer
>noch der selbe.

Sicher, das ist er aber auch bei 50 MHz.

>Wenn ich dagegen mit 50 MHz abtaste werte ich GARANTIERT
>jeden Fehler in der Schleiferbahn des Drehgebers aus. Und die

Nein, das ist schlicht falsch.

>Wahrscheinlichkeit dass in 50 Millionen Abtastungen irgend eine Sequenz
>enthalten ist die einen Zählfehler ergibt ist höher als bei 1000
>Abtastungen.

Ja, aber ist dennoch nicht wasserdicht.

>Es gibt kein "richtig" und "falsch",

Oh doch!

> es ist alles ein Kompromiss
>zwischen Aufwand und Nutzen. Ein CE an ein FlipFlop zu legen kostet
>weder Zeit noch FPGA-Ressourcen.

In einem FPGA! sind immer ein paar FlipFlops noch frei, um die digitalen 
Filter einzubauen.

MfG
Falk

[Andreas S. (andreas) (Admin)]

Falk Brunner wrote:
> @ Andreas Schwarz (andreas)
>
>>Genau darum geht es doch, die Wahrscheinlichkeit zu reduzieren.
>
> Das reicht aber nicht! Statt 10 Fehler pro Sekunde hast du dann immer
> noch 1 Fehler pro Sekunde (als Beispiel).

Und wenn das reicht um die Spezifikation zu erfüllen? Wenn ich einen 
Drehgeber zur Eingabe von Parametern verwende, dann darf es nicht 
passieren dass man einen Schritt dreht und der Drehgeber um 5 Schritte 
springt, aber ist es völlig egal wenn bei 100 Schritten mal nur 99 
erkannt werden.

>>Ein einziger Störimpuls den man zufällig bei der Abtastung erwischt
>>ändert nichts am Ergebnis.
>
> Ohh doch. Damit kannst du genauso Schiffbruch erleiden, wenn gleich die
> Wahrscheinlichkeit geringer ist. Wasserdicht ist es denoch nicht, erst
> mit RC-Filter oder digitlem Filter.

Es gibt keine wasserdichten Lösungen, nirgendwo und auch nicht bei der 
Drehgeberauswertung. Auch dein Filter kann Fehler nicht völlig 
ausschließen.

>>Nach 10 -> 11 -> 10 ist der Zählerstand immer
>>noch der selbe.
>
> Sicher, das ist er aber auch bei 50 MHz.

Bei 10 -> 11 -> 01 -> 00 -> 10 aber nicht. Und das kann bei 50 MHz eher 
passieren als bei 1 kHz.

>>Wenn ich dagegen mit 50 MHz abtaste werte ich GARANTIERT
>>jeden Fehler in der Schleiferbahn des Drehgebers aus. Und die
>
> Nein, das ist schlicht falsch.

Wieso ist das falsch?

[Falk B. (falk)]

@  Andreas Schwarz (andreas)

>Und wenn das reicht um die Spezifikation zu erfüllen? Wenn ich einen

Dünnbrettbohrerei. Wenn ich wenig Aufwand ein Design wasserdicht machen 
kann, dann tu ich das. Egal was die Spezifikation fordert.

>Drehgeber zur Eingabe von Parametern verwende, dann darf es nicht
>passieren dass man einen Schritt dreht und der Drehgeber um 5 Schritte
>springt, aber ist es völlig egal wenn bei 100 Schritten mal nur 99
>erkannt werden.

OK.

>Es gibt keine wasserdichten Lösungen,

Aber sicher gibt es die. Und das nicht nur bei Uboot-bau ;-)

> nirgendwo und auch nicht bei der
>Drehgeberauswertung. Auch dein Filter kann Fehler nicht völlig
>ausschließen.

Aber er kann sie um Zehnerpotenzen verringern, mehr als eine niedrigere 
Abtastrate.

>Bei 10 -> 11 -> 01 -> 00 -> 10 aber nicht. Und das kann bei 50 MHz eher
>passieren als bei 1 kHz.

Ja EBEN. Du bist dir noch immer nicht über die Bedeutung der 
Wahrscheinlichkeit im Klaren.

>>>Wenn ich dagegen mit 50 MHz abtaste werte ich GARANTIERT
>>>jeden Fehler in der Schleiferbahn des Drehgebers aus. Und die

>> Nein, das ist schlicht falsch.

>Wieso ist das falsch?

Weil ich mit 50MHz Abtastung NICHT GARANTIERT JEDEN Fehler auswerte, 
allerdings ist die Wahrscheinlichkeit höher.

MfG
Falk

[Andreas S. (andreas) (Admin)]

Falk Brunner wrote:
> @  Andreas Schwarz (andreas)
>>Es gibt keine wasserdichten Lösungen,
>
> Aber sicher gibt es die. Und das nicht nur bei Uboot-bau ;-)

Und trotzdem hat das U-Boot Lenzpumpen...

>> nirgendwo und auch nicht bei der
>>Drehgeberauswertung. Auch dein Filter kann Fehler nicht völlig
>>ausschließen.
>
> Aber er kann sie um Zehnerpotenzen verringern, mehr als eine niedrigere
> Abtastrate.

Die "mehreren Zehnerpotenzen" klingen ziemlich aus der Luft gegriffen.

>>Bei 10 -> 11 -> 01 -> 00 -> 10 aber nicht. Und das kann bei 50 MHz eher
>>passieren als bei 1 kHz.
>
> Ja EBEN. Du bist dir noch immer nicht über die Bedeutung der
> Wahrscheinlichkeit im Klaren.

?

>>>>Wenn ich dagegen mit 50 MHz abtaste werte ich GARANTIERT
>>>>jeden Fehler in der Schleiferbahn des Drehgebers aus. Und die
>
>>> Nein, das ist schlicht falsch.
>
>>Wieso ist das falsch?
>
> Weil ich mit 50MHz Abtastung NICHT GARANTIERT JEDEN Fehler auswerte,
> allerdings ist die Wahrscheinlichkeit höher.

Das ist genauso "garantiert" wie deine Lösung "wasserdicht" ist.

Um das mal abzuschließen: in der Praxis scheint die Abtastung mit vollem 
Takt ausreichend zu sein, ich konnte zumindest mit meinem mechanischen 
Drehgeber keine Fehler feststellen. Aber mir war unwohl dabei, ein 
Signal das sich nur sehr langsam ändern darf so auszuwerten als würde es 
sich um einen Faktor 10^6 schneller ändern dürfen. Es ist einfach 
unnötig, es verbessert nicht die Auswertung des Nutzsignals, aber wertet 
potentiell mehr Störungen aus. Deshalb habe ich das CE eingebaut und 
damit die selbe Lösung implementiert wie sie bei Mikrocontrollern weit 
verbreitet und bewährt ist.

[Falk B. (falk)]

@  Andreas Schwarz (andreas)

>Und trotzdem hat das U-Boot Lenzpumpen...

Feiglinge ;-)

>potentiell mehr Störungen aus. Deshalb habe ich das CE eingebaut und
>damit die selbe Lösung implementiert wie sie bei Mikrocontrollern weit
>verbreitet und bewährt ist.

Womit alles im grünen Bereich ist. Bei nen Drehknopf isses ja nun nicht 
wirklich superkritisch.

Amen!

MFG
Falk