Ich dachte mir, da JLog ja auch HoTT als Telemetrie bedient, ich sage mal etwas zum evtl. besseren Verständnis des Systems:
HoTT kennt zwei Modi, den Textmodus und den Binärmodus (grafisches Display).
Ab HoTT v4, ein (Software-)Update, das Ende des Jahres, Anfang 2012 erscheinen wird, sind die Sensoren auch im Textmodus einzeln adressierbar, also dann uneingeschränkt in beiden Modi parallel betreibbar. Darauf beziehe ich gleich mal meine Beschreibung.
Die Dokumentationen bieten leider beschränkte Klarheit bzgl. der Begrifflichkeit, jedenfalls hatte ich so meine anfänglichen Verständnisprobleme hinsichtlich der Namengebung, die Sensoren nennen sich noch heute “Modul”, obwohl Graupner unter “Modul” etwas anderes versteht.
Wir unterscheiden die folgenden Instanzen, die das System HoTT ausmachen:
HoTT-Sender, ein Sender, der die Telemetrie integriert hat, also auch seitens seines Displays. Äußerlich erkennbar am Sendergehäuse, die Dinger sehen nicht mehr aus wie von JR/Horizon.
HoTT-Sender-Modul, einzusetzen in einen Graupner-Sender, der nicht zur o.g. Kategorie gehört. Als Display wird hier eine externe SmartBox verwendet. Der Sender hat keine Sprachausgabe, der Modul auch nicht.
SmartBox. Die SmartBox empfängt Daten von einem Modul (s.o.) und stellt sie dar, sie kann als externer Monitor (Zweitdisplay) an einem HoTT-Sender betrieben werden, oder sie wird direkt an einen Sensor angeschlossen, im Textmodus betrieben, zum Setup des Sensors verwendet. Das Setup kann aber auch wireless via den Sender erfolgen, mit einem HoTT-Sender direkt über dessen Display und seine Tasten, nicht über die SmartBox, mit einem HoTT-Modul im Sender (umgerüstet) via die SmartBox am Modul.
HoTT-Empfänger. Der Empfänger kann NICHT mittels einer direkt angeschlossen SmartBox konfiguriert werden, nur via einen Sender, Voll-HoTT oder mit SmartBox am HoTT-Modul. Der Empfänger ist selbst auch ein Sensor (Empfängerspannung, innere Temperatur, Übertragungsqualität, Paket-Laufzeiten etc.), ein Sensor, der grundsätzlich und immer da ist.
HoTT-Sensor. Zur Zeit haben wir den GAM (General Air Module), GEM (General Engine Module), EAM (Electric Air Module), GPS und VARIO. GAM und GEM unterscheiden sich nur minimal, der GAM hat auch einen Drucksensor. Die Sensoren werden parallel am Telemetrieanschluss eines HoTT-Empfängers betrieben, per Y-Kabel, z.B., man kann auch alternativ (auf der Werkbank) eine SmartBox direkt anschließen und, SmartBox im Textmodus, einen Sensor konfigurieren. Dasselbe geht aber auch via einen Sender. (Die eigentlichen Sensoren, die in und an einem HoTT-Sensor hängen, Spannung, Druck, Strom, Temperatur, Drehzahl, etc., sind also gewissermaßen “Sensoren an der Peripherie”, während ein HoTT-Sensor grundsätzlich ein Multisensor ist, so wie 3rd party Sensoren, die HoTT unterstützen, Unilog2, JLog, …)
Nun muss man die Prinzipien des HoTT-Busses, also des HoTT-Protokolls verstehen:
Das ist ein 1-Draht-Bus, gesendet und empfangen wird also im Semiduplex auf dem einen Signaldraht, 19200 Baud asynchron-seriell, TTL-Pegel. Auf dem Bus gibt es immer einen Master und einen oder mehrere Slaves. Der Master fragt die Slaves im Binärmodus reihum ab, im Textmodus gezielt, diese antworten mit ihren Daten, wenn sie mit ihrer Adresse angesprochen wurden. Master ist ein HoTT-Empfänger oder eine SmartBox. (Hier findet sich der Grund, warum man einen Empfänger nicht mit einer SmartBox im direkten Anschluss konfigurieren kann, beide sind Master.) Slaves sind die Sensoren oder ein HoTT-Modul (in einem umgerüsteten bzw. HF-modularen Sender). - Der HoTT-Empfänger nimmt eine Sonderrolle ein bzgl. seiner Mitfunktion als Sensor, nur ein HoTT-Sender oder HoTT-Modul kann seine Sensordaten empfangen.
Textmodus
Der Sensor sendet den Inhalt eines Displays, 8 Zeilen á 21 Zeichen, Display im HoTT-Sender oder einer SmartBox. Jedes Zeichen kann auch invertiert dargestellt werden (hell auf dunklem Hintergrund). Mitgesendet werden Alarmcodes, was der empfangende Master damit macht, ist seine Sache. Der Sensor generiert also selbst die Alarme, entsprechend seinem Setup. Der Sensor kann so viele Textseiten senden, wie er will, denn der Textmodus ist ein interaktiver Modus: Der Master verbindet sich mit dem Slave, er ist dann in einer “Sitzung” mit dem Sensor. Mittels der Tasten ESCape, Up, Down und RETurn, am Sender oder der SmartBox, kann mit dem Sensor kommuniziert werden, der reagiert nach seiner Fasson im Display 8×21. Die Sitzung muss explizit verlassen werden (ESC), um sich evtl. mit einem anderen Sensor im Textmodus oder mit demselben oder einem anderen Sensor im Binärmodus (grafisch) zu verbinden, sprich, um erstmal in das übergeordnete Menü des Senders oder einer SmartBox zu gelangen.
Binärmodus (grafischer Modus)
Hier gibt es keine “Sitzung”, man “verbindet” sich nicht. Der HoTT-Sender oder HoTT-Modul fragt reihum alle Sensoren im Binärmodus ab, die in seinem Menü dafür freigeschaltet wurden, und sammelt deren Daten. Man wählt dann EIN grafisches Display zur Anzeige aus, derzeitig GAM/GEM oder EAM oder GPS oder VARIO, ab HoTT v4 kann das Display am Sender on-the-fly gewechselt werden. (Eine an einen HoTT-Sender als “externer Monitor” angeschlossene SmartBox hat den Charme, dass man auf ihr das angewählte grafische Display sieht, während man sich mit dem Display des Senders in dessen Menü tummeln kann. Der externe Monitor ist aber funktionslos im Textmode.)
Die grafischen Displays sind in ihrem Aufbau fix durch die Firmware bestimmt, also durch die Software des HoTT-Senders oder der SmartBox, so Gott will, auch immer einheitlich nach Aufbau (Elementen), dargestellten Maßeinheiten und Sprache.
Ausgewählte Elemente eines grafischen Displays können zu Alarmzwecken invertiert werden. Die Datenklassen und ihre Wertebereiche sind fix, ein 3rd party Sensor wie JLog muss also evtl. Display-Elemente für Werte “vergewaltigen”, die eigentlich im Display nicht vorgesehen sind. JLog tut das im Augenblick mit dem Display für GAM. Da muss leider getan werden, solange es kein spezifisches grafisches Display für einen solchen Sensor gibt.
Alarme
Wie gesagt, Alarme löst der Sensor mit seinem Datenblock aus, identisch im Text- und im Binärmodus. (Wie dargestellt, ob Text- oder Binärmodus, bestimmt der Master mit seinen Abfragen auf dem HoTT-Sensorbus, ist also eine Frage der momentanen Einstellung/Bedienung durch den Anwender.) Nun kann der Empfänger der Alarme damit etwas machen. - Der HoTT-Empfänger nimmt hier eine Spezialrolle ein: Er ist zwar stets der Busmaster, was er aber auf dem Bus abfragt, bestimmt der Sender. Der Empfänger ist der Stellvertreter des Senders auf dem HoTT-Bus. Die SmartBox als Master hingegen bestimmt das selbst, sie hat Menüs dafür, ob man im Text- oder Binärmodus fragt und nach welchem Sensor.
Es spielt für die Alarmgebung keine Rolle, ob man sich mit dem Sender in einer Binäranzeige befindet und welche grafische Seite (von welchem Sensor) man gerade anzeigen lässt, oder ob man sich gerade im Textmodus und dabei mit welchem Sensor befindet. Lediglich: Diese Popup-Alarmdisplays im HoTT-Sender kommen nur, solange man sich in (irgend)einer grafischen Telemetrieseite befindet.
Alarme grafisch: Der Sensor bestimmt mit den von ihm zurückgegebenen Daten, welches Element in einem grafischen Display invertiert wird bzw. er invertiert Zeichen in einem Textdisplay. JLog macht beides. Das ist alles mit einer SmartBox an einem HoTT-Modul und im direkten Anschluss an einen Sensor. Ein HoTT-Sender tut hier noch mehr, ein von Einigen ungeliebtes Feature: Der Sender kennt grafische Subdisplays, er schaltet auf ein passendes um, wenn ein Alarm vorliegt, schaltet wieder zurück zum grafischen Basisdisplay, wenn der Alarm verschwindet. Der Sensor hat es zunächst in der Hand durch die Verweildauer von ihm gesendeter Alarmcodes, wie lange und wie oft so ein Umschalten im Alarmzustand geschieht.
Alarme akustisch: Die SmartBox bzw. der HoTT-Modul (auch ein HoTT-Sender) hat einen Piezo Buzzer, um mit einer Tonfolge (unterschiedliche Töne (Frequenzen) möglich) zu signalisieren.
Ein HoTT-Sender hat auch einen Sprachmodul in dessen Software, zeitgleich zur grafischen Signalisierung und dem Gepiepe über den Piezo Buzzer werden sprachliche Alarme ausgegeben, an der 3,5mm-Audio-Klinkenbuchse an der Senderrückseite. (Man kann hier ohne extra Verstärker einen kleinen Lautsprecher anschließen, solche kleinen Lautsprecher für Mobilfunk, z.B.) – Der Piezo Buzzer schaltet sich ab, wenn sich ein Stecker in der Klinkenbuchse befindet.
Außerdem kann man hier die ständige Ansage eines ausgewählten Wertes machen lassen, die Wiederholzeit dieser Ansage konfigurieren, einen Schalter definieren, der diese Ansagen ein/aus-schaltet, einen weiteren Schalter (nicht rastend), mit dem man durch die Werte schaltet, die zur fortlaufenden Ansage ausgewählt wurden, also reihum. – Achtung! Hier werden wirklich Werte mit Maßeinheit gesprochen, während jeder Alarm eine fixe Ansage ist, ohne Werte. Diese Werte updaten sich durch den Empfang von Binärdaten der Sensoren. Binärdaten (für grafische Displays) werden aber nicht abgefragt, wenn man sich mit dem Sender im Textmodus befindet, der jeweilige Wert steht, ohne ein Update zu erfahren! Ansagen erfolgen auch im Textmodus, wobei hier so eine fortlaufende Ansage aus eben genanntem Grunde keinen Sinn macht, die gesprochenen Alarme aber schon. Werte ständiger Ansagen werden upgedatet, sobald man den Textmodus verlässt.
Leider hat der Sprachmodul noch eine hinderliche Eigenschaft: Es gibt kein Queueing zur Sprachausgabe einlaufender Alarme, es gibt keine Priorität für Alarmansagen über fortlaufende Ansage. Die Alarme EINES Sensor sind synchron zueinander (aus einer Hand), so ein Multisensor, wie JLog, z.B., kann durch ein geeignetes Timing seiner Alarmausgaben dafür sorgen, dass ALLE seine aktiven Alarme zur Sprachausgabe kommen. Asynchron dazu sind aber zu sprechende Ereignisse von der fortlaufenden Ansage aus dem Sender und vor allem auch von anderen Sensoren. Es kann hier dazu kommen, dass deren Alarme über einen (evtl. längeren) Zeitraum im Eingang des Sprachmoduls kollidieren und sich somit gegenseitig an der Sprachausführung hindern. – Die Wiederholzeit einer fortlaufenden Ansage sollte daher nicht kleiner als 10 Sekunden gewählt werden! JLog wiederholt Alarme alle 6 Sekunden, damit ist gewährleistet, dass Alarme Priorität gegenüber der fortlaufenden Ansage haben. Kommt ein weiterer Sensor hinzu, dann ist evtl. alles zu spät, wenn nun 3 Einheiten asynchron zueinander versuchen, ihre Sprachausgabewünsche gleichzeitig loszuwerden. – Auch das Gequietsche für eine Variofunktion ist eine “Sprachausgabe” in diesem Sinne. Heftig einlaufende Alarme werden die akustische Varioausgabe u.U. empfindlich stören.
Man muss aber dazu sagen: Meine Feststellungen basieren auf Worst-Case-Tests unter Bedingungen, wie sie in der Praxis so gut wie nie auftreten werden.
SmartBox direkt an einem Sensor und Binärmodus
Eine Binärseite (graf. Display) wird hier in der SmartBox nicht aktualisiert, das hat einen einfachen Grund: Die Implementierung des Binärmodus in der SmartBox ist auf den Anschluss an einen HoTT-Modul zugeschnitten. Der Modul empfängt via den Empfänger binäre Daten von Sensoren, die an den Telemetriebus des Empfängers angeschlossen sind. Der Empfänger übermittelt außerdem seine eigenen Sensordaten. Ein Datum davon erscheint in jedem Binärdisplay: “Empfangsqualität”. – Die SmartBox ist der Master, der den Slave “HoTT-Modul” nach Text- oder Binärseiten eines Sensors fragt. Der HoTT-Modul antwortet im Binärmodus mit einem Header von Bytes, in denen Sensordaten des Empfängers übermittelt werden, dann erst gefolgt von den Daten des angefragten Sensors. – Die SmartBox erwartet das so und funktioniert so im Binärmodus. Daher kann sie im Binärmodus nicht funktionieren, wenn sie diese Daten von einem direkt angeschlossenen Sensor bekommt. – Die Firmware von JLog für HoTT v4 wird für einen speziellen Anwendungsfall, nämlich die SmartBox als Display mit der JLog-eigenen Telemetrie “JTX”, einen HoTT-Modul emulieren. Somit kann mit “JTX” wahlweise auch grafisch angezeigt werden. (Die Firmwares JLog2/HoTTv4 sind fertig, werden aber erst mit Erscheinen von HoTT v4 released.)
Hinweis zur Variofunktion Die Variofunktion beruht ja auf der Tendenz im barometrischen Druckverlauf. Es gibt 4 Graupner Sensoren, die über einen dazu erforderlichen Drucksensor verfügen, VARIO, GPS, EAM und GAM! Ich brauche also keinen VARIO Sensor, um die Variofunktion zu haben, wenn ich bereits einen der drei anderen Sensoren habe. (Nach meinem Eindruck “rauscht” der Drucksensor im EAM etwas mehr als der im VARIO oder GPS, was aber für die Variofunktion nicht wirklich etwas heißen muss. Den im GAM habe ich nicht getestet. Die Kleindrucksensoren (barometrisch) sind aber in allen HoTT-Sensoren identisch.)
Das grafische Vario-Hauptdisplay (Binärmodus) wird nur vom Sensor VARIO bedient, wohl aber das Sub-Display Höhe//ms/s durch die anderen Sensoren mit Drucksensor, wenn man den betreffenden Sensor, sein grafisches Haupt-Display, zuvor angewählt hatte.
(Ich habe hier witzigerweise einen GAM 33611 ohne Drucksensor, da wird sich wohl die Platine eines GEM 33610 in das Gehäuse des GAM verirrt haben. )
Anzeige HF Status Diese Anzeige im Sender bzw. im PC-Programm “Radio_grStudio” hat einen verwirrenden Fehler. Nicht nur, dass die dBm-Werte eigentlich negativ sein müssten, auch die Balkenanzeige läuft verkehrt herum, kleiner Balken == große Feldstärke.
Ausblick
Kurzfristig nach Release des HoTT v4 wird es neue grafische Displays geben. Das v4 Protokoll umfasst bereits jeweils zusätzliche Datenwerte in den Binärseiten, die dann mit den neuen Displays auch zur Anzeige kommen können. Sensoren, auch 3rd party Sensoren wie JLog, müssen dann in ihrer Firmware nachlegen, indem sie diese Datenfelder auch besetzen, wo sie bei Start von v4 erstmal nur eh nicht angezeigte Dummywerte senden.
Es gibt teilweise Gemoser… Die Sensoren seien so groß, die Datenzusammenstellung in manchen Anwendungsfällen ungünstig, kein einzelner, kleiner 6S-Einzellzellenspannungssensor etc. pp….. Ein kompakter Sensor ist in der Design-Phase, sehr viel kleiner/leichter, dabei kann er auch noch sehr viel mehr. Die logistischen Weichen sind aber noch nicht gestellt. Alles, was das momentan aussagen kann, ist: Man ist nicht taub. — Es wird dann auch eine Reihe neuer peripherer Sensoren geben, die Strommessung wird auch eleganter. Ein Muster des Füllstandsmessers wurde testimplementiert. “Füllstand” ist eigentlich nicht richtig, so etwas geht nicht beim 3D-Fliegen, so eine 4-stufige Anwesenheitsanzeige wie von HiTec kann nicht die Lösung sein. Das Prinzip ist Durchflußmengenmessung, und es funktioniert bereits auf den Milliliter genau, wobei beide Fließrichtungen unterschieden werden. Der Sensor wird auf den ausgeliterten Tankinhalt und die Dichte/Viskosität der Flüssigkeit einmalig durch den Anwender kalibriert, somit ist jede Art “Sprit” möglich. – Die Neuerungsrate ist hoch, wer mault da über Softwareupdates?
Jede der o.g. HoTT-Instanzen enthält einen Microcontroller (MCU). Eine MCU hat 3 Arten Speicher, Flash-ROM, RAM und EEPROM. Der Flash-ROM enthält das Programm. Bei einem Update (Flashen) wird der applikative Teil des Flash-ROM komplett überschrieben, u.U. auch Teile des EEPROM, hier kommen zusätzliche Daten rein, meist bzgl. des Setup.
Eine MCU teilt ihren Flash-ROM i.Allg. in zwei Teile, einen kleineren für eine eigenständige Software, den Bootloader, den größeren für die Anwendung, das, was wir beim Update flashen wollen. Beim Flashen redet ein PC-Programm via USB und den USB-Seriell-Umsetzer (TTL-Pegel , nicht den PC direkt anhängen wollen!) mit dem Bootloader, schiebt dem die Update-Datei byteweise zu, der wiederum dekodiert es und schafft es in den Flash-ROM. – Nun muss man den Controller dazu bringen, erstmal in sein anderes Programm, in den Bootloader zu gehen, damit man mit ihm reden kann. Das geschieht durch ein RESET. Der USB-Umsetzer hat keine extra Leitung, um dieses RESET an die MCU zu geben, denn das Kabel hat nur 3 Pole, (+), (-) und Signal (seriell), es wird ja der Telemetrieanschluss des Devices hier sinnvollerweise mitbenutzt. Das ist der Grund, weshalb man das RESET als Power-On-RESET geben muss durch Anlegen der Betriebsspannung an die zu flashende Einheit, um im rechten Augenblick, während die PC-Software versucht, mit dem Bootloader in’s Gespräch zu kommen, den Bootloader zu starten. (Spricht niemand zum Bootloader, wechselt der i.Allg. nach weniger als einer Sekunde zur Applikation, startet die eigentliche Software der Einheit, – und die kann nicht mit dem Flash-Programm reden.) – Besonderheit ist der Empfänger, der einen Taster hat, den man zusätzlich zum Power-On-Reset halten muss. Hierbei wünscht man sich eine dritte Hand. – Für die Updaterei nimmt man das Programm “Firmware_Upgrade_grStudio_Ver-n.n.exe”, und nur dieses, damit kann auch die Voice-Datei eines HoTT-Senders aktualisiert werden. Hier gleich mal den vorsorglichen Hinweis: Für HoTT v4 wird es eine neue Version dieses Programms geben, mit der Vorversion lässt sich nicht alles von v4 flashen.
24.12.2011: HoTT v4, finale Version, ist online, für ALLES, nur bei den ROM-Upgrades, mc19, mc22, dauert es noch einen Augenblick, diese sprechen solange ein v4 preliminary release, das ist aber kein prinzipielles Hindernis für die Teilnahme am “HoTT v4 Verkehr”. – Die mc32 muss auch upgedatet werden, sie kam ja mit einem Zwischenstand der v4 zur Welt!
Es findet sich alles im Download bei Graupner, v3 und v4 für alle Sender ungleich mc32, ausschließlich v4 bei der mc32. Die jeweiligen Firmware-/Software-Pakete einer Version sind identisch und immer für ALLE Komponenten, egal, unter welchem Sender man sie findet. Ein Downgrade, v4 zu v3, ist jederzeit möglich.
“Final”: Eine Software ist niemals final. Eine statische Software kann einfach nur das Zeichen für eine eingeschlafene Produktpflege sein. In einem der nächsten Releases von v4 werden z.B. die oben erwähnten neuen grafischen Displays kommen, aufgebohrt.
Noch mal, was ist v4 inhaltlich? Die Datenrahmen bzw. -pakete haben sich geändert, sowohl im Textmodus als auch im grafischen (Binärmodus). Im Textmodus werden die Sensoren jetzt genauso einzeln und direkt adressiert wie im Binärmodus. Infolgedessen kann man nun am Sender direkt, quasi per Hotkey, einen Sensor selektieren, grafisch UND Text (Terminal). — Die binären Datenpakete für die einzelnen Sensoren, GEM/GAM, EAM, GPS, VARIO, können nun zusätzliche, weitere Daten enthalten, was sich mit einem der nächsten Updates in verbesserten (aufgebohrten) grafischen Displays äußern wird. — HoTT v3 und v4 sind inkompatibel, verstehen sich nicht am applikativen Ende der Übertragungsstrecke. Es gibt aber im Textmodus ein Device “etc” (im Sender, in der SmartBox “old sensor”), mit dem man Sensoren mit alter Firmware (v3) auch erreichen kann, also immer nur einen Sensor, ausschließlich, so, wie mit v3 vorher. Das geht aber nur im Textmodus. Im grafischen Mode versteht ein Sender mit v4 bzw. eine v4-SmartBox an einem Tx-Modul einfach nur Bahnhof, wenn ein v3-Sensor zu ihm spricht. Auch die Empfänger wechselten ihre Weltanschauung von v3 auf v4, und natürlich auch die Tx-Moduln für umgerüstete bzw. HF-modulare Sender.
HoTT v4 macht vor allem Eines: Es implementiert konsequent ein Protokoll, was den uneingeschränkten Parallelbetrieb aller Sensortypen ermöglicht, also je Typ einen. Die Sensoren werden einfach parallel auf den Telemetriebus gesteckt, per Y-Kabel, z.B.
Was man noch am Sender als “neu” vermerkt: Habe ich eine fortlaufende Ansage rennen und gehe mit dem Sender in den Textmodus (Terminalsitzung mit einem Sensor), dann werden nur noch Werte gesprochen, die vom Sender kommen, da andere Daten ja kein Update erfahren, während man sich nicht im Binärmodus für grafische Anzeigen befindet. Alarmansagen kommen aber immer, in jeder Menü-Lebenslage des Senders. - Ein bisschen zu verbessern gibt es immer: Dabei (s.o.) wird nicht der Varioton abgeschaltet, obwohl dessen Daten ja auch “von ferne” im Binärmode kommen. Aber dafür hat man ja den Schalter, den man ohnehin definieren muss. Verlässt man den Textmodus und geht mit SET gleich wieder hinein, kann es passieren, dass der selektierte Sensor umspringt, man muss ihn erneut am linken Keypad auswählen. – Das ist ja eine der bemerkbaren Veränderungen mit v4, man kann, während man im Textmodus ist, mit dem linken Keypad den Sensor genauso on-the-fly auswählen, wie das im grafischen Modus (binär) geht.
JLog2 als GAM hat noch eine Änderung erfahren, anstatt bisher “m/s” wird nun “m/3s” für das Anzeigen von “Gas” im Binärmodus verwendet werden, weil man sonst die Variofunktion stören könnte. Die JLog-Firmwares für die finale HoTT v4 sind online.
. . .
OT hier: Satelliten-Rx für HoTT? Wozu? Die Satelliten von Spektrum machen Rx Diversity, weil jeder Rx nur eine Antenne hat. Die HoTT-Rx haben Antenna Diversity, im Endeffekt dasselbe. – Sollte es dabei um ein “1-Draht-Signal” gehen: Ein digitales Rx-Ausgangssignal gibt es bei HoTT (noch) nicht, nur “SuSi”, also PPM.
.
Irgendwie kam das allenthalben noch nicht so richtig an:
Wenn der Voll-HoTT-Sender auf v4 läuft, muss es auch der Rest tun, also Rx und Sensoren, auch die “3rd-Party-Sensoren”, wie JLog2 und SM Unilog2 und GPS-Logger! Die Standard-HoTT-v4-Firmware für JLog ist hier. Ich glaube, für den SM Unilog2 und den GPS-Logger gibt es noch keine v4. Läuft der Sender+Empfänger auf v4 und der Sensor nicht, hat das folgende Auswirkungen:
- Der Sensor kann im Textmodus nur als “etc” (old sensor) erreicht werden. Es darf nur einen v3-Sensor zur gleichen Zeit am Bus geben, weil alle v3-Sensoren auf dieselbe Adresse hören.
- Das grafische Display (Binärmodus) eines v3-Sensors kann ein v4-Sender nicht verstehen, allerdings ein Tx-Modul in einem umgerüsteten/modularen Sender (+SmartBox). Die Sensoren dürfen sich aber trotzdem parallel auf dem Bus befinden.
.
Hardware mäßig ist die MX 16 identisch zur MX 20.
Nö. Die mx20 ist eher eine zu heiß gewaschene mc32.
.
Noch mal, HF Status Anzeige: Der obere Teil (“S-dBm”) zeigt, wie der Sender den Empfänger sieht, darunter (“R-dBm”) andersherum, wie der Empfänger den Sender sieht. Das unten kommt also per Telemetrie vom Empfänger. Es handelt sich um die Empfangseingangsleistung, was da angezeigt wird. Die Balken laufen falsch herum, kleine Balken für große Feldstärke.
Die Empfangseingangsleistung wird in dBm angezeigt, -dBm, wir hantieren hier ja nicht mit dem Großsender Nauen. Null dBm entspricht 1mW, daher wird “dBm” hier auch manchmal als “dBmW” bezeichnet, -20dBm sind 10µW, -40 100nW, -73dBm, 50,12pW (50,2µV an 50Ω), sind “S9″ auf dem S-Meter eines Kurzwellentransceivers, oberhalb “S9″ kommt der “Möbelwagen” (-93dBm in Bändern oberhalb, ab VHF). – Die Maßeinheit im grafischen Telemetriedisplay des Rx wurde mit HoTT v4 korrigiert, von “dBm” auf “-dBm”.
Dass “S-dBm” stets etwas höher angezeigt werden als “R-dBm”, schiebe ich auf die vermutliche Tatsache, dass es sich hier nur um eine “relative HF-Anwesenheitsanzeige” handelt, – Softwarebug nicht ausgeschlossen, zumal ja der Programmierer schon mal was bzgl. der Balkenanzeige, “-dBm”, in den falschen Hals bekommen hatte. Allerdings könnte eine verquer in die Anzeige einbezogene AGC (Automatic Gain Control) ähnliches bewirken. Irgendwo in den Untiefen des Sender-Manuals wird gesagt, der Empfänger hätte im Rückkanal eine wesentlich geringere Ausgangsleistung als der Sender. Der Transceiver-Chip ist ein CC2500, das HF-Front-End ein CC2591. Das Front-End hat einen 11dB LNA (rauscharmer Vorverstärker im Empfangszweig, ca. 4,8dB Empfindlichkeitsgewinn unter Einbeziehung der Verluste in T/R-Switch und Anpassung) und kann bis zu 22dBm Output (160mW). (Davor sitzt ein µPG2214TK, vermutlich ein PIN-Dioden-Schalter, der die Antenna Diversity macht. Sein Insertion Loss von typ. 0,35dB drückt noch etwas die Empfindlichkeit und den Output.) Angesichts des Strombedarfs des Empfängers von 70mA wird sein HF-Output nicht mehr als 14dBm, 25mW, betragen (einstellbar am CC2591). OK, das wäre dann ein Viertel der Ausgangsleistung des Senders, im Endeffekt eine S-Stufe (6dB) weniger als Tx->Rx, nichts Weltbewegendes. – Wäre noch der Antennengewinn einzubeziehen, Lambda/4 Strahler am Empfänger (aber zwei umschaltbare Polarisationsebenen), Lambda/2 am Sender?
— Es wird dann auch eine Reihe neuer peripherer Sensoren geben, die Strommessung wird auch eleganter. Ein Muster des Füllstandsmessers wurde testimplementiert. “Füllstand” ist eigentlich nicht richtig, so etwas geht nicht beim 3D-Fliegen, so eine 4-stufige Anwesenheitsanzeige wie von HiTec kann nicht die Lösung sein. Das Prinzip ist Durchflußmengenmessung, und es funktioniert bereits auf den Milliliter genau, wobei beide Fließrichtungen unterschieden werden. Der Sensor wird auf den ausgeliterten Tankinhalt und die Dichte/Viskosität der Flüssigkeit einmalig durch den Anwender kalibriert, somit ist jede Art “Sprit” möglich. – Die Neuerungsrate ist hoch, wer mault da über Softwareupdates? 