FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Aufgrund des super Wetters konnte ich nicht mehr still sitzen und musste wieder an die Knüppel.
Dafür habe ich meine Taranis auf D16V2 geflasht und mit OpenTX 2.3.5 ausgestattet. Ein X8R in einem 380er Heli hat dafür dann die passende D16V2 LBT Firmware bekommen. Einen größeren Heli werde ich erstmal nicht riskieren.
Erstmal zum Guten, die Kiste fliegt mit der Kombi. Mit nur 4 Akkus bin ich aber noch weit weg von intensivem Testing. Ich habe extra eine Taranis mit einem X8R genommen, weil diese Kombi ja eigentlich auch vor dem FW Update nicht problematisch schien.
Es gibt aber auch noch Bugs in der jetzigen Firmware bezüglich der Telemetrie. Bei Telemetrieverlust kann es vorkommen dass die Verbindung nicht mehr aufgebaut wird. Zunächst bleiben die Updates der einzelnen Telemetriekanäle (bis auf RSSI und RxBT) aus, dann bekommt man einen "Sensor lost" für jeden einzelnen Sensor. Die Telemetrie liefert bei dem Heli ein Unisens. Schafft man es bei der Flugvorbereitung und im Flug keinen Telemetrieverlust zu provozieren dann werden alle Sensoren weiterhin aktualisiert. Im anderen Fall hört man einen Sensorverlust nach dem anderen. Es ist jetzt nichts was zum Crash führt aber dennoch ein Bug der nervig ist.
Wenn es jetzt nicht angefangen hätte zu regnen würde ich weitere Akkus verheizen. Nach fast 3 Monaten Flugabstinenz kann ich jetzt keinen Regen gebrauchen...
Dafür habe ich meine Taranis auf D16V2 geflasht und mit OpenTX 2.3.5 ausgestattet. Ein X8R in einem 380er Heli hat dafür dann die passende D16V2 LBT Firmware bekommen. Einen größeren Heli werde ich erstmal nicht riskieren.
Erstmal zum Guten, die Kiste fliegt mit der Kombi. Mit nur 4 Akkus bin ich aber noch weit weg von intensivem Testing. Ich habe extra eine Taranis mit einem X8R genommen, weil diese Kombi ja eigentlich auch vor dem FW Update nicht problematisch schien.
Es gibt aber auch noch Bugs in der jetzigen Firmware bezüglich der Telemetrie. Bei Telemetrieverlust kann es vorkommen dass die Verbindung nicht mehr aufgebaut wird. Zunächst bleiben die Updates der einzelnen Telemetriekanäle (bis auf RSSI und RxBT) aus, dann bekommt man einen "Sensor lost" für jeden einzelnen Sensor. Die Telemetrie liefert bei dem Heli ein Unisens. Schafft man es bei der Flugvorbereitung und im Flug keinen Telemetrieverlust zu provozieren dann werden alle Sensoren weiterhin aktualisiert. Im anderen Fall hört man einen Sensorverlust nach dem anderen. Es ist jetzt nichts was zum Crash führt aber dennoch ein Bug der nervig ist.
Wenn es jetzt nicht angefangen hätte zu regnen würde ich weitere Akkus verheizen. Nach fast 3 Monaten Flugabstinenz kann ich jetzt keinen Regen gebrauchen...
Mal eine frage für die Mess-Spezialisten:
Ich habe einen meiner Whoops mit XM+ Empfänger jetzt erst mal an mein Vantac MPM Lite Modul an meinem X-Lite Sender gebunden, da der Rest schon auf 2.0.x geflasht ist und FrSky das Update für den XM+ bekanntlich auch im zweiten Anlauf verbockt hat. So kann ich vorerst beide Protokolle ohne ständiges Umflashen nutzen.
Dabei ist mir heute aufgefallen, dass der XM+ auf Entfernung wesentlich höhere RSSI-Werte meldet als früher, wo er noch an das interne Modul der X-Lite gebunden war und im Nahbereich unter 2m treten deutlich mehr Lockouts auf als früher.
Haben die MPM-Module mehr Ausgangsleistung oder woran könnte das sonst liegen?
Gruß Gerd
Ich habe einen meiner Whoops mit XM+ Empfänger jetzt erst mal an mein Vantac MPM Lite Modul an meinem X-Lite Sender gebunden, da der Rest schon auf 2.0.x geflasht ist und FrSky das Update für den XM+ bekanntlich auch im zweiten Anlauf verbockt hat. So kann ich vorerst beide Protokolle ohne ständiges Umflashen nutzen.
Dabei ist mir heute aufgefallen, dass der XM+ auf Entfernung wesentlich höhere RSSI-Werte meldet als früher, wo er noch an das interne Modul der X-Lite gebunden war und im Nahbereich unter 2m treten deutlich mehr Lockouts auf als früher.
Haben die MPM-Module mehr Ausgangsleistung oder woran könnte das sonst liegen?
Gruß Gerd
Ewald und Udo haben in RCG die Idee des SBus Ringbuffers vorgestellt 
Es scheint, dass sie selbst immer noch daran glauben. Das ist natürlich für FrSky eine ideale Gelegenheit, sich und die Lost Frames hinter den "Experten" zu verstecken. Ich glaube und hoffe, dass FrSky den Quatsch nicht selbst geglaubt hat, das würde mir doch etwas den Boden unter den Füßen wegziehen.
Das Gute ist, dass FrSky ohne großen Gesichtsverlust den Besch!ss wieder zurücknehmen kann.
So allmählich beginnt man jetzt zu verstehen, was FrSky getrieben hat. Auch die Verschlüsselung zum Ausschluss der Konkurrenz ist akzeptiert.
Es scheint, dass sie selbst immer noch daran glauben. Das ist natürlich für FrSky eine ideale Gelegenheit, sich und die Lost Frames hinter den "Experten" zu verstecken. Ich glaube und hoffe, dass FrSky den Quatsch nicht selbst geglaubt hat, das würde mir doch etwas den Boden unter den Füßen wegziehen.Das Gute ist, dass FrSky ohne großen Gesichtsverlust den Besch!ss wieder zurücknehmen kann.
So allmählich beginnt man jetzt zu verstehen, was FrSky getrieben hat. Auch die Verschlüsselung zum Ausschluss der Konkurrenz ist akzeptiert.
Zuletzt bearbeitet:
Die Strategie, um betroffene Sender/Empfänger Kombinationen zu finden:
- mit dem Lost Frame Sensor nach auffälligen Frameverlusten und Lockouts suchen
- mit einem unverdächtigen Sender X9D/E gegenchecken, oder mit einem getuneden MPM
- der Sender kann auch mit einem Spektrum Analyser geprüft werden, ob er den FrSky Standard einhält
- die Empfänger können mit dem MPM auf Toleranz geprüft werden. Dabei kommt es nur auf die Unterschiede zwischen den Empfängern an, nicht auf die absolute Zahl. Einige MPM liegen ebenfalls daneben, was aber unkritisch it, weil es sich abstimmen lässt.
Hier ein reales Beispiel (nicht von mir):
G-RX6 +68 - 10 = 58 : 2 = 29
X8R +94 - 22 = 72 : 2 = 36 <-- vermutlich die exakte Mitte dieses MPM
G-RX8 + 85 - 1 = 84 : 2 = 42
Man sieht auch schön die unterschiedlichen Fangbereiche der Empfänger:
G-RX6 = 78
X8R = 114 (!)
G-RX8 = 86 (ältere Firmware)
Was das aber in der Praxis bedeutet, kann man wieder nur mit dem Lost Frame Sensor herausfinden. Bis FrSky wieder arbeitet, wissen wir mehr. Wäre schön, wenn noch ein paar Leute mit verdächtigem Sender mittesten. Ich weise auch noch mal auf das Script von @fsjunk hin, um geeignete Logdateien zu analysieren.
- mit dem Lost Frame Sensor nach auffälligen Frameverlusten und Lockouts suchen
- mit einem unverdächtigen Sender X9D/E gegenchecken, oder mit einem getuneden MPM
- der Sender kann auch mit einem Spektrum Analyser geprüft werden, ob er den FrSky Standard einhält
- die Empfänger können mit dem MPM auf Toleranz geprüft werden. Dabei kommt es nur auf die Unterschiede zwischen den Empfängern an, nicht auf die absolute Zahl. Einige MPM liegen ebenfalls daneben, was aber unkritisch it, weil es sich abstimmen lässt.
Hier ein reales Beispiel (nicht von mir):
G-RX6 +68 - 10 = 58 : 2 = 29
X8R +94 - 22 = 72 : 2 = 36 <-- vermutlich die exakte Mitte dieses MPM
G-RX8 + 85 - 1 = 84 : 2 = 42
Man sieht auch schön die unterschiedlichen Fangbereiche der Empfänger:
G-RX6 = 78
X8R = 114 (!)
G-RX8 = 86 (ältere Firmware)
Was das aber in der Praxis bedeutet, kann man wieder nur mit dem Lost Frame Sensor herausfinden. Bis FrSky wieder arbeitet, wissen wir mehr. Wäre schön, wenn noch ein paar Leute mit verdächtigem Sender mittesten. Ich weise auch noch mal auf das Script von @fsjunk hin, um geeignete Logdateien zu analysieren.
