Anzeige:
Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 16 bis 30 von 55

Thema: Tutorial zum Parallelport ...

  1. #16
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.263
    Moin,

    Zitat Zitat von nobody0
    Was soll sigma-delta am Parallelport? Das eine ist ein AD-Verfahren und das andere ist digital; das passt nicht.
    Naja, aber gerade fuer die von dir vorgestellten "langsam" sich aenderenden Messwerte passt das prima - obs dann ueber nen Parallelport oder sonstirgendwie in den PC faellt ist allerdings wurscht.
    Uebrigens gehts auch prima in die andere Richtung: D->A : Ein simpler RC-Tiefpass und fertig ist der Lack - z.b. 8 analoge Ausgangsspannungen aus einem Parallelport; Aufwand: 8 Widerstaend und 8 Cs

    Zitat Zitat von nobody0
    Am Parallelport gibt's normalerweise keine Übertragungsfehler. Wenn doch, kann man das mit Leitungstreibern und Terminierung beseitigen.
    Wollte damit nur verdeutlichen, das der Graycode keinerlei Korrektureigenschaften oder auch nur Fehlererkennungseigenschaften hat.
    Zitat Zitat von nobody0
    Ja, denn mit Polling wird viel CPU-Zeit verbraten, mit Hanschaking oder IRQ sieht's zwar besser aus, aber da geht zumindest ein Bit für die Synchronisation weg und einfach nur Auslesen, so wie beim Gray-Code, reicht da nicht.
    Da steh' ich aber jetzt irgendwie maechtig aufm Schlauch. Wie soll den der Graycode Polling verhindern koennen? Will ich irgendwelche Werte einlesen, dann isses doch voellig wurscht, wie die codiert sind. Ich nehm' oder gebe halt z.b. ein 8-bit Sample, wenn ich ein Byte via parallelport ausgebe oder einlese. Und wenn ich wissen will, ob sich irgendwas am Parport geaendert hat, dann lass' ich's nen IRQ ausloesen oder ich poll' halt den Port - jenachdem wie pressant das Ereignis so ist - aber was hat das mit Graycode zu tun?

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

  2. #17
    Registrierter Benutzer
    Registriert seit
    Mar 2001
    Beiträge
    1.397
    Zitat Zitat von derguteweka
    Moin,
    Da steh' ich aber jetzt irgendwie maechtig aufm Schlauch. Wie soll den der Graycode Polling verhindern koennen? Will ich irgendwelche Werte einlesen, dann isses doch voellig wurscht, wie die codiert sind. Ich nehm' oder gebe halt z.b. ein 8-bit Sample, wenn ich ein Byte via parallelport ausgebe oder einlese. Und wenn ich wissen will, ob sich irgendwas am Parport geaendert hat, dann lass' ich's nen IRQ ausloesen oder ich poll' halt den Port - jenachdem wie pressant das Ereignis so ist - aber was hat das mit Graycode zu tun?

    Gruss
    WK
    Ganz einfach: Die Gray-codierten Werte sind immer exakt, während einfach-binäre synchron eingelesen werden müssen. Für das korrekte Einlesen ist beim Gray-Code also nix zu tun, während ansonsten ein Synchronisierungs-Signal nötig ist, das zumindest eine Signalader belegt und extra erzeugt werden muss.
    Beim Gray-Code kann man einfach dann einlesen, wenn die Daten benötigt werden; ansonsten ist die Synchronisierung nötig oder warten oder Polling.

    Die Einschränkung beim Gray-Code ist die langsame Änderung, also z. B. langsame AD-Werte oder ein Zähler, dessen Wert sich nicht sehr schnell ändert.

    Über den Parallelport kann man damit gray-codiert 13 Bit einlesen oder 12 Bit ausgeben.
    Geändert von nobody0 (18.11.05 um 23:42 Uhr)
    This is a manual signatur virus. Distribute me!

  3. #18
    Registrierter Benutzer Avatar von marvelous
    Registriert seit
    Nov 2005
    Beiträge
    17

    hilfeeeeeeeeeeeee....



    mama....verstehe nur BAHNHOF...^^

    wollte nur grundsätzliches wissen,
    hätte nie gedacht das das so ausartet


    lg mario
    /SuSE/Kernel 2.6.13-15/ http://krimskrams.2page.de

  4. #19
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.263
    Moin,

    OK, ich glaub' so langsam schwant mir, auf was du raus willst - aber das kommt mir ein bisschen so vor, als ob man mitm Akkuschrauber einen Nagel in die Wand kloppt. Das geht zwar auch besser, als den Nagel mit der blossen Faust oder mit nem Schraubenzieher in die Wand zu kriegen, aber deswegen ist ein Akkuschrauber trotzdem eigentlich nicht das richtige Werkzeug.
    Das Problem bein lesen des Ports ohne ein CLK-Signal ist einfach, dass man nicht sicher sein kann, ob sich die Daten nicht einige Nanosekunden vor oder nach dem Lesevorgang aendern, was dazu fuehren kann, dass falsche Daten eingelesen werden. Gut - wenn ich jetzt weiss, das die eingelesenen Daten gray-codiert sind und sich nur um +1, -1 oder nicht geaendert haben, dann hab' ich eine gewisse Chance das dann rauszufinden. Aber auch nicht zuverlaessig. Wenn ich aber eh' schon weiss, dass die naechsten Daten nur maximal +/-1 von den letzten gelesenen Daten abweichen koennen, dann brauch' ich fuer die Uebermittlung nach der Informationstheorie eh' nur 1.585 bit - wahrscheinlich noch weniger, wenn die Wahrscheinlichkeiten, mit denen eines der 3 Ereignisse (+1,-1, 0) auftritt unterschiedlich sind - praktisch also 2bit. Das gilt auch fuer beliebig grosse Werte - da tut dann eine extra clk-Leitung wirklich nicht mehr weh

    Es hat schon einen Grund, das gray-codierte Daten z.b. bei AD- oder DA-Wandlern nicht besonders verbreitet sind - da gibts eben keinen wirklichen Vorteil. Graycode ist dann interessant, wenn man bei Zaehlern aus irgendeinem Grund Probleme mit der Stromaufnahme hat - sei es, weil die unterschiedliche Anzahl von Flipflops, die beim Binaerzaehler kippen, Stoerungen verursachen koennen, oder weil man sich nicht von aussen (z.b. durch Messung der Stromaufnahme) in die (Smart-)Karten schauen lassen will...

    Zitat Zitat von marvelous
    mama....verstehe nur BAHNHOF...^^
    Mach' dir keinen Kopp, das sind ziemlich theoretische Probleme - mit so lustigen Problemstellungen kann man sich z.b. im Nachrichtentechnikstudium in epischer Breite befassen - Fuer 'ne LED Ansteuerung ist das zum Glueck kein Thema

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

  5. #20
    Registrierter Benutzer
    Registriert seit
    Mar 2001
    Beiträge
    1.397
    Zitat Zitat von derguteweka
    Moin,
    Das Problem bein lesen des Ports ohne ein CLK-Signal ist einfach, dass man nicht sicher sein kann, ob sich die Daten nicht einige Nanosekunden vor oder nach dem Lesevorgang aendern, was dazu fuehren kann, dass falsche Daten eingelesen werden. Gut - wenn ich jetzt weiss, das die eingelesenen Daten gray-codiert sind und sich nur um +1, -1 oder nicht geaendert haben, dann hab' ich eine gewisse Chance das dann rauszufinden. Aber auch nicht zuverlaessig.
    Falsch!
    Schliesslich ist a) ein kippendes Bit nicht definiert; es ist egal was da eingelesen wird und b) macht das maximal +1 beim hochzählen, -1 beim runterzählen (und null sonst).
    Der übertragene Wert ist in jedem Fall korrekt und genau der Wert, der entweder
    unmittelbar vor oder nach dem Kippen vorhanden war.
    Deshalb nimmt man das zum Beispiel zum auslesen von Zählern in Korrelatoren, welche die Auto- u. Kreuzkorrelationsfunktionen von Photomultiplier-Pulsen berechnen.


    Zitat Zitat von derguteweka
    , mit denen eines der 3 Ereignisse (+1,-1, 0)
    Falsch!
    Es geht hier um Bits und beim Gray-Code immer nur um ein Bit. Da gibt's nur 0 oder 1 entsprechend ENTWEDER 0 und +1 ODER 0 und -1; je nachdem ob hoch oder runter gezählt/gemessen wurde (ob nach oben oder unten gekippt wurde).


    Zitat Zitat von derguteweka
    auftritt unterschiedlich sind - praktisch also 2bit. Das gilt auch fuer beliebig grosse Werte - da tut dann eine extra clk-Leitung wirklich nicht mehr weh
    Wenn man einen 12-Bit-AD-Wandler am Parallelport hat, braucht man die 13. Eingangs-Ader für das Overflow-Bit; da müsste man das LSB für eine extra clk-Leitung opfern.
    Geändert von nobody0 (19.11.05 um 15:48 Uhr)
    This is a manual signatur virus. Distribute me!

  6. #21
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.263
    Moin,

    Zitat Zitat von nobody0
    Falsch!
    Schliesslich ist a) ein kippendes Bit nicht definiert; es ist egal was da eingelesen wird und b) macht das maximal +1 beim hochzählen, -1 beim runterzählen (und null sonst).
    Der übertragene Wert ist in jedem Fall korrekt und genau der Wert, der entweder
    unmittelbar vor oder nach dem Kippen vorhanden war.
    Deshalb nimmt man das zum Beispiel zum auslesen von Zählern in Korrelatoren, welche die Auto- u. Kreuzkorrelationsfunktionen von Photomultiplier-Pulsen berechnen.
    OK, gut - hast recht. In dem Fall, das sich die Daten nur um max. +/-1 aendern ist das Einlesen mittels Graycode moeglich.
    Zitat Zitat von nobody0
    Falsch!
    Es geht hier um Bits und beim Gray-Code immer nur um ein Bit. Da gibt's nur 0 oder 1 entsprechend ENTWEDER 0 und +1 ODER 0 und -1; je nachdem ob hoch oder runter gezählt/gemessen wurde (ob nach oben oder unten gekippt wurde).
    Betrachts' mal nicht aus der Hardwareseite, wo's nur ganze bits gibt, sondern aus der Informationstheoretischen Seite:
    Jeder Messwert, den du aufnimmst kann sich gegenueber dem letzten nur um max. +/-1 veraendern (Sonst wuerds ja auch nicht mit m Graycode funktionieren).
    D.h. bei jeder neuen Messung kann nur einer dieser 3 Faelle auftreten:
    Code:
    1.) neuer Messwert = alter Messwert
    2.) neuer Messwert = alter Messwert + 1 
    3.) neuer Messwert = alter Messwert - 1
    Damit liegt der Informationsgehalt dieser "Nachrichtenquelle" bei ld(3) = 1.585 bits.
    Es ist voellig wurscht, ob du da jetzt einen 8 bit oder 12 oder 13 oder 32 bit Messwert (absolut) hast. Der Informationsgehalt liegt immer bei 1.585 bit (oder sogar noch niedriger, wenn die 3 moeglichen Faelle nicht gleichwahrscheinlich auftreten).
    Also ist es doch recht unclever, eine Information mit 1.585 bit Informationsgehalt mit deutlich mehr Bit (z.b. 8 oder noch mehr) zu uebertragen, als es sein muss.
    Zitat Zitat von nobody0
    Wenn man einen 12-Bit-AD-Wandler am Parallelport hat, braucht man die 13. Eingangs-Ader für das Overflow-Bit; da müsste man das LSB für eine extra clk-Leitung opfern.
    Wie grad' schon angefuehrt, ist es keine clevere Loesung so etwas zu machen.
    Warum 12 - 13 Leitungen fuer was verbraten, was genauso gut mit 2 Leitungen und einem Clk geht?

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

  7. #22
    Registrierter Benutzer
    Registriert seit
    Mar 2001
    Beiträge
    1.397
    Zitat Zitat von derguteweka
    Jeder Messwert, den du aufnimmst kann sich gegenueber dem letzten nur um max. +/-1 veraendern
    ...
    Damit liegt der Informationsgehalt dieser "Nachrichtenquelle" bei ld(3) = 1.585 bits.
    Das hat mit Gray-Code nix zu tun, denn da kann zu einem Zeitpunkt nur ein Bit kippen. Und das bedeutet nur eine Phasenverschiebung durch Logikgatter-Trägheit.


    Zitat Zitat von derguteweka
    Also ist es doch recht unclever, eine Information mit 1.585 bit Informationsgehalt mit deutlich mehr Bit (z.b. 8 oder noch mehr) zu uebertragen, als es sein muss.
    Es geht hier um Gray-Code; der verwendet vollständige Kodierung. 8 Bit bedeuten auch im Gray-Code 256 Zeichen; nur sind die anders kodiert als einfach binär.


    Zitat Zitat von derguteweka
    Wie grad' schon angefuehrt, ist es keine clevere Loesung so etwas zu machen.
    Warum 12 - 13 Leitungen fuer was verbraten, was genauso gut mit 2 Leitungen und einem Clk geht?
    Wie willst du 13 Bit über 2 Leitungen und EINEM Clk(-Puls) übertragen?
    This is a manual signatur virus. Distribute me!

  8. #23
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.263
    Moin,

    Zitat Zitat von nobody0
    Das hat mit Gray-Code nix zu tun, denn da kann zu einem Zeitpunkt nur ein Bit kippen. Und das bedeutet nur eine Phasenverschiebung durch Logikgatter-Trägheit.
    Da kippt immer genau ein bit, wenn du eben um eins hoch oder runterzaehlst. Diese Eigenschaft nutzt du aus, um auf ein Clk-Signal verzichten zu koennen.
    Zitat Zitat von nobody0
    Es geht hier um Gray-Code; der verwendet vollständige Kodierung. 8 Bit bedeuten auch im Gray-Code 256 Zeichen; nur sind die anders kodiert als einfach binär.
    Richtig, ich hab' hoffentlich auch nix anderes gesagt.
    Zitat Zitat von nobody0
    Wie willst du 13 Bit über 2 Leitungen und EINEM Clk(-Puls) übertragen?
    Das versuch' ich dir ja zu erklaeren :Ich muss in dem von dir angenommenen Fall eben niemals die 13 Bit uebertragen. Es reichen 2 bit dicke. Weil eben deine Quelle dadurch, dass du die Einschraenkung auf "langsame" Aenderungen machst, automatisch keine 13 bit an Information mehr bereitstellt, sondern nur die 1.5bla bit. Und fuer die reichen halt 2 bit Leitungskapazitaet.
    Klar hat dein AD-Wandler immernoch die 13 Bit Ausgangsdatenwortbreite, aber die muessen nicht zwangslaeufig in den PC uebertragen werden, um den 13 bit Wert zu kennen; es reichen eben 2 bit.

    Um die Verwirrung noch zu steigern:
    Wenn man den Fall, dass der neue Messwert genau gleich dem alten Messwert ist, zu einem der beiden anderen Faelle dazurechnet (was man auch recht gut machen kann, den die Wahrscheinlichkeit, dass 2 analoge Werte "genau" gleich sind, ist nahezu beliebig klein (OK, bei der Elementarladung sind dann irgendwann Grenzen) - dann braucht man sogar nur noch 1 bit Daten und Clk zu uebertagen. Das waere dann die von mir ganz am Anfang angesprochene Sigma-Delta Geschichte.

    Ist man aber schonmal soweit, dann kann man auch noch sagen, dass bei 1 bit Datenbreite Graycode und "normale" Binaerkodierung identisch sind und man sich dann auch noch das Clk Signal sparen kann...
    Das zurechnen des Falles "neuer Messwert = alter Messwert" zu einem der beiden anderen Faelle, spart also 1-2 Leitungen ein, erkauft mit einer Ungenauigkeit von +/- 0.5LSB - damit kann man oft leben.

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

  9. #24
    Registrierter Benutzer
    Registriert seit
    Mar 2001
    Beiträge
    1.397
    Das mit den wenigen Leitungen kann nur funktionieren, wenn du ständig pollst und zudem den Anfangs-Zählerstand kennst; wenn auch nur ein Bit verloren geht, zählt du falsch!
    Ich benutze Gray um eben NICHT zu pollen!
    Ausserdem geht das mit den 1-2 Adern nicht mit Speed-Gray, bei dem nicht nur +-1 gemacht wird, sondern allgemein auch schneller veränderliche Werte übertragen werden:
    Es werden alle möglich zulässigen Gray-Werte berechnet, also der Wert, den man nach Kippen von BIT0 hat, ... den Wert, den man nach Kippen von BITc hat (0xc=13; allgemein kann das ein anderer Wert sein). Danach wird von den 14 Codeworten dasjenige Codewort genommen, das dem Soll-Wert am nächste kommt und dieses übertragen. Diese Datenübertragung ist zwar nicht exakt, aber bei nicht allzu schnellen Analog-Signalen und nicht hochgenauem AD-Wandler geht das im Rauschen unter.
    Deshalb benutze ich bei der AD-Wandlung Speed-Gray mit bis zu 400 kHz am Parallelport.
    This is a manual signatur virus. Distribute me!

  10. #25
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.263
    Moin,

    Zitat Zitat von nobody0
    Das mit den wenigen Leitungen kann nur funktionieren, wenn du ständig pollst und zudem den Anfangs-Zählerstand kennst; wenn auch nur ein Bit verloren geht, zählt du falsch!
    Ich benutze Gray um eben NICHT zu pollen!
    Aber sowie bei deinem Graycode eine Messung verloren geht, verlierst du auch deine Sicherheit, das sich nur ein Bit aendert...
    Zitat Zitat von nobody0
    Ausserdem geht das mit den 1-2 Adern nicht mit Speed-Gray, bei dem nicht nur +-1 gemacht wird, sondern allgemein auch schneller veränderliche Werte übertragen werden:
    Es werden alle möglich zulässigen Gray-Werte berechnet, also der Wert, den man nach Kippen von BIT0 hat, ... den Wert, den man nach Kippen von BITc hat (0xc=13; allgemein kann das ein anderer Wert sein). Danach wird von den 14 Codeworten dasjenige Codewort genommen, das dem Soll-Wert am nächste kommt und dieses übertragen. Diese Datenübertragung ist zwar nicht exakt, aber bei nicht allzu schnellen Analog-Signalen und nicht hochgenauem AD-Wandler geht das im Rauschen unter.
    Deshalb benutze ich bei der AD-Wandlung Speed-Gray mit bis zu 400 kHz am Parallelport.
    Ich bezweifel' nicht, dass das irgendwie funktioniert, die einen nennens halt Speed-Gray, die anderen maximum likelihood estimation - Huups, kommts mir nur so vor, oder hast du an deinem Tutorial den betreffenden Absatz geaendert? Ich mein, die Stelle, ueber die ich gestolpert bin, nicht mehr zu finden
    Dann will ich mal mein Korinthenpupsen hier langsam einstellen

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

  11. #26
    Registrierter Benutzer
    Registriert seit
    Mar 2001
    Beiträge
    1.397
    Zitat Zitat von derguteweka
    Moin,
    Aber sowie bei deinem Graycode eine Messung verloren geht, verlierst du auch deine Sicherheit, das sich nur ein Bit aendert...
    Aber nur beim Empfänger und das interessiert den nicht; der will nur Daten einlesen und wie die genau aussehen ist egal; hauptsache sie stimmen, werden also korrekt eingelesen. Danach kommt dann die Konversion Gray -> binär und der Empfänger verwendet die Binärdaten; alles andere interessiert nicht.

    Deshalb kann der AD-Wandler am Parallelport mit einigen MHz arbeiten, also die gray-kodierten Werte ändern, unabhängig davon, wie schnell/langsam die Werte vom Parallelport gelesen werden.
    Das Limit ist nur die Zeitspanne, die zum Übertragen der Werte in die Eingangs-Register dauert, denn in dieser Zeit (ca. 100 ns) darf nur maximal ein Bit kippen.
    This is a manual signatur virus. Distribute me!

  12. #27
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.263
    Moin,

    Zitat Zitat von nobody0
    Aber nur beim Empfänger und das interessiert den nicht; der will nur Daten einlesen und wie die genau aussehen ist egal; hauptsache sie stimmen, werden also korrekt eingelesen.
    Genau da liegt doch der Hund begraben:
    Wenn sie immmer "korrekt" eingelesen werden koennten, also immer zu einem Zeitpunkt zu dem sie sich sicher nicht aendern (also mit einem Clk Signal), dann braeuchts ja dieses ganze Theater mit Graycode garnicht. Der Graycode ist aber nur dann sicher, wenn ich bestimmte Anforderungen an meine Daten stelle ("nur langsame Aenderungen"). Wenn sich die Daten "schnell" aendern, nuetzt der Graycode nix, klar kann ich dann noch anfangen, systematisch zu raten (maximum likelihood), aber da hat der Graycode gegenueber anderen Codierungen imho nicht mehr unbedingt die Nase viel weiter vorne.
    Zitat Zitat von nobody0
    Danach kommt dann die Konversion Gray -> binär und der Empfänger verwendet die Binärdaten; alles andere interessiert nicht.
    Kommt halt auf die Problemstellung an, obs interessiert, wenn die Daten nicht stimmen und das nicht gemerkt wird...
    Zitat Zitat von nobody0
    Deshalb kann der AD-Wandler am Parallelport mit einigen MHz arbeiten, also die gray-kodierten Werte ändern, unabhängig davon, wie schnell/langsam die Werte vom Parallelport gelesen werden.
    Das Limit ist nur die Zeitspanne, die zum Übertragen der Werte in die Eingangs-Register dauert, denn in dieser Zeit (ca. 100 ns) darf nur maximal ein Bit kippen.
    OK, die kritische Zeitspanne sollte noch ne Zehnerpotenz kleiner sein, sogar der gute, alte 74ALS374 hat ne Setuptime von 6 nsec und ne holdtime von 1 nsec. D.h. wenn ich einen Wandler hab, der mir 1MSamples/sec liefert, und ich les' ohne Clksignal, dann verletz' ich mit ner Wahrscheinlichkeit von 7/1000 eine der Zeiten - ob sichs auf die Daten auswirkt, ist dann auch noch fraglich, also krieg' ich mit 99,3% Wahrscheinlichkeit die richtigen Daten, sogar ganz ohne Gray.

    Aber mal n Beispiel mit jeweils 4 bit breiten Samples:
    Ich hab beim letzten mal den Wert "0010" eingelesen, diesesmal lese ich den Wert "0101" ein. Wenn ich jetzt mit Graycode arbeite, dann weiss ich, dass ich entweder mindestens zwei Messwerte verpasst hab' oder sich die Messwerte doch schneller geaendert haben oder das ich irgendwelche Bits "falsch" eingelesen hab' (Eben durch eine Verletzung der mindest Setup/hold Zeiten).
    - ernsthaft glauben wollt' ich so erhaltenen Werten in keinem Fall - wurscht ob Graycodiert oder binaer

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

  13. #28
    Registrierter Benutzer
    Registriert seit
    Mar 2001
    Beiträge
    1.397
    Das sich die Werte am Eingang nicht sehr schnell ändern dürfen ist natürlich die Voraussetzung, aber bei 400 kHz lese-Frequenz am Parallelport bedeutet das einige MHz. Wenn man von den 6 ns ausgeht, kann man über Gray-Codierung bis 166 MHz Frequenzen fehlerfrei über den Parallelport messen und das ist nicht allzu langsam.
    Bei der AD-Wandlung hat man mit Speed-Gray bei den 400 kHz auch praktisch immer exakte Werte; für die Rechnung zum Nachweis bin ich aber zu faul
    This is a manual signatur virus. Distribute me!

  14. #29
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.263
    Moin,

    Zitat Zitat von nobody0
    Das sich die Werte am Eingang nicht sehr schnell ändern dürfen ist natürlich die Voraussetzung, aber bei 400 kHz lese-Frequenz am Parallelport bedeutet das einige MHz. Wenn man von den 6 ns ausgeht, kann man über Gray-Codierung bis 166 MHz Frequenzen fehlerfrei über den Parallelport messen und das ist nicht allzu langsam.
    Hilfe! Deine fehlererkennenden Eigenschaften verliert dein Graycode ganz schnell, eben sowie sich das Signal schneller aendert, eben genau deshalb, weil ein z.b. 8bit-Graycode 256 verschiedene legale Werte annehmen kann.
    Zitat Zitat von nobody0
    Bei der AD-Wandlung hat man mit Speed-Gray bei den 400 kHz auch praktisch immer exakte Werte; für die Rechnung zum Nachweis bin ich aber zu faul
    Das glaub' ich dir sofort, denn mittels der ueberschlaegigen Hausnummer von mir mit den 6+1 nsec setup& hold time sampelst du bei 400KHz alle 2.5 µsec, also koennten Fehler prinzipiell nur bei 7nsec/2.5µsec auftreten, also 0.28% der Samples . Aus (leidvoller - zum Glueck wars nicht meine Schuld) Erfahrung weiss ich, das die Verletzung der setup&hold Zeiten bei vielen Bausteinen ueberhaupt nicht zu Problemen fuehrt - nur wehe, der Hersteller wechselt mal das Fabrikat des Chips - dann ist ploetzlich die Ka*ke am dampfen...
    Nochwas zur "langsamen" Aenderung - wenn du mit deinem Wandler ein "langsames" Signal abtasten willst (also hoechstens +/- 1 bit Aenderung), dann wuerde das bei einem vollausgesteuerten Sinus als Eingangssignal eine maximale Frequenz von
    Code:
    Fsample/(2*PI*(2^(N-1)))
    (das -1 wegen dem Vorzeichen und der Naehrung sin(x)=x fuer kleine Argumente) bedeuten, konkret mit 400KSamples/s und 12 bit Aufloesung also eine maximal zulaessige Frequenz von 31 Hz bedeuten. D.h. sowie du Signale von mehr als 31 Hz verarbeitest, musst du entweder die Aussteuerung runtersetzen (schwachsinnig) oder die Korrektureigenschaften deines Grays gehen langsam (OK, mach noch 2 - 3 Oktaven deine Maximumlikelihood) vor die Hunde.

    Langes Gesabbel, kurzer Sinn: Dass das bei dir hinhaut, liegt hauptsaechlich nicht am Graycode, sondern an der im Vergleich zur setup&hold Zeit recht niedrigen Samplerate.

    Hast du mal n paar Links zu den Kreuzkorrelatoren, die mit Graycode schaffen?
    Google liefert mir Filmkameras und Grauwale

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

  15. #30
    Registrierter Benutzer
    Registriert seit
    Mar 2001
    Beiträge
    1.397
    Zitat Zitat von derguteweka
    Moin,
    Hilfe! Deine fehlererkennenden Eigenschaften verliert dein Graycode ganz schnell,
    Fehlerkorrektur und Gray-Code sind zwei verschiedene Dinge; die haben nix mit einander zu tun. Gray-Codierung ist nur eine robuste Codierung, bei der jeweils maximal ein Bit kippen kann und das bedeutet im worst case nur eine Phasenverschiebung, aber niemals einen falschen Wert.


    Zitat Zitat von derguteweka
    Das glaub' ich dir sofort, denn mittels der ueberschlaegigen Hausnummer von mir mit den 6+1 nsec setup& hold time sampelst du bei 400KHz alle 2.5 µsec, ...
    Unsinn; wenn mit 400 kHz vom Parallelport gelesen wird, hat das mit Sample-Frequenz des AD-Wandlers nix zu tun. Und wenn der AD-Wandler mit 4 MHz und Speed-Gray arbeitet, wird die durch Gray-Kodierung bedingte Nicht-Exaktheit der Ausgabe vernachlässigbar, denn mehr als 200 kHz kann man ohnehin nicht auflösen und die sind mit 4 MHz Speed-Gray sehr genau verfolgbar.


    Zitat Zitat von derguteweka
    Hast du mal n paar Links zu den Kreuzkorrelatoren, die mit Graycode schaffen?
    Google liefert mir Filmkameras und Grauwale
    Nach gray code counter oder grey code counter suchen ...
    This is a manual signatur virus. Distribute me!

Ähnliche Themen

  1. Kein Parallelport unter Cups/Kernel-2.6.8
    Von DERRICHTER im Forum System installieren und konfigurieren
    Antworten: 5
    Letzter Beitrag: 14.09.04, 16:01
  2. Bluetooth und Motorola v525 Tutorial
    Von City][Sepp im Forum Tipps und Tricks
    Antworten: 7
    Letzter Beitrag: 20.05.04, 14:54
  3. Laptop - Ethernet (Parallelport) - Kernel 2.4.18
    Von comrad im Forum System installieren und konfigurieren
    Antworten: 0
    Letzter Beitrag: 19.03.02, 10:06
  4. parallelport
    Von Linuxexplorer im Forum System installieren und konfigurieren
    Antworten: 2
    Letzter Beitrag: 09.01.02, 11:29
  5. Vernünftiges Firewall Tutorial für IPTables
    Von Catonga im Forum Linux als Server
    Antworten: 6
    Letzter Beitrag: 20.08.01, 17:52

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •