Datenprotokoll automatisch erkennen?

[Elrond (Gast)]

Hi,

es gibt ja Geräte, die diverse Datenübertragungsprotokolle automatisch 
erkennen und die dort übertragenen Rohdaten dann direkt darstellen - man 
muss also nicht mehr wie blöde auf den Oszi starren, 
Synchronisationspunkte finden und Bits zählen.

Jetzt habe ich hier ein serielles Protokoll, bei dem ich keine Ahnung 
habe, um was es sich handelt. Es wird als Differenzsignal über zwei 
Leitungen übertragen (ähnlich RS485), ist aber kein UART, da das längere 
Startbit fehlt.

Mit welchen Analysegeräten könnte ich dem denn zu Leibe rücken um

a) herauszufinden, was für ein Protokoll das ist
b) die übertragenen Daten mitzulesen?

Gibt es da irgend einen möglichst universellen Analyser?

Danke!

[H.Joachim S. (crazyhorse)]

Elrond schrieb:
> das längere Startbit

Was ist das? Kommt bei mir nicht vor.

[Blume (Gast)]

in Kombination mit Sigrok

https://sigrok.org/

und einem biligen Salea 8 Bit Clone für 10 Euro

+ Wandler deiner Signale auf TTL Pegel


wenn du dann habwegs eine Ahnung hast wie die Daten zu interpretieren 
sind, kannst du mit einem Sigrok Protocoll Decoder (kann man auch selber 
schreiben) die Roh - Daten zerlegen

[Georg (Gast)]

Elrond schrieb:
> ist aber kein UART, da das längere
> Startbit fehlt.

Das gibt es auch nicht.

Georg

[Elrond (Gast)]

Georg schrieb:
>> ist aber kein UART, da das längere
>> Startbit fehlt.
>
> Das gibt es auch nicht.

Ja, das Stoppbit. Da jetzt alle meinen Tippfehler kommentiert haben: 
können wir bitte zur eigentlichen Frage zurückkommen?

Danke!

[Nick M. (Gast)]

Elrond schrieb:
> ist aber kein UART, da das längere
> Startbit fehlt.

Das Stopbit kann aber auch gleich lang als die Bits sein. 8N1, 8E1, 8O1.

[Wolfgang (Gast)]

Elrond schrieb:
> - man muss also nicht mehr wie blöde auf den Oszi starren,

Das tut heutzutage fast keiner mehr, da es Logikanalysator-Frontents für 
PCs gibt, die notfalls stundenlang Daten mitschneiden und preislich in 
der Größenordnung eines Kantinenessens liegen.

Elrond schrieb:
> Ja, das Stoppbit. Da jetzt alle meinen Tippfehler kommentiert haben:
> können wir bitte zur eigentlichen Frage zurückkommen?
>
> Danke!

Warum soll das Stoppbit länger sein. Du kannst es sowieso nicht vom 
Ruhepegel unterscheiden, d.h. sobald die Zeichen nicht mit pausenlos 
übertragen werden, hast du eine scheinbare Verlängerung, die aber nichts 
zu sagen hat.

Bitte!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Elrond schrieb:
> können wir bitte zur eigentlichen Frage zurückkommen?
Zeug doch einfach mal das Signal mit Pegeln und Timings.

Zum Decodieren taugen die Picoscope recht ordentlich...

[oerks (Gast)]

> preislich in der Größenordnung eines Kantinenessens liegen.

Du kennst die Preise von Hamburger Versicherungskantinen nicht.
Da kannst du mehrere LAs kaufen.

[oerks (Gast)]

Solange du HDLC und SDLC nicht auseinanderhalten kannst,
nuetzt der LA auch nichts.
Nimm lieber das Essen.

[Sebastian (Gast)]

Elrond schrieb:
> Gibt es da irgend einen möglichst universellen Analyser?

Ja: dieses Forum :)

LG, Sebastian

[c-hater (Gast)]

Elrond schrieb:

> Ja, das Stoppbit.

Auch das Stopbit muss nicht länger sein. Bei dem heute wohl am 
häufigsten verwendeten Frameformat 8N1 ist es das z.B. nicht.

> können wir bitte zur eigentlichen Frage zurückkommen?

Ja, die Antwort ist: du hast keine Ahnung und suchst eine Sache, die 
dieses Manko ausgleichen kann.

Tatsache ist: du wirst keine solche Sache finden, zumindest keine, die 
das sicher für jedes bekannte und dokumentierte Protokoll kann. Und 
natürlich schon garnicht eins, was das für irgendwelche proprietären 
Protokolle kann...