Minicom-Output bei Laufzeit filtern bzw. serielle Schnittstelle filtern

Minicom-Output bei Laufzeit filtern bzw. serielle Schnittstelle filtern (9 Beiträge, 373 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich möchte den Datenverkehr der seriellen Schnittstelle mitlauschen und bei Laufzeit (bzw. zumindest alle paar Sekunden) filtern. Die gefilterten Informationen sollen in eine Datei geschrieben werden.

Ich habe versucht direkt von der seriellen Schnittstelle mit "od" in hexadezimal umzuwandeln und dann mittels sed zu filtern. Leider verliere ich da immer wieder Botschaften, nur weiss ich nicht warum.
Mein Kommando lautet

od -tx1 -An < /dev/ttyUSB0 | sed 'bla bla bla'

sed ist nicht die Ursache für den Datenverlust, denn auch im ungefilterten Mitschnitt fehlen die Botschaften bereits.
Ich habe versucht die Priorität von od raufzusetzen, aber das bringt gar nichts.

Wenn ich hingegen den Datenverkehr mit Minicom logge und die Log-Datei danach filtere, sind die Botschaften da.
Hier mache ich zuerst

minicom -w -C bla.log

und anschliessend

cat bla.log | sed 'bla bla bla'

Natürlich könnte ich einen cron-job einrichten, der die Log-Datei aus minicom nachträglich filtert, aber das gefällt mir nicht.

Gesucht ist also eine Alternative zu minicom, mit dem ich das Filtern vor der Ausgabe in die Datei hinkriege oder ein Shell-Befehl, mit dem ich keine Botschaften verliere.

Habe seit 15 Jahren nichts mehr mit Linux gemacht, deshalb bin ich für jeden Tipp dankbar.

BMW 320d E90:

Yamaha FZ6-S Fazer:

Verstehe ich jetzt nicht ganz:
dein Input ist ASCII-Text und du filterst mit ein und demselben pattern entweder das minicom-Log
ODER den od-hexdump? Also ohne im Vergleich das minicom-log durch od zu pipen und auf gleiche
Zeilenlänge/Blockung zu schauen???

Sind deine Daten zeilenorierentiert oder ein Stream ohne Zeilensprünge?

Poste mal ein paar Zeilen von beiden Quellen.

Mit der Priorität der beteiligten Programme hat es jedenfalls nichts zu tun, für den "backpressure"
bzw. Pufferung ist die Pipe zuständig - einzig: wenn dein serielles Gerät, wie heute üblich, seine
Daten ohne flow control liefert, könnten schon welche verlorengehen, bei höheren Datenraten
(>>115kb).

dein Input ist ASCII-Text und du filterst mit ein und demselben pattern
entweder das minicom-Log
ODER den od-hexdump?

Minicom habe ich auf Hex-Anzeige umgestellt, damit filter ich immer dasselbe Format.

Sind deine Daten zeilenorierentiert oder ein Stream ohne Zeilensprünge?

Letzteres.

Poste mal ein paar Zeilen von beiden Quellen.

So sieht das Minicom-Capture aus:

3 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00 08

Und so sieht's direkt mit od in der Pipe gelesen aus:

00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00
55 03 03 00 0c f1 00 20 01 f3 00 55 01 04 00 0e
01 ed 00 55 02 03 00 0b f2 00 55 03 03 00 0c f1
00 55 04 04 00 09 01 f2 00 55 f0 00 55 00 04 00
08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02 03 00
0b f2 00 55 03 03 00 0c f1 00 55 04 04 00 09 01
f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55 01 04
00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03 03 32
04 c7 00 55 04 04 00 09 01 f2 00 55 f0 00 55 00
04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00 55 02
03 00 0b f2 00 55 03 03 00 0c f1 00 55 04 04 00
09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3 00 55
01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00 55 03
03 00 0c f1 00 55 04 04 00 09 01 f2 00 55 f0 00
55 00 04 00 08 01 f3 00 55 01 04 00 0e 01 ed 00
55 02 03 00 0b f2 00 55 03 03 00 0c f1 00 55 04
04 00 09 01 f2 00 55 f0 00 55 00 04 00 08 01 f3
00 55 01 04 00 0e 01 ed 00 55 02 03 00 0b f2 00
55 03 03 00 0c f1 00 55 04 04 00 09 01 f2 00 55

(Sind natürlich unterschiedliche Schnipsel, Minicom ist von gestern Abend, od von gerade eben.)

Im ersten Schritt ersetze ich mit sed jedes Vorkommen von "00 55" durch "00\n55", weil jede Botschaft mit 00 endet und mit 55 beginnt. Anschliessend lösche ich nochmal alle Zeilenschaltungen, weil durch die Pipe-Ausgabe immer am Zeilenende automatisch Zeilenschaltungen gemacht werden, die ich nicht will/brauche. Danach nochmal das erste Kommando, dann habe ich jede Botschaft in einer separaten Zeile.

sed '/00 55/ s//00\n55/g' -u | sed -e :a -e '$!N;s/\n / /;ta' -e 'P;D' -u | sed '/00 55/ s//00\n55/g'

Danach filtere ich noch die Botschaften mit den Geräte-IDs weg, weil ich nur die "echten Botschaften" brauche. Zum Schluss setze ich vor jede Zeile noch den aktuellen Zeitstempel.
Alle sed-Kommandos laufen mit Option -u, damit der Stream sofort gefiltert wird. (Deshalb das wirre Konstrukt mit dem doppelten "s/00 55/00\n55/g".)

Ich habe gestern Abend begonnen mit Minicom ein Capture aufzuzeichnen und das gerade mit derselben sed-Pipe von oben gefiltert.
Das Ergebnis ist makellos, es scheinen keine Botschaften zu fehlen. (Eines der Geräte auf dem Bus überträgt jede Minute die akuelle Uhrzeit. Lese ich direkt in der Pipe mit od, fehlen immer wieder einzelne dieser Botschaften, mal alle paar Minuten, mal 1-2x pro Stunde. Im Minicom-Output sind seit gestern Abend alle Minuten drin.)

EDIT: Zu Kontrollzwecken habe ich natürlich auch schon ungefiltert aus der Pipe geschrieben und anschliessend mit Textverarbeitung "gefiltert". Auch da fehlen schon die Botschaften, d.h. das anschliessende sed ist unschuldig.

BMW 320d E90:

Yamaha FZ6-S Fazer:

17.06.2017, 13:12 Uhr - Editiert von TheTrumpeter, alte Version: hier

Zu Kontrollzwecken habe ich natürlich auch schon ungefiltert aus der Pipe
geschrieben und anschliessend mit Textverarbeitung "gefiltert". Auch da fehlen
schon die Botschaften, d.h. das anschliessende sed ist unschuldig.

Ich würde sicherheitshalber noch einmal mit so einer Konstruktion

cat < /dev/ttyUSB0 | tee raw.log | od .... | tee hexdump.log | sed ... | tee prefiltered.log | usw.

prüfen, ob da schon was im ersten Schritt verlorengeht oder ob sich da die Pipe verschluckt.

Danach überprüfen, was die Schnittstelle so macht bzw. herausfinden, was minicom anders macht (Baudrate und Buffer), als eine Pipe direkt aus /dev/ttyUSB0 = Detaileinstellungen von minicom nachlesen (wie initialisiert es die Schnittstelle?)

Welcher USB-Adapter/Chip hängt denn dran? FTDI, Prolific, Silabs, CH34x? FTDI-Treiber sind um einiges mächtiger (auch wenn minicom da nicht speziell drauf eingeht) und haben debug-Möglichkeiten ( http://ftdi-usb-sio.sourceforge.net/ ).

Ich würde sicherheitshalber noch einmal mit so einer Konstruktion
cat < /dev/ttyUSB0 | tee raw.log | od .... | tee hexdump.log | sed ... | tee
prefiltered.log | usw.
prüfen, ob da schon was im ersten Schritt verlorengeht oder ob sich da die
Pipe
verschluckt.

Tatsächlich... Im hexdump.log sind die Botschaften noch drin, nach dem mehrfachen sed sind sie weg.
Habe jetzt weiter debugged und siehe da, offenbar ist der letzte Teil vom sed, der die Botschaften mit den Geräte-IDs löschen soll, ursächlich.

Gelöscht wird beispielsweise diese Zeile, die ich aber behalten möchte:

55 01 07 21 0f 24 11 06 11 7d 00

Der schuldige Teil von sed ist

/00 08 01 f3/d;/00 0b f2/d;/00 09 01 f2/d;/00 0e 01 ed/d;/00 0c f1/d;/55 f0 00/d

Der ganze Befehl lautet:

sed '/00 55/ s//00\n55/g;/00 08 01 f3/d;/00 0b f2/d;/00 09 01 f2/d;/00 0e 01 ed/d;/00 0c f1/d;/55 f0 00/d' -u

Im ersten Teil mache ich nochmal bewusst Zeilenschaltungen, dann lösche ich die Botschaften. Wenn ich das nochmal auf 2 seds aufteile, klappt's komischerweise:

sed '/00 55/ s//00\n55/g' -u | sed '/00 08 01 f3/d;/00 0b f2/d;/00 09 01 f2/d;/00 0e 01 ed/d;/00 0c f1/d;/55 f0 00/d' -u

Ich verstehe zwar nicht warum, aber Hauptsache es funktioniert.

BMW 320d E90:

Yamaha FZ6-S Fazer:

Ich verstehe zwar nicht warum, aber Hauptsache es funktioniert.

Wahrscheinlich liegt die Antwort im Detailverhalten bei mehreren Befehlen hintereinander und das kann bei einer anderen Implementierung wie erwartet funktionieren.
Zeilenenden, Whitespaces, NUL usw. sind immer gut für Probleme und Mehrdeutigkeiten bei Parsern.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung