PS: Dies ist ein Dokument, das ich laufend aktualisiere, sobald ich neue Erkenntnisse und Informationen gewinne. Wie immer gilt: Nichts davon ist in Stein gemeißelt – nur ein alter Mann, der mit sich selbst redet.
Alle Informationen unten sind meine Vermutungen, wie das System funktionieren könnte und was die beobachteten Effekte erklärt.
Und ja – mein kleiner Helfer schreibt viele dieser Wörter. Ich selbst hätte keine Lust, so viele Wörter zu tippen. Zu viel Schreiberei, schadet meiner Tastatur 😉
Q-Wert Telemetrie-Lücken-Analyse
Fluglog: ASK21 (20250913/15-00-46.log)
Timeout-Ereignisse: 5 Ereignisse analysiert
Gesamtpakete: 42.442 über 43,3 Minuten
Was Jeti behauptet
Offizielle Dokumentation (deren Wortlaut):
„Signalqualität Q zeigt die Erfolgsrate der bidirektionalen Kommunikation zwischen Sender und Empfänger in Prozent an.“
(Meine Anmerkung: Das ist also der Prozentsatz der gültigen Datenpakete, die der Empfänger sieht. Ein Modell bleibt noch mit 20 % Paketen steuerbar – es reagiert nur träger.)
Marketingunterlagen behaupten:
– Q misst nur den Telemetrie-Rückkanal (RX → TX)
– Das Modell bleibt auch bei Q = 0 % steuerbar (100 mW ERP im Sender vs 10 mW ERP im Empfänger – wahrscheinlich hören wir den Empfänger früher nicht mehr als umgekehrt.)
– Nur die Telemetrie ist während Timeouts betroffen
Problem: Diese Aussagen widersprechen sich. Es kann nicht bidirektional sein und gleichzeitig nur RX → TX betreffen.
Systemarchitektur in der Praxis
Physischer Aufbau:
TX ↔ Rx1 (bidirektional, unabhängig)
TX ↔ Rx2 (bidirektional, unabhängig)
Rx1 ↔ Central Box (EX-Bus – bidirektional!)
Rx2 ↔ Central Box (EX-Bus – bidirektional!)
CB ↔ weitere Sensoren (gleicher Bus)
Wichtige Punkte:
– Central Box ist ein weiterer Sensor auf dem Telemetrie-Bus (vermutlich mit höherer Priorität)
– Jeder Empfänger hat einen eigenen Q-Wert
– Empfänger senden alle Daten (Kanäle + Telemetrie) über EX-Bus an die CBox
– Die CBox entscheidet, welche Telemetrie zurückgesendet wird
– EX-Bus ist bidirektional
– CB erzeugt die Timeout-Alarme, nicht die Empfänger
– Einzelne Empfänger (ohne CB) melden keine Timeouts
Mehrstufige Überwachung
Das System überwacht auf mehreren Ebenen:
- Central Box überwacht die lokalen Busverbindungen und erzeugt Timeout-Alarme
- Der Sender (TX) hat eigene Alarmoptionen – meldet, wenn Empfänger verloren gehen
- Fallen beide Empfänger aus, erkennt das der Sender ebenfalls (selbst ohne CB)
Alarme im Sender können deaktiviert werden, wenn CB-Timeouts ausreichend sind.
Der entscheidende Punkt – Dual-Empfänger-Redundanz
Wenn im Log „Rx1 timeout“ steht:
- CB erkennt Signalabfall bei Rx1
- CB schaltet auf Rx2 (bereits aktiv)
- Kurzzeitiger Umschaltvorgang
- CB erzeugt Timeout-Alarm und sendet über Rx2
- Alarm wird über Rx2 an den TX gesendet
Zum Zeitpunkt des Logs läuft das System bereits auf Rx2!
Was die Daten zeigen
5 Timeout-Ereignisse analysiert, jeweils ±10 s Fenster.
Ergebnis:
Alle 5 zeigen durchgehende Telemetrie während des Timeouts (20–219 ms Intervalle, keine Unterbrechung).
Der Alarm selbst wird empfangen – System läuft bereits auf dem zweiten Empfänger.
13 Telemetrie-Lücken (~500 ms):
– Keine während Timeouts
– Meist 3–9 s vorher/nachher
– Nur eine innerhalb 500 ms vor Timeout (296 ms)
– Bei größerer Distanz (500–800 m)
→ Diese Lücken zeigen das Signal-Abfallen, das die Umschaltung auslöst.
| Ereignis | Zeit | RX | Lücken | Lückenzeiten | Zustand |
|---|---|---|---|---|---|
| 1 | 22:00 | Rx1 | 2 | −1.8 s, +0.8 s | Normal (auf Rx2) |
| 2 | 22:05 | Rx1 | 2 | −7.5 s, −4.9 s | Normal (auf Rx2) |
| 3 | 33:20 | Rx2 | 4 | −4.4 s, −3.3 s, −0.3 s, +1.9 s | Normal (auf Rx1) |
| 4 | 33:25 | Rx2 | 3 | −9.0 s, −6.0 s, −3.8 s | Normal (auf Rx1) |
| 5 | 33:53 | Rx1 | 2 | −7.3 s, −6.1 s | Normal (auf Rx2) |
Bedeutung
Wenn Jetis Aussage richtig wäre (Q misst nur RX → TX):
– Müssten Telemetrie-Lücken zeitgleich mit Timeouts auftreten
– Lücken und Timeouts würden zusammenfallen
Tatsächlich:
– Telemetrie läuft normal, während Timeout geloggt wird
– Lücken treten Sekunden vorher auf
– ~500 ms Lücken sind normales HF-Verhalten
– System meldet Timeout nachträglich
– Umschaltvorgang geschieht vor dem Alarm
Wahrscheinlicher Ablauf
- Rx1-Signal verschlechtert sich (~500 ms-Lücken 3–9 s vorher)
- CB überwacht Q-Werte
- CB entscheidet: Rx1 zu schwach → Umschaltung auf Rx2
- Kurzzeitige Umschaltung
- System läuft auf Rx2
- CB erzeugt „Rx1 Timeout“
- Alarm über Rx2 → TX → Logger
- Timeout im Log, Telemetrie läuft weiter
Offene Fragen
- Wenn Q nur RX → TX misst – warum läuft Telemetrie während Timeouts normal?
Weil der andere Empfänger sendet. - Was löst CB-Timeout aus?
Sinkende Q-Werte → CB schaltet um. - Ist Steuerpfad funktionsfähig?
Ja, in der Praxis läuft die Steuerung weiter (dank Dual-Empfänger). - Stellen ~500 ms-Lücken den Umschaltmoment dar?
Wahrscheinlich zeigen sie die Signalverschlechterung vor dem Wechsel.
Fazit
- Timeouts werden von der CBox erzeugt, nicht vom Empfänger
- Telemetrie läuft weiter (über den anderen RX)
- ~500 ms-Lücken treten vorher auf
- Englische und deutsche Jeti-Texte widersprechen sich
- Dual-Empfänger = nahtlose Umschaltung
Beobachtung
Die ~500 ms-Telemetrie-Lücken wirken harmlos – kurz, konsistent, bei größerer Distanz, mit schneller Erholung.
Sie zeigen normales HF-Verhalten, das zur Umschaltentscheidung führt.
Die Timeout-Ereignisse selbst sind die Meldung der CB: „Ich habe umgeschaltet“ – keine Störung, sondern Information.
Das Dual-Empfänger-System funktioniert wie geplant: Nahtloses Failover mit minimaler Unterbrechung.