Rasbian 10 (buster): nanoCUL wird nicht erkannt about asksinanalyzerxs HOT 5 CLOSED

das Kommando bleibt aber anscheinend hängen, ich habe das nach 2m per ^C abgebrochen.

Bug ;) hab ich behoben.

Ansonsten sieht das für mich eigentlich alles korrekt aus.
asksin-analyzer-xs --list-ports erkennt den FTDI als root nicht aber als User analyzer wobei minicom zugreifen kann, sehr komisch.

In der letzten Develop-Version hab ich nun ein hartes Überschreiben des Ports ermöglicht, auch wenn er nicht erkannt wird.

asksin-analyzer-xs --data /tmp/my-data-dir --serial-port /dev/ttyUSB0

from asksinanalyzerxs.

Ich habe die aktuelle Dev-version installiert, nun funktionierte die Erkennung des USB-Port.

Ich habe leider auch hier einen Abbruch des Empfangs von Telegramme nach einiger Zeit (wie in #7).
Da das zwei unterschiedliche HW (NUC vs. Raspi 2B+) und OS (Ubuntu 18.04.3
vs. Rasbian 10).
Soweit ich gesehen habe gibt es unter Raspbian kein Powermanagment des USB-Ports.

Das lenkt natürlich den Verdacht von Rechner-HW / OS in Richtung USB-Stick, wobei mich schon wundert, das der der Empfang nach Speichern der (unveränderten) Konfiguration wieder aufgenommen wird. Was passiert in einem solchen Fall im Serverprozess?

Ich habe nun erstmal das USB-Kabel ersetzt und dabei auch die Länge minimiert (30cm).

Einen 2. Stick habe ich natürlich nicht zur Hand, müsste ich mir erst besorgen.

Macht es Sinn, den Output des Stick einfach per minicom oder cu abzugreifen um zu schauen, ob da nach einigen Stunden nix mehr kommt? Müsste ja einfach nix mehr kommen...

from asksinanalyzerxs.

wobei mich schon wundert, das der der Empfang nach Speichern der (unveränderten) Konfiguration wieder aufgenommen wird. Was passiert in einem solchen Fall im Serverprozess?

Hier wird im Grund das UART-Device (usb0) neu verbunden da es sich potentiell geändert haben könnte.

Macht es Sinn, den Output des Stick einfach per minicom oder cu abzugreifen um zu schauen, ob da nach einigen Stunden nix mehr kommt? Müsste ja einfach nix mehr kommen...

Ja das wäre mein Vorschlag, Damit du das etwas differenzieren kannst brauchst du iwie noch ne Art Date-Ausgabe, vllt über Bash so

( minicom ..args.. & while true ; do date ; sleep 180 ; done ) | cat

from asksinanalyzerxs.

su, ich nahe nun mit minicom protokolliert (Anmerkung: mit CTRL-A N kann man Timestams einschalten und man kann ja alles in ein Logfile protokollieren)

Ich bekommen 1-2x pro Sekunde einen 1-Byte-Wert, Bsp.

:4F;

ab und an gibt es dann längere Zeilen

[2020-03-22 18:08:07] :5F;
[2020-03-22 18:08:08] :431E10008EA4F857BED9C8000099159856FCC5C601325144A43D45591695953F;
[2020-03-22 18:08:08] :2A1714008EBED9C8A4F8570D2C4F42D7EB27F2744CBE30DEFB;
[2020-03-22 18:08:08] :432110088EA4F85797C50C00009916DCC971432B85AC2A66394B4CA5385D1E7107D13D;
[2020-03-22 18:08:08] :291410008EBED9C8A4F8570D2C4F43B0C9F791D7E4C0;
[2020-03-22 18:08:08] :60;
[2020-03-22 18:08:09] :61;

das interpretiere ich als Telegramme.

Aber ... nach einiger Zeit kommen nur noch die kurzen Meldungen, auch wenn definitiv Action los ist.

Es ist also nicht so, das es keine Kommunikation mehr gibt, aber keine Telegramme.

Wenn ich minicom beende, geht's sofort wieder los.

Wenn noch Daten kommen ist der USB-Stick ja nicht funktionslos sein.

Die Software auf dem Stick ist der master-Tree von https://github.com/jp112sdl/AskSinAnalyzer/tree/master/AskSinSniffer328P und gemäß User der-pw den GPIO angepasst. Da wird doch auch kein solcher Fehler drin sein, das wäre doch aufgefallen ...
Aber ein HW-Defekt des Stick ... warum funktioniert er manchmal und manchmal nicht?

Ich habe im Augenblick keine Ahnung ... hast du noch einen Tip für mich?

from asksinanalyzerxs.

Der Stick wurde ja nach deiner letzten Änderung erkannt, also ist der Vorgang damit meiner Meinung nach erledigt.
Das Problem mit dem Dauerbetrieb war ein defekter Stick (siehe #7)

danke

from asksinanalyzerxs.