Hilfe die Prüfsumme zu berechnen

[Simon S. (simschmid)]

Kann mir Jeamnd helfen, wie die Prüfsumme hier berechnet wird:

Speed  Move go

0  **RL**11*00*80*80*80*80*80*80*CD
1  **RL**11*00*80*81*80*80*80*80*CC
2  **RL**11*00*80*82*80*80*80*80*CB
10  **RL**11*00*80*8A*80*80*80*80*BC
20  **RL**11*00*80*94*80*80*80*80*C8
100  **RL**11*00*80*E4*80*80*80*80*BC
127  **RL**11*00*80*FF*80*80*80*80*A9

und die Raw Daten:

000 > 2A 2A 52 4C 2A 2A 31 31 2A 30 30 2A 38 30 2A 38 30 2A 38 30 2A 38 
30 2A 38 30 2A 38 30 2A 43 44
001 > 2A 2A 52 4C 2A 2A 31 31 2A 30 30 2A 38 30 2A 38 31 2A 38 30 2A 38 
30 2A 38 30 2A 38 30 2A 43 43
002 > 2A 2A 52 4C 2A 2A 31 31 2A 30 30 2A 38 30 2A 38 32 2A 38 30 2A 38 
30 2A 38 30 2A 38 30 2A 43 42
010 > 2A 2A 52 4C 2A 2A 31 31 2A 30 30 2A 38 30 2A 38 41 2A 38 30 2A 38 
30 2A 38 30 2A 38 30 2A 42 43
020 > 2A 2A 52 4C 2A 2A 31 31 2A 30 30 2A 38 30 2A 39 34 2A 38 30 2A 38 
30 2A 38 30 2A 38 30 2A 43 38
100 > 2A 2A 52 4C 2A 2A 31 31 2A 30 30 2A 38 30 2A 45 34 2A 38 30 2A 38 
30 2A 38 30 2A 38 30 2A 42 43
127 > 2A 2A 52 4C 2A 2A 31 31 2A 30 30 2A 38 30 2A 46 46 2A 38 30 2A 38 
30 2A 38 30 2A 38 30 2A 41 39



Der Speed wird jeweils im 4. Byte nach dem **RL** angegeben. Wenn sich 
ein Byte verändert zb. 80 > 81, dann nimmt die Prüfsumme um 1 ab. Dies 
gilt aber auch bei 80 > 90.

Ziel ist es die Commands mit dem Arduino zu senden, dabei können die 
Speedwerte (Analog in) variieren.

[A.. P. (arnonym)]

Vielleicht verrätst du uns noch, was das überhaupt für Daten sind? Oder 
sollen wir das noch erraten?
Ich weiß nämlich nicht, was "Speed Move go" sein soll und was die Daten 
überhaupt darstellen.

Woher kommen die Daten? Wohin gehen sie? Mit wem kommunizierst du die? 
Was soll das für ein Protokoll sein?

[Roland P. (pram)]

Hast du schon mal versucht, die bytes aller raw daten abzüglich der 
prüfsumme zu addieren?  Und dann auf das Ergebnis die Prüfsumme?

[Simon S. (simschmid)]

Roland P. schrieb:
> Hast du schon mal versucht, die bytes aller raw daten abzüglich der
> prüfsumme zu addieren?  Und dann auf das Ergebnis die Prüfsumme?

Ja, das geht leider nicht. ich habe festgestellt, dass die Prüfsumme 
abnimmt, wenn die Command Bytes zunehmen. Also, Wird ein Byte um eins 
erhöht, nimmt es in der Prüfsumme um eins ab. Es scheint so ... 
jedenfalls.

[Simon S. (simschmid)]

A.. P. schrieb:
> Vielleicht verrätst du uns noch, was das überhaupt für Daten sind?

Sorry, das ging unter.

