Hallo zusammen, ich habe eine alte Messstation (Wetter) und ein altes Programm, dieses bekommt per RS232 die Daten und zeigt mir die Messwerte an. (Firma/Doku etz gibts nicht mehr) Nun möchte ich aber ein eigenes Programm dafür schreiben und habe versucht die RS232 Daten mithilfe des Hyperterminal und einem zweiten Rechner abzufangen. Das habe ich auch hingekriegt, jedoch sind die Daten in ASCII Code der nicht dem Klartext entspricht. Nun ist halt die Frage wie ich vom ASCII Code zum Klartext komme. Eine Struktur der Daten ist zu erkennen jedoch kann ich sie nicht einfach so entschlüsseln. Jemand ne Idee oder Erfahrung mit einem solchen Problem ? Gruß
Die gegebenen Informationen sind unzureichend für eine Hilfestellung. Lass dir die Daten nicht aus der Nase ziehen. Poste halt mal einen Datensatz, dann kann dir Hilfe gegeben werden. Hinweis: Werde dir zunächst mal klar darüber was ASCII und Klartext bedeutet. Aus deiner Seriellen Schnittstelle kommen immer nur bytweise Zahlen heraus. Diese Zahlen kann man als Ascii-Zeichen interpretieren (gemäß einer Übersetzungstabelle) oder halt nicht. Manche Terminalprogramme (zB. Hterm) kann man zwischen unterschiedlichen Ansichten (Ascii, Dezimal, Binär usw) umschalten. Mein Tipp: Lade dir Hterm herunter und dann nehme einen Datensatz in allen denkbaren Ansichten und poste das hier. lg stm
Ein paar Datensätze unter kontrollierten Bedinungen wären wichtig, d.h z.B. ein definierter langsamer Temperaturanstieg mit bekannten Endwerte, möglichst ohne Datenänderung auf anderen Kanälen (Wind, Feuchte, Regen oder was auch immer an der Station noch dran hängt). Hat die Station vielleicht auch eine Typbezeichung oder meldet sich damit auf der Schnittstelle?
Hallo, hab die Daten jetzt nur als Bild vorlegen da ich es nicht zuhause hab: http://www7.pic-upload.de/14.10.12/y1msi4byhz.jpg So sehen die Daten aus. Die oberen Zeilen entsprechen/bzw sollten den unteren entsprechen. Es kann aber auch zu manchen Fehlern bei der abgefangenen Übertragung kommen. Soweit mir bekannt. Soo vlt. hat ja jemand ne Idee wie ich weiter vorgehen soll? Gruß Vielen Dank an alle!
Nimm das Programm hterm, das kann Dir die empfangenen Daten als Hexdump anzeigen. Bist Du Dir bei den Einstellungen der seriellen Schnittstelle, insbesondere der Baudrate sicher?
Danke für die Tipps. Und was genau kann ich dann erwarten wenn ich es als Hexdump anzeigen lasse? Oder was genau soll ich dann mit den Daten machen, ich kenne mich damit nicht besonders gut aus. Kann ich nicht einfach den ASCII code in Hex umwandeln lassen ? Weil mit 3t Software auf den PCs ist das bei uns so ne Sache. Gruß
> Oder was genau soll ich dann mit den Daten machen
Angucken und nach bekannten Werten suchen.
Hi >Und was genau kann ich dann erwarten wenn ich es als Hexdump anzeigen >lasse? >Oder was genau soll ich dann mit den Daten machen, ich kenne mich damit >nicht besonders gut aus. >Kann ich nicht einfach den ASCII code in Hex umwandeln lassen ? HTERM zeigt dir die Daten Hexadezimal, Dezimal, Binär und/oder als ASCII an. http://www.der-hammer.info/terminal/ MfG Spess
Brong schrieb: > Und was genau kann ich dann erwarten wenn ich es als Hexdump anzeigen > lasse? > Oder was genau soll ich dann mit den Daten machen, ich kenne mich damit > nicht besonders gut aus. Hmm, wie willst du denn selbst ein Programm schreiben, das solche Daten auswertet, wenn du es nicht mal schaffst diese Daten mit Papier und Bleistift auszuwerten wenn du sie vor dir siehst?
Danke für die Antwort, wie gesagt ich verstehe nicht ganz was ich mit den Daten dann anstellen soll, deswegen frage ich auch ? Wie soll ich sie auswerten, das ist doch auch die Frage? Ich habe Sie jetzt in ASCII vorliegen die Umwandlung zu HEX - Binär etz. ist ja nicht das Problem. Sondern, was ich anschließend mit ihnen anstellen soll. Gruß
Brong schrieb: > www7.pic-upload.de/14.10.12/y1msi4byhz.jpg Du hast doch schon alles vorliegen, in ASCII Datum, Uhrzeit, Temperatur, Luftfeuchte, Luftdruck, ?, ?,?,? Kurt
Brong schrieb: > Danke für die Antwort, > > wie gesagt ich verstehe nicht ganz was ich mit den Daten dann anstellen > soll, deswegen frage ich auch ? > > Wie soll ich sie auswerten, das ist doch auch die Frage? > Ich habe Sie jetzt in ASCII vorliegen die Umwandlung zu HEX - Binär etz. > ist ja nicht das Problem. Sondern, was ich anschließend mit ihnen > anstellen soll. > Tja, das wird dir niemand beantworten können. Kurt
Nein, die Daten die man lesen kann habe ich vom Programm entnommen. Die oberen in ASCII sind die welche ich an der RS232 Schnittstelle abfange. Eine bitte, keine sinnlosen antworten wie die über meinem jetzigen Beitrag.
Brong schrieb: > Nein, die Daten die man lesen kann habe ich vom Programm entnommen. Die > oberen in ASCII sind die welche ich an der RS232 Schnittstelle abfange. > Sorry, das hab ich nicht geschnallt. Bist du dir sicher dass du die Daten auch mit der richtigen Baudrate und richtigen Parität usw. abgefangen hast? Das ist wichtig denn sonst ist es fast unmöglich da was rauszulesen. Ein HEXDUMP wäre natürlich bestens geeignet um da was erkennen zu können. Ob die Daten in der gleichen Reihefolge wie am Schirm kommen steht auf einem ganz anderem Blatt. Denn diese Abstände werden per TAB gesetzt, das wird sicherlich nicht übertragen. Im HEXD sucht man zuerst nach Wiederholungen um ev. die Datenstruktur erkennen zu können. Dann nach einer Zuordnung der einzelnen Variablen. Diese dürften meisst Words sein. Ob die Daten überhaupt als Bytes übertragten werden ist auch nicht sicher. Kurt
Kurt schrieb: > Bist du dir sicher dass du die Daten auch mit der richtigen Baudrate und > richtigen Parität usw. abgefangen hast? Da würde ein Oszi einem höchstwahrscheinlich weiter helfen. Zumindest Baudrate, Datenrahmen und Framelänge lassen sich damit feststellen.
Brong schrieb: > Eine bitte, keine sinnlosen antworten wie die über meinem jetzigen > Beitrag. Das die Antwort dir sinnlos erscheint bedeutet nicht das sie es auch ist. Du hast sie nur nicht verstanden. Wenn dir so grundsätzliche Sachen, wie das Wissen darum was man mit einem Hexdump anfangen kann, fehlen dann kann das nichts werden. Daher ist zu bezweifeln, das du jemals etwas programmiert hast, denn jeder Programmierer hat schon mal in seinem Leben einen Hexdump benutzt.
Werner schrieb: > Kurt schrieb: >> Bist du dir sicher dass du die Daten auch mit der richtigen Baudrate und >> richtigen Parität usw. abgefangen hast? > > Da würde ein Oszi einem höchstwahrscheinlich weiter helfen. Zumindest > Baudrate, Datenrahmen und Framelänge lassen sich damit feststellen. Stimmt! das würde bestimmt hilfreich sein. Also ich möchte das nicht unbedingt rauskitzeln müssen. Wenn es Bytes sind, nur ein Stopbit verwendet wird, dann ist es auch schon happig um zu erkennen ob es 6,7,8,9 Bits pro Bytes sind. Kurt
Ich würde den folgenden Weg einschlagen: 1. Feststellen ob die Übertragungsparameter richtig erkannt wurden. "Sieht" man das nicht sofort, so hilft im Allgemeinen nur ein Oszi. 2. Datenrahmen ausbaldowern. Wenn Du nicht weist wo's los geht, kannst Du auch nichts analysieren. Da üblicherweise zwischen den Datensätzen eine kleine Pause ist, kann Dir auch hier ein Oszi. helfen. 3. Ein gewisser Sisyphos lässt grüßen: Du musst feststellen, in welchem Format die Daten sind. Dazu zeichnet man diese am besten hexadezimal auf. 4. Rhythmen feststellen. Du stehst nämlich vor dem Problem erst mal festzustellen was was ist. Also werden deine Temperaturen 3, 4, 5 oder Sechsstellig übertragen. (-20, +200 (ohne Komma) +0200 u.s.w.) Binär oder Hexadezimal ist das nicht immer offensichtlich. Du kannst bei der Rhythmusfeststellung auch etwas trixen. Stell das Ding in eine ruhige Ecke am besten mit einem Heizlüfter in ausreichender Entfernung und schau Dir die Daten an. Stell den Lüfter ohne Heizung an. Jetzt müssten die Winddaten, eine Spalte in deiner Datenanzeige, ausflippen. Alle anderen sollten nicht "spinnen" oder nur minimale Änderungen aufweisen. Im nächsten Schritt könntest Du denselben Lüfter auf Heizen stellen. Die Winddaten sollten jetzt ähnlich bleiben, aber die Temperatur sollte hochgehen. Wenn Du auf diese Weise die Grundstruktur erkannt hast, kannst Du anhand der zu Fuß umgerechnen Werte Luftdruck und Luftfeuchte identifizieren.
@Kurt @amateur Vielen Dank für die Antworten! Nein leider bin ich mir mit den Einstellungen nicht sicher. Wenn ich das jetzt richtig verstehe, muss ich die Daten mit den richtigen Einstellungen abfangen und versuchen im Hexdump festzustellen welches Format die Daten besitzen. Wie genau müsste ich jetzt mit dem Oszi vorgehen um zb. die Baudrate herauszufinden. Ich weiß zwar wie das rs232 Übertragungsverfahren aussieht, aber wie genau finde ich das jetzt das Paritätsbit/Baudrate heraus. Amateur, leider kann ich schlecht tricksen, weil das eine feststehende Station ist, weit weg von mir. Wenn ich jetzt den Hexdump vor mir habe, wie genau sieht dann jetzt mein Vorgehen aus, stehe da noch etwas auf dem Schlauch. Vielleicht mögen meine Fragen sehr einfach zu beantworten sein, jedoch kenne ich mich nicht besonders gut damit auch. Deswegen Frage ich hier und versuche dazu zu lernen. Danke an alle! @who Und du hast schon alles von Geburt an gewusst? -> mit sinnlos meinte ich die erste Antwort im Thread!
Brong schrieb: > Vielleicht mögen meine Fragen sehr einfach zu beantworten sein, jedoch > kenne ich mich nicht besonders gut damit auch. Deswegen Frage ich hier > und versuche dazu zu lernen. Eben nicht, dein Vorhaben ist recht anspruchsvoll, je nachdem wie die Daten eben codiert sind. Wenn das im reinen Ascii übertragen wird (wie GPS-NMEA z.B.) dann wirds sehr einfach, wenn das ein properitäres Binärprotokoll ist, womöglich noch Komprimiert dann ist es eventuell ganz unmöglich. Allerdings erzählst du dauernd, dass du wenig Ahnung hast und das passt nicht zur Aufgabenstellung. Für sowas muss man sich zumindest mit RS232 auskennen, und dann kann man auch mit einem Oszi die Bitbreite (vom Startbit) messen und hat dann die Baudrate. Außerdem solltest du natürlich keine Probleme mit Hexdumps, Zahlendarstellungen usw. haben, aber da wirkst du nicht fit. Es braucht auch etwas Erfahrung und Kentnisse in gängigen Codierungen sonst weiß doch gar nicht nach was man suchen könnte. Wenn du schon sowas sagst wie > jedoch sind die Daten in ASCII Code der > nicht dem Klartext entspricht. Dann merkt man du hast da nicht viel Ahnung. Jedes Byte hat eine ASCII Repräsentation, aber nicht jeder Bytestrom ist ASCII Codiert nur weil du ihn in einem Terminal als Zeichen anzeigen lässt. Also das ganze ist eher Heuristisch, da gibts keinen Algorithmus der dich zum Ziel führt. Und es scheint nicht so als könntest du das Problem mit deinem Wissen sinvoll angehen. gruß cyblord
Brong schrieb: > Wie genau müsste ich jetzt mit dem Oszi vorgehen um zb. die Baudrate > herauszufinden. Ich weiß zwar wie das rs232 Übertragungsverfahren > aussieht, aber wie genau finde ich das jetzt das Paritätsbit/Baudrate > heraus. Mit dem Oszi kannst du die Übertragungsgeschwindigkeit bestimmen, indem du die Bitdauer der Datenbits ausmißt. Dabei besteht die Möglichkeit, dass die Dauer der Stop-Bits das 1,5-fache beträgt. Davon darfst du dich dann nicht irritieren lassen. Dann geht es daran, die Start-, Daten-, Stop- und evtl. Paritätsbits zu identifizieren. Dann hast du das Übertragungsformat, kannst dein Empfangsprogramm entsprechend konfigurieren und mit dem Hexdump weitermachen. > @who > -> mit sinnlos meinte ich die erste Antwort im Thread! Das war wohl die (verdeckte) Aufforderung, irgendwelche sachdienlichen Hinweise zu deinem Datenstrom zu offenbaren ;-) Gruß Matthias
@Cyblord Mir ist natürlich bewusst das der Bytestrom nicht in ASCII codiert sein muss. Ich meinte damit das ich die Daten in ASCII vorliegen habe. Die Frage bezieht sich eher darauf wie ich nun von den Daten in ASCII zum richtigen Format komme. Das verstehe ich! Ja, ich kenne mich mit RS232 nicht besonders gut aus, naund, dann lerne ich es halt. Muss ich sowieso früher oder später. Ich verstehe die Abneigung gegen mein Vorhaben nicht. Ich frage ja einfach wie ich vorgehen soll oder was ich mir für Wissen aneignen soll. Zudem was soll dieses ständige "Dann merkt man du hast da nicht viel Ahnung.". Ich mein ernsthaft, füllst du dich dann besser? Ich hab doch geschrieben das ich mich mit dem Thema auseinandersetze. >Es braucht >auch etwas Erfahrung und Kentnisse in gängigen Codierungen sonst weiß >doch gar nicht nach was man suchen könnte. Das ist doch die Frage! Nach was soll ich dann suchen! ------------------------------------------------------------------------ --- Wie ich das jetzt verstehe kriege ich einen Bytestrom an Daten durch die RS232 diese sind in irgend einem Format. Nun steht die Frage aus - wie komme ich auf dieses Format. Ich habe herausgefunden das die Daten eine Festkommazahl mit 1 Kommastelle sind zudem -3276,8 ... 3276,8 als Wertebereich besitzen. - Die B
Ein anderer Lösungsansatz wäre die Verwendung von Portmon. Das ist eine Software, die die Kommunikation zwischen dem Programm und dem Treiber der seriellen Schnittstelle anzeigt. Damit lässt sich einerseits herausfinden, wie die Schnittstelle durch das Programm konfiguriert wird, und andererseits werden die empfangenen und gesendeten Daten angezeigt. Das setzt natürlich voraus, daß man zur Untersuchung des ganzen Portmon auf dem Rechner installieren kann, auf dem das Wetterstationsprogramm läuft. http://technet.microsoft.com/de-de/sysinternals/bb896644.aspx
token schrieb: > @Cyblord > > Mir ist natürlich bewusst das der Bytestrom nicht in ASCII codiert sein > muss. Ich meinte damit das ich die Daten in ASCII vorliegen habe. Du hast sie scheinbar aber eben nicht als ASCII. Was du hast, ist eine Abfolge von Bytes. Jedem Byte kann man laut ASCII Tabelle ein anzeigbares Zeichen zuordnen und das dann auf einem Terminal anzeigen. Das ist aber trivial und hat nichts mit einer ASCII Codierung zu tun.
So habe ich das aber gemeint, weil ich die Daten in der ASCII Darstellung habe. Ich hab nicht von codierung gesprochen! Mir ist bewusst das es einfach bytes sind welche hier in ASCII dargestellt sind. Das sie anderweitig codiert sind ist mir auch bewusst. Was ich mir überlegt habe ist, ob die ersten Daten in der Tabelle (siehe link oben) nicht ein Timestamp sein könnten. Jedoch wenn ich das ganze in Hex überführe, sieht es doch nicht danach aus. Gibt es Timestamps im Format DD/MM/JJJJ HH/MM die 8Byte lang sind - ohne Sekunden?
Klär doch erstmal, ob Du überhaupt mit der korrekten Baudrate arbeitest. Solange das nicht stimmst, empfängst Du Müll. Die Anzahl der Stopbits ist beim Mithören irrelevant, allenfalls die Parität ist noch wichtig. Nimm, wie ich schon weiter oben empfohlen habe, das Programm "Portmon". Und lass die Darstellung als "Text", sieh Dir den Hexdump an, nur den Hexdump und nichts als den Hexdump.
token schrieb: > Ich frage ja einfach wie ich > vorgehen soll oder was ich mir für Wissen aneignen soll. und das wurde dir schon x-Mal gesagt: als erstes schaust Du mit dem Oszi den Bitstrom an, vorher brauchst Du hier nicht mehr weiterfragen!
Bong schrieb: > Gibt es Timestamps im Format DD/MM/JJJJ HH/MM die 8Byte lang sind - ohne > Sekunden? JA!
Die andere Möglichkeit ist, du schaltest ein paar populäre Baudraten durch und schaust ob du bei einer Klartext empfängst. 8N1 sind doch relative gängige Parameter, das kann man damit mal versuchen. Ansonsten ist das ein Tappen im Dunkeln, wie halt immer wenn man eine unbekannte Codierung verstehen will. gruß cyblord
Bong schrieb: > So habe ich das aber gemeint, weil ich die Daten in der ASCII > Darstellung habe. Ich hab nicht von codierung gesprochen! > Mir ist bewusst das es einfach bytes sind welche hier in ASCII > dargestellt sind. Das sie anderweitig codiert sind ist mir auch bewusst. Was soll dann der Mist mit ASCII? Entweder die Bytes ergeben auf Anhieb einen einigermasse vernünftigen Klartext oder sie tun das nicht. Wenn nicht, dann ist ASCII erst mal sofort aus dem Rennen. Interessiert keinen mehr. > Was ich mir überlegt habe ist, ob die ersten Daten in der Tabelle (siehe > link oben) nicht ein Timestamp sein könnten. Jedoch wenn ich das ganze > in Hex überführe, sieht es doch nicht danach aus. Nicht in Hex 'überführen'! Du musst bereits bei Hex beginnen! D.h. du musst dir die Bytes in Hex so ansehen, wie sie von der Schnittstelle reinkommen. (Der Grund dafür ist, dass es einige Byte-Werte gibt, für die es keine sichtbare ASCII-Zeichen gibt. Je nach Anzeigeprogramm werden die entweder anders oder auch gar nicht dargestellt. D.h. stellt man die Byte-Werte und die ASCII Werte gegenüber, dann kann es sein, dass zb 50 Bytes als lediglich 30 darstellbare Zeichen angezeigt werden. D.h. Von ASCII auf die Byte-Werte zurückzuschliessen ist der falsche Weg.) Und als allererstes muss erst mal klar sein, ob die Baudrate stimmt. Ich würd so vorgehen: Mit einem Oszi ein paar Abläufe beobachten und nach dem kürzesten 'Puls' suchen. Theoretisch ist es natürlich möglich, dass in den Daten nie ein 0-1-0-1 Übergang vorkommt, in der Praxis wird sich sowas aber meistens irgendwo im Bitstrom ein paar mal finden. Und den misst man dann eben aus und rechnet daraus die Baudrate hoch.
Mach hinne - auf die Art habe ich mal einen SMD-Bestücker aus Japan gehackt ... Aufzeichnen, kleine Änderung am Gerät und 'rantasten.
cyblord ---- schrieb: > Die andere Möglichkeit ist, du schaltest ein paar populäre Baudraten > durch und schaust ob du bei einer Klartext empfängst. 8N1 sind doch > relative gängige Parameter, das kann man damit mal versuchen. Ansonsten > ist das ein Tappen im Dunkeln, wie halt immer wenn man eine unbekannte > Codierung verstehen will. Was auch noch hilfreich ist (und was HTerm ermöglicht): Sich ansehen ob die UART Empfangsfehler meldet. Wenn die Baudrate nicht stimmt, dann ist die Chance auf Framing Errors schon relativ hoch. Man müsste die Byte-Werte schon entsprechend 'konstruieren', so dass man mit der falschen Baudrate keine Framing (oder sonstige) Errors erhält. Hat man einen Hex-Dump (vom Empfangsprogramm), welcher ohne UART-Fehler reinkommt UND bei dem sich im Datenstrom eine regelmässige Wiederholung abzeichent (auf Byte-Ebene), dann stehen die Chancen gar nicht so schlecht, dass man mit der Baudrate richtig liegt. Wenn man dann auch noch zeigen kann, dass sich einzelne Bytes gezielt verändern, wenn man den Sender zu einer Veränderung zwingt (wie zb eine leichte Temperaturerhöhung), dann wird die Wahrscheinlichkeit sogar noch höher, richtig zu liegen. Richtiges Pech hat man, wenn der Datenstrom verschlüsselt wird. Dann wirds richtig schwer. Allerdings würde ich das bei einer Wetter-Station erst mal nicht annehmen. So sensibel sind die Daten dann auch wieder nicht. Und wenn du jetzt das Gefühl hast, das ganze hat mehr mit Intuition und Raten zu tun - Bingo! Genau das ist der Fall.
Thread beobachten
Seitenaufteilung abschalten
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.