FRSKY Das neue FrSky ACCESS Protokoll

in der Auflistung fehlt der LR12 Mode, oder hast du den mit Absicht weggelassen ?

und schreib vielleicht mal rein das nur der D16 Mode bzw. Access von FCC/ LBT betroffen ist....

Ralf
 

weixelgeist

Erfahrener Benutzer
Die Umrüstplatine (IXJT2.0) für meine X10S hab ich noch nicht eingebaut.
Wenn ich die einbaue, dann macht mein Sender beim hochfahren diesen Test, ob es ein Original-Sender ist?
Und funktioniert der?
 
Auf RCG gibt es einen Log ACCESS mit R9 kombiniert. Leider hat der Kollege nur mit 1s aufgezeichnet. Aber man sieht ganz gut das Potential. Wenn FrSky das Telemetrieproblem noch löst, könnte diese Kombi für Leute die viele 2.4 GHz Störungen haben (und für die, die sowieso immer Angst haben ;)) sehr interessant werden.

Vor allem hat man jetzt ständig Kontrolle über beide Links.

Die Lost Frames sehen erstmal bescheiden aus, aber ich denke für einen Full Carbon Segler ist das absolut die Norm. Das Teil schirmt halt regelmäßig beim Fliegen/Kreisen und die niedrige Zeitauflösung lässt es schlimmer aussehen, als es ist.
 

FJH

Erfahrener Benutzer
Hab's gerade auch gesehen, schlägst du ihm jetzt ne 0,2s Aufzeichnung vor, damit er dann auch ggf Lockouts erkennen kann? Übrigens wird FrSky den FLR mit nem LQ ersetzen, der dann mit LQ=100%-FLR den mittlerweile gewohnten Kurvenverlauf bietet, also 100% dann keine Paketverluste.
 
Er wollte ja wissen, nach welchemKriterium die R9 Leistung ungeschaltet wird. Wenn er zeitlich höher aufgelöst hätte, würde er es am RSSI gut erkennen.

Eventuelle Lockouts sieht man im FLR. Wie dieser zeitlich auflöst, müsste mal jemand prüfen. Ich hoffe nicht, dass sie nur 1x/s den Wert senden, sondern einen gleitenden Durchschnitt. Tadango hat es ja vorgemacht.
Ich werde erstmal bei ACCST V1 bleiben, ein "Killerargument" für ACCESS sehe ich für mich noch nicht. Zur Zeit funktioniert mein Kram, wie ich es mir besser nicht malen kann.
 

FJH

Erfahrener Benutzer
Ich habe mal in meinen Logfile von vorgestern geschaut. Geflogen mit einer X9Lite und G-RX8 mit ACCESS 2.1.0. Beim kurzen Flug keine besonderen Vorkommnisse gehabt, war mit nem Bixler unterwegs bis auf ca 200m Höhe, geloggt mit 0,2s. Bei den FLRs sind es immer mindestens 3 gleiche Werte, bevor der Wert sich ändert. Demnach müssten diese 0,6s die Frequenz sein, mit der der FLR-Wert von der Firmware ermittelt wird.
 

Anhänge

Ich habe mal in meinen Logfile von vorgestern geschaut. Geflogen mit einer X9Lite und G-RX8 mit ACCESS 2.1.0. Beim kurzen Flug keine besonderen Vorkommnisse gehabt, war mit nem Bixler unterwegs bis auf ca 200m Höhe, geloggt mit 0,2s. Bei den FLRs sind es immer mindestens 3 gleiche Werte, bevor der Wert sich ändert. Demnach müssten diese 0,6s die Frequenz sein, mit der der FLR-Wert von der Firmware ermittelt wird.
Der FLR% Wert wird über 100 Frames gemessen. Da die Framerate bei ACCESS 7ms ist, ergibt das eine Updaterate von 0,7s. Es wird kein gleitender Mittelwert gebildet, sondern einfach die Framelosses über 100 Frames aufaddiert. Siehe auch hier.
 