Die Daten (Seriel 9600 8N1, steuern einen Kamerakopf.
Die einzlenen ASCI Bytes sind dabei zuständig für eine Achse, also Pan, 
Tilt, Zoom, Focus, etc. Der Wert 80 ist dabei die Stopp-Position, Werte 
über 80 sind Bewegungen in die positive, unter 80 in die negative 
Richtung. Je mehr die Werte von 80 gegen 00 oder FF abweisechen, desto 
schneller passiert die Veränderung. Ich hoffe, dies schafft Klarheit.

[FloMann (Gast)]

Simon S. schrieb:
> Roland P. schrieb:
> Hast du schon mal versucht, die bytes aller raw daten abzüglich der
> prüfsumme zu addieren?  Und dann auf das Ergebnis die Prüfsumme?
>
> Ja, das geht leider nicht. ich habe festgestellt, dass die Prüfsumme
> abnimmt, wenn die Command Bytes zunehmen. Also, Wird ein Byte um eins
> erhöht, nimmt es in der Prüfsumme um eins ab. Es scheint so ...
> jedenfalls.

Hast du die Summe mal komplementiert, stellt sich noch die frage nach 
der genauen
framelänge die berechnet wird. Von arbeitswegen her war dies bei uns 
länger der olle
Standard prüfsummen weg alles addieren und als prüfsumme das lsb der 
Summe komplementiert anhängen. Bei ascii bassierenden cmd frames wurde 
die cs ebenso
Berechnet aber mit 2 ascii Zeichen als hex lesbar angehangen.

[Simon S. (simschmid)]

Das tönt spannend. Kannst du mir das mit dem Komplemengieren erklären. 
Ich dachte auch schon, ev. müsse ich einfach den errechneten Wert von FF 
abziehen oder so ...

[Nop (Gast)]

Simon S. schrieb:
> Das tönt spannend. Kannst du mir das mit dem Komplemengieren
> erklären.
> Ich dachte auch schon, ev. müsse ich einfach den errechneten Wert von FF
> abziehen oder so ...

Man berechnet die Summe der Bytes, und die Prüfsumme muß dann so sein, 
daß deren Addition darauf dann 0 ergibt, das wäre üblich. Das würde auch 
erklären, wieso sie um 1 abnimmt, wenn eines der Datenbyte um 1 zunimmt.

0 heißt natürlich modulo 256. Also müßtest Du nicht von FF abziehen, 
sondern von 256.

[Simon S. (simschmid)]

Das probiere ich gleich aus, was passiert mit dem Übertrag bei der 
Addition? Springt der bei 255 wieder auf 0?

[Nop (Gast)]

Simon S. schrieb:
> Das probiere ich gleich aus, was passiert mit dem Übertrag bei der
> Addition? Springt der bei 255 wieder auf 0?

Ja, das heißt "modulo 256". Der Rest, der bei einer Division durch 256 
übrig bleibt, also das unterste Byte.

Also in hex kommt nach 0xff ja 0x100, aber es wird nur das unterste Byte 
verwertet. Du kannst also einfach alle Bytes aufaddieren, in einen 
ausreichend breiten Integer, und dann nur das unterste Byte betrachten.

[Yalu X. (yalu) (Moderator)]

Mich wundert etwas, dass im 4. und 6. Beispiel die Prüfsumme gleich ist
(BC), obwohl sich in den Nutzdaten nur ein Wert ändert (von 8A nach E4).
Prüfsummenalgorithmen zeichnen dadurch aus, dass insbesondere kleine
Änderungen in den Nutzdaten (durch kurz andauernde Störungen auf der
Datenleitung) garantiert eine Änderung der Prüfsumme zur Folge haben.

Bist du sicher, dass es sich bei der letzten Hexzahl tatsächlich um eine
Prüfsumme handelt?

Wenn ja, dann hat sich diesen Algorithmus evtl. ein Anfänger ausgedacht,
wodurch die Anzahl der denkbaren Möglichkeiten so riesig ist, dass die 7
Beispiele kaum ausreichen werden, um zu einer sicheren Lösung zu kommen.

Kannst du mehr Beispiele posten?

[A.. P. (arnonym)]

Definieren wir

    % := Modulo

dann gilt:

0 % 256 = 0
1 % 256 = 1
…
255 % 256 = 255
256 % 256 = 0
257 % 256 = 1
usw.

Das Prinzip sollte deutlich werden.

[Nop (Gast)]

Yalu X. schrieb:

> Prüfsummenalgorithmen zeichnen dadurch aus, dass insbesondere kleine
> Änderungen in den Nutzdaten (durch kurz andauernde Störungen auf der
> Datenleitung) garantiert eine Änderung der Prüfsumme zur Folge haben.

Aber nur, wenn es gute Prüfsummen sind, was bei arithmetischen 
Checksummen nicht der Fall ist. Noch weniger bei XOR-Summen.

[Yalu X. (yalu) (Moderator)]

Nop schrieb:
> Aber nur, wenn es gute Prüfsummen sind, was bei arithmetischen
> Checksummen nicht der Fall ist. Noch weniger bei XOR-Summen.

Auch bei byteweiser Addition oder XOR-Verknüpfung wären die Prüfsummen
in den beiden genannten Beispielen verschieden.

[Simon S. (simschmid)]

Danke @Nop und Co. Ihr habt mich wieder auf die richtige Spur gebracht. 
Nun hab ichs:

Hab in Excel rumprobiert und alle Raw Bytes als DEC addiert, zusammen 
mit der Checksumme in DEC bekomme ich 1685. Nun habe ich bei den anderen 
Commands die Bytes ohne die Prüfsumme zusammengezählt und dann von 1685 
abgezogen, und siehe da: Bei allen Beispielcommands, die ich gesnifft 
habe, stimmt die daraus resulteirende Prüfsumme!

Leider habe ich das mit dem Module noch nicht ganz begriffen. Würde dies 
meine obige Therie mit der Komplettsumme 1685 irgendwie übereinstimmen?

[Roland P. (pram)]

Yalu X. schrieb:
> Mich wundert etwas, dass im 4. und 6. Beispiel die Prüfsumme gleich ist
> (BC), obwohl sich in den Nutzdaten nur ein Wert ändert (von 8A nach E4).

Die Raw Daten unterscheiden sich dabei wie folgt:

... 38 41...
... 45 34...

Und 38+41=45+34 was für eine simple Summe der Rohdaten spricht und kein 
kompliziertes Polynom

Simon S. schrieb:
> Ja, das geht leider nicht. ich habe festgestellt, dass die Prüfsumme
> abnimmt, wenn die Command Bytes zunehmen. Also, Wird ein Byte um eins
> erhöht, nimmt es in der Prüfsumme um eins ab. Es scheint so ...
> jedenfalls.

Ja das ist doch sehr gut. Zusamengezählt ergibt sie wahrscheinlich 0 
(mod 256) oder einen anderen konstanten Wert

[Simon S. (simschmid)]

> Simon S. schrieb:
>> Ja, das geht leider nicht. ich habe festgestellt, dass die Prüfsumme
>> abnimmt, wenn die Command Bytes zunehmen. Also, Wird ein Byte um eins
>> erhöht, nimmt es in der Prüfsumme um eins ab. Es scheint so ...
>> jedenfalls.
>
> Ja das ist doch sehr gut. Zusamengezählt ergibt sie wahrscheinlich 0
> (mod 256) oder einen anderen konstanten Wert

1685 Scheint hier the Magic Number! Kommt euch der Wert bekannt vor?
(695h oder 0110 1001 0101b) oder ist die Zahl eher Zufall oder das 
Geburtsdatum der Freundin des Programmierers?

[Yalu X. (yalu) (Moderator)]

Roland P. schrieb:
> Yalu X. schrieb:
>> Mich wundert etwas, dass im 4. und 6. Beispiel die Prüfsumme gleich ist
>> (BC), obwohl sich in den Nutzdaten nur ein Wert ändert (von 8A nach E4).
>
> Die Raw Daten unterscheiden sich dabei wie folgt:
>
> ... 38 41...
> ... 45 34...
>
> Und 38+41=45+34 was für eine simple Summe der Rohdaten spricht und kein
> kompliziertes Polynom

Ach, jetzt, klar :)

