Forum: Mikrocontroller und Digitale Elektronik Datentelegramm, wie effizient auswerten


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von C. L. (calle)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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
von C. L. (calle)


Bewertung
0 lesenswert
nicht lesenswert
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

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Jakob (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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??

von C. L. (calle)


Bewertung
0 lesenswert
nicht lesenswert
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

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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
von C. L. (calle)


Bewertung
0 lesenswert
nicht lesenswert
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

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Patrick B. (p51d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
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

von C. L. (calle)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.