Hallo Zusammen, ich habe mehrere Hexcodes unterschiedlicher Länge und weiss welche Informationen die beinhalten, ein paar davon sind z.b: 1000570010000000d00703d007000000 1000570020000000d00703d007000000 0d003e0001d00700d00703d007 0d003e0000d00700d00703d007 10005e001c000000d00728000000d007 10005e001b000000d00728000000d007 10006400a4194800d00700470001d007 1000560020000000d00703d007000000 16006400A4194800660028000000d007002700002900 160064008c194800660028000000d007002700002900 alle Informationen sind in den Bytes vor dem Byte "d0" enthalten. Die letzten acht Bytes (inlusive "d0) weiss ich nicht wofür sie stehen. Kann es sein, dass dies eine Art checksum ist oder sowas? Hat jemand damit Erfahrung oder vielleicht eine Idee? Gruss, finalcu
finalcu schrieb: > Hallo Zusammen, > > ich habe mehrere Hexcodes Woher? > 1000570010000000d00703d007000000 ... > 0d003e0001d00700d00703d007 ... > 16006400A4194800660028000000d007002700002900 Das erste Byte könnte die Länge sein. > alle Informationen sind in den Bytes vor dem Byte "d0" enthalten. Die > letzten acht Bytes (inlusive "d0) weiss ich nicht wofür sie stehen. Kann > es sein, dass dies eine Art checksum ist oder sowas? Hat jemand damit Addiere doch mal die Datenbytes, ob das letzte Byte herauskommt.. > Erfahrung oder vielleicht eine Idee? Sieht aus wie verkrüppelter Intel Hex-code. Falk
Ja das erste Byte ist die Länge - wie bereits gesagt, bis zum Byte "d0" weiss ich was die Bytes darstellen. Die Hexcodes werden von einer russischen Simulationssoftware für die Steuerung verwendet. Ein Beispiel: 10005e001c000000d00728000000d007 beinhaltet folgende Informationen: - 10 00 ist die Länge (Bytes sind in umgekehrter Reihenfolge), also 16 Bytes - 5e 00 ist der Steuerungsbefehl, also Befehl-Nr. 94 - 1c 00 00 00 ist ein Parameter, also 28 mit diesem Befehl setzt man eine Spannung auf 28 V. Die Frage ist nun was die anderen Bytes an Informationen beinhalten könnte. Meiner Meinung nach beinhalten sie keine weitere Informationen und müssten demnach irgend eine Redundanz oder änliches darstellen...
eine kleine Anmerkung: da es sich um eine russische Software handelt, dachte ich dass die restlichen Bytes vielleicht sowas wie eine Beschreibung des Befehls auf russisch beinhalten könnte. Da aber das Byte 00 relativ häufig vorkommt glaube ich nicht, dass es sich um irgendeinen Unicode handelt da 00 z.b in KOI-8 keine Bedeutung hat...
... Ja klar, um den Hacker zu verwirren, werden sinnlose Bytefolgen gesendet... :-)))) ähm, ich habe auch eine Frage: was bedeutet das: 0x2A
Der Russe schrieb: > ... wie kommst du auf 42 und was bedeutet das? ... ;-) Hier gibts ne Lektüre zur Antwort "42": http://de.wikipedia.org/wiki/42_(Antwort) Gruß, Magnetus
... hmmm, dann frage ich mich, warum 42 nicht in obiger Fragestellung auftaucht! Oder habe ich etwas übersehen?
wahrscheinlich bin ich einfach zu dumm um den Scherz zu erkennen aber was hat das alles mit meinem Problem zu tun?
Das ist wie bei Onkel Heisenberg: Du kennst entweder die Frage oder die Antwort, nie aber beides zugleich.
... achso, was mir gerade noch zu der Frage oben einfällt: die Russen waren doch auch mal mit den Chinesen befreundet --> vielleicht handet es sich ja auch um eine chinesische Beschreibung der Befehle, oder liege ich da ganz falsch?
"00" macht auch im chinesischen Unicode wenig Sinn. Es sieht doch eher nach einer Zahl oder mehreren Zahlen aus. Da die letzten acht Bytes aber hoechtswahrscheinlich keine weiteren Informationen bez. dem Steuerungsbefehl beinhalten tippe ich auf eine Art Checksum oder sowas. Komisch ist nur, dass es sich dabei um soviele Bytes handelt...
finalcu schrieb: > Ja das erste Byte ist die Länge - wie bereits gesagt, bis zum Byte "d0" > weiss ich was die Bytes darstellen. ich würde eher sagen, das sind mehere Parameter die, durch d007 getrennt sind. d007, umgeschrieben in die richtige Reihenfolge 07d0 ergibt dezimal genau 2000. Kann natürlich auch Zufall sein, aber diese Zahl ist mir zu 'glatt'. Meine Hypothese: diese 2000 sind eine Form eines Trennzeichens. Vor allen Dingen, weil diese 7d0 in jedem Datensatz auch mehrfach auftauchen und immer an derselben Stelle. Wie sinnvoll ein derartiges Trennzeichen in einer binären Übertragung ist, lass ich mal dahingestellt. Vielleicht ist es auch ein historisches Überbleibsel. > Ein Beispiel: > > 10005e001c000000d00728000000d007 beinhaltet folgende Informationen: > > - 10 00 ist die Länge (Bytes sind in umgekehrter Reihenfolge), also 16 > Bytes > - 5e 00 ist der Steuerungsbefehl, also Befehl-Nr. 94 > - 1c 00 00 00 ist ein Parameter, also 28 > > mit diesem Befehl setzt man eine Spannung auf 28 V. Welche Spannung? Steckt das im Befehlscode (94) drinnen, oder kann es sein, dass die restlichen Bytes dies beschreiben? Kannst du noch ein paar weitere Befehl in ihre Bedeutung aufdröseln?
1 | 10 00 57 00 10 00 00 00 d0 07 03 d0 07 00 00 00 |
2 | 10 00 57 00 20 00 00 00 d0 07 03 d0 07 00 00 00 |
3 | 0d 00 3e 00 01 d0 07 00 d0 07 03 d0 07 |
4 | 0d 00 3e 00 00 d0 07 00 d0 07 03 d0 07 |
5 | 10 00 5e 00 1c 00 00 00 d0 07 28 00 00 00 d0 07 |
6 | 10 00 5e 00 1b 00 00 00 d0 07 28 00 00 00 d0 07 |
7 | 10 00 64 00 a4 19 48 00 d0 07 00 47 00 01 d0 07 |
8 | 10 00 56 00 20 00 00 00 d0 07 03 d0 07 00 00 00 |
9 | 16 00 64 00 A4 19 48 00 66 00 28 00 00 00 d0 07 00 27 00 00 29 00 |
10 | 16 00 64 00 8c 19 48 00 66 00 28 00 00 00 d0 07 00 27 00 00 29 00 |
Diese beiden Datensätze
1 | 10 00 64 00 a4 19 48 00 d0 07 00 47 00 01 d0 07 |
2 | 16 00 64 00 A4 19 48 00 66 00 28 00 00 00 d0 07 00 27 00 00 29 00 |
sind interessant. Hast du dich da beim Abschreiben vertan oder ist das wirklich so: Gleicher Befehlscode, aber unterschiedliche Parameterlänge und Anzahl.
Karl heinz Buchegger schrieb: > Welche Spannung? > Steckt das im Befehlscode (94) drinnen, oder kann es sein, dass die > restlichen Bytes dies beschreiben? Das steckt im Befehlscode drinnen... Karl heinz Buchegger schrieb: > Diese beiden Datensätze > 10 00 64 00 a4 19 48 00 d0 07 00 47 00 01 d0 07 > 16 00 64 00 A4 19 48 00 66 00 28 00 00 00 d0 07 00 27 00 00 29 00 > sind interessant. Hast du dich da beim Abschreiben vertan oder ist das > wirklich so: Gleicher Befehlscode, aber unterschiedliche Parameterlänge > und Anzahl. Das ist wirklich so. Beim zweiten Code handelt es sich um zwei Befehle die in einem Paket geschickt werden: 10 00 64 00 a4 19 48 00 d0 07 00 47 00 01 d0 07 bedeutet: - 10 00 = 16 Bytes - 64 00 = Befehl-Nr. 100 - a4 19 48 00 ist ein Parameter der in binär Schreibweise die Zustände von LEDs angibt (0 = aus, 1 = ein), also a4 19 48 00 = 010010000001100110100100 => LED0=aus, LED1=ein, LED2=aus, LED3=aus etc. 16 00 64 00 A4 19 48 00 66 00 28 00 00 00 d0 07 00 27 00 00 29 00 bedeutet: - 16 00 = 22 Bytes - 64 00 a4 19 48 = Befehl-Nr. 100 mit gleichem Parameter wie oben - 66 00 zusätlicher Befehl = Befehl-Nr. 102 - 28 00 00 00 = 40, Parameter der zum Befehl 102 gehoert (ich weiss nicht genau was der macht, ich glaube es öffnet ein Ventil wobei 40 die Nr. des Ventils ist) was ich soweit gesehen habe ist, dass es keine Rolle spielt wieviele Befehle aneinander gehängt werden, am Ende folgen immer 8 Bytes beginnend mit "d0"... ich werde gleich nochmal an den Simulator gehen und überprüfen ob dies auch für ganze lange Befehlsreihen zutrifft (beispielsweise bei der Initialisierung bis zu 300 Bytes). Gruss, finalcu
UPDATE: Folgendes habe ich in der Zwischenzeit herausgefunden: - Auch bei einem langen Paket (Initialisierungspaket 373 Bytes) werden am Ende acht Bytes angehängt. Folgend ein Beispiel einer Initialisierung:
1 | 75010100000200000300000400000500000600000700000800000900000a00000b00000c00000d00000e00000f00001000001100001200001300001400001500001600001700001800001900001a00001b00001c00001d00001e00001f00002000002100002200002300002400002500012600002700002800002900002a00002b00012c00012d00002e00002f00003000003100003200003300003400003500003600003700003800003900003a00003b00003c00003d00003e00003f00004000004100004200004300004400004500004800004900004a00004b00004c00004d00004e00004f00005000005100005200005300005400005500005600005700015800015900015a00005b00005c00005e001c00000060000100000061000062000000000063000000000064008c29280065000000a2006600280000006700000000006800016900000000006a00006b00000000006c00bc0200006d00000000006e00000000006f0000000000d007000000000000 |
- 7501 ist wieder die Länge, also 373 Bytes - dann folgen die Befehle: 0100 = Befehl-Nr. 1 mit Parameter 00 = 0, 0200 = Befehl-Nr. 2 mit Parameter 00 = 0 (bei den Parametern handelt es sich um booleans, also entweder 0 (00) oder 1 (01) daher wird wahrscheinlich nur ein Byte verwendet, und so geht es weiter bis zum letzten Befehl 6f00 = Befehl-Nr. 111 mit Parameter 00000000 = 0 - am Ende steht wieder dieser komische 8 Byte Code, diesmal sieht er jedoch leicht ander aus: d007000000000000 Edit Ich habe mir die Freiheit genommen, die abartig lange Zeile in [ pre ][ /pre ] (ohne Leerzeichen) einzuschließen. rufus
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.