Graupner HoTT Telemetrie-Sensoren Eigenbau DIY | Telemetrie-Protokoll entschlüsselt

JLog S32

JLog S32

Super, Vielen Dank für die schnelle Antwort,
gibt es sogar auf der Graupner Homepage.
Ich bin zwar auf der Suche mal darübergestolpert, konnte es aber nicht erkennen das er auch wie ein Konverter die Protokolle umwandeln kann, z.B von X-BUS nach HoTT.
Ich schaue es mir jetzt mal in ruhe an, da es doch einiges an Information zum lesen gibt.

Danke und Gruß
Jörg
 
Nachfrage JLOG 32S

Nachfrage JLOG 32S

Hallo,
nach dem ich einiges auf der JLOG Seite und die Anleitung gelesen habe, konnte ich nicht explizit herauslesen das es Protokolle (z.B. Sepektrum Eingang nach HoTT Ausgang) umwandelt.
Ob es die Eierlegendewollmilchsau ist kann ich nicht beurteilen :eek: Aber eventuell ist es für den JLOG 32S so banal dass es nicht erwähnt wird.
Wäre Super wenn mir jemand erklären könnte das das JLog Protokolle konvertieren kann.

Gruß
Jörg
 

Volker Cseke

Moderator
Teammitglied
Hallo,

ich denke, diesen speziellen Fall kann nur Thomas sicher beantworten. Auf der JLOG-Seite ist seine Kontaktmöglichkeit aufgeführt.

Oder die besorgst dir ein JLOG und probierst es aus. Das Ding macht echt viel Spaß und hat viele Möglichkeiten.

LG

Volker
 
Ich habe e Frage. Kann m wär ein Stromsensor mit Drehzahlsensor Bauen?

Ich habe e Frage. Kann m wär ein Stromsensor mit Drehzahlsensor Bauen?

Hallo Leute. Einen GPS bzw 4Sensor habe ich nur Kappa und Drehzahl Fehlt mir. Mein ESC Gibt direkt die Drehzahl aus. Ist ein JEP90lv von HK.
Gruss Milan
Hallo
Hallo,

ich denke, diesen speziellen Fall kann nur Thomas sicher beantworten. Auf der JLOG-Seite ist seine Kontaktmöglichkeit aufgeführt.

Oder die besorgst dir ein JLOG und probierst es aus. Das Ding macht echt viel Spaß und hat viele Möglichkeiten.

LG

Volker
 
Hallo. Ich wollte Fragen ob mir einer einen Strom und Drehzahl Sensor Bauen?

Hallo. Ich wollte Fragen ob mir einer einen Strom und Drehzahl Sensor Bauen?

Top wäre natürlich gleich ein 4-6S Sensor mit integriert? Gruss Milan
 
Abfragezyklus der Sensoren

Abfragezyklus der Sensoren

Hallo,
habe schon einige Graupner Sensoren im Einsatz. Weiterhin habe ich mir nun ein eigenen Stromsensor mit Arduino gebaut. Grundlage war das Programm von Ziege-One. Danke dafür.
Der Eigenbau funktioniert auch soweit. Nun ist mir aufgefallen, dass der Eigenbau nur alle 800ms ein Log Punkt setzt (Ausgelsen von der SD-Karte im Sender). Schauhe ich mit die Logs von einem Graupner ESC (oder Voltage Modul) an, so wird hier alle 50ms ein Log-Punkt gesetzt.
Wie kommt dieser Unterschied zustande? Mache ich was Falsch?

Wie sind die Zeiten im aktuellen Protokoll?
Getestet habe ich mit MC-20 und GR12L und Brushless Controll +T 35.

Gruß Matthias
 
Hallo Matthias,

schau mal in der Datei Message.cpp nach. Darin gibt es eine Methode Send(...) zum Verschicken des Telemetriepaketes an den Empfänger. In der Schleife wird nach dem Senden jedes Bytes 650 Mikrosekunden Pause gemacht. Bei der Größe der EAM- bzw. GAM-Datenstrukturen kommt da unterm Strich schon einiges zusammen. Die entsprechende Konstante HOTTV4_TX_DELAY ist übrigens in der Headerdatei Message.h deklariert.

Vielleicht ist in Deinem Code auch noch der Debugmodus aktiviert, das kostet noch zusätzliche Zykluszeit.

