PS: Was mir gerade in den Sinn kommt, ist eine Minimaltelemetrie für den JLOG1. Also z.B. Kapaalarm per ATTiny weiter an einen HoTT Empfänger ...
Jo, das ginge natürlich. Am besten den OpenFormat-Livestream (asynchron-seriell 9k6) von JLog1 auswerten, da sind alle Daten und auch die Alarme einzeln drin. So macht es ja auch Linus mit seiner eigenen Telemetrie mit XBee, mit JLog1 und 2.

Meine eigene Telemetrie "JTX" macht es ja quasi auch so, nur, dass ich die binären Datenpakete des JIVE in einem am Modell befindlichen JLog2 (Hardware) auswerte, logge und alarmbewerte, dann modifiziere und mit eigenen Daten auffülle (Status, mAh nur am Modell berechnet wg. möglichem Datenverlust auf der Strecke, JLog-eigene Sensoren (Daten)) und per XBee zu einem zweiten JLog2 (Hardware) am Boden sende, der mit den Basisdaten in den Paketen genau dasselbe macht, wie das Teil am Modell. JLog-eigene Sensordaten sind für den nur genauso "virtuell" wie die Sensordaten aus dem JIVE. Er kann nun auch loggen, oder man schaltet das im JLC ab. Er macht dann einfach JETI(box) oder Unidisplay oder HoTT (SmartBox) zur Anzeige und alarmiert mit eigenem Geber (Buzzer, LED). Siehe hier.
Bitte unbedingt auch die Nachsätze beachten. Ungeschachtelt zum Uplink im selben Band zu senden (Was übrigens auch Spektrum mit dem TM1000 macht!), kann u.U. leicht ungesund für die Hauptanwendung sein. In DE bleibt uns dann nur das 433MHz-ISM-Band als Ausweg, was ich als HAM hasse, oder eben evtl. 868MHz.
EDIT: Oops, Du sprachst ja von HoTT, da war mein Gelaber über "JTX" nicht ganz passend. Sorry, nicht aufgepasst.

Und kannst Du ein paar Worte zur Smartbox sagen? Habe bisher nur Textmode und Binärmode verstanden.
Ich weiß jetzt nicht genau, was Du meinst. Die SB ist ein Busmaster wie auch der Empfänger, weshalb man auch mit der SB nicht einen Rx im Direktanschluss als Terminal konfigurieren kann, wohl aber die anderen Sensoren.
Die SB kennt nun logischerweise, wie ein Sender, die zwei Modi, "Text" (Terminal, 8x21Z, interaktiv mit 4 Tasten) und "Binär" (unidirektional). Allerdings zeigt die Box im Direktanschluss an einen Sensor binär nichts an, nur, wenn sie an einen Tx-Modul angeschlossen wird, also so ein Ding zur Auf-/Nachrüstung. Grund ist, dass eine Binäranzeige immer mehr will, als ein einzelner Sensor sendet, nämlich vor den Daten des eigentlichen Sensors (GAM/GEM, EAM, VARIO, GPS) auch teilweise Daten des Empfängers als Sensor, in einem Header. Das liegt in der "embedded SB" in einem Full-HoTT-Sender vor, und natürlich auch beim Anschluss einer physischen SB an einen Tx-Modul, die TXe kriegen ja ihr Zeugs von einem Rx.
(Ich habe dann den Bodenteil meiner "JTX"-Telemetrie ("JTX Base") seitens HoTT modifiziert, sodass bei Wahl einer SB (also HoTT) als Display auch die grafischen Binärseiten wahlweise verwendet werden können.)

Wurden die Datenstrukturen, außer mit Nullbytes Auffüllen auf die neuen Framelängen geändert?
Das ist jetzt so 'ne Frage. Erstmal: Ja. Nur, der Wechsel von v3 auf v4 war ja kein glatter, da haben Ralf Helbing und ich (Evtl. auch Andere?) so einige Gefühlswechsel durchleben dürfen, weshalb es mir gerade im Vergleich zur v3 direkt schwer fällt, die letztendlichen Änderungen zu benennen. Ich nehme mal an, Deine Frage bezieht sich auf den Unterschied zur Vorversion, also v3, also den offiziell einzigen Schritt v3-->v4? Das Blöde war eben nur, dass es für mich verschiedene Schritte waren, mit Zwischenschritten, da hat die Altzheimer freie Bahn.

In Stichworten:
- Textmodus: Sensoren haben jetzt auch eine dedizierte Adresse wie im Binärmodus, vorher gab es (zum Glück) auch schon eine Adresse, aber EINE Adresse für alle Sensoren. Das ist der Grund, weshalb ein Sender zusätzlich "etc" bzw. eine SB "oldSensor" kennt, damit wird ein alter Sensor (v3) textuell adressiert. Glücklicherweise ist die Sammeladresse, die in V3 verwendet wurde, in v4 nicht mehr in Benutzung, alle dedizierten Adressen unterscheiden sich von der (alten) Sammeladresse.

- Binärmodus: Zunächst kamen die 9 Bytes hinten ran, Byte 35 bis 43, die kann man im Augenblick einfach mit Nullen füllen, solange neue Binärdisplays, die das nutzen, noch nicht da sind (im Sender, in der SB). In den Datenbytes davor blieb alles unverändert. Was sich noch verändert hat, ist der Header, Byte 1 bis 6: Nach 5ms Idle Line (!) kommt wie zuvor Byte1==0x7C, dann Byte2==<binäre SensorID>, Byte3==Alarmbits (wie in v3), Byte4==<SensorID wie im Textmode, 4Bit-Tastencode==0>(!), Byte5,6==Alarm-Inverse-Bits (wie in v3). Ab Byte7 dann die Daten wie in v3, also z.B. Zelle1 beim GAM. -- Der empfangende Binärmodus der SB (nur für Betrieb an einem Tx-Modul gedacht) sieht völlig anders aus als der sendende eines Sensors, - zwischen binärer und textueller SensorID befinden sich 13 Bytes des besagten Rx-Headers, und die beiden Alarm-Inverse-Bytes finden sich nach den 9 neuen Datenbytes und vor dem Endezeichen.

Mannomann, ich werde noch des Hochverrats angeklagt..