Ja richtig, dieser wirklich aussergewöhnliche, aber dokumentierte Fall ist bislang einzig. Dies gilt aber auch für alles, was bisher von Andrew als Testergebnisse kam. Ich glaube schon, dass Andrew sehr sorgfältig ist mit dem, was er da macht. So stellt er natürlich auch u.a. sein Equipment (SEnder/Empfänger) in Frage. Mal schauen, was Andrew auf meine Fragen hin mir antwortet.
FRSKY Das neue FrSky ACCESS Protokoll
- Themenstarter Carbonator
- Beginndatum
Wir alle müssen ein bisschen aufpassen, dass ACCST V2 und ACCESS 2.1 nicht durcheinandergewürfelt werden.
Nachdem ich jetzt endlich OpenTX selbst kompilieren kann, werde ich das ISRM uf 2.1 aktualisieren und in der T16 ein bisschen ACCESS testen. So wie ich es verstanden habe, kann man doch exclusiv mit der externen Antenne fliegen. Was mir wesentlich lieber ist, wie diese Timesharing Sache, die nur Leuten nützt, die nicht wissen, wie man die Antenne ausrichtet und wo ihr Modell gerade fliegt
Edit: Dass die Servos Vollauschlag beim Editieren der Empfängeroptionen machen, sollte man im Auge haben. Scheint beim Flashen mit angeschlossenen Servos auch so zu sein, uffbasse.
Nochnedit: LFR% ist ehrlich, man muss bei ACCESS keinen Sensor mehr dranhängen. Im Nachbarforum testen sie übrigens ACCST V2 mit Tadango-Sensor und sind begeistert, dass kein einziges Frame verlorengeht
Nachdem ich jetzt endlich OpenTX selbst kompilieren kann, werde ich das ISRM uf 2.1 aktualisieren und in der T16 ein bisschen ACCESS testen. So wie ich es verstanden habe, kann man doch exclusiv mit der externen Antenne fliegen. Was mir wesentlich lieber ist, wie diese Timesharing Sache, die nur Leuten nützt, die nicht wissen, wie man die Antenne ausrichtet und wo ihr Modell gerade fliegt
Edit: Dass die Servos Vollauschlag beim Editieren der Empfängeroptionen machen, sollte man im Auge haben. Scheint beim Flashen mit angeschlossenen Servos auch so zu sein, uffbasse.
Nochnedit: LFR% ist ehrlich, man muss bei ACCESS keinen Sensor mehr dranhängen. Im Nachbarforum testen sie übrigens ACCST V2 mit Tadango-Sensor und sind begeistert, dass kein einziges Frame verlorengeht
Zuletzt bearbeitet:
Nochnedit: LFR% ist ehrlich, man muss bei ACCESS keinen Sensor mehr dranhängen. Im Nachbarforum testen sie übrigens ACCST V2 mit Tadango-Sensor und sind begeistert, dass kein einziges Frame verlorengeht
......wenn doch da mal eine Linie drin wäre...
...Seufz..
Nochnedit: LFR% ist ehrlich, man muss bei ACCESS keinen Sensor mehr dranhängen. Im Nachbarforum testen sie übrigens ACCST V2 mit Tadango-Sensor und sind begeistert, dass kein einziges Frame verlorengeht
Bei ACCESS scheint es aber eine klare Verfahrensweise zu geben. Echter (leider reduzierter) RSSI und echter Frameverlust. Damit kann man arbeiten.
Wenn nicht das Gepiense gewesen wäre, dass der RSSI viel zu hoch ist (größer 100, also ganz echt) hätten wir heute auch den gleichen Failsafewert wie bei ACCST. Jetzt wird wegen der niedrigen ACCESS RSSI Werte gepienst
Damit kann man aber leben. Der erste Frame Counter von FrSky wurde iirc alle 90 Sekunden aktualisiert, das ist doch ein Riesen-Fortschritt. Wenn man konkret in die Fehlersuche gehen muss, kann man immer noch etwas Gescheites dranhängen. Aber für Ottonormaluser ist das doch fast schon perfekt. Man sieht eindeutig, wenn sich etwas verschlechtert. Ein gleitender Durchschnitt wäre optisch schöner, aber die reine Information ist vergleichbar. Der gleitende Durchschnitt hat übrigens auch Nachteile, weil fehlende Frames immer auch ein fehlendes Telemetriepaket bedeuten. Der 100 Frames Wert ist redundant, weil er mehrmals gesendet wird, die Tadango Werte sind bei Frameverlusten im ungünstigsten Fall verloren.
Wenn nicht das Gepiense gewesen wäre, dass der RSSI viel zu hoch ist (größer 100, also ganz echt) hätten wir heute auch den gleichen Failsafewert wie bei ACCST. Jetzt wird wegen der niedrigen ACCESS RSSI Werte gepienst
Damit kann man aber leben. Der erste Frame Counter von FrSky wurde iirc alle 90 Sekunden aktualisiert, das ist doch ein Riesen-Fortschritt. Wenn man konkret in die Fehlersuche gehen muss, kann man immer noch etwas Gescheites dranhängen. Aber für Ottonormaluser ist das doch fast schon perfekt. Man sieht eindeutig, wenn sich etwas verschlechtert. Ein gleitender Durchschnitt wäre optisch schöner, aber die reine Information ist vergleichbar. Der gleitende Durchschnitt hat übrigens auch Nachteile, weil fehlende Frames immer auch ein fehlendes Telemetriepaket bedeuten. Der 100 Frames Wert ist redundant, weil er mehrmals gesendet wird, die Tadango Werte sind bei Frameverlusten im ungünstigsten Fall verloren.
Die Linie ist doch glasklar. Bei ACCST ist die Mischkalkulation seit jeher üblich und alle User sind das so gewohnt. Auch der dazu passenden FS-Grenzwert ist mit ca. 35dB allgemein gültig und bekannt. Die neue unvermatschte RSSI-Berechnung (eben ohne LQ-Berechnungseinfluss) findet sich bei allen mit ACCESS-Firmware betriebenen Empfängern. Die dazu passenden niedrigeren RSSI-Alarmwerte wurden auch von FrSky vorgegeben.
Genau das sehe ich nicht so und dabei geht es nicht um Optik sondern um Informationsgehalt. Stell dir nur mal rein theoretisch folgendes mit zwei 100er Paketen vor. Beim ersten Paket sind die ersten 50 Frames okay und die zweiten 50 Frames haben sehr viele FLs. Dann nimm das darauffolgende zweite Paket, bei dem die Anteile der beiden 50er Pakete genau andersherum sind. Die FrSky-Rechnung würde für beide 100er Pakete ca denselben FLR-Wert rausgeben. Eine gleitende Mittelwertberechnung aber nicht, die würde nämlich im Lauf der Berechnung beide schlechten 50er-Pakete auch sehen und zwar als 100er Paket und damit dann auch einen deutlich schlechteren Wert ausgeben. Die FrSky-Methode beschönigt also den FLR-Wert, ich sage aber ausdrücklich nicht, dass das so beabsichtigt ist.
Zuletzt bearbeitet:
Deine Aussage ist korrekt, wenn das eine Telemetriepaket, um das es hier geht, gesendet werden konnte. Bei hohen Frameverlusten ist das aber nicht garantiert. Am Ende muss jede Messung interpretiert werden, egal ob gleitender Durchschnitt oder 100er Paket. Die Lockouts sollten irgendwann Geschichte sein, dann passt das mit den 100er Paketen schon, da würde ich keinen Aufstand machen.
Es wäre an LQ Sensorbesitzer (habe leider noch keinen), ACCESS Firmware zu testen und die Werte des FrSky FLR mit dem Sensor-ermittelten Wert als Kurve darzustellen, und zwar für die jeweils aktuelle Testfirmware. Reinhard hatte das ja bereits einmal gemacht für eine mittlerweile überholte Firmwareversion. Kritischster Vertreter ist auch unter ACCESS wohl der G-RX8.
Der Kollege hat netterweise wie von @FJH gewünscht, die "telemetrie lost" Stellen mit SF markiert. Man sieht, dass dies meistens mit einem Frameverlust zusammen passiert, aber nicht immer. Man sieht auch hier, dass unter RSSI 45dB der Frameverlust beginnt, wie ich es immer wieder beschreibe. Allerdings finde ich keine Telemetriewerte, die an den entsprechenden Stellen fehlen. Da muss man mal schauen, was genau diese Meldung in OpenTX triggert.
Jetzt wäre natürlich interessant, wie sich ein "normaler" ACCESS RX in dieser Situation verhält. Oder der G-RX8 ohne Baro. FrSky scheint mit der Baro-Firmware einfach überfordert zu sein.
Jetzt wäre natürlich interessant, wie sich ein "normaler" ACCESS RX in dieser Situation verhält. Oder der G-RX8 ohne Baro. FrSky scheint mit der Baro-Firmware einfach überfordert zu sein.
Anhänge
Habe mal Kilrah angefragt, was genau den Telemetriealarm triggert. Die Durchsicht von seinem Fluglog zeigt ausser einigen kurzen FL-Peaks für mich keine Auffälligkeiten. Habe die beiden Kollegen aber mal gebeten, bei mehreren Flügen hintereinander, vor einem Neustart den Empfänger kurz stromlos zu machen. Möchte einfach mal schauen, ob das vielleicht Unterschiede bewirkt und man diese dann auch im Log sieht.
Und schon Antwort von Kilrah bekommen: Der Alarm Telemetry lost/recovered wird getriggert durch Empfangsausfall eines RSSI-Datenpakets für ca. 1 sek. Demnach müsste man also im Log an den betreffenden Stellen konstante (eingefrorene) RSSI-Werte finden.
Und schon Antwort von Kilrah bekommen: Der Alarm Telemetry lost/recovered wird getriggert durch Empfangsausfall eines RSSI-Datenpakets für ca. 1 sek. Demnach müsste man also im Log an den betreffenden Stellen konstante (eingefrorene) RSSI-Werte finden.
Zuletzt bearbeitet:
Dann müsste man es aber auch im Log sehen. Im ACCESS Protokoll soll ja irgendwann von mehreren RX RSSI übertragen werden können. Dieses Feature hat FrSky aber noch nicht zum Funktionieren gebracht. Vielleicht triggert OpenTX den Alarm bei ACCESS deswegen zu früh, weil "Platzhalter" für weitere RX mitgezählt werden - nur so eine Idee. Irgendetwas in der Richtung könnte es sein. Die Telemetrie sieht laut Log komplett unverdächtig aus.
Müsste nach meinem und auch Kilrah's Verständnis im Log als "RSSI-Freeze" zu sehen sein, ist es aber nicht. Hast du ja auch keine bei bzw. vor den markierten Stellen gefunden. Im Moment ein Mysterium.
D. Thompson fliegt ja ACCESS mit einem G-RX8 und einem R9mini in einem Master/Slave Setup und da findet man alle Telemetriewerte und zwar von beiden Empfängern. Kilrah sagt dazu, dass von OTx jeder Empfänger separat gesehen wird und darum auch entsprechende Meldungen von jedem der Empfänger ausgelöst werden, wobei die Ausgabe der Meldung selber halt nicht unterscheidet und man deswegen bei beiden im Log checken muss.
D. Thompson fliegt ja ACCESS mit einem G-RX8 und einem R9mini in einem Master/Slave Setup und da findet man alle Telemetriewerte und zwar von beiden Empfängern. Kilrah sagt dazu, dass von OTx jeder Empfänger separat gesehen wird und darum auch entsprechende Meldungen von jedem der Empfänger ausgelöst werden, wobei die Ausgabe der Meldung selber halt nicht unterscheidet und man deswegen bei beiden im Log checken muss.
Hier noch mal ein Detail. Man sieht grün, wo "telemetrie lost" signalisiert wurde. Da der Kollege ein ganz fitter ist, das sieht man am ruhigen Flug und den sehr aktiven Steuerbewegungen - bei den meisten ist es übrigens genau andersrum - kann man davon ausgehen, dass er maximal 2-3s gebraucht hat, um SF zu betätigen. Und da ist nirgendwo der RSSI länger als 0,4s konstant. Ich denke, mit dieser Datengrundlage könnte man einen OpenTX issue eröffnen. Soll ich das machen?
Auch schön zu sehen, dass mit ACCESS alle 0,7s ein neuer FLR% Wert kommt, da ACCESS alle 7ms ein Frame sendet. Damit kann man locker leben ....
- kann man davon ausgehen, dass er maximal 2-3s gebraucht hat, um SF zu betätigen. Und da ist nirgendwo der RSSI länger als 0,4s konstant. Ich denke, mit dieser Datengrundlage könnte man einen OpenTX issue eröffnen. Soll ich das machen?Auch schön zu sehen, dass mit ACCESS alle 0,7s ein neuer FLR% Wert kommt, da ACCESS alle 7ms ein Frame sendet. Damit kann man locker leben ....
Anhänge
Kilrah schrieb übrigens noch, dass die Telemetriedaten mit einem Checksummenwert gesendet und empfangen werde, der von OTx geprüft wird. Im Falle eines OTx-Fehlers würden dann alle Telemetriewerte betroffen sein und nicht nur einer würde dann einen solchen Extrempeak im Log zeigen. Ein solch gleichzeitiges Auftreten von Alt und VSpd habe ich aber nicht gesehen, es war in allen Fällen entweder der eine oder der andere. Nach Kilrah spricht das gegen einen OTx-Fehler und für ein Firmware-verursachtes Phänomen.
Ich hab die Fakten zusammengestellt, mal sehen was die Chefetage spricht.