LG
Roland
 
Hallo Roland,

danke für deine Tipps. Ich habe am Wochenende ein wenig ausprobiert. Ich habe mit dem delay experimentiert. Hierbei ist mir nicht ganz klar warum es 650µs sind. Es gab mal die Information, dass es mindestens 1ms sein soll...?
Beim Versuch mit unterschiedlichen Zeiten wurde kurzeitig keine Werte im Display angezeigt. Bei mir läuft es am besten mit 500µs. Mit 1000µs lief es nicht so gut
Der Debug Mode ist nicht aktiv.

Die Zykluszeit kommt doch daher, da der Empfänger doch den Takt vorgibt oder? Der Controller könnte schneller denke ich.
In der Log Datei ist zu erkennen, dass die Abfragen in den ersten 30s sogar langsamer kommen (der Log ist etwas verspätet angefangen). Ich denke durch die Abfrage des Empfängers welche Sensoren anwesend sind.
Ab Zeile 9 sind es dann 800ms.

Log_1.JPG

Kommischerweise habe ich es einmal hinbekommen, das der Eigenbau auch alle 50ms ein Log Eintrag gesetzt hat. Weiß aber nicht warum.

Hier mal ein Log von dem Graupner Telemetrie Regler. Dieser wird anscheinend alle 50ms abgefragt (ab zeile 17).

Log_2.JPG

Da doch die Sensoren nur auf Anfrage senden muss doch der Empfänger dann ein anderen Abfrage Zyklus haben. Das ist mir gerade irgendwie ein Rätsel.

Gruß Matthias
 
Hallo Matthias,

hast Du mal getestet, ob Dein Sender auch die entsprechenden Binärwerte Deiner Sensoren abfragt?

Ich vermute sehr stark, dass da Textmeldungen mit den jeweils vollen 173 Bytes über den Rückkanal gefunkt werden. Und das für EAM, GAM und was sonst noch im Code implementiert ist.

Klammere einfach mal zum Test die EAM- bzw. GAM cases in der Gmessage Behandlung aus. Es könnte ein Timing Problem vorliegen, dass Dein Arduino die Anfragen vom Sender nicht rechtzeitig mitkriegt.

Ich kenne mich allerdings mit Hott überhaupt nicht aus, daher die Vermutung.

LG
Roland
 
Moin Matthias

Kann es an der Anzahl von Sensoren liegen ? (EAM GAM ESC.... die wechseln sich ja auch noch ab). Strom2Hott sendete glaub ich mehrere ?
 
Hallo zusammen,
danke für eure Hilfe.

Bin leider noch nicht zum testen gekommen und dann ist mir heute auch noch mein Test-Flieger abgestürzt...

Ich werde mal die Tage testen wenn ich im code nur einen Sensor aktiv lasse und die Textmeldung deaktiviere.
Kommisch ist halt, dass es durch Zufall schon einmal funktioniert hat mit 50ms.

Weiß denn jemand warum es 650µs zwischen den Bytes im Strom2Hott code sind?

Gruß Matthias
 
Moin Matthias
Früher waren es 2mS zwischen den Bytes, ich hatte vor ca. einem Jahr die aktuelle Protokollbeschreibung von Graupner /Ralf Helbig bekommen, Ralf schrieb, aktuell sind 1mS spezifiziert, bei 2mS kann es mit neuerer Firmeware evlt Probs geben.
Da ich nicht weiß. ob zwischen den Bytes evtl auch Daten in Richtung Empfänger geschickt werden, halte ich mich da sicherheitshalber strickt an die 1mS.

Die "Telemetrierate" lässt sich im Telemetriemenü im Sender ja zwischen 1-10Hz einstellen. (Ich selber nutze 1-2Hz, um bei meinen Solarmodellen Strom zu sparen, fühlt sich erst sehr schleppend an, aber mir reicht es).

Ein Datensatz GAM EAM mit 1mS sind ja ca. 50mS (45Byte +)
Dann kommen aber noch die Daten vom Empfänger, und kommt noch ein Modul dazu, wären es auch 150mS ?
 
Hallo zusammen,

Im OpenXsensor Code für Hott-Telemetrie sind auch noch die 2ms Pause für sehr alte Hott Versionen eingebaut.
Für ein Eigenbau-Vario hatte ich mit dem OpenXsensor-Code und der Übertragungsrate etwas experimentiert:

