Hallo zusammen, Aus einer Funkstrecke kommt ein Telegramm mit o.g. anfänglichem Aufbau. Kein Normprotokoll wie z.B. RS232 o.ä. sondern eine nicht änderbares 128 Bit -Telegramm, diff.Manchester codiert. Ca.+/- 6200Bps scheinbar schwankend, kann auch an der Auflösung des Logikanalyzers liegen, mehr geht leider nicht. Der Wert liegt auch nicht schön in Registern vor, er kommt undvorhersehbar und muss via Bitbanging oder so empfangen werden. Zudem ist das schwierge, es aus einem ständig stattfindenden Datenverkehr auf dieser Leitung auch noch gezielt rauszufinden. Das 5V Signal geht auf einen PIC 18F2685 (Port kann ich frei wählen). Um die Informationen zu nutzen und CRC zu berechnen brauche ich das Telgramm ja erstmal komlett abgespeichert. Wie mache ich das nun am sinnvollsten? Momentan beginne ich mit der Startflanke und warte x us und checke dann, ob es "1" oder "0" ist und speichere das dann ab. Sollte der Sender aber Schwankungen in der Datenrate haben (was ich nicht genau weiß) haut dieses Verfahren ggf. nicht mehr hin. Ich kann auch nicht sagen ob die Bitbreite sich ändert. Laut Logikanalyzer und Oscar würde ich sagen, die Bitbreite ist fest; quasi sauber getaktet. Macht es mehr Sinn, das mit Pulsbreitenmessung zu tun, Interrupt und dann Takte zählen? Wie geht Ihr sowas an? Gibt es andere Methoden? Gruß CL PS hiernochmal die Taktbreiten, weil es in dem Foto nicht zu erkennen ist. von l nach r 331us 160us 488us 488us 365us 618us 472us 493us 239us 231us
Angehängte Dateien:
-
Telegramm_2.png
2,6 KB
:
Bearbeitet durch User
C. L. schrieb: > Macht es mehr Sinn, das mit Pulsbreitenmessung zu tun, Interrupt und > dann Takte zählen? Wie geht Ihr sowas an? Interrupt auf jede Flanke, erste Messung verwerfen, danach hast du genau das, was du oben aufgeschrieben hast, nur noch dekodieren. P.S. Timer signalisiert das Ende, nach etwa 1ms oder so ohne Interrupt.
:
Bearbeitet durch User
Marc V. schrieb: > erste Messung verwerfen Was meinst Du damit? Marc V. schrieb: > Timer signalisiert das Ende, nach etwa 1ms oder so ohne Interrupt. Hä?? Ich versuche mal zu interpretieren: INT auf Flanke, Timer starten, INT auf Flanke Timer stoppen und Differenz ergibt ein Ma? für die Bitbreite? CL
C. L. schrieb: > Marc V. schrieb: >> erste Messung verwerfen > > Was meinst Du damit? Erste Flanke löst zwar auch Interrupt aus, aber der Timerstand zeigt nichts sinnvolles. C. L. schrieb: > Ich versuche mal zu interpretieren: > INT auf Flanke, Timer starten, INT auf Flanke Timer stoppen und > Differenz ergibt ein Ma? für die Bitbreite? So ähnlich. INT auf jede Flanke einstellen, Timer starten. Wenn INT zuschlägt, Timer auslesen und rücksetzen, auf nächstes INT oder Timerüberlauf warten. Timer so einstellen, dass nach etwa 1ms Überlauf eintritt, was konkret bedeutet, dass dein Telegram zu Ende ist.
:
Bearbeitet durch User
Manchester ist es schonmal nicht, da Manchester nur 2 verschiedene Pulsdauern hat, entweder 1 oder 0,5 Bitzeiten. Man müßte also erstmal wissen, wie Dein Signal kodiert ist und dann würde ich die Bits gleich an den Flanken dekodieren und in ein Byte-Array schieben (je 8 Bits einschieben und dann den Byteindex hochzählen).
Wie effizient man ein Signal auswerten kann, hängt von der Codierung ab. Also erzähl doch erst mal, wie das Signal codiert ist. Kannst/willst du nicht lesen, oder weißt du garnicht, was das für ein Code sein soll??
Hi, @Peter und Marc Dann werde ich es mal so angehen. Einzige Info die ich habe ist das mit dem Differential Manchester. Evtl. ist der vordere Teil eine Sync oder Präambel. Der weitere Verlauf könnte dann doch Manchester sein. Zum Schluss ist es dann wieder wie am Anfang und das Telegramm ist zuende. Jakob schrieb: > Also erzähl doch erst mal, wie das Signal codiert ist. > > Kannst/willst du nicht lesen, oder weißt du garnicht, was > das für ein Code sein soll?? Die Tonart ist falsch. Ich hatte ja geschrieben, das es sonst keine Infos zu diesem Signal gibt also kann ich auch nichts dazu sagen. Ausserdem geht es hier nicht primär um Decodierung sondern erst mal darum es einzulesen und dann auszuwerten. Danach kann man dann weiter machen. CL
C. L. schrieb: > Evtl. ist der vordere Teil eine Sync oder Präambel. Der weitere Verlauf > könnte dann doch Manchester sein. Zum Schluss ist es dann wieder wie am > Anfang und das Telegramm ist zuende. Ja, ohne komplettes Telegram kann man nichts gescheites dazu sagen. Nimm mal den vorderen und hinteren Syncteil raus, falls die verblieben Bitbreiten im Verhältnis 1:2 sind, hast du Manchester. P.S. Toleranz +/- 25% - deswegen ist Manchester auch so gut. ;-)
:
Bearbeitet durch User
Marc V. schrieb: > Nimm mal den vorderen und hinteren Syncteil raus, falls die verblieben > Bitbreiten im Verhältnis 1:2 sind, hast du Manchester. Ja, das sind sie. Dann werde ich das mal versuchen, habe allerdings noch das Problem, das das eigentliche Nutztelegramm in einem kontinuierlichen "unwichtigen" Datenstrom eingebettet ist. Ich kann also nicht gezielt triggern sondern muss 'on the fly' das Bit ausmessen und wenn die Sync erkannt wurde, dann den Datenstrom abspeichern. CL
C. L. schrieb: > Datenstrom eingebettet ist. Ich kann also nicht gezielt triggern sondern > muss 'on the fly' das Bit ausmessen und wenn die Sync erkannt wurde, > dann den Datenstrom abspeichern. Alles wie gehabt... Timer starten aber OVF-ISR ausschalten, auf Flanken-ISR warten. Wenn BitLänge > 550ms (dein Beispiel), auf BitLänge <= (2T * 1.25) warten, Wert merken, OVF-ISR einschalten. Weiter mit Telegram bis OVF-ISR oder erneut BitLänge > 550ms kommt, danach dekodieren.
Mhm, ich bin etwas verwirrt: Wenn du doch weisst, dass es Manchester ist dann nutze doch Google! Erster Treffer mit "decode Manchester" gibt dir schon ein PDF mit 2 Varianten und sogar C-Code Beispiele... http://www.atmel.com/images/atmel-9164-manchester-coding-basics_application-note.pdf So schwer? Ok, kommt jetzt auf dein gesamtes System an, aber je nachdem bietet sich auch ein CPLD oder ein kleines FGPA für die Aufgabe an, wenn nebenbei noch viel anderes gemacht werden soll.
C. L. schrieb: > Marc V. schrieb: >> Nimm mal den vorderen und hinteren Syncteil raus, falls die verblieben >> Bitbreiten im Verhältnis 1:2 sind, hast du Manchester. > > Ja, das sind sie. > Dann werde ich das mal versuchen, habe allerdings noch das Problem, das > das eigentliche Nutztelegramm in einem kontinuierlichen "unwichtigen" > Datenstrom eingebettet ist. Ich kann also nicht gezielt triggern sondern > muss 'on the fly' das Bit ausmessen und wenn die Sync erkannt wurde, > dann den Datenstrom abspeichern. Da du von Funkstrecke sprichst, kann es sein das dein kontinuierlicher Datenverkehr einfach nur das Rauchen ist was der Empfänger ohne Träger ausgibt? Sascha
Patrick B. schrieb: > Mhm, ich bin etwas verwirrt: Wenn du doch weisst, dass es Manchester ist > dann nutze doch Google! > > Erster Treffer mit "decode Manchester" gibt dir schon ein PDF mit 2 > Varianten und sogar C-Code Beispiele... > http://www.atmel.com/images/atmel-9164-manchester-coding-basics_application-note.pdf > So schwer? Ne, nicht schwer sondern nicht klar aufgrund fehlender Informationen. Es geht ja nicht um das decodieren, sondern das einlesen und separieren. @Sascha Ich bin momentan auch der Meinung, das es ein Rauschen sein kann, weil es vor allem auch unterschiedliche Bitbreiten sind. vor dem eigentlichen Telegramm ist dann 9ms "0" und dann beginnt das Telegram. Spricht ja auch für den Träger vorweg. CL
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.