mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Baudrate RS232 herausfinden


Autor: Michael Glaser (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich habe hier eine Datei, geloggt aus einer RS232-Schnittstelle. Ca 5sek 
lang. Kann mir einer sagen, welche Baudrate es ist? Habe es mit 115k 
probiert. Kann man das mit einer Log-Datei feststellen? Oder bedarf es 
da spezieller Geräte? Vielen Dank.

Autor: Stefan Us (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
So geht das nicht. Du musst zuerst die richtige Baudrate einstellen, 
sonst empfängt dein Anschluss nur Müll.

Autor: Sapperlot W. (jetztnicht)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Da Einfachste ist mit einem Oszilloskop die Zeit fuer ein Bit zu messen.

Autor: Christian Müller (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder mit Ausprobieren, wenn's TXT ist!

Gruss Chregu

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Kann mir einer sagen, welche Baudrate es ist?

ja, "geloggt" mit 115k (test_115.log)

was drin steckt, das ginge mit der richtigen Baudrate loggen oder Oszi 
und beim loggen ansehen.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Kann man das mit einer Log-Datei feststellen?

Nicht mit dieser. Verschiedene Baudraten ausprobieren ginge mit einer 
Log-Datei, in der alle Flanken des Signals mit Zeitstempel aufgezeichnet 
sind, die hast du aber nicht. Mein Protokollanalysator macht das so, der 
hat aber sowieso auch eine Funktion zur Baudratenerkennung. Wobei zu 
beachten ist: man muss nicht nur die Baudrate herausfinden, sondern auch 
die Parameter Wortlänge, Parity, Stoppbits, um was vernünftiges zu 
empfangen. Das ergibt mehr als 100 Varianten.

Georg

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Für alle i∈[0,98] hat das Byte an der Position 4+260·i den Wert 53+i.

Zufall?

Wenn nicht, dann hast du die richtige Baudrate bereits gefunden.

Wenn du etwa dreimal so viele Daten (also statt 5 ca. 15 Sekunden)
aufzeichnest, müsste dieses Zählerbyte irgendwann überlaufen. Falls dann
eines der beiden Nachbarbytes inkrementiert wird, kannst du ziemlich
sicher sein, dass die Daten mit Absicht so aussehen und damit die 115200
Baud stimmen.

: Bearbeitet durch Moderator
Autor: M. Köhler (sylaina)
Datum:
Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
Ich hab mir das File mal mit nem simplen Textviewer angeschaut. 
Interessant die rot eingerahmte Spalte. Fällt da was auf? ;)
Das ist viel zu viel System für ne zufällige Zeichenfolge aufgrund 
falsch eingestellter Baudrate. Ich denke daher, dass die 115 kBd schon 
völlig korrekt sind, nun muss man nur noch herausfinden, was die Daten 
zu bedeuten haben.

Autor: Christian Müller (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hei, super beobachtet. Habe das File auch schon offengehabt, aber 
irgendwie nichts bemerkt. Aber jetzt wo Du's sagst! :-))

Auch in Col 14 und 256 gibt es so ändernde Zeichen, aber ohne 
ersichtliche Reihenfolge.

Bis jetzt bin ich immer davon ausgegangen, dass es eine viel niedrigere 
Baudrate ist, und einfach bei steigenden Flanken ein Startbit sieht, 
auch mitten im Zeichen.

Sich ändernde Zeichen würden dann grössere Sprünge machen als nur 
Inc/Dec um 1.

Damit ist wohl ziemlich sicher dass es hundertfünfzehn-zweihundert 
ist...

Gruss Chregu

Autor: M. Köhler (sylaina)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Christian M. schrieb:
> Hei, super beobachtet.

Das geübte Programmierer-Auge erkennt sofort die ASCII-Tabelle, wenn es 
sie sieht. ;)

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für eure Unterstützung . Also kann man davon ausgeben,daß 
die 115kb stimmen. Ist das möglich, dass  die Zeichen der umrahmten 
Stelle ein startbit ist? oder ein zeit/index-Wert?  sind denn alle 
Zeichen immer glei,oder ändert sich da auch -abgesehen von dem 
index-wert - noch ein anderer Wert?.

Autor: Christian Müller (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das Startbit siehst Du nicht. Das ist beim Übertragen im Zeichen 
"enthalten" und wird dann wieder "entfernt".
Ausser den von sylaina gezeigten Zeichen, die in der ASCII Tabelle 
stehts um eins steigen, eben noch das 14. und 256. Zeichen.
Am Ende der Zeile ist ein LF, und sonst eine Menge NUL.
Öffne das Ganze mal in einem Texteditor, der auch nicht druckbare 
Zeichen darstellen kann, oder in einem HEX-Editor! Nur Du weisst, von 
was einer Maschine/Apparat sie kommen...

Gruss Chregu

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian M. schrieb:
> Nein, das Startbit siehst Du nicht. Das ist beim Übertragen im Zeichen
> "enthalten" und wird dann wieder "entfernt".

Das ist nur die halbe Wahrheit und funktioniert nur, wenn der Empfänger 
richtig synchronisiert hat. Dir richtige (Neu-)Synchronisation auf das 
Startbit funktioniert nur, wenn der Empfänger vorher im Wartezustand 
war. Innerhalb eines kompakt (i.e. ohne Pause zwischen den Zeichen) 
übertragenen Blocks, hat der Empfänger keine Garantie, dass er nicht 
irgendein Bit als vermeintliches Startbit auffasst, wenn er vorher nicht 
richtig auf Start/Stop-Bits "eingerastet" war. Meist wird er sich 
irgendwo im Block wieder fangen, aber bis dahin kann durchaus Müll 
rauskommen und Start-Stop-Bits als vermeintliche Datenbits - Statistik 
eben.

Autor: Adapter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Ich hab mir das File mal mit nem simplen Textviewer angeschaut.
> Interessant die rot eingerahmte Spalte. Fällt da was auf? ;)
> Das ist viel zu viel System für ne zufällige Zeichenfolge aufgrund
> falsch eingestellter Baudrate. Ich denke daher, dass die 115 kBd schon
> völlig korrekt sind, nun muss man nur noch herausfinden, was die Daten
> zu bedeuten haben.

Gute Arbeit, Holmes!

:-)

Weitere These: Sieht so aus, als ob das } ein Framestartzeichen und das 
~ ein Frameendzeichen ist (so ein bisschen an PPP angelehnt). Ich würde 
mal etwas länger mitschneiden und sehen, ob in dem "variablen" Part 
(also die ASCII Tabelle durch) diese beiden Zeichen mit durchlaufen 
werden. In einem sauber spezifizierten Protokoll dürfen nämlich die 
Framingzeichen innerhalb des Frames nicht auftauchen, damit der 
Datenstrom sauber auf das Frame synchronisiert werden kann. Die müssten 
dann durch Transposition o.ä. manipuliert werden.

