HOTT USB/Bluetooth Protokoll entschlüsselt - Brauche eure Hilfe

Status
Nicht offen für weitere Antworten.
Scavanger

Scavanger

Benutzer
#1
#1
Servus an alle HOTT Jünger,

ich bin gerade dabei das HOTT USB/Bluetooth Protokoll zu entschlüsseln, das nicht identisch mit dem "normalen" HOTT bzw. Smartboxprotokoll ist. Die Anfragen sind etwas komplexer aufgebaut.
Dieses Protokoll kann auch viel mehr, z.B. nutzt das "Firmware Upgrade Studio" dieses Protokoll um die Firmware zu flashen, erlaubt Zugriff auf das EEPROM (Modellspeicher) und SD Karte, usw.
Allerdings beschränke ich mich drauf über dieses Protokoll zugriff auf die Telemetrie zu bekommen, so wie die Smartphone Apps.
Die Informationen sind sehr spärlich dazu in Netz und wenn dann ist das Protokoll sehr "hölzern" nachgebaut, hab auch schon bei Graupner danach gefragt, hab aber nur die Spezifikationen für das normale HOTT-Protokoll genommen. :( Naja, nun ist halt reverse Engineering gefragt. :D

Bin schon ein ganzes Stück vorangekommen, allerdings habe ich nicht alle Sensoren hier zum testen, vor allem die Abfrage welche Sensoren aktuell angeschossen bereitet mir etwas Kopfzerbrechen, hab zwar eine starke Vermutung was die Antwort bedeuten soll aber bin mir nicht ganz sicher. :eek:

Hier brauch ich Hilfe von euch.

Ich brauch einen kleinen Dump der Antwort vom Empfänger.

Kleine Anleitung:

Ihr braucht dieses Programm: HTerm http://www.der-hammer.info/terminal/index.htm
Braucht ihr auch nicht installieren, einfach runter laden und starten.

Schließt euren HOTT Sender per Bluetooth oder USB an den Rechner an.

Nehmt in HTerm die folgende EInstellungen vor:
Port: Port von HOTT Sender
Baud: 115200
Data: 8
Stop: 1
Parity: None

Bei Received Data NUR HEX wählen

Bei Input Control ebenfalls NUR Hex
und Type ebenfalls HEX.

Wie hier auf dem Screenshot:
HTerm-HOTT-Settings.png

Verbindet euch nun in HTerm mit dem COM Port des Senders.

Nun gebt bei "Input Control" folgendes ein:
Code: 
00 01 FE 00 00 04 32 D5 DA
Und drückt Enter, nicht "ASend"!

Dieses Kommando fragt die angeschlossenen Sensoren ab.

Und postet das Ergebniss (unter Recieved Data, als HEX) zusammen damit welche Sensoren angeschlossen sind.

Wenn ihr mehrere Sensoren habt, würde ich mich wahnsinnig freuen wenn ihr die mehrerer Kombinationen von angeschossenen Sensoren testet, z.B. Voltage-Module, Electric Air und GPS zusammen, dann jeweils nur ein Sensor angeschlossen, usw.

Wer Lust daran hat mit am entschlüsseln des Protokolls zu werkeln darf sich natürlich auch gerne melden.
Wenn ich soweit bin das man das Ergebnis vorzeigen kann werde ich meine Ergebnisse natürlich veröffentlichen.

Schon mal im voraus vielen Dank für die Mithilfe. :)
 
Scavanger

Scavanger

Benutzer
#3
#3
Hallo,

kenn ich, hilft mir leider nicht bei meinem Problem weiter, und genau den meinte ich mit "hölzern". ;)

