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
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?
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?
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:
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.
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.
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.
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.
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.
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.
Eine eigene Frage?
Dieser Thread ist über 7 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
Zwischenablage01.png
(130 KB)