Also nochnmal mitschneiden (mindestens 256 Zyklen)!

Autor: Michael Glaser (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
nach etwas Pause, konnte ich eine neue Datei erstellen. Was meint ihr? 
vielen Dank.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die enthält ja nur 00- und E0-Bytes. Da war deine erste Datei spannender 
:)

Autor: Michael Glaser (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Na prima :(
Neuer Versuch :)
Ist jetzt was sinnvolles, zum ersten Beispiel passendes passiert? Vielen 
Dank.

Autor: Martin H. (mahi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für eine Antwort erwartest Du?
Die Baudrate scheint immernoch zu passen.
Wie die Daten zu interpretieren sind, musst Du wissen.
Vielleicht kann hier jemand dabei helfen, wenn Du sagst woher die Daten 
stammen...

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich erwarte keine Antwort, ich würde mich nur über die Antwort "ja, 
diesmal hat es geklappt, Daten sind dem Muster entsprechend" freuen ;)

Nein, weil man ja die Daten vom Muster einem Gerät zuordnen könnte, 
nicht umgekehrt. Wer die Daten kennt, kennt auch ein Gerät dazu :)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Habe es mit 115k probiert.
Warum?
Hast du es auch mal mit anderen Baudraten "probiert"? Es gibt ja nicht 
allzuviele "genormte"...

Autor: Michael Glaser (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
das wurde alles oben schon geklärt...

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So auf die Schnelle:

Man kann die Daten ähnlich wie im ersten Beispiel in Abschnitte
unterteilen, die sich in ähnlicher Form wiederholen. Allerdings waren
diese Abschnitte im ersten Beispiel 260 Byte groß, jetzt sind es nur
noch 256 Byte. Außerdem werden vor dem ersten dieser gleichartigen
Abschnitte noch Daten übertragen, die nicht in dieses Schema passen
(vielleicht eine Art Startmeldung).

Wie im ersten Beispiel enthält jeder dieser Abschnitte eine Art
fortlaufende Nummer. Im erste Beispiel wurde diese von 53 bis 151
hochgezählt. Da diese Zahlen mit 8 Bit darstellbar sind, war es nicht
klar, ob diese Nummer aus einem einzelnen oder aus mehreren Bytes
bestehen (s. mein Beitrag vom 30.5.). Im neuen Beipiel kann man
erkennen, dass die Nummer aus zwei Bytes im Little-Endian-Format
zusammengesetzt ist. Ihr Wert reicht von 11 bis 2372.

Der Bytestrom enthält somit eine aufsteigende Sequenz von über 2000
16-Bitzahlen, die kaum durch falsche Abtastung entstanden sein kann. Die
115 kbaud würde ich damit als endgültig gesichert ansehen.

Vielleicht schaue ich mir die Daten heute Abend noch einmal etwas
genauer an.

Darf man fragen, von welchen Geräten diese Daten stammen?

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hört sich schon besser an, vielen Dank :)
Ist ein Steuergerät einer Automatiesierungsmaschine, so einer Art 
Fräs/Drehmaschine

Habe ich das richtig verstanden: beim ersten, kurzen Log sind es 
260Zeichen zwischen Anfangs- und Endzeichen. Jetzt, beim 2ten Log, sind 
es 256 Zeichen?

Autor: Yalu X. (yalu) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Habe ich das richtig verstanden: beim ersten, kurzen Log sind es
> 260Zeichen zwischen Anfangs- und Endzeichen. Jetzt, beim 2ten Log, sind
> es 256 Zeichen?

Es gibt keine expliziten Anfangs- und Endzeichen und auch keine
Prüfsumme zur Erkennung von Übertragungsfehlern, was bei einem auf
RS-232 laufenden Kommunikationsprotokoll schon etwas seltsam ist.

Hier sind ausschnittsweise drei Beispieldatensätze aus der neuen
Log-Datei:

<——————————————————————————————— 256 Bytes ———————————————————————————————>
0b 00 ... 91 01 00 8d 02 00 7b 23 01 ... 2d 05 64 47 ... 64 49 8b ... 00 00
0c 00 ... 95 01 00 8d 02 00 7b 24 01 ... 2d 05 64 3d ... 64 49 8b ... 00 00
0d 00 ... 94 01 00 8d 02 00 7b 24 01 ... 2d 05 64 33 ... 64 49 8b ... 00 00  

Die ersten beiden Bytes bilden die fortlaufende 16-Bit-Nummer, von der
ich oben schrieb (hier also dezimal 11, 12 und 13). Man erkennt in den
Datensätzen an mehreren Stellen ähnliche Bytefolgen. Da diese sich alle
256 Byte in ähnlicher Form wiederholen, kam ich zum Schluss, dass die
Datenübertragung wohl in Sätzen zu je 256 Byte erfolgt.

Die Log-Datei enthält 592384 Bytes und damit 592384/256=2314 Datensätze.
Die ersten beiden davon sind anders aufgebaut als der Rest (der zweite
besteht sogar aus lauter Nullen), deswegen betrachten wir nur die 2312
verbleibenden Datensätze.

Die Frage ist nun, welche Bedeutung die 256 Bytes jedes Datensatzes
haben. Die ersten beiden, also Byte 0 und Byte 1, nummerieren die
Datensätze einfach durch. Von den restlichen 254 Bytes ändern sich viele
während der Aufzeichnung überhaupt nicht. Möglicherweise ändern sie
sich, wenn irgendwelche Komponenten der Maschine aktiviert werden, was
aber zum Zeitpunkt der Aufzeichnung nicht geschehen ist.

An anderen Stellen ändern sich die Bytes aber tatsächlich, und ich
vermute, dass es sich dabei größtenteils um irgendwelche Sensormesswerte
handelt, da ihre Werte relativ kontinuierlich steigen und fallen, aber
nicht so systematisch wie die laufenden Nummern in den ersten beiden
Bytes. Bei einigen Bytes habe ich den Eindruck, dass sie für sich
alleine einen 8-Bit-Messwert darstellen, andere scheinen als Byte-Paar
einen 16-Bit-Messwert zu bilden.

Ich habe die veränderlichen Bytes bzw. Byte-Paare über alle 2312
Datensätze als Digramme (32 Stück) plotten lassen und die Plots als
Zip-File angehängt. In den Dateinamen sind jeweils die Byte-Positionen
der geplotteten Daten innerhalb der Datensätze angegeben. Zusätzlich
habe ich eine Datei mit den 32 Datenreihen in Tabellenform angehängt.

Zwei Beispiele dieser Plots habe ich exemplarisch direkt angehängt,
damit nicht jeder das ganze Zip-File herunterladen und auspacken muss.
Die Daten in byte002-003.png könnten vielleicht den Motorstrom eines der
Antriebe darstellen. Die Daten in byte161-161.png könnten vielleicht von
einem Inkrementalgeber mit 8-Bit-Zähler stammen, mit dem die Drehzahl
bspw. einer ständig laufenden Spindel überwacht und geregelt wird.

Einige der Diagrammkurven weisen große Sprünge auf, um dann wieder für
eine gewisse Zeit konstant zu verlaufen. Evtl. sind das gar keine
Messwerte, sondern Statusinformationen.

Um das Ganze genauer zu analysieren, müsste man die gesendeten Daten
beobachten, während die Maschine läuft, um zu sehen, wie sie sich bspw.
mit der Position und der Geschwindigkeit der einzelnen Antriebe ändern,
Einige der im Log unveränderlichen Daten zeigen vielleicht auch den
Status von Bedienelementen an und können durch Betätigen derselben zur
Änderung bewegt werden.

Du hast also noch einige Arbeit vor dir, wenn du tatsächlich das
kommunikationsprotokll vollständig analysieren möchtest ;-)

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke für die Analyse und werde wohl das Wochenende deine 
Ausführungen auswerten, so gut es geht ;)