Ich ging irrtümlicherweise davon aus, dass die Prüfsumme nicht über die
Rohdaten, sondern über die ASCII-kodierten Hexzahlen gebildet wird, da
ja auch die Prüfsumme selbst so dargestellt wird.

[Roland P. (pram)]

1685 mod 256 wäre 149 und das wird wohl der Programmierer als "magic 
const" gewählt haben

Vielleicht hat er wirklich am 14.9 Geburtstag.
Alles in allem kommt mir die Prüfsummenberechnung etwas laienhaft oder 
sagen wir 'eigenartig' vor.
Mach einfach noch ein paar Versuche ob du nun immer auf die richtige 
Prüfsumme kommst.

VG Roland

[Nop (Gast)]

Roland P. schrieb:

> Alles in allem kommt mir die Prüfsummenberechnung etwas laienhaft oder
> sagen wir 'eigenartig' vor.

Wieso, das ist nicht soviel anders als z.B. im Intel-Hexformat.

[Simon S. (simschmid)]

Es scheint zu funktionieren (in der Theorie, im moment fehlt mir die 
Hardware). Hier für die Interessierten die Funktion, die ich für Arduino 
in processing.org geschrieben habe.

void sendString(int ADR, int PAN, int TILT, int ZOOM, int FOCUS, int IRIS) {  
  //Zusammensetzen der Befehle
  String cmdstr = "**RL**";
  cmdstr = cmdstr + hex(ADR,1) + "1" + "*";
  cmdstr = cmdstr + hex(00,2) + "*";
  cmdstr = cmdstr + hex(PAN,2) + "*";
  cmdstr = cmdstr + hex(TILT,2) + "*";
  cmdstr = cmdstr + hex(ZOOM,2) + "*";
  cmdstr = cmdstr + hex(FOCUS,2) + "*";
  cmdstr = cmdstr + hex(IRIS,2) + "*";
  cmdstr = cmdstr + hex(128,2) + "*";
  
  //Berechnen der ASCII Summe
  int SUM = 0;
  for (int x = 0; x < cmdstr.length(); x++)
  {
    SUM = SUM + (byte(cmdstr.charAt(x)));
  }
  
  //Berechnen der Checksumme
  int CHK = 1685 - SUM;
  
  //Zusammensetzen des Serialcommands
  cmdstr = cmdstr+hex(CHK,2);
  
  //Debugasugabe
  println(cmdstr);
  
  //Ausgabe auf myPort
  myPort.write(cmdstr);
}