Hi, ich habe hier zwei Geräte, die über ein (proprietäres?) serielles Protokoll miteinander kommunizieren. Ich habe mir das mal mit dem Oszi aufgenommen (siehe Anhang), kann jetzt aber nur erkennen, dass das vermutlich kein UART ist: - die übertragenen Nutzdaten haben eine Länge von 20 Bit - ob noch Steuerbits enthalten sind, ist nicht bekannt, würde ich aber vermuten - die in der aufgenommenen Sequenz enthaltenen Nutzdaten sollten alle 0 sein Leider kann ich da nirgends eine Regelmäßigkeit erkennen, die auf die 20 Bit Nutzdaten schließen lässt bzw. irgendwo die Daten erkennen. Deswegen meine Frage: was könnte das für ein Protokoll sein bzw. wo sind hier möglicherweise die Daten versteckt? Hat jemand schon mal sowas gesehen? Danke! Ornes
Angehängte Dateien:
-
Zwischenablage01.png
130 KB
Mit einem Logic-Analyser wäre es evtl. leichter. Ornes schrieb: > ich habe hier zwei Geräte Was sind das für Geräte? Was wird zwischen den kommuniziert? Ornes schrieb: > die übertragenen Nutzdaten haben eine Länge von 20 Bit Wie kommst du auf 20 Bit? Ornes schrieb: > die in der aufgenommenen Sequenz enthaltenen Nutzdaten sollten alle 0 > sein Diese Information hast du von wo? Dann weißt du ja was und zu welchem Zeitpunkt übertragen wird? Kommst du irgendwie an die innere Hardware, was sind es für Anschlüsse, wieviele Leitungen werden für die Kommunikation genutzt, ist eine davon evtl. eine Taktleitung?
Es ist zwar ein Muster zu erkennen, aber die unterschiedliche Breite der "Bits" könnte ich mir jetzt nicht erklären. Entspricht die X-Achsen Aufteilung (Zahlen) einer Zeiteinheit, z.B. ms?
Angehängte Dateien:
-
Datenstrom.png
130 KB
Ornes schrieb: > aufgenommen (siehe Anhang), kann jetzt aber nur erkennen, dass das > vermutlich kein UART ist: Ist es auch nicht. > Leider kann ich da nirgends eine Regelmäßigkeit erkennen, Ich schon, siehe Anhang. die auf die 20 > Bit Nutzdaten schließen lässt bzw. irgendwo die Daten erkennen. > Deswegen meine Frage: was könnte das für ein Protokoll sein bzw. wo sind > hier möglicherweise die Daten versteckt? Hat jemand schon mal sowas > gesehen? Das sieht nach Manchesterkodierung aus. Bei Dauer-Null kommt da der volle Symboltakt raus. Rot könnten Kopfdaten sein, danach folgen ca. 10 Nullbits (grün). Möglicherweise sind deine 20 Bit in 2 Datenpaketen verpackt.
Falk B. schrieb: > Das sieht nach Manchesterkodierung aus Ja das würde erklären warum 0 Daten herauskommen wenn man es wieder dekodiert...aber was ist mit den Spikes (unterschiedliche Bit-Breite). Wenn die Clock so "schnell" wäre würde es wieder nicht zu 0 Daten passen, dann wäre der Daten strom ja nicht 010101 = 000 sonden 00110011 usw. Oder übersehe ich da grad etwas?
Adam P. schrieb: > Kommst du irgendwie an die innere Hardware, was sind es für Anschlüsse, > wieviele Leitungen werden für die Kommunikation genutzt, ist eine davon > evtl. eine Taktleitung? Die Hardware kann ich zum Teil sehen - es kommt eine einzelne Datenleitung aus einem FPGA und wird dann auf RS232 gewandelt. Das Signal ist rein seriell, es gibt keinen Takt/Sync/sonstwas. Für die Kommunikation wird nur die eine Leitung (plus GND) mit dem Signal von dem RS232-Baustein genutzt.
Ornes schrieb: > es gibt keinen Takt/Sync/sonstwas Dann muss darin eine Start-Kennung enthalten sein, dass wenn der Empfänger sich den Takt generiert, auch auf etwas triggern kann.
Ornes schrieb: > Die Hardware kann ich zum Teil sehen - es kommt eine einzelne > Datenleitung aus einem FPGA und wird dann auf RS232 gewandelt. Das > Signal ist rein seriell, es gibt keinen Takt/Sync/sonstwas. Für die > Kommunikation wird nur die eine Leitung (plus GND) mit dem Signal von > dem RS232-Baustein genutzt. Was für ein RS232 Baustein?
Es kann auch ein einfaches PWM Signal sein, ähnlich OneWire. Vielleicht IrDa?
Falk B. schrieb: > Es kann auch ein einfaches PWM Signal sein Aber wenn man die Taktrückgewinnung in betracht zieht, könnte es wirklich Manchester sein. Dann wären die von dir grün markierten Bereiche jedoch der Synch. und nicht die Nutzdaten: https://de.wikipedia.org/wiki/Leitungscode Ausschnitt:
1 | PLL wird synchr. | PLL bleibt synchronisiert |
2 | Start
|
3 | Datenbits: 0 1 1 0 0 0 0 0 0 1 ... |
4 | Sync/Daten: 1 1 1 1 1 ...1 1 1 1 0 1 0 0 1 1 0 0 0 0 0 0 1 ... |
5 | Leitungsbits: 1010101010...1010101001 1001 01101001010101010110... |
6 | Pegel: +-+-+-+-+-...+-+-+-+--+ +--+ -++-+--+-+-+-+-... |
Trotzdem würde dann immer noch der "Spike" bleiben...
Ornes schrieb: > Die Hardware kann ich zum Teil sehen Kannst du uns nicht sagen, was das für Geräte sind? Wenn man mal bedenkt wieviele Kodierungen es gibt, könnte das im ersten Moment so gut wie alles sein.
Gurgl schrieb: > Es wäre sinnvoll wenn du uns 1-2 andere Werte liefern würdest als 0 @Ornes (Gast): Vllt. den maximal Wert, hast du auf die Werte einfluss? Sind es signed oder unsigned? Was haben die Werte für eine Auflösung, 8, 16, 32, oder vllt. wirklich 20 Bit? Was ich damit sagen möchte: wenn du sicherstellen kannst das du es hinbekommst, eine Zahl zu übertragen, die Binär 11111111...usw Entspricht, dann schneide das mal mit.
Das ist keine gewöhnliche, sondern eine differentielle Manchester- Kodierung mit 0,64 Bit pro Zeiteinheit. Es werden abwechselnd zwei Datenblöcke mit jeweils 64 Bit übertragen, die sich jeweils in 2 Bits unterscheiden und zum größten Teil aus Nullen bestehen. Gurgl schrieb: > Es wäre sinnvoll wenn du uns 1-2 andere Werte liefern würdest als 0 Am besten zusammen mit der Information, um welche Werte es sich genau handelt.
Falk B. schrieb: > Was für ein RS232 Baustein? Ist der relevant? Ich sehe die selben signale auch auf der Datenleitung vor dem RS232-Konverter, das macht keinen Unterschied. Die Nutzdaten sind definitiv immer 20 Bit, ich weiß aber nicht, ob da nicht noch ein paar zusätzliche Steuerbits hinzukommen. D.h. ich kann mal versuchen, ein 0xFFFFF zu senden, kann aber diese möglichen Steuerbits dabei nicht beeinflussen.
Ornes schrieb: > ich kann mal versuchen, ein 0xFFFFF zu senden Interessant wären auch andere (krumme) Werte. Falls man diese in dem Bitmuster wiederfindet, weiß man, wie lang ein einzelner Datenblock ist und wo in diesem zusätzliche Steuerinformationen liegen.
Yalu X. schrieb: > Interessant wären auch andere (krumme) Werte. Das wird schwer. Und auch bei 0xFFFFF kann ich nur versuchen das hinzubekommen - ob der gesendete Wert dann wirklich das Maximum oder vielleicht nur 0xFFFF3 ist, kann ich leider nicht direkt beeinflussen.
Adam P. schrieb: > Kannst du uns nicht sagen, was das für Geräte sind? > > Wenn man mal bedenkt wieviele Kodierungen es gibt, könnte das im ersten > Moment so gut wie alles sein. Geheimnisse in Fragen bringen geheime Hilfe!
Ornes schrieb: > Falk B. schrieb: >> Was für ein RS232 Baustein? > > Ist der relevant? Kann schon sein. Denn wenn dort irgendwo normales RS232 rauskommt, muss ja irgend jemand das dahin umwandeln. Die IC-Bezeichnung könnte da hilfreich sein.
Falk B. schrieb: > Ornes schrieb: >> Falk B. schrieb: >>> Was für ein RS232 Baustein? >> >> Ist der relevant? > > Kann schon sein. Denn wenn dort irgendwo normales RS232 rauskommt, muss > ja irgend jemand das dahin umwandeln. Die IC-Bezeichnung könnte da > hilfreich sein. Es ist ein ST232CDR bei dem nur T1 verwendet wird.
Angehängte Dateien:
-
bitcode.png
59 KB
Route 6. schrieb: > Geheimnisse in Fragen bringen geheime Hilfe! Warum müssen wir wissen warum er das nicht beeinflussen kann und was das für Geräte sind? Inwiefern trägt das zur Klärung bei? Eine regelmässige Abfolge ist ja zu erkennen. Mal einen kleinen Bereich höher auflösen. Mit der Info das es 20bit mit nur Nullen sind: Es gibt eine auffällig lange Pause, dazwischen etwas das mal als 10 Nutzbit, eingerahmt in einen Start und Stopcode interpretieren könnte. Ich vermute die Pause ist die Startbedingung. Dann kommt eine 1010 Folge zur Synchronisierung, 10 Nutzbits + irgendwas mit langem Puls als Ende Markierung. Zumindest taucht diese Folge wiederkehrend auf. Der Rest des Bildes sind nur Wiederholungen. >> Was für ein RS232 Baustein? Reiner Pegelwandler. Spielt doch keine Rolle ob der von Sipex, Maxim oder TI kommt.
Yalu X. schrieb: > Das ist keine gewöhnliche, sondern eine differentielle Manchester- > Kodierung [...] Das würde mich mal interessieren: Aus welcher Eigenschaft im Oszillogramm schliesst Du das? Magst Du das kurz erklären?
Ornes schrieb: > Falk B. schrieb: >> Ornes schrieb: >>> Falk B. schrieb: >>>> Was für ein RS232 Baustein? >>> >>> Ist der relevant? >> >> Kann schon sein. Denn wenn dort irgendwo normales RS232 rauskommt, muss >> ja irgend jemand das dahin umwandeln. Die IC-Bezeichnung könnte da >> hilfreich sein. > > Es ist ein ST232CDR bei dem nur T1 verwendet wird. Ich glaube wir reden aneinander vorbei. Mach mal ein Bild und Blockschaltbild von deinem Aufbau. Dein ST232CDR ist eine MAX232 Kopie, das ist ein reiner Pegelwandler. Damit kann man aber nicht deinen kryptischen Datenstrom in einen normalen UART im PC einlesen, bestenfalls mit einer ebenso kryptischen Gegenstelle.
Falk B. schrieb: > Ich glaube wir reden aneinander vorbei. Ich glaube das hier hast Du überlesen: Ornes schrieb: > Die Hardware kann ich zum Teil sehen - es kommt eine einzelne > Datenleitung aus einem FPGA und wird dann auf RS232 gewandelt. Weiter kommt er nicht ran. Unbekannt was im FPGA stattfindet.
> Ich glaube wir reden aneinander vorbei. Mach mal ein Bild und > Blockschaltbild von deinem Aufbau. Dein ST232CDR ist eine MAX232 Kopie, > das ist ein reiner Pegelwandler. Damit kann man aber nicht deinen > kryptischen Datenstrom in einen normalen UART im PC einlesen, Von so einem PC war nie die Rede, die Gegenstelle sieht so ähnlich aus: RS232-Wandler -> R-Ausgang auf FPGA -> FPGA=Black Box
Theor schrieb: > Yalu X. schrieb: >> Das ist keine gewöhnliche, sondern eine differentielle Manchester- >> Kodierung [...] > > Das würde mich mal interessieren: Aus welcher Eigenschaft im > Oszillogramm schliesst Du das? Magst Du das kurz erklären? Gute Frage. Noch einmal näher betrachtet ist es nämlich gar kein Manchester-Code, weder ein gewöhnlicher noch ein differentieller. Manchester-Codes haben u.a. die Eigenschaft, dass die einzelnen Low- und High-Phasen entweder 1 oder 2 Zeiteinheiten (ZE) lang sind. In dem von Ornes geposteten Beispiel sind aber auch ein paar Phasen mit 3 ZE zu sehen. Dafür gibt es folgende Möglichkeiten: - Es ist ein erweiterter Manchester-Code, in dem die 3-ZE-Phasen eine spezielle Funktion haben und bspw. zur Synchronisierung genutzt werden. - Der Manchester-Code wurde falsch implementiert. - Es handelt sich um ein völlig anderes Modulationsverfahren. Mit weiteren Beispielen kann man evtl. mehr erkennen.
Angehängte Dateien:
-
DS0002.png
300 KB
Sorry, das hat leider ein wenig gedauert. Anbei der Graph wenn einer der 20-Bit-Frames auf Maximalwert ist. Allerdings weiß ich jetzt auch nicht mit Sicherheit, ob "Maximalwert" wirklich 0xFFFFF bedeutet oder ob es sich um einen "signed" Wert handelt und dieser deswegen nur halb so groß ist (sprich das Vorzeichenbit ist immer noch auf 0). Beides passt jedenfalls nicht zu den 18 schmalen Pulsen, die da im Vergleich zum ersten Signal aufgetaucht sind.
Also wenn man beide Bilder übereinander anordnet, erkennt man den Unterschied - Problem hierbei: Du hast beide Bilder in verschiedener zeitlicher Auflösung, das macht eine optische Erkennung nicht einfacher. Das eine hat eine Schrittweite von 40, das andere 60. Poste vllt. nochmal beide Bilder in gleicher Auflösung.
Einiges spricht dafür, dass es sich doch um einen (etwas modifizierten) differentiellen Manchester-Code handelt. Dann würde ich da – umgeben von anderen Daten ein 0xFFFFD oder ein 0x7FFFE erkennen. Es scheint aber so zu sein, dass abwechselnd zwei verschiedene Werte übertragen werden (vielleicht zwei Kanäle einer Messvorrichtung?). Der zweite Wert ist nach wie vor entweder 0x00000 oder 0x00001 (je nachdem, wo genau die Daten innerhalb des Signalverlaufs angesiedelt sind). Wenn du sicher bist, dass in deinem ursprünglichen Beispiel exakt 0x00000 (und nicht 0x00001) übertragen wurde, dann ist dieser zweite Wert ebenfalls 0x00000 und der erste 0x7FFFE, und die o.g. Alternative (0xFFFFD) scheidet aus. Pro übertragenem 20-Bit-Wert werden noch 12 weitere Bits übertragen, die sich zwischen den beiden (vermuteten) Kanälen in 2 Bits unterscheiden. Darin könnte neben Steuerinformation auch die Kanalnummer enthalten sein. Ein kompletter Datenblock ist damit 32 Bit lang, was ja eigentlich eine schöne Zahl ist :) Die für einen Manchester-Code ungewöhnlichen Pulse mit 3 Zeiteinheiten könnten der Synchronisation dienen, da sie pro Datenblock nur einmal bzw. zweimal direkt hintereinander auftreten.
:
Bearbeitet durch Moderator
Falk B. schrieb: > Ornes schrieb: > >> aufgenommen (siehe Anhang), kann jetzt aber nur erkennen, dass das >> vermutlich kein UART ist: > > Ist es auch nicht. Sagt wer ? Wisst ihr beide überhaupt wofür UART steht ? UART ist Hardware Bezeichnung, hat mit verwendetem Protokoll gar nichts zu tun.
Beitrag #5725452 wurde vom Autor gelöscht.
Ornes schrieb: > Yalu X. schrieb: >> Interessant wären auch andere (krumme) Werte. > > Das wird schwer. Versuch's trotzdem ;-) > Und auch bei 0xFFFFF kann ich nur versuchen das hinzubekommen - ob der > gesendete Wert dann wirklich das Maximum oder vielleicht nur 0xFFFF3 > ist, kann ich leider nicht direkt beeinflussen. Warum ist das so? Hängt das irgendwie mit Messfehlern o.ä. zusammen? Falls ja, wäre es evtl. möglich, dem System einen krummen Wert zu entlocken, der wenigstens ungefähr bekannt ist? Also bspw. den Wert 0x4D5??, wobei die Fragezeichen für unbestimmte Ziffern stehen?
Yalu X. schrieb: > Ornes schrieb: >> Yalu X. schrieb: >>> Interessant wären auch andere (krumme) Werte. >> >> Das wird schwer. > > Versuch's trotzdem ;-) > >> Und auch bei 0xFFFFF kann ich nur versuchen das hinzubekommen - ob der >> gesendete Wert dann wirklich das Maximum oder vielleicht nur 0xFFFF3 >> ist, kann ich leider nicht direkt beeinflussen. > > Warum ist das so? Hängt das irgendwie mit Messfehlern o.ä. zusammen? Nein, mit einem proprietären Treiber, der dazwischenhängt. Der ist bekannt dafür, bei 16 Bit signed nicht genau zu wissen, ob das Limit bei (+-)32767 oder bei (+-)32768 liegt und wird das in der 20 Bit Version kaum besser können :-D Zu den Daten: ja, nur einer der Werte ist auf Maximum, der andere sollte nach wie vor 0 sein.
Marc V. schrieb: > UART ist Hardware Bezeichnung, hat mit verwendetem Protokoll gar > nichts zu tun. UART kann aber nur festgelegte Bit-Folgen generieren. Ornes und Falk B. haben Recht... > Falk B. schrieb: >> Ornes schrieb: >> >>> aufgenommen (siehe Anhang), kann jetzt aber nur erkennen, dass das >>> vermutlich kein UART ist: >> >> Ist es auch nicht. ...denn die UART-typischen Start/Stopp-Sequenzen sind nicht vorhanden.
Route 6. schrieb: > UART kann aber nur festgelegte Bit-Folgen generieren. Das ist natürlich Unsinn. > Ornes und Falk B. haben Recht... Natürlich nicht. Route 6. schrieb: > ...denn die UART-typischen Start/Stopp-Sequenzen sind nicht vorhanden. Was heißt hier typisch ? Es gibt beim UART nichts typisches außer Spannungspegel. Was du meinst, kann höchstens ein Serielles Datenformat sein, aber das kann man genauso gut über RS485 senden.
Beitrag #5728682 wurde von einem Moderator gelöscht.
Marc V. schrieb: > Es gibt beim UART nichts typisches außer Spannungspegel. Dann überlege mal, was UART bedeutet. Das "Asynchron" bedingt die Verwendung von Start- und Stopbits, damit sich der Empfänger immer neu auf die gesendeten Bytes synchronisieren kann.
Marc V. schrieb: > Es gibt beim UART nichts typisches außer Spannungspegel. Wie kommst Du auf diese interessante Sichtweise? UARTs verwenden ein recht wohldefiniertes Rahmenformat (das mindestens aus Start-, Daten- und Stopbits besteht); das, was hier passiert, hat nichts mit UARTs zu tun. Wenn Du eine andere Definition für UARTs verwendest, ist das schön für Dich, aber bei der Kommunikation mit anderen äußerst hinderlich.
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.