Es gibt also keine Start/Stopzeichen, wie noch beim ersten Log von dir 
vermutet, richtig? Ich bin jetzt leider total enttäuscht, ich dachte 
nämlich, daß das der Ansatz ist, die Daten loggen und entschlüsseln zu 
können? Denn wie soll man den Anfang bzw. das Ende der 256byte finden? 
Der Datenzähler ändert sich ja und kann so keinen "Nullpunkt" mehr 
bilden...

Autor: Ruediger Asche (Firma: keine) (rac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Ich danke für die Analyse und werde wohl das Wochenende deine
> Ausführungen auswerten, so gut es geht ;)
>
> Es gibt also keine Start/Stopzeichen, wie noch beim ersten Log von dir
> vermutet, richtig? Ich bin jetzt leider total enttäuscht, ich dachte
> nämlich, daß das der Ansatz ist, die Daten loggen und entschlüsseln zu
> können? Denn wie soll man den Anfang bzw. das Ende der 256byte finden?
> Der Datenzähler ändert sich ja und kann so keinen "Nullpunkt" mehr
> bilden...

Sehr gute Analyse, Yalu, chapeau!!!

Tja, ungeframte serielle Protokolle sind richtig ekelig... dann kann es 
sein, dass entweder das timing kritisch ist (also z.B. zwischen Ende 
eines Frames und Start des neuen Frames strikte Zeitvorgaben bestehen) 
oder aber zusätzliche Leitungen zur Synchronisation benutzt werden. Für 
beides reicht das logging in der Form nicht aus. Müsstest Du mal ein 
Oszi ranhängen und möglichst ein komplettes Paket mitschneiden, dabei 
alle durchverbundenen Leitungen (ausser vielleicht Masse ;-)) 
anschliessen.

