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