FJH

Erfahrener Benutzer
Der FLR% Wert wird über 100 Frames gemessen. Da die Framerate bei ACCESS 7ms ist, ergibt das eine Updaterate von 0,7s. Es wird kein gleitender Mittelwert gebildet, sondern einfach die Framelosses über 100 Frames aufaddiert. Siehe auch hier.
Bei gleitender Mittelwertberechnung sollte das demnach anders aussehen, richtig?? Müsste aber andererseits doch auch nicht unbedingt über 100 Frames gehen. Kleiner würde doch auch kleineren Speicherbedarf bedeuten, oder? Was wäre da ein brauchbarer Kompromiss? Möchte da nochmal versuchen, auf FrSky einzuwirken.
 
Zuletzt bearbeitet:
Ja, da würde das Signal nicht so stufig aussehen und nicht für 700ms gleich sein, sondern sich alle 100ms ändern (bei 100ms Log Rate).

edit: Wenn man über 100 Frames aufaddiert, erhält man automatisch einen % Wert. Dafür braucht man nur ein Byte als Akkumulator. Wenn man einen gleitenden Mittelwert berechnen will, braucht man einen Ringspeicher. Idealerweise 100 Byte, da das dann auch automatisch den % Wert ergibt. Man kann den Ringspeicher natürlich kleiner machen, wenn RAM knapp ist.
 
Zuletzt bearbeitet:

FJH

Erfahrener Benutzer
Was wäre da ein noch sinnvoller (kleinerer) Wert? Vielleicht 50 oder 25? Frage das, um es FrSky vielleicht schmackhafter zu machen, wenn es um Speicherresourcen geht.
 
Was wäre da ein noch sinnvoller (kleinerer) Wert? Vielleicht 50 oder 25? Frage das, um es FrSky vielleicht schmackhafter zu machen, wenn es um Speicherresourcen geht.
Wenn man alle 100ms einen aktualisierten Wert haben möchte, kann man rechnen 100ms / 7ms = 14 frames = 14 Byte als Minimum für den Ringspeicher

edit: Mit höherem Codieraufwand kann man die FL-Bits als Bit speichern, statt als Byte. Dann könnte man mit einer 16Bit Integer Variablen 16 FL-Bits speichern. Dieser Platz ist mit Sicherheit vorhanden.
 

FJH

Erfahrener Benutzer
Danke dir. Bei den 14 frames wären aber andererseits auch wieder Sprünge nicht auszuschliessen, da wäre also ein grösserer Wert in Richtung Glättung vielleicht vorzuziehen?? Werde mal 50 vorschlagen und nur bei Speicherknappheit runter auf 25. Mal sehen, ob da bei FrSky was geht.
 
Zuletzt bearbeitet:
Wäre auch mal interessant, welche Fehlermeldung kommt, wenn man jeweils einen Link deaktiviert, also den Komplettausfall einer Funkstrecke simuliert. "Telemetry lost"? ;)
 

FJH

Erfahrener Benutzer
Bei welchem Empfängersetup meinst du das? Haupt-/Satellit oder ...??

Der Kollege Dale Thompson hat ja auf RCG ein paar Fluglogs gepostet mit einer ACCESS-Kombi aus G-RX8 unf R9mini. Hast du sicher gesehen.
 
Bei welchem Empfängersetup meinst du das? Haupt-/Satellit oder ...??

Der Kollege Dale Thompson hat ja auf RCG ein paar Fluglogs gepostet mit einer ACCESS-Kombi aus G-RX8 unf R9mini. Hast du sicher gesehen.
Klar. Jede Funkstrecke in diesem Setup kann ja ausfallen. Die Frage ist, was bekommt der Pilot davon mit. Die Telemetrie der jeweiligen Funkstrecke fällt ja ebenfalls aus und damit sind die RSSI und LFR Werte "eingefroren".
 
FPV1

Banggood

Oben Unten