Vorsicht bei "Telemetrie verloren" mit Horus

Wir machen vielleicht demnächst einen "Messtag" im Raum Hockenheim, das sind ~70km. Wenn es klappt, melde ich mich.
 

bendh

Erfahrener Benutzer
Da würde ich gerne dabei sein, prima. ich könnte auch noch etwas weiter fahren. Nur die nächsten beiden Samstage gehen nicht. Gern aber auch unter der Woche, da über 63. :)
 

arti

Well-known member
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...
 

GerdS

Erfahrener Benutzer
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 kann nicht mal binden mit meinem alten MPM, ohne vorher zu tunen. Mein Neues liegt ganz passabel. Aber tunen mit MPM und FrSky ist eigentlich Pflicht.
 
Gibt es noch einen Breakdance verdächtigen FrSky Sender im Großraum Rhein Neckar? Am Donnerstag wollen wir messen. Der Sender kann auch an einen Teilnehmer übergeben werden. PM bitte an @quax2011 oder mich.
 
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.
 
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.
 

Bussard

Erfahrener Benutzer
...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)
Hier paßt was nicht: entweder (erste Zeile) +68 bis 10 = 58:2 = 29 oder etwa (+68 bis -10):2= 39, letzere paßt zu erster Zeile unterer Block zum selben G-RX6 = 78 Abstimmbereich
usw.

Gruß
 

FJH

Erfahrener Benutzer
Die passen alle!!

Du machst einen Rechenfehler. 39 ist die Mitte der Spanne zwischen beiden Werten. Die musst du jetzt noch von einem Endwert subtrahieren, also => 68-39=29
 

weixelgeist

Erfahrener Benutzer
Wenn ich jetzt das Tuning mit meiner Jumper T16 und mit einem X8R mache und dabei z.B. ein Mittelwert von 25 heraus kommt.
Was bringt mir das, wenn ich dann diesen Empfänger mit meiner Horus X10S betreibe?
 
RCLogger

FPV1

Banggood

Banggood

Oben