FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Naja, ich fliege schon recht lange Frsky und habe alle Flash-Arien miterlebt.
Ich habe allerdings immer FCC bevorzugt. LBT war mir bei Frsky immer suspekt.
Produktentwicklung beim Kunden. Ich muß das nicht mehr haben und die S-Empfäger
funktionieren bis heute nicht zuverlässig.
Ich kann mich täuschen, aber Frsky und problemlos, das muß sich jetzt erst mal in der
Praxis zeigen. Bisher ein riesen Chaos...
Ich habe beide Systeme und kann im Laufe des Jahres vergleichen. Das Bessere werde ich dann
einsetzten. Und auf Tests die im Zimmer vor dem WLanrouter stattfinden mit alten Firmwareständen, gebe ich gar nichts, sind für mich nicht aussagekräftig.
Das System muß im E-Impellerjet, im Jet, im Benzinmodell, im Copter gleichermaßen gut funktionieren und das hat Frsky noch nicht bewiesen. In einem Jahr wissen wir mehr.
Raimund
Ich habe allerdings immer FCC bevorzugt. LBT war mir bei Frsky immer suspekt.
Produktentwicklung beim Kunden. Ich muß das nicht mehr haben und die S-Empfäger
funktionieren bis heute nicht zuverlässig.
Ich kann mich täuschen, aber Frsky und problemlos, das muß sich jetzt erst mal in der
Praxis zeigen. Bisher ein riesen Chaos...
Ich habe beide Systeme und kann im Laufe des Jahres vergleichen. Das Bessere werde ich dann
einsetzten. Und auf Tests die im Zimmer vor dem WLanrouter stattfinden mit alten Firmwareständen, gebe ich gar nichts, sind für mich nicht aussagekräftig.
Das System muß im E-Impellerjet, im Jet, im Benzinmodell, im Copter gleichermaßen gut funktionieren und das hat Frsky noch nicht bewiesen. In einem Jahr wissen wir mehr.
Raimund
Hier die Logfiles:
Zuerst nochmal mit dem X8R:
Mit dem G-RX8:
Bei beiden Tests befanden sich TX und RX an der gleichen Position.
Die RSSI Werte sind jetzt besser.
Die LQ Werte irritieren mich etwas, nur ein kurzer Einbruch ???
Könnte es sein das die FS Werte im G-RX8 geschönt werden und im X8R nicht ?
Der LQ Sensor ist aber in Ordnung. Hier die LQ Werte im RWT Modus:
Zuerst nochmal mit dem X8R:
Mit dem G-RX8:
Bei beiden Tests befanden sich TX und RX an der gleichen Position.
Die RSSI Werte sind jetzt besser.
Die LQ Werte irritieren mich etwas, nur ein kurzer Einbruch ???
Könnte es sein das die FS Werte im G-RX8 geschönt werden und im X8R nicht ?
Der LQ Sensor ist aber in Ordnung. Hier die LQ Werte im RWT Modus:
Die 191115 Firmware beim G-RX8 fälscht unverschämt, damit ging es los. Die V2 Firmware fälscht etwas weniger, aber immer noch frech 
Vor der 191115 war die Firmware ehrlich. Wenn du den "echten" G-RX8 sehen willst, dann ist die 181025 die richtige.
Oder mach dir die LQBB4 auf den Sensor, der zeigt dir dann sowohl die "gefälschte" LQ vom SBus als auch die ehrliche LQ mit der BB-Methode an.
Vor der 191115 war die Firmware ehrlich. Wenn du den "echten" G-RX8 sehen willst, dann ist die 181025 die richtige.
Oder mach dir die LQBB4 auf den Sensor, der zeigt dir dann sowohl die "gefälschte" LQ vom SBus als auch die ehrliche LQ mit der BB-Methode an.
Interessante Entwicklung: Bei ACCESS soll es wieder eine ehrliche Lost Frame Anzeige geben. Vermutlich kriegen sie mit ACCESS das Problem der Frameverluste in den Griff. Angeblich soll ja die nächste ACCESS Firmware individuell nachtunen.
Währenddessen versuchen noch über 3000 Forenmitglieder in Deutschland den Ewaldschen SBus Filter zu verstehen. Dass gar keiner nachfragt, ist schon faszinierend
Währenddessen versuchen noch über 3000 Forenmitglieder in Deutschland den Ewaldschen SBus Filter zu verstehen. Dass gar keiner nachfragt, ist schon faszinierend
Der "Filter" ist Quatsch und logischerweise ist auch jede Erklärung dazu Quatsch. FrSky schönt die Lost Frames, das ist alles. Der Sinn des Lost Frame Bit im SBus ist, darauf hinzuweisen, dass das aktuelle Frame ungültig ist und die Werte im SBus eine Wiederholung der letzten SBus- bzw. Kanalausgabe darstellen.
Du warst ja schon auf der richtigen Spur, als du nach der Latenz gefragt hast. Schau dir einen einzelnen Kanal an, dann wird es klarer. Nimm an. Kanal 7 ist an der Reihe, egal ob im 8 oder 16 Kanal Modus. Das Over The Air Frame ist ungültig, also kann nur der der letzte gültige SBus Inhalt und der letzte Kanalwert wiederholt werden und das Lost Frame Flag muss gesetzt werden.
Jetzt erklär du bitte die Ewald/FrSky Vorgehensweise, ich bin gespannt.
Du warst ja schon auf der richtigen Spur, als du nach der Latenz gefragt hast. Schau dir einen einzelnen Kanal an, dann wird es klarer. Nimm an. Kanal 7 ist an der Reihe, egal ob im 8 oder 16 Kanal Modus. Das Over The Air Frame ist ungültig, also kann nur der der letzte gültige SBus Inhalt und der letzte Kanalwert wiederholt werden und das Lost Frame Flag muss gesetzt werden.
Jetzt erklär du bitte die Ewald/FrSky Vorgehensweise, ich bin gespannt.
Klar, das wird so erzählt, aber das ist Quatsch. Die Auswertung von 4 Frames würde eine zusätzliche Latenz von 36ms bedeuten, das ist mehr als die Gesamtlatenz der Übertragung bei 8 Kanälen. Denk dir doch den Vorgang anhand eines einzigen Kanals durch. Wann sollte es Sinn machen, etwas anderes als den letzten gültigen Wert zu übertragen? Wenn der aktuelle OTA Frame ungültig ist, muss das Lost Frame Flag gesetzt werden und die letzten gültigen Kanalwerte werden weiter im SBus und an den PWM Anschlüssen ausgegeben - das ist alles und alles andere macht wirklich null Sinn.
Weitere gute Nachricht von MB zur V2.1 Firmware, FrSky hat offenbar die Verschlüsselung der Datenpakete zurückgenommen => RC Groups - View Single Post - Important Firmware Update ACCST D16 2.0.0 - ACCESS also affected
Das hatte ich bislang eigentlich auch so verstanden und ist als solches sicher eine Verbesserung der Übertragungssicherheit. Ich war zugegebenermassen auch etwas überrascht mit dem, was MB gepostet hat, kann es aber selber nicht verifizieren. Dennoch habe ich es dann zur Info hier einfach gepostet
=> I've looked at the V2.1 test version firmware and the "encryption" that had been added to normal packets has now been removed
Dann wäre doch die einfache Frage an MB, ob er hier das Data Whitening meint, denn doch nur das sollte doch bei den normalen Datenpaketen zur Anwendung kommen. Oder sehe ich das verkehrt? Würde dann aber auch bedeuten, dass das nicht mehr gemacht wird, was ich wiederum nicht glauben mag.
Edit: Entsprechende Frage an MB auf RCG gestellt.
=> I've looked at the V2.1 test version firmware and the "encryption" that had been added to normal packets has now been removed
Dann wäre doch die einfache Frage an MB, ob er hier das Data Whitening meint, denn doch nur das sollte doch bei den normalen Datenpaketen zur Anwendung kommen. Oder sehe ich das verkehrt? Würde dann aber auch bedeuten, dass das nicht mehr gemacht wird, was ich wiederum nicht glauben mag.
Edit: Entsprechende Frage an MB auf RCG gestellt.
Zuletzt bearbeitet:
