AKmod hat mir Equipment z.V. gestellt, habe somit ab heute Nachmittag was dran gemacht, und siehe, fertsch.
Die Telemetriedisplays des Senders (XG8) können leider (noch) nicht das, was das Protokoll vorsieht.
Protokoll und Prinzip sind.. na ja.., das Übliche Aber klar gegliedert. (Die Menüs im Sender sind sowas von intuitiv bedienbar!)
Somit in der Telemetrie, neben BEC-Spg. in Form der Rx-Spg.: Ubat, Imot, tFET, mAh, Watt, RPM (Motor/Rotor - Untersetzung im Sender einstellbar).
Die wenigen Displays im Sender erlauben leider nicht Ibec, Gas, PWM und JLog-eigene Sensordaten, Letzteres auch mit SPEKTRUM nicht anders. Ich habe keinen Wert mißbraucht!
JLog verwendet die Sensoradressen (jeweils nur 1x auf dem Bus): TEMP, POWER und UPM, mit JLog3 dann auch PRESSURE (für Altitude) und VARIO (echtes Vario).
SPEED werde ich noch nachziehen bei Bedarf in JLog2, in JLog3 dann eh.
Alarme werden nur im Sender gesetzt/erzeugt, mAh werden als Restkapazität angezeigt, Alarm auf einstellbaren Restbetrag (prozentual von Nominalkapazität). Und, ja
, CAPALARMSTOP ist auch wieder dabei in JLog.Es bleibt zu hoffen, dass POWER als Multisensor später im Sender unterstützt wird, und dann auch die anderen Sensoren, die es lt. Protokoll gibt.
JLC muss noch.
Noch mal nachdenken vielleicht auch.
Wer mal ganz eilig testen will, kann hier vorab Firmware haben, für JIVE oder CC.
---------
Die andere Telemetrie, die, über die ich mir mal nicht die Krätze ärgern muss, die ab JLog3, ging auch voran.
Die eigene Funkstrecke erfüllt die Vorschriften der ETSI Bürokraten (EN 300 220-1) hoch&runter, LBT (Listen Before Talk), AFA (Adaptive Frequency Agility), was hier AFH (Adaptive Frequency Hopping) heißt, etc.pp. Alles Software-Kino. Man MUSS das alles machen, einschließlich Hopserei durch das ganze Band, also AFA auch ohne Grund durch LBT, sonst ist die Nutzbarkeit für Telemetrie nach den Zugriffsregeln etwas Essig.
Als alter Funkamateuer bin ich begeistert, wie schnell man so irre mit diesem Kram durch's Band hopsen kann, und das mit LBT. Immerhin geht das alle 40ms: Master (fliegend): Hören, evtl. Nachhören (Kanal wurde frei), evtl. Ausweichspringen und wieder Hören, Senden, Hören (Acknowledge mit Tastencodes vom Boden). Slave (Boden): Hören, sofort Senden (ACK Transmission).
Der Datendurchsatz ist hoch, es ist interaktiv mit der Bodenstation (Tasten, bis zu 7), die Latenz ist gering (45ms). Das alles trotz geringer Bandbreite (bessere Empfindlichkeit) und 50kHz Channel Spacing.
Naja.. wenn die ETSI so weiter macht, kann man alle Vorschriften in einen Satz bringen: Nicht senden.
Insbesondere LBT ist ein Freibrief für Frechheit-Siegt, für den ganzen Chinamüll auf den ISM/SRD-Bändern (und anderswo). Ein breitbandiger Störer nimmt sich ungeschoren mal eben das ganze Band, und die ganzen ETSI-hörigen Devices haben die Klappe zu halten, auszuweichen, bis ganz schnell nichts mehr frei ist im Spektrum. Habe das hier mit einem Afu-Transceiver im Nahfeld getestet, auweia, da wird's ganz schnell dünne mit der Bandnutzbarkeit, wenn mir so eine Drecksau richtig reinleuchtet in die Antenne. -- Abgesehen davon, dass LBT die Latenz hochgehen lässt. Nach dem ganzen unsinnigen Latenzwettbewerb der FS-Hersteller im 2G4-ISM-Band müssen da nun wieder Abstriche gemacht werden. Und wenn einer mein Modell vom Himmel holen will, macht ihm das LBT ganz leicht.