Hintergrund:
Beim loggen der seriellen Daten vom "Firmware Upgrade Studio", das ja auch die Telemetrie Daten anzeigen kann, ist mir aufgefallen das nur die Sensoren abgefragt werden die tatsächlich angeschlossen werden, das o.g. Kommando (genauer gesagt das 7. Byte 0x32 ist das eigentliche Kommando) wird immer zuerst gesendet, je nachdem welche Sensoren angeschlossen sind kommt eine entsprechende Antwort zurück, und genau dieses Kommando habe ich noch nirgendwo implementiert gesehen.
Auch der Source Code des Data Explorer bzw. der HOTT Adapters, der mir sehr viel geholfen hat, implementiert zwar viel, aber eine Abfrage der angeschlossenen Sensoren nicht. :(
 
Scavanger

Scavanger

Benutzer
#5
#5
Schon klar,

wie ich schon geschrieben hab es gibt das Kommando "0x04 0x32", das die angeschlossenen Sensoren abfragt.
Bei der Grauner PC Software laufen keine Abfragen "ins leere".
Ginge zwar auch anders, aber ich hätte es gerne drin.
 
Scavanger

Scavanger

Benutzer
#7
#7
Ziege-One hat gesagt.:
GAM und Air ESC

Antwort
00 01 FE 01 00 04 01 23 A1 51
Zum Vergrößern anklicken....
Servus,

Danke!
Mein persönlicher Held des Tages!

Das Bestätigt genau meine Vermutung! :D

Die angeschlossenen Sensoren sind als Bitfeld codiert, die Antwort ist ein einziges Byte, hier 0x23, ein Bit entspricht einem Sensor, also Bit gesetzt = Sensor vorhanden.

Wenn man sich die Befehle zum Abfragen der Sensoren ansieht sind sie Aufsteigend, von 0x34 für den Empfänger bis 0x3A für Car ESC sortiert. Ich dachte mir schon das sie in gleicher Reihenfolge codiert sind.

Also:

Bit Sensor
0 Empfänger
1 General Module
2 Electric Air
3 Vario
4 GPS
5 Air ESC
6 Car ESC
7 Reserviert

0x23 = 0b00100011‬ Passt also!
 
Ziege-One

Ziege-One

Erfahrener Benutzer
#9
#9
Hi

ich suche was

Telemetriedaten vom Vario. oder GR18
Das Vario hat 21Zeichen Text im Koptermenu da sollen Daten vom Gryro und Accel drinstehen.

Hat einer ein Bild davon hat ?

Wofür das Ganze? das neue Graupner OSD erechnet aus den Daten den Horizont :D wenn man wüste wie könnte man das auch mit Daten aus cleanligt füttern

MfG Ziege-One
 
Scavanger

Scavanger

Benutzer
#10
#10
Hi,

sowas ähnliches hatte ich auch schonmal überlegt. :)
Wäre cool wenn Cleanflight die Acc und Gyrodaten über HOTT Telemetrie ausgeben könnte. :cool:

Sicher das das der GR18 sich als Vario ausgibt? Könnte aber gut sein.

Die Struktur (für das Bluetooth-Protokoll), soweit ich sie herausfinden konnte, nur für das Vario :
Code: 
INT16 Höhe
INT16 Max. Höhe
INT16 Min. Höhe
INT16 Steigrate in 1 sec
INT16 Steigrate in 3 sec
INT16 Steigrate in 10 sec
UINT8 RXSQ
Der ganze Block ist allerdings 41 Bytes lang, bleiben noch 28 Bytes frei für Acc/Gyro usw.

Mit einem GR18 oder gar einem Dump kann ich aber leider nicht dienen.
 
Zuletzt bearbeitet:
Scavanger

Scavanger

Benutzer
#12
#12
Ahhh..

*klatsch*. Ja stimmt natürlich, man sollte halt die HOTT Doku genau lesen. :eek:

Ich bin ja immer noch daran ein HOTT-OSD für Android zu entwickeln, also für die Leute die per Easy-Cap FPV fliegen. Da hätte den Horizont auch gerne drin.

Ich hab mir jetzt spontan nen GR-18 bestellt, wenn auch nur zum Auswerten der Daten.
Stell dann natürlich gerne die Daten zur Verfügung.
 
Ziege-One

Ziege-One

Erfahrener Benutzer
#13
#13
Das hört sich gut 😄
Wo jetzt genau die daten für den horizont liegen, kann ich noch nicht sagen entweder im vario oder im Receiver Protokoll.
Denke im Receiver weil der Horizont nur mit osd an der funke geht, und nicht im modell weil man ja den Receiver nicht auslesen kann über den telemerie Port
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten