Probleme Checksum bei Telemetriedaten Flight Control

[Michael S. (snickers)]

Hallo,

ich habe nun wegen "Babypause" (Erst eins und nachher noch Zwillinge) 
schon seit über 7 Jahren so gut wie nix mehr mit meinem Hobby Elektronik 
und Modellbau gemacht. Jetzt sind die Kids aus dem gröbsten raus und ich 
kann mich nun auch ab und zu mal wieder meinem Hobby widmen.

Aber nun zu meinem Problem.
Ich habe hier eine Flight Control die Telemetrie-Daten an die 
Fernsteuerung überträgt. Verbunden ist sie über eine Serielle 
Schnittstelle mit dem Empfänger.
Bis jetzt konnte ich schon einmal die Daten Auslesen und habe auch schon 
raus wofür 2 Werte sind (Altitude Spalte 7 und Voltage Spalte 5) und 
konnte auch die Ausgelesenen Daten an die Fernsteuerung via PC am 
Enpfänger übertragen mit einer Ausgabe am Display.
Nun habe ich aber das Problem das in Spalte 35 wohl irgendeine Prüfsumme 
berechnet wird, wo ich nicht leider nicht weiß wie sie berechnet wird. 
Ich habe es mal mit CRC8 versucht aber leider nicht die Erlösung 
bekommen. Da meine Elektronik-Kenntnisse nur leicht erhöhtes 
Hobby-Niveau sind stecke ich hier aber nun fest.

Ich habe mal drei Screenshots der Telemetriedaten, einmal mit Akku und 
einmal nur mit 5V an der FC, hier abgelegt um unterschiedliche Werte zu 
bekommen.

Ich habe festgestellt das die Prüfsumme manchmal gleich ist obwohl die 
Werte sich gesteigert haben z.B. hier mal ein paar Datenpakete die 
direkt hintereinander von der FC gesendet wurden (36 Bytes in Hex) :

A524012041000900000000000000F5FF0000000000000000000000000000000B0000685A
 - Hier ist Byte 5 = 41h und Byte 7 = 09h und Byte 35 ist 68h
A524012042000900000000000000F5FF0000000000000000000000000000000B00006B5A
 - Byte 5 Ändert sich von 41h in 42h und Byte 35 wird 6B
A524012041000A00000000000000F5FF0000000000000000000000000000000B00006B5A
 - Byte 5 wieder 41 aber Byte 7 0Ah -> Byte 35 bleibt 6B
A524012041000A00000000000000F5FF0000000000000000000000000000000B00006B5A
 - Alles unverändert
A524012042000A00000000000000F5FF0000000000000000000000000000000B0000685A
 -Und hier ist Byte 5 = 42h und Byte 9 = 0Ah aber Byte 35 auch wieder 
68h
A524012041000A00000000000000F5FF0000000000000000000000000000000B00006B5A
 - Hier Byte 5 wieder 41h -> Byte 35 wieder 6B
A524012041000900000000000000F5FF0000000000000000000000000000000B0000685A
 - Byte 7 wird 09h _ Byte 35 68h
A524012041000900000000000000F5FF0000000000000000000000000000000B0000685A
 - Alles unverändert
A524012041000900000000000000F5FF0000000000000000000000000000000B0000685A
 - Alles unverändert
A524012041000A00000000000000F5FF0000000000000000000000000000000B00006B5A
- Byte 7 wird wieder 0Ah -> Byte 35 wird wieder 6Bh


Byte 5 ist Byte 7 ist hier das einzige was sich ändert und halt immer 
Byte 35 wohl als Prüfsumme.

In den Screenshots sind die Werte von Byte 5,7 & 35 auch mal ganz 
anders.

Ich hoffe hier kann mir einer von den Profis helfen, worauf diese 
Prüfsumme basieren könnte...

MfG

Michael

[Marc V. (Firma: Vescomp) (logarithmus)]

Michael Schneider schrieb:
> Ich hoffe hier kann mir einer von den Profis helfen, worauf diese
> Prüfsumme basieren könnte...

 Mit Excel anstatt Screenshot wären deine Chancen ungefähr 100x größer.

[Michael S. (snickers)]

Naja, mit einer Excel-Datei kann ich zur Zeit leider nicht Dienen, aber 
ich habe mal ein log File aus HTerm etwas zusammengeschnitten, mit 
möglichst verschiedenen Werten.
Ich hoffe das reicht auch erstmal aus.


Gruß

Michael

[Marc V. (Firma: Vescomp) (logarithmus)]

Michael Schneider schrieb:
> Naja, mit einer Excel-Datei kann ich zur Zeit leider nicht Dienen, aber

 Keine Ursache.

[Michael S. (snickers)]

Marc Vesely schrieb:
>  Keine Ursache.

Vielen, vielen Dank !

Ich war in der Zwischenzeit auch fleißig und habe mit OpenOffice die 
Hex-Bytes aufgesplittet zur Übersicht und als excel gespeichert. Die 
Dezimal Übersicht brauche ich ja dann nicht mehr zu machen ;-)
Ich denke zu der obigen Liste eine kleine Ergänzung

MfG

Michael

[Nils Z. (nils_z)]

Die Prüfsumme ist vermutlich nur ein XOR über die Daten.

Ein Paket:
A5 24 01 20410009 [...] 68 5A

Ich vermute:
- A5: Startzeichen
- 24: Paketlänge, 0x24 = 36
- 01: ?
- 20, 41, 00, 09, evtl weitere: Daten, darüber wird die Prüfsumme 
gebildet
- [...]: ?
- 68: Prüfsumme
- 5A: Schlusszeichen

0x20 ^ 0x41 ^ 0x00 ^ 0x09 = 0x68 (Prüfsumme)


Das passt auch für die anderen Pakete.

[Michael S. (snickers)]

Nils Z. schrieb:
> Die Prüfsumme ist vermutlich nur ein XOR über die Daten.

Hi, danke für diesen Hinweis ! Genau das ist es.
Es werden die Bytes 3 bis 34 XOR verknüpft. So paast es auch mit den 
anderen Daten aus anderen Ausschnitten.

Und so wirds sein, 0xA5 das Startbyte, dann die 0x24 für 36 Datenpakete 
danach 32 Bytes Daten und zum Schluß die Prüfsumme und das Stoppbyte 
0x5A.

Vielen Dank für die schnelle Hilfe !!

Gruß

Michael

[Nils Z. (nils_z)]

Ja kann natürlich auch über mehr Bytes sein, bei den ersten Paketen hat 
es zufällig auch mit einem Teil der Daten gepasst, dann habe ich nicht 
weiter probiert.

Schön, dass es gelöst ist!