Hi, ich möchte gerne ein Datensignal, das per Impuls über eine Antenne übertragen wird auslesen. Das Signal ist folgendermaßen aufgebaut: Es gibt ein festes Zeitfenster (3,42us) in dem jeweils ein Informationsbit übertragen wird. Das erste Zeitfenster mit einem Doppelimpuls gibt sozusagen das Startsignal. Ab diesem Startsignal wird alle 3,42us ein neues Bit übertragen. Also Impuls tritt auf = 1, kein Impuls = 0. Meine Idee war den per SchmittTrigger entstörten Impuls an den Interrupt eines Atmega88 zu legen. Der Interrupt soll dann einen Timer starten können, der immer nach der Länge des Zeitfensters überläuft. Der Timer setzt beim Überlaufen ein Flag, das im Hauptprogramm gepollt wird. Das Hauptprogramm prüft dann wie viele Interrupts in dem Intervall des Zeitfensters getriggert wurden und entscheidet anhand dieser Information, ob die Startbedingung gegeben ist bzw. wie die Bits zu schreiben sind. Kann das so funktionieren? Wie könnte ich noch eine Fehlererkennung einbauen? Wahrscheinlich nur über die Menge der Impulse oder? Gruß Stephan
Hallo, so wie beschrieben ist das Protokoll komplett unbrauchbar: wenn z.B. 100 mal Null kommt, ist das ununterscheidbar von einer Signalunterbrechung, eine Resynchronistaion ist nicht mehr möglich. Bewährte Protokolle begrenzen daher die Anzahl aufeinanderfolgender Nullen oder Einsen auf 6 bis 8. Gruss Reinhard
Hi, ich hatte vergessen zu erwähnen, dass die Blöcke immer nur 20 Bit lang sind. =) Also ein Synchronisationsdoppelimpuls und dann 20 Datenbits. Gruß
Und warum verwendest Du kein Standardprotokoll? Das verbreitetste und einfachste wäre das serielle mit Start und Stoppbits und ggf. Parity. Nicht immer das Rad neu erfinden. Für weitere Fehlersicherheit kannst Du die Daten blockweise senden und eine CRC Prüfung implementieren.
U.R. Schmitt schrieb: > Und warum verwendest Du kein Standardprotokoll? Habe leider kein Einfluss auf das Sendeprotokoll. Muss es nur auswerten, um an die Daten zu kommen. > Für weitere Fehlersicherheit kannst Du die Daten blockweise senden und > eine CRC Prüfung implementieren. Werde mir die Prüfgeschichte mal ansehen. Danke für den Tipp :) Prinzipiell sollte meine Vorgehensweise aber funktionieren? Oder habe ich noch einen Denkfehler in meinem Programmablauf.... Gruß
Im Prinzip könnte Dein Algorithmus funktionieren. Allerdings solltest Du mal nachsehen, wieviele Maschinenbefehle der AVR in 3.42 µsec abarbeiten kann, und wie lange es dauert, bis auf ein externes Ereignis hin die dadurch ausgelöste Interruptroutine abgearbeitet wird. Und dann überlegen, ob es Dir gelingt, Deinen Algorithmus mit den zur Verfügung stehenden zeitlichen Vorgaben umzusetzen.
Stephan Mustermann schrieb: > Prinzipiell sollte meine Vorgehensweise aber funktionieren? Oder habe > ich noch einen Denkfehler in meinem Programmablauf.... Ich würde das als Zustandsautomat (auch "endlicher Automat" genannt) implementieren. Mal schnell angedacht: Zustand 1: Warten auf Low High Pegelwechsel (Beginn der Startsequenz) Zustand 2: Startsequenz prüfen Zustand 3: Bits lesen Übergänge: Von 1 auf 2 Wenn Pegel auf High wechselt Von 2 auf 3 Wenn nach halber Bitbreite und nach 1,5 facher Bitbreite beide Pegel High waren, sonst auf Zustand 1 zurück Von 3 auf 1: Wenn alle Bits gelesen wurden. Fehlerbehandlung? Wohl eher in einem übergeordneten Protokoll. Rufus hat vollkommen recht mit seinem Zeitaspekt. Hier wäre ggf. darüber nachzudenken, ob man nicht in Assembler programmiert und ggf. zumindest in Teilen die Zeit über die Befehle, die abgearbeitet wurden berechnet. Wenn Du dann noch ein weiteres Protokoll darüberlegen willst um Blockweise einen CRC auszuwerten kommst Du ganz schnell an die Grenzen, außer Du kannst das quasi offline erledigen, also dann wenn keine Daten gesendet werden, bzw. Du hast die Möglichkeit die Datenübertrgung kurz anzuhalten.
Hi, prima. Genau so wie den "Zustandsautomat" hatte ich mir das auch vorgestellt. Bleibt abzuwarten ob der uC schnell genug ist und die Signale sauber genug. Ich habe ausgerechnet, dass der uC in jedem Zeitfenster (also in 3,4us) etwa 70 Schritte machen kann (AtMega88A mit 20Mhz) das sollte denke ich reichen um die Flanken zu erkennen und ein Schieberegister damit zu füttern. Gruß Stephan
Bitte 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.