Ich möchte bei zwei Maschinen, die seriell verbunden sind mit RS232, RS422 oder ähnliches, abhören, also aufzeichnen was tatsächlich über die Leitung geht, denn es gibt sporadische Fehler, die in Log-Dateien wie beschädigte Datenpakete aussehen. Mit dem Oszilloskop habe ich im ersten Schritt schon sehen können, das Timing und Level der Bits ok sind und die Zeitabstände zwischen den Datenpaketen "ok aussehen", aber ich brauche das auch aufgezeichnet mit einem Rechner und zwei Adaptern, zum Empfangen der von beiden Maschinen gesendeten Bytes. Wichtig ist dabei auch die Zeitstruktur der Datenpakete, so das die Logdatei beispielsweise so aussehen soll: Datum/Zeit vom Empfang des ersten Byte des Datenpaketes, Quelle Datenpaket Byte0 Byte1 ... optional Zeit zum Empfang des gesamten Datenpakets oder Zeitdifferenz zum nächsten Datenpaket Beispiel: 2014-09-01 01:02:03,0123; Nr. 1 00 01 02 03 04 05 06 13 ms rec, 17 ms diff 2014-09-01 01:02:03,0123; Nr. 2 ... Nebenbei wäre auch eine Statistik hilfreich, z. B. Länge des längesten Datenpakets, kurzestes usw., denn das ist ja minimaler Programmieraufwand. Allerdings ist die Suche nach einen solchen simplen Programm bisher frustrierend: Die meisten Programme zum Loggen sind Terminal-Programme, die nicht mit Zeitstruktur und binär arbeiten sondern mit Buchstaben/Zahlen/Steuerzeichen und Zeilenstruktur. Und die Programme, die alles Aufzeichnen, können meist nur von einem Ausgang aufzeichnen und produzieren unbrauchbare Datenhalden, weil ohne Zeitstempel. Am besten geeignet erscheint mir bisher Jpnevulator, http://jpnevulator.snarl.nl/ aber das hat einen nicht unerheblichen Bug: http://www.filewatcher.com/p/jpnevulator_1.3.0-1_s390.deb.19696/usr/share/doc/jpnevulator/BUGS.html Deshalb stellt sich die Frage was man denn für die simple Aufgabe eine serielle Kommunikation zwischen zwei Maschinen aufzuzeichnen nehmen kann; was empfehlen die Profis hier?
Erwin Meyer schrieb: > die simple Aufgabe eine > serielle Kommunikation zwischen zwei Maschinen aufzuzeichnen Nickname schrieb: > klingt alles nach Standardfeatures Wenn es so "simpel" wäre und mit "Standardfeatures" zu erledigen wäre, dann gebe es dafür bestimmt 'ne App. ;-) Dein Beispiel zeigt, dass du dir eine zeitliche Auflösung von 100µs vorstellst. Das geht ... aber nicht nicht einem einfachen Programm auf dem PC. Evtl. ist es die simpelste Lösung, wenn du dir einen Datenanalysator ausleihst.
Konrad S. schrieb: > Wenn es so "simpel" wäre und mit "Standardfeatures" zu erledigen wäre, > dann gebe es dafür bestimmt 'ne App. ;-) Ja, zb diese: Nickname schrieb: > https://sites.google.com/site/terminalbpp/
Um eine Kommunikation mitzuhören, muss man beide Kanäle abhören, so etwas wie "terminalbpp" (was wohl eine neuere Variante des schrecklichn "Bray" zu sein scheint) oder hterm ist hierzu ungeeignet, da diese Programme nur mit einer seriellen Schnittstelle kommunizieren, man zum Mithören zweier Kanäle aber deren zwei benötigt. Wenn man dann auch noch das Timing mit einer gewissen Präzision aufzeichnen möchte, ist eine reine Softwarelösung (die zwei Schnittstellen simultan aufzeichnen muss) zumindest unter üblichen PC-Betriebssystemen problematisch, weil da die Hardwareansteuerung der Devicetreiber, etwaige Hardware-Empfangs-Fifos sowie Zwischenpufferung im Betriebssystem dazwischenfunken können und das Timing verzerren. Wirklich brauchbare Ergebnisse gibt es hier nur mit zusätzlicher Hardware (die man sich mit 'nem µC, der zwei serielle Schnittstellen und ausreichend Speicher hat, auch selbst bauen kann). Ein kommerzielles Beispiel: https://iftools.com/analyzer/msb-rs232/index.de.php
Die meisten Terminalprogramme lassen sich auch zweimal parallel starten, damit kann man über 2x RS232 des PC auch zwei Leitungen mitschneiden. Und der TO schrieb in seinem Beispiel von Zeiten, die im zweistelligen ms-Bereich liegen. Das sollte doch zu machen sein... Logisch, dass man mit Hardware wie im Link von Rufus wesentlich genauer und schneller ist. Aber das Teil hat natürlich auch seinen Preis. Vielleich kann Conrad S. mal erläutern, wie er auf 100µs kommt. Ich kann das im Moment nicht nachvollziehen. Der TO schrieb von 13ms, 17ms (Beispiel). Ihm ging es doch um die Zeiten eines ganzen Datenpaketes und nicht um die Analyse von Bitlängen. Dafür würde man sicher auf Hardware zurückgreifen müssen.
Erwin Meyer schrieb: > Ich möchte bei zwei Maschinen, die seriell verbunden sind mit RS232, > RS422 oder ähnliches, abhören, also aufzeichnen was tatsächlich über die > Leitung geht Ich setze für diese Zwecke Docklight ein. http://www.docklight.de Hier ein Beispiel eines aufgezeichneten Traces. Erst mal im Speicherformat "Hex":
1 | Docklight Log File (HEX) - Started 18.09.2012 18:45:45.516 |
2 | |
3 | 18.09.2012 18:45:25.954 [COM10] - 7E 02 02 00 7D |
4 | 18.09.2012 18:45:26.000 [COM9] - 7E 02 03 01 7D |
5 | 18.09.2012 18:45:26.454 [COM10] - 7E 02 02 00 7D |
6 | 18.09.2012 18:45:26.499 [COM9] - 7E 02 03 01 7D |
7 | 18.09.2012 18:45:26.954 [COM10] - 7E 02 02 00 7D |
und der gleiche Trace im "ASCII"-Format
1 | Docklight Log File (ASCII) - Started 18.09.2012 18:45:45.515 |
2 | |
3 | 18.09.2012 18:45:25.954 [COM10] - ~<STX><STX><NUL>} |
4 | 18.09.2012 18:45:26.000 [COM9] - ~<STX><ETX><SOH>} |
Der Trace mit Nutzdaten im ASCII-Format:
1 | 18.09.2012 18:46:16.679 [COM9] - ~<STX><DC1><NUL><SI>+CPIN: READY<NUL><SOH>€ó} |
2 | 18.09.2012 18:46:16.770 [COM10] - ~<STX>‘<NUL><DC4>AT^CCIB=2.10-/UHP4-<CR>¼} |
3 | 18.09.2012 18:46:16.778 [COM9] - ~<STX>ƒ} |
4 | 18.09.2012 18:46:16.871 [COM10] - ~<STX><STX><NUL>} |
5 | 18.09.2012 18:46:16.879 [COM9] - ~<STX><DC1><NUL><ENQ>OK<NUL><SOH>€“} |
6 | 18.09.2012 18:46:16.974 [COM10] - ~<STX>‘<NUL><HT>AT^CENC?<CR>è} |
und im Hex-Format:
1 | 18.09.2012 18:46:16.679 [COM9] - 7E 02 11 00 0F 2B 43 50 49 4E 3A 20 52 45 41 44 59 00 01 80 F3 7D |
2 | 18.09.2012 18:46:16.770 [COM10] - 7E 02 91 00 14 41 54 5E 43 43 49 42 3D 32 2E 31 30 2D 2F 55 48 50 34 2D 0D BC 7D |
3 | 18.09.2012 18:46:16.778 [COM9] - 7E 02 83 81 7D |
4 | 18.09.2012 18:46:16.871 [COM10] - 7E 02 02 00 7D |
5 | 18.09.2012 18:46:16.879 [COM9] - 7E 02 11 00 05 4F 4B 00 01 80 93 7D |
6 | 18.09.2012 18:46:16.974 [COM10] - 7E 02 91 00 09 41 54 5E 43 45 4E 43 3F 0D E8 7D |
Aufgezeichnet wurde mit einem doppelten seriellen Adapter (Cardbus). Es soll aber auch einen Adapter mit niedriger Latenz geben: http://www.docklight.de/info.htm -> Docklight Tap. Den habe ich aber nicht getestet. Grüße Stefan
?!? schrieb: > Ihm ging es doch um die Zeiten eines ganzen Datenpaketes und > nicht um die Analyse von Bitlängen. Ja, das sagt er so. Aber es ist zweifelhaft, ob er so seine Übertragungsfehler findet. Georg
Stefan Wagner schrieb: > Es soll aber auch einen Adapter mit niedriger Latenz geben Gemeint war "USB-Seriell-Adapter". Grüße Stefan
?!? schrieb: > wie er auf 100µs kommt Erwin Meyer schrieb: > 2014-09-01 01:02:03,0123; Nr. 1 ^^^^^ Wären das hinter dem Komma keine Sekundenbruchteile, dann hätten die Zeitstempel nur eine Auflösung von einer Sekunde. Das wäre dann allerdings auch mit den billigsten USB-Seriell-Wandlern hinzubekommen. Timing-Angaben im Millisekundenbereich sind dann natürlich nicht sinnvoll, da spricht schon USB dagegen. Rufus hat's schon gesagt: Es müssen zwei serielle Schnittstellen zum Mithören vorhanden sein. Je nach zu analysierendem Kommunikationsprotokoll braucht man für jedes Byte den Zeitstempel mit so guter Auflösung, dass die beiden Datenströme korrekt zu einer Darstellung zusammengeführt werden können, bei der die Zugehörigkeit jedes Bytes zu seinem Datenstrom erkennbar ist und wo auch das Zeitverhalten dargestellt wird. Bei Kommunikationsprotokollen, die sich zeitlich wie Halbduplex verhalten, ist der Aufwand geringer - es sei denn, das Problem liegt genau in der Verletzung dieser Annahme.
Stefan Wagner schrieb: > > Hier ein Beispiel eines aufgezeichneten Traces. > Erst mal im Speicherformat "Hex": > >
1 | > Docklight Log File (HEX) - Started 18.09.2012 18:45:45.516 |
2 | > |
3 | > 18.09.2012 18:45:25.954 [COM10] - 7E 02 02 00 7D |
4 | > 18.09.2012 18:45:26.000 [COM9] - 7E 02 03 01 7D |
5 | > 18.09.2012 18:45:26.454 [COM10] - 7E 02 02 00 7D |
6 | > 18.09.2012 18:45:26.499 [COM9] - 7E 02 03 01 7D |
7 | > 18.09.2012 18:45:26.954 [COM10] - 7E 02 02 00 7D |
8 | > |
Das mag in deinem Fall funktionieren, ich bekomme aber vom DockLight die Datenpakete zerlegt und neu zusammengesetzt, so das zwar noch die Byte-Reihenfolge von den verschiedenen Quellen jeweils stimmt, aber nicht die Struktur, so das selbst bei Halbduplex-Verbindungen das Docklight die zeitliche Reihenfolge falsch anzeigt. Das ist auch nicht gerade Sinn der Sache, vom Programme wild zusammengesetzte Pseudo-Pakete angezeigt zu bekommen, wo die tatsächlichen Pakete anders aussehen und auch eine andere zeitliche Reihenfolge haben. Da bleibt mir wohl nur jpnevulator für X Schnittstellen X-mal zu starten und dann die X Logdateien zusammenzuführen mit cat, sort usw.. Daneben muss ich wohl von USB-Adaptern wechseln nach Adaptern mit weniger Latenz, z. B. PCI oder PCIe oder Expresscard.
:
Bearbeitet durch User
Erwin Meyer schrieb: > ich bekomme aber vom DockLight die > Datenpakete zerlegt und neu zusammengesetzt Mein HP Protocol Analyzer hat mit sowas keine Probleme, der zeigt die Zeichen auf den Leitungen in 2-Zeilen-Darstellung zeitrichtig untereinander an - kannst du dir sowas nicht ausleihen? Georg
Georg schrieb: > kannst du dir sowas nicht ausleihen? Frage an den TO: Wie schnell ist die mitzuschneidende Strecke? Wenn es nicht mehr als 19k2 sind, könnte ich leihweise einen HP4951 beisteuern. (Der kann leider nur maximal 19k2 asynchron und 64k synchron. Ist halt etwas älter.) Grüße Stefan
Hallo, ich bin einer der Docklight-Entwickler und über den Beitrag gestolpert: Ja, bei zwei COM-Anschlüssen und Windows-Software-Monitoring können bei schnellen Frage/Antwort-Zyklen die Datenrichtungen nicht zuverlässig auseinander gehalten werden. Da zerlegt nicht die Windows-Anwendung, sondern die beiden COM-Ports haben jeweils individuelle Latenzzeiten und USB-Paketaufteilungen, ohne vom zweiten COM-Port überhaupt zu wissen. D.h. die korrekte zeitliche Abfolge kann nur bei rel. großen Abständen (z.B. Pause zwischen Frage/Antwort > 20 Millisek.) gewährleistet werden. Mehr Genauigkeit ist nur über eine hardware-basierte Lösung möglich. Oliver
Oliver Heggelbacher schrieb: > Mehr Genauigkeit ist nur über eine hardware-basierte Lösung möglich. Endlich, nach 14 Monaten, weiss der TO Bescheid. Jetzt kann er weitermachen. Georg
Oliver Heggelbacher schrieb: > Hallo, ich bin einer der Docklight-Entwickler und über den Beitrag > gestolpert: > > Ja, bei zwei COM-Anschlüssen und Windows-Software-Monitoring können bei > schnellen Frage/Antwort-Zyklen die Datenrichtungen nicht zuverlässig > auseinander gehalten werden. Da zerlegt nicht die Windows-Anwendung, > sondern die beiden COM-Ports haben jeweils individuelle Latenzzeiten und > USB-Paketaufteilungen, ohne vom zweiten COM-Port überhaupt zu wissen. > > D.h. die korrekte zeitliche Abfolge kann nur bei rel. großen Abständen > (z.B. Pause zwischen Frage/Antwort > 20 Millisek.) gewährleistet werden. > > Mehr Genauigkeit ist nur über eine hardware-basierte Lösung möglich. Nein, mit USB-Adaptern kommt man auf circa 10 Millisekunden, mit onboard-Ports oder Ports auf PCI(e)-Karten auf circa 10 Mikrosekunden - mit einem RT-Kernel (Linux +Preempt_RT, erfordert unter Debian nur aptitude install linux-image-rt-amd64) garantiert unter 50 Mikrosekunden. Ein Übersprechen bei den Ports habe ich unter Linux bisher nicht gesehen. Neben jpnevulator für kurze Tests nehme ich hauptsächlich multithreaded_logger, um nebenbei auch parallele Daten mit 30 kHz einzulesen, wobei ich nur Level-Änderungen aufzeichne, da der Rest redundant ist: http://true-random.com/homepage/projects/logger/index.html Bei Adaptern die schneller sind als USB-Adapter sollte man ADAPTER_LATENCY entsprechend anpassen, z. B. 100 (µs) bei PCI(e)-Adaptern.
Erwin M. schrieb: > Am besten geeignet erscheint mir bisher Jpnevulator, > > http://jpnevulator.snarl.nl/ Erwin M. schrieb: > Neben jpnevulator für kurze Tests nehme ich Da der TO sogar noch nach 14 Monaten antwortet und dabei auch noch einmal seinen Tipp aus dem Eröffnungs-Thread wiederholt, frag ich mich doch, ob er die 'richtige' Antwort nicht schon von Anfang an wusste... jpnevulator scheint richtig gut zu sein - werd ich gleich mal testen. Grüße Knut
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.