Ab etwa Mitte 2017 gab es bei den Empfänger Firmware-Updates das Stichwort "schnellere Telemetrie".
Seitdem wurden die Telemtriemodule 20 mal pro Sekunde abgefragt, bei n-angeschlossenen Modulen also mit eine Rate von (20/n)Hz.
Vorausgesetzt das Telemetrie-Modul antwortet schnell genug.
Mit einem Zähler im oXs-Telemetriemodul, der bei jedem Abfragen durch den Empfänger hochzählt und über die Telemtrie mitgesendet wird, kann die Gechwindigkeit gut bestimmt werden.
Erst bei etwa 200µs Pause oder kürzer wurden die 20Hz wirklich erreicht und auch mit 100µs funktioniert es noch einwandfrei. Das entspricht bei 19200Baud dann etwa 2 zusätzlichen Stoppbits. (oXs warte auch noch 5ms nach dem Abfragen durch den Empfänger bis die Telemetriedaten gesendet werden)
Mit dem GR-24 und 100µs funktioniert das seit >100 Flugstunden jetzt einwandfrei.

Gruß
Holger (zufälliger Namensvetter ...)
 

ingo_s

User
schnellere Telemetrie Info?

schnellere Telemetrie Info?

Hallo,

ab und zu habe ich auch mal HoTT Sensoren mit Timing der der offiziellen Dokumentation gebaut.

Gibt es irgendwo offizielle Unterlagen über das Sensor Timing der "schnelleren Telemetrie"?
Oder gibt es nur private Erkenntnisse von Leuten, die sich mit HoTT Sensorbau befassen und wenn ja, wo ist die Suche am erfolgreichsten?

Gibt es Erkenntnisse, ob auch die Telemetrie Datenrate und Zykluszeit zum Sender schneller geworden ist?

Gruß Ingo
 
Moin
Die Bytes sollten inzwischen jede 1ms geschickt werden, nicht mehr alle 2 ms.

Wie ich oben schon geschriebem direkt von Graupner, Ralf Helbig, per Mail im Herbst (Okt 2019), inkl aktueller Protokollbeschreibung, drum halte ich mich dran. (Die Protokollbeschreibung gab es immer nur per Mail, und nicht öffentlich, darum hatte ich mal eine aktuelle angefragt und auch bekommen).
 
Eine ältere Version ist hier:

https://github.com/openXsensor/openXsensor/blob/master/Hott doc/Sensorenschnittstelle_V4_2.doc

ich hatte im Dezember 2018 bei Graupner nach einer Aktuellen gefragt und eine V4_3 bekommen (@Holger L._: Welche Version ist Deine?)
Der einzige Unterschied zum Datenformat besteht aus dem ersatzlosen Weglassen von:

"About 2ms delay between all bytes."
und
"Bei der Antwort müssen die einzelnen Bytes in einem Raster von etwa 2 ms
gesendet werden. Nicht am Stück senden! "


Da die 20Hz auch mal "offiziell" von Ralf Helbing genannt wurden und sich auch als maximale Datenrate im Log-File Format, zumindest der MC/MX Serie, wiederfinden, muss die Pause wesentlich kleiner sein als 1ms.
Rechnerisch:
Der Empfänger frägt mit 2 Bytes das Modul ab, dann sollen 5ms gewartet werden, dann kommen 45 Bytes Modulantwort mit 19,2 kbaud, 1 Startbit, 8 data bits, 1 Stopbit.
d.h ohne jede zusätzliche Verzögerung vergehen schon 30ms.
Macht man nach jedem Byte ein extra Delay kommen 44*Delay dazu, für 20Hz sind aber nur noch 20ms übrig
--> Pause muss kürzer als 450µs sein, wenn noch eine (unbekannte) Mindestzeit für den Empfänger zwischen Frame und der nächste Abfrage dazukommt ist eine maximal Pause von rund 200µs plausibel (Vielleicht auch 300µs, ich hab da keine exakte Schwelle ermittelt).


Da ich nicht weiß. ob zwischen den Bytes evtl auch Daten in Richtung Empfänger geschickt werden, halte ich mich da sicherheitshalber strickt an die 1mS.

Die Zeit wäre ohnehin zu kurz, da schickt auch kein Gerät irgendwas, der Empfänger fragt reihum die angeschlossenen Sensoren ab, welche nur auf Aufforderung senden und wartet auf das Ende bzw die CRC Summe oder timeout. Die Empfängerdaten sind schon im Empfänger, es gibt also kein Gerät das den Bus benutzen will. Vielleicht war das am Anfang als eine Art Interrupt-Möglichkeit gedacht, wurde aber nie benutzt.

Und die leidvolle Geschichte mit der (ehemals) Graupner Dokumentation: Ich glaub langsam das war noch nicht mal bewusste Geheimniskrämerei, die interne Dokumentation war wohl einfach so chaotisch bis nicht vorhanden das es einfach nichts gab das rausgegeben werden konnte. Das sah man ja auch an der "Versionsverwaltung" und der Dokumentation der Firmware Versionen.
Ob das jetzt unter koreanischer Leitung besser wird glaub ich aber auch nicht wirklich ....

Eigentlich schade, das Hott-Telemetrieprotokoll ist nämlich genial einfach zu bedienen, mit jeder normalen Hardware UART ohne Verrenkungen im Datenformat machen zu müssen, dasselbe gilt auch für das HOTT-SUMD Protokoll.
Nur auch hier ist die Dokumentation eher bescheiden und man muss vieles mühsam selbst austesten ...

Holger
 

ingo_s

User
Ich habe 2012 die erste Variante und 2014 die letzte Version der Dokumentationen incl. der bldc und Air Sensoren im Excel Format von Herrn Helbig bekommen.

Ich war doch etwas verwundert 2012, das es kein offizielles Dokument über das Protokoll war, sondern eine Ideen Zusammenstellung in Verbindung mit externen Sensor Anbietern.
Vom eigentlichem Sensor Format bin ich sehr enttäuscht, ich hatte eine Weiterentwicklung des MPX MSB Protokolls erhofft und nicht Sensor spezifische proparitäre Zusammenstellungen von Sensor Werten, die ja auch bei jedem weiterem Sensor zu zwangsweisen Updates der Sender führen.

Ingo
 
Hallo Ingo,

also ein Excel-File zu den Sensoren kenn ich leider nicht, nur das oben verlinkte pdf/word Document in verschiedenen Versionen.

Was ich meinte, das Konzept der Hott-Telemetrie ist eben gerade nicht sensorspezifisch. Es sind 5 Adressen (Die "zufällig" Vario, GPS, EAM, GAM und ESC genannt wurden), und für die jeweils 40Byte übertragen werden.
Von Protokoll-Seite sind das 800 Bytes/s die eigentlich frei verwendbar sind. Die sensorspezifischen Sachen sind nur die Maske wie der Sender die Werte anzeigt bzw ansagt.
Im Logfile und am Data-Port der Sender sind die Werte 1:1 wie die angeschlossenen Telemetriemodule das auch abgeliefert haben.

Gegenüber Header, die noch Typ und Priorität des Wertes bestimmen müssen, kommt mir das sehr einfach und gleichzeitig relativ flexibel vor, allerdings kenn ich auch nicht viele Details der anderen Systeme.
Und eine frei konfigurierbare Ausgabe hat es halt nie gegeben, auch nicht von Dritt-Anbietern am Data-Port, wohl auch wegen fehlender Dokumentation und Graupner Unterstützung.
Aber hinter dem Data-Port hätte man (theoretisch) noch alle Freiheiten gehabt ....

Na ja hätte Fahrradkette, ich vermute Graupner Korea wird nur noch auf Mainstream setzen und wohl auch kaum den OpenSource/DIY/3rd Party Gedanken pflegen.
Bei der Wahl für Graupner Hott kannte ich auch noch nicht das Telemetrie-Protokoll. Früher oder später steht wahrscheinlich doch ein Wechsel zu OpenTX an.

Holger
 

ingo_s

User
Hallo Holger,

da der Sender die Werte nach der Spezifikation anzeigt, kann man die 40 Byte nicht einfach frei verwenden und man muss mit der Sensor spezifischen, proparitären Anordnung der Werte leben. Dazu kommt noch, das von jedem Sensor nur einer eingesetzt werden kann. 2Mot mit zwei Sensor-Reglern geht da z.B. nicht.

Ingo
 
Ansicht hell / dunkel umschalten
Oben Unten