Du sagst ja aber, dass das physikalische Protokoll RS232 ist. Hast Du 
beide Seiten zum loggen zusammengeführt, oder ist das nur der Trace in 
eine Richtung? Fehlen also vielleicht Soft ACKs, die das Protokoll 
synchronisieren?

: Bearbeitet durch User
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Denn wie soll man den Anfang bzw. das Ende der 256byte finden?

Es könnte einfach eine Ruhepause zwischen den Datensätzen sein. Diese 
kann man mit einer Timeoutbehandlung beim Lesen herausfinden. Aus Deinen 
Logs gehen solche Zeiten (Timestamps) ja leider nicht hervor.

Sollten die Daten tatsächlich kontinuierlich übertragen werden, kannst 
Du Dich nur auf bestimmte Muster einklinken, d.h. Du wartest, bis eine 
unveränderliche Bytesequenz kommt. Yalu schrieb ja, dass einige Werte 
innerhalb des Datenstroms konstant sind.

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, einige Werte sind konstant, aber wie schon vermutet könnten das auch 
konstante Bedingungen etc sein. Darauf kann man sich wohl nicht 
verlassen.

Timing? also es ist definitiv nur die RS232-Leitung. Nix weiter, kein 
Shake oder DX oder so.

Wie könnte man denn ein besseres Logging über ein Terminalprogramm 
einrichten, was speziell auf Timing aus ist?

Autor: Ruediger Asche (Firma: keine) (rac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
>
> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Bei HTerm kannst Du mit Zeitstempeln loggen.

Aber wie war das mit der Rückrichtung? Ist die im log mit drin?

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze Hterm :) 0.81 beta, ist wohl die aktuellste Version...wo 
stellt man da was sein? Höre ich zum ersten Mal..

Rückrichtung? Die Maschine sendet nur Infos.

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das einfachste wäre ein Logik-Analyser...oder ganz simpel ein Oszi.
Bit-Zeit ablesen und in Baud umrechnen.

Angenommen die 115k stimmen, was fängst du mit dieser Info an, wenn du 
nicht weißt, wie die Daten zu interpretieren sind?

Denn: Wenn man wüsste wie die Daten (Protokoll) zu interpretieren sind,
wüsste man, was an Byte[0], Byte[1] usw. erwartet wird...und dann könnte 
man die Baud-Einstellung solange ändern, bis es passt.

Von was für einem Gerät sind die Daten?

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:

> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Indem Du mal 15€ für einen CHina-Logicanalyzer ausgibts, dazu ein 
Breakoutboard mit einem MAX3232, die beiden Receive-Kanäle des MAX3232 
mit auf die serielle Leitung (RX und TX) klemmst und dann am LA die 
Bitzeit ausmisst. Bingo. Länger als eine Stunde sollte das eigentlich 
nicht dauern.

fchk

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Timing? also es ist definitiv nur die RS232-Leitung. Nix weiter, kein
> Shake oder DX oder so.

Das habe ich auch nicht erwartet. Aber ich vermute, dass zwischen den 
256 Byte-Paketen eine Pause ist, die man detektieren kann.

> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Gar nicht. Dafür müsstest Du schon ein eigenes Programm schreiben, 
welches ab einer bestimmten Timeout-Schwelle die mittlerweile 
übertragenenen Zeichen ausgibt. Haben die ausgegebenen Werte einen 
Abstand von 256, hast Du die Schwelle gefunden.

: Bearbeitet durch Moderator
Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Du kannst im HTerm zumindest einstellen, nach wieviel ms er in einer 
neuen Zeile beginnen soll:
"Newline after ... ms receive pause (0=off)"

Falls jeder Datensatz mit diesem "2@P`5)" beginnt, dürfte es nicht 
schwer sein - bis es geordnet untereinander steht.

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Buzzer dranhängen und mit am guten Ohr hörst du es raus.

Autor: Ruediger Asche (Firma: keine) (rac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Adam P. schrieb:
> Michael Glaser schrieb:
>> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
>> einrichten, was speziell auf Timing aus ist?
>
> Du kannst im HTerm zumindest einstellen, nach wieviel ms er in einer
> neuen Zeile beginnen soll:
> "Newline after ... ms receive pause (0=off)"
>
> Falls jeder Datensatz mit diesem "2@P`5)" beginnt, dürfte es nicht
> schwer sein - bis es geordnet untereinander steht.

Du hast auch bei beim "Save as" die Option, Zeitstempel in den log 
einzufügen, was die Interpretation natürlich etwas schwerer macht. Aber 
wenn Du über ein einzelnes Zeichen mit der Maus wanderst, kriegst Du im 
jeweiligen Tooltipfenster auch die Zeitstempel.

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, ich verstehe! Es gibt eine Übertragung und diese stoppt nach 
dem Ende für x ms und setzt dann wieder ein? Und das sieht man auf dem 
log nicht. Hat man nach dem Einsetzen der Übertragung das erste Zeichen, 
hat man auch den Anfang, richtig?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Hat man nach dem Einsetzen der Übertragung das erste Zeichen, hat man
> auch den Anfang, richtig?

Ja, korrekt. Gerade wenn irgendwelche Frame-Markierungen in den Daten 
wie <STX> und <ETX> fehlen, wäre das eine sinnvolle Herangehensweise.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Es gibt also keine Start/Stopzeichen,

Genau.

> wie noch beim ersten Log von dir vermutet

Wo habe ich das vermutet?

Frank M. schrieb:
> Es könnte einfach eine Ruhepause zwischen den Datensätzen sein.

Diese Pausen sind definitiv vorhanden, zumindest im ersten Log vom
30.5., denn:

Michael Glaser schrieb:
> ich habe hier eine Datei, geloggt aus einer RS232-Schnittstelle. Ca 5sek
> lang.

Die Datei umfasst 25740 Byte. Bei 260 Byte pro Datensatz sind das genau
99 Datensätze. Also wird alle 5s/99=51ms ein Datensatz übertragen. Die
eigentliche Übetragung der 260 Bytes dauert aber bei 115200,8,N,1 nur
260·10/115200Hz=23ms. Es verbleibt also eine Pausenzeit von 51ms-23ms
=28ms, die, wenn sie immer am Ende eines jeden Datensatzes eingefügt
wird, durchaus zur Synchronisation genutzt werden könnte.

Diese Pausen erhöhen auch deutlich die Wahrscheinlichkeit dafür, dass
Start und Ende des Logs jeweils zwischen zwei Datensätzen liegen. Und
tatsächlich ist die Länge beider Logs (sowohl des alten als auch des
neuen) ein ganzzahliges Vielfaches der jeweiligen Datensatzlänge.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Indem Du mal 15€ für einen CHina-Logicanalyzer ausgibts, ...

Wo gibt es die denn noch für 15€? Da musst du inzwischen heftig suchen.
Ebay-Artikel Nr. 172169652368

Beitrag #5060731 wurde vom Autor gelöscht.
Autor: Michael Glaser (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
eine neue Datei. Diesmal im Ruhezustand und dann mit Start und kurzem 
Lauf der Maschine. Das mit dem Zeitlogging bekomme ich nicht hin :( Kann 
man nicht wirklich die 2@P als Bezungspunkt nehmen?

Das Format ist wieder wie Version 1. Und bleibt auch diesmal dabei;) 
Hatte einen kleinen Fehler beim Loggen in der Version 3. Entschuldigung

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> Diesmal im Ruhezustand und dann mit Start und kurzem
> Lauf der Maschine.

Falls die 115k stimmen, dann stimmt ebenfalls deine Aussage:
Ruhezustand -> kurzer Lauf.

Nehmen wir mal an, der Datenstream bildet interne Daten-Register ab 
(Zähler, Messwerte, etc.), dann erkennt man dies in deinem Log.

Annahme: 260 Byte / Datensatz
Log-Datei hat 3458 Datensätze
Datensatz 0 - 1733 = Ruhezustand
Bei Datensatz 2896 ist noch etwas passiert, mehr Mess/Datenwerte.

Sieht man ganz gut mit dem Prog. "HxD".
Zeilenbreite auf 260 Stellen und dann mal runter scrollen.

Autor: Michael Glaser (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, kurze Sommerpause vorbei und weiter geht es ;)
Habe einiges probiert, aber mir scheint, es gibt da irgendwie keine 
feste Reihenfolge, kann das sein? Ich orientiere mich da an dem Zähler, 
der jedes mal um 1 nach oben gesetzt wird und beim erreichen von 255 das 
nebenstehende Byte um 1 erhöht...diese beiden finde ich aber immer an 
unterschiedlichen Stellen im Datensatz

Ich habe jetzt bei hterm mal die Funktion "Neue Zeile nach x ms" 
eingestellt und einmal 18ms und einmal 22ms und dann 23ms probiert: 
gemessen von dem doch sehr statischen "2@P" sind die Zähler jedesmal wo 
anders :(

Auch wenn ich andere "Anfangszeichen" wähle, sind die Zähler 
woanders...was mache ich falsch?

Anbei noch ein etwas längerer Log, auch da sind die Zähler woanders, 
allerdings wurde da nicht irgendwie was mit neuer Zeile bei hterm 
angegeben, also ganz normal geloggt...

Wer hat da eine Idee? Was mache ich falsch? Vielen Dank

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast mal mein Vorschlag probiert?

- Log die Daten einfach, ohne Interpretation in ein File
(so wie du es schon gemacht hast)
- Öffne diesen Log mit dem Programm 'HxD' und stell dort die Anzahl an 
Bytes auf 260.

Dann hast du dein 'Counter' an Offset 0xEF und 0xF0.

Oder im HTerm nicht nach X ms eine neue Zeile, sondern nach 260 Bytes.

Kannst ja mal ausprobieren.

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ja habe ich. 260 Zeichenbreite ist ganz schön viel, aber ausser 
einem Musster kann ich da nichts erkennen, das ist ja das Problem. In 
der Ansicht sieht es alles schön geordnet aus..also habe ich mich 
verschaut und du findest den Counter immer an der selben Stelle in allen 
Datein?

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, hast wohl recht, 260 scheint wirklich nicht korrekt zu sein.
Zumindest in soweit nicht konsistent, dass die erste Zeile zu allen 
anderen passt.

...hab grad alle Dateien offen.

23.log:
Hier scheint 260 zu passen, der Counter folgt immer auf die Sequenz
32 40 50 60 <Counter>

18.log:
22.log:
115k_6a.log:
Bei diesen Logs hab ich unterschiedliche Längen und dann passen diese 
nur für die ersten 2 Zeilen.

Falls der Datenstream zu Beginn mit 32 40 50 60 beginnt und, da sich 
dies immer wiederholt und danach der Counter steht, ist es evtl. auch 
die Kennung für einen Datensatz.

Kommisch ist nur das es einmal passt und dann wieder nicht.

Autor: Yalu X. (yalu) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Irgendetwas läuft beim Aufzeichnen der Daten falsch.

Ziemlich sicher ist, dass die Daten in Blöcken konstanter Länge
übetragen werden. Bei deinen ersten Logs war die Blocklänge 260 Bytes,
dann hast du Logs mit einer Blocklänge nur 256  gepostet. Zwischendurch
enthielten die Logs nur Mülldaten. Bei den neuen Logs ist die Blocklänge
wieder 260, allerdings ist bei drei der vier Logs der erste Block
unvollständig.

Ich habe von allen vier Logs jeweils die ersten drei Blöcke gehexdumpt.
Jede Zeile des Dumps enthält 26 Bytes, ein kompletter Block besteht
somit aus 10 Zeilen. Jeder Block beginnt mit der Bytefolge 32 40 50 60,
gefolgt vom Low- und High-Byte der fortlaufenden 16-Bit-Zahl.

Wenn man im ersten Block an geeigneter Stelle eine geeignete Anzahl
Bytes einfügt, stimmen sowohl die Blocklänge als auch ein Großteil des
Inhalts mit den anderen Blöcken überein. Die fehlenden Bytes sind in den
Dumps mit "--" gekennzeichnet.

Bei 115k_6a.log fehlen 25 Bytes, bei 18.log 18 Bytes und bei 22.hex 4
Bytes. Nur 23.log ist vollständig. Die fehlenden Bytes deuten auf einen
Pufferüberlauf, Übertragungsfehler o.ä. hin.

Ich weiß nicht, ob deine Tools fehlerhaft sind oder ob du sie falsch
bedienst. Auf jeden Fall erschwerst du die Analyse damit gewaltig.

Ich habe aber sowieso meine Zweifel, ob es dir jemals gelingen wird, das
Protokoll zu entschlüsseln. Dazu enthalten die Blöcke einfach zu viele
Daten, die sich über einen längeren Zeitraum nicht ändern. Aber selbst
diejenigen Daten, die veränderlich sind und tatsächlich physikalische
Mess- bzw. Stellgrößen zu enthalten scheinen (s. mein Beitrag vom
28.06.) sind nur schwer konkreten Sensoren bzw. Aktoren zuzuordnen, wenn
man die Maschine nicht im Detail kennt.

Ein gewisse Chance, das Protokoll zu entschlüsseln, würde ich höchstens
dann sehen, wenn jemand, der sowohl Ahnung von der Analyse unbekannter
Protokolle als auch von Fräsmaschinen hat, vor Ort direkten Zugriff auf
die Maschine und einen Einblick in ihren inneren Aufbau hat. Aber selbst
dann gestaltet sich die Sache immer noch sehr schwierig.

Warum benutzt du die Fräsmaschine nicht einfach, wie sie ist, und
erfreust dich an den schönen Dingen, die man damit fertigen kann?

Autor: Michael Glaser (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Na prima :( Mein "Tool" ist ein recht frisch aufgesetzter XP-Laptop mit 
ausgeschaltetem Virusscanner und Hterm und einem billig 
RS232-USB-Wandler..

Was meinst du mit "fehlen"? In dem ganzen Log fehlt dann jeweils in 
jedem Block Daten? Oder wie ist es gemeint?

Naja, ich krieg das schon irgendwie hin ;) Zumindest die 
Datenzuordnung..denke ich, ich bräuchte halt nur einen Anfang vom 
Datensatz...

Ich hänge noch ein paar logs an, kannst du bitte mal schauen, ob die 
auch fehlerhaft sind? Wäre ja übel, wenn es da wirklich Probleme beim 
Loggen geben würde. Könntest du bitte einmal schauen, ob die auch nicht 
stimmen? Vielen Dank.

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grundsätzliche Frage:
Wann fängst du an 'aufzuzeichnen'?

Datei: 115k_5b.log
Hat eine Datensatzlänge von 260 Byte, jedoch fängt hier der Mitschnitt 
mit
7d 00 01 ff ... an?!

Kann es sein, dass du bei manchen Logs mitten im Betrieb anfängst die 
Daten aufzuzeichnen?

Datei: 115k_4.log
Datensatzlänge 260 Byte und fängt mit 32 40 50 60 an.

Kannst du vllt. mal bitte eine Log anhängen wo du das Aufzeichnen 
startest, bevor du die Maschine einschaltest. (Also von Anfang an)

Michael Glaser schrieb:
> Was meinst du mit "fehlen"?

Bei deinen vorherigen Log Dateien, fehlten bei einigen in den ersten 2 
Datensätzen Bytes. Warum auch immer.

Yalu X. schrieb:
> Ich habe aber sowieso meine Zweifel, ob es dir jemals gelingen wird, das
> Protokoll zu entschlüsseln.

So sehe ich das auch.

: Bearbeitet durch User
Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh...schande über mich! Selten am Start der Maschine, sehr oft logge ich 
einfach im Betrieb, wenn die Maschine läuft..bin am Wochenende wieder 
vor Ort und werde vor dem Start der Maschine den Logger einschalten.

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-D

Das erklärt natürlich einiges.

Dann erstell mal ein Log vom Start an und über eine längere Zeit (inkl. 
einigen Aktionen der Maschine).

Hast du für uns nicht mal den Hersteller und Typ der Maschinensteuerung?

Autor: Michael Glaser (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
weiter geht es :) Was sagt ihr zu diesem Log? 2@P' scheint wohl doch der 
Anfang zu sein und der Counter befindet sich an der richtigen 
Stelle...nur wie bekomme ich raus, ob es ein 16-Bit-Wert ist (also 2 
Bytes einen Wert ergeben) oder ein 8bit-Wert (ein 1Byte ein Wert)?

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist jetzt das Problem, welches wir schon angesprochen hatten.
Die Interpretation der Daten kann beliebig kompliziert sein, da die 
Werte alles bedeuten könnten, sie könnten 8, 16, 32 bit sein.

Mir ist noch aufgefallen, da der Counter nur 16-bit hat, erfolgt nach 18 
Std. ein Überlauf.

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mh, okay, aber prinzipiell stimmst du mir zu, daß der Start mit " 2@P'" 
los geht, oder?

Autor: Yalu X. (yalu) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> 2@P' scheint wohl doch der Anfang zu sein

Nicht 2@P', sondern 2@P` bzw. 32 40 50 60 in Hexdarstellung. In der
letzten Logdatei steht allerdings vor dem ersten Datenblock noch ein
einzelnes NUL-Byte (hex 00). Möglicherweise sendet die Maschine dieses
Byte einmalig direkt nach dem Einschalten. Dass viele deiner Logdateien
direkt mit der Sequenz 32 40 50 60 beginnen, deutet daraufhin, dass die
Pause zwischen den einzelnen Datenblöcken genau vor dieser Sequenz liegt
und diese somit den Anfang des Datenblocks darstellt. Das NUL-Byte am
Anfang der Logdatei kannst du also zunächst einmal ignorieren.

> und der Counter befindet sich an der richtigen Stelle

Ja.

> nur wie bekomme ich raus, ob es ein 16-Bit-Wert ist (also 2 Bytes
> einen Wert ergeben) oder ein 8bit-Wert (ein 1Byte ein Wert)?

Man kann da nur raten, vermuten und hoffen :)

Beim Zählerwort ist es noch relativ klar. Byte 4 des Datenblocks wird in
jedem neuen Block inkrementiert und springt nach FF wieder auf 00
zurück. Bei jedem dieser Rücksprünge wird Byte 5 inkrementiert. Hier ist
ein entsprechender Ausschnitt aus der Logdatei in Hexdarstellung:

Byte 4   Byte 5
  ⋮        ⋮
  FD       00 
  FE       00 
  FF |     00 |
  00 |     01 |
  01       01 
  02       01 
  ⋮        ⋮

Das sieht also sehr stark nach einem 16-Bit-Zähler aus.

Bei halbwegs stetigen Mess- oder Stellwerten kann man eine ähnliche
Überlegung anstellen. Hier ist ein Ausschnitt der Logdatei für Byte 6
und 7 jedes Blocks:

Byte 6   Byte 7
  ⋮        ⋮
  96       03 
  D5       03 
  D1 |     03 |
  1A |     04 |
  1A       04 
  47       04 
  98       04 
  AF       04 
  EC |     04 |
  07 |     05 |
  F9 |     04 |
  06 |     05 |
  D9       04 
  DD       04 
  AF       04 
  75       04 
  75       04 
  2D       04 
  29 |     04 |
  E5 |     03 |
  D5       03 
  C6       03 
  ⋮        ⋮

Die Zahlenwerte in Byte 7 werden immer dann inkrementiert, wenn Byte 6
einen großen negativen Sprung macht. Umgekehrt wird Byte 7 immer dann
dekrementiert, wenn Byte 6 einen großen positiven Sprung macht. Das
deutet darauf hin, dass die großen Sprünge von Byte 6 durch Überläufe
verursacht werden, die jeweils zu einem Übertrag nach Byte 7 führen.

Hat man erst einmal diesen "Anfangsverdacht", kann man die Daten auch
grafisch vergleichen (s. Anhang). Welche der beiden Kurven würdest du
als die "richtigere" ansehen?

Autor: Michael Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank!! Genau das, was ich suche! Nur wie hast du aus Bit 7 und 8 
eine Zahl bekommen? deine 16-Bit-Zahl stimmt, aber wenn ich 96 03 
zusammenfasse zu 9603 und in Dezimal umrechne, komme ich auf  38403....

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Glaser schrieb:
> aber wenn ich 96 03 zusammenfasse zu 9603

Vertausch das mal.

0x0396 = 918dez

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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