FRSKY Das neue FrSky ACCESS Protokoll
- Themenstarter Carbonator
- Beginndatum
So,
gestern habe ich meine Taranis X-Lite Pro noch einmal testen können. Mittlerweile habe ich ja die Firmware auf dem Sender, mit der man das neue Protokoll ACCESS wie auch das bisherige Protokoll XJT D16 auswählen kann.
2 Modelle sind mit den neuen Empfängern ausgestattet (G-RX6, RX4R) und werden mit dem neuen Protokoll betrieben.
1 Modell mit einem X6R EU/LBT Empfänger wurde mit dem Sender im Modus XJT D16 gebunden, was auch gleich im 2. Anlauf gelang. Allerdings unterstützt Companion bis 2.3.0N28 diesen Modus noch nicht, so dass bei Änderungen an der Programmierung und Rückübertragung auf den Sender die Bindung verloren geht, da Companion wohl die Empfängerparameter nach dem neuen Standard speichert. Ein anschließendes nochmaliges Binden des Modells funktioniert dann aber schon nach dem neuen Standard: Im Sender "BIND" aktivieren, Empfänger normal einschalten - Bindung ist wieder hergestellt.
Das Fliegen mit den 3 Modellen war nach einigen Trimmkorrekturen ohne irgendwelche Auffälligkeiten. Im Gegenteil, ich hatte subjektiv den Eindruck, dass sich die Modelle direkter steuern lassen und schneller auf Steuerbefehle reagieren. Störungsmäßig ist mir nichts aufgefallen. Ein ständiges "Sendersignal schwach" oder "... kritisch" konnte ich wärend der ganzen Flüge nicht hören, auch nicht bei dem Modell im konventionellen Modus.
Es sieht so aus, dass sich der kleine Sender zu einem "überall dabei Gerät" entwickelt, womit einem "Rucksackfliegen" in Zukunft nichts mehr im Wege steht
gestern habe ich meine Taranis X-Lite Pro noch einmal testen können. Mittlerweile habe ich ja die Firmware auf dem Sender, mit der man das neue Protokoll ACCESS wie auch das bisherige Protokoll XJT D16 auswählen kann.
2 Modelle sind mit den neuen Empfängern ausgestattet (G-RX6, RX4R) und werden mit dem neuen Protokoll betrieben.
1 Modell mit einem X6R EU/LBT Empfänger wurde mit dem Sender im Modus XJT D16 gebunden, was auch gleich im 2. Anlauf gelang. Allerdings unterstützt Companion bis 2.3.0N28 diesen Modus noch nicht, so dass bei Änderungen an der Programmierung und Rückübertragung auf den Sender die Bindung verloren geht, da Companion wohl die Empfängerparameter nach dem neuen Standard speichert. Ein anschließendes nochmaliges Binden des Modells funktioniert dann aber schon nach dem neuen Standard: Im Sender "BIND" aktivieren, Empfänger normal einschalten - Bindung ist wieder hergestellt.
Das Fliegen mit den 3 Modellen war nach einigen Trimmkorrekturen ohne irgendwelche Auffälligkeiten. Im Gegenteil, ich hatte subjektiv den Eindruck, dass sich die Modelle direkter steuern lassen und schneller auf Steuerbefehle reagieren. Störungsmäßig ist mir nichts aufgefallen. Ein ständiges "Sendersignal schwach" oder "... kritisch" konnte ich wärend der ganzen Flüge nicht hören, auch nicht bei dem Modell im konventionellen Modus.
Es sieht so aus, dass sich der kleine Sender zu einem "überall dabei Gerät" entwickelt, womit einem "Rucksackfliegen" in Zukunft nichts mehr im Wege steht
Die Horus X10 wird es bald als ACCESS Version geben. Wer jetzt glaubt, die heißt X10 ACCESS ....... falsch
Das wird die X10 EXPRESS werden, es soll auch ein ACCESS HF-Modul zum Nachrüsten geben, ich schlage vor, es iXJT EXCESS zu nennen
Das wird die X10 EXPRESS werden, es soll auch ein ACCESS HF-Modul zum Nachrüsten geben, ich schlage vor, es iXJT EXCESS zu nennen
ACCESS wird ja beworben mit 11ms konstanter Latenz vom Stick zum PWM Ausgang. Der neuseeländische Kollege hat eine variable Latenz von 12 bis 21ms gemessen, die auch grob so von den OpenTX Entwicklern bestätigt wird. Was hört man dazu eigentlich von unseren europäischen Premium Händlern, die ja nach eigener Aussage intensiv am Testen sind? Irgendwie ist es still geworden .....
Zuletzt bearbeitet:
Eine feste Latenz wird es nicht geben, da die Pakete in festen Abständen gesendet werden. Je m´nachdem wann du den Wert änderst, kann es kurz vor der Veränderung ( kleine Latenz ) oder kurz danach ( max. Latenz).
Wichtiger sind die Schwankungen der Latenz - die sind kleiner 10msec - ein guter Wert.
Ingesamt ist aber die LAtenz von 2.2 auf 2.3 von ~ 30msec auf ~20 msec gesunken - die Varianz bei ~ 10msec hat sich wenig geändert ( siehe oben).
Naja - sind halt Werbeaussagen - die ein Techniker so wohl nicht schreiben würde. Dadurch machen sie sich angreifbar.
Viel schlimmer finde ich die Versprechen - die sie weder vom Umfang noch Inhalt - und auch vom Termin nicht halten. Da haben sie sich wohl mächtig verhoben.
Wichtiger sind die Schwankungen der Latenz - die sind kleiner 10msec - ein guter Wert.
Ingesamt ist aber die LAtenz von 2.2 auf 2.3 von ~ 30msec auf ~20 msec gesunken - die Varianz bei ~ 10msec hat sich wenig geändert ( siehe oben).
Naja - sind halt Werbeaussagen - die ein Techniker so wohl nicht schreiben würde. Dadurch machen sie sich angreifbar.
Viel schlimmer finde ich die Versprechen - die sie weder vom Umfang noch Inhalt - und auch vom Termin nicht halten. Da haben sie sich wohl mächtig verhoben.
Hy,
nicht zu vergessen in V2.30 wird auch das Heartbeat-Signal verarbeitet zur Synchronisation.
Dank Mike Blandfort wurde das in openTx übernommen.
Damit ist auch ACCST D16 nur noch ca 1ms langsamer als das hochgelobte ACCESS und hat bei 8 Kanal fixe 9ms
Heartbeat-Sgnal erlaubt dann auch eine Synchronisation von internem und extermen Modul und erlaubt dann auch ein Multiswitchsystem auf 2,4GHz,
da auf diesen Impuls getriggert werden kann.
(Ich hatte da schon mal eine Schaltung für den Schiffsmodellbauer)
nicht zu vergessen in V2.30 wird auch das Heartbeat-Signal verarbeitet zur Synchronisation.
Dank Mike Blandfort wurde das in openTx übernommen.
Damit ist auch ACCST D16 nur noch ca 1ms langsamer als das hochgelobte ACCESS und hat bei 8 Kanal fixe 9ms
Heartbeat-Sgnal erlaubt dann auch eine Synchronisation von internem und extermen Modul und erlaubt dann auch ein Multiswitchsystem auf 2,4GHz,
da auf diesen Impuls getriggert werden kann.
(Ich hatte da schon mal eine Schaltung für den Schiffsmodellbauer)
FrSky hat gerade ein paar Messungen herausgerückt. Scheinbar lassen sie dabei die Eingangsverarbeitung außen vor und triggern mit einer Spezialfirmware irgendwo dazwischen. Das erklärt den Unterschied zu unabhängigen Messungen.
Trotzdem sind die Messungen von den festen 11ms weit entfernt, die immer noch auf der ACCESS Seite behauptet werden. Ein von den vielen Bildchen beeindruckter Kollege hat schon mal ein "Impressive" herausgehaucht. Meine Antwort darauf ist leider von mir zensiert worden
Im Prinzip ist aber die Latenz mit der Berücksichtigung des Heartbeat deutlich verbessert worden, auch schon ohne ACCESS, das ist die Hauptsache.
Trotzdem sind die Messungen von den festen 11ms weit entfernt, die immer noch auf der ACCESS Seite behauptet werden. Ein von den vielen Bildchen beeindruckter Kollege hat schon mal ein "Impressive" herausgehaucht. Meine Antwort darauf ist leider von mir zensiert worden
Im Prinzip ist aber die Latenz mit der Berücksichtigung des Heartbeat deutlich verbessert worden, auch schon ohne ACCESS, das ist die Hauptsache.
Da FrSky dankenswerterweise diesmal selbst gemessen hat, können wir uns auf die Diskussion beschränken. Was sieht man?
- Zuerst vergessen wir mal die erste Zeile, den pin_Change_Trigger, das ist offensichtlich die von der Spezialfirmware getriggerte Aktion, die dann parallel am SPort ausgegeben wird
- interessant ist die zweite Zeile, das ist die Ansteuerung des ISRM-ACCESS Moduls. Alle 7ms wird ein Frame gesendet
- in der dritten Zeile sieht man den SBus des Empfängers, an dem alle 7ms ein SBus Frame ausgegeben wird
Man kann die Latenz vom Anfang des ISRM-Frame bis zum Ende des SBus Frame mit etwa 10ms herauslesen, dieser Wert ist konstant. Wir denken uns zu einem beliebigen Zeitpunkt ein Steuerkommando. OpenTX wertet das Kommando aus und berechnet die Kanalwerte. Das dauert die Zeit X, nehmen wir mal an 3ms. Dann muss auf das nächste ISRM-Frame gewartet werden. Das kann im schlimmsten Fall erst in 7ms so weit sein, weil das letzte Frame gerade eben gesendet wurde. Also haben wir minimal 13 und maximal 20ms Latenz.
Wer Trainstation versteht, hier die Übersetzung: Alle 7 Minuten fährt eine UBahn zum Einkaufszentrum, die Fahrt selbst dauert 10 Minuten.
Wenn die Kauflust durch das Shoppingporno gucken im TV zu groß wird, beschließt man spontan einkaufen zu fahren. Zum Bahnhof sind es 3 Minuten Fußweg. Wenn man Glück hat, hüppt man noch in die abfahrende Bahn, Pessimisten sehen noch die Schlusslichter der gerade abgefahrenen Bahn und warten 7 Minuten auf die nächste Bahn. Also braucht man zwischen 13 und 20 Minuten zum Ziel.
- Zuerst vergessen wir mal die erste Zeile, den pin_Change_Trigger, das ist offensichtlich die von der Spezialfirmware getriggerte Aktion, die dann parallel am SPort ausgegeben wird
- interessant ist die zweite Zeile, das ist die Ansteuerung des ISRM-ACCESS Moduls. Alle 7ms wird ein Frame gesendet
- in der dritten Zeile sieht man den SBus des Empfängers, an dem alle 7ms ein SBus Frame ausgegeben wird
Man kann die Latenz vom Anfang des ISRM-Frame bis zum Ende des SBus Frame mit etwa 10ms herauslesen, dieser Wert ist konstant. Wir denken uns zu einem beliebigen Zeitpunkt ein Steuerkommando. OpenTX wertet das Kommando aus und berechnet die Kanalwerte. Das dauert die Zeit X, nehmen wir mal an 3ms. Dann muss auf das nächste ISRM-Frame gewartet werden. Das kann im schlimmsten Fall erst in 7ms so weit sein, weil das letzte Frame gerade eben gesendet wurde. Also haben wir minimal 13 und maximal 20ms Latenz.
Wer Trainstation versteht, hier die Übersetzung: Alle 7 Minuten fährt eine UBahn zum Einkaufszentrum, die Fahrt selbst dauert 10 Minuten.
Wenn die Kauflust durch das Shoppingporno gucken im TV zu groß wird, beschließt man spontan einkaufen zu fahren. Zum Bahnhof sind es 3 Minuten Fußweg. Wenn man Glück hat, hüppt man noch in die abfahrende Bahn, Pessimisten sehen noch die Schlusslichter der gerade abgefahrenen Bahn und warten 7 Minuten auf die nächste Bahn. Also braucht man zwischen 13 und 20 Minuten zum Ziel.
Leider funktioniert das angekündigte drahtlose Firmware-Update mit den real existierenden Empfängern mit ACCESS Firmware nicht. Mit neuen ACCESS Empfängern soll es dann wohl klappen. Diese gibt es aber (noch) nicht. Ach doch: Die neuen R9 OTA (over the air) Receiver können es natürlich schon, OTA Receiver können aber kein ACCST mehr, also Uffbasse.
Zuletzt bearbeitet:
So wie es aktuell aussieht, können nur die RXe auf ACCESS umgestellt werden, für die derzeit schon die neue Firmware verfügbar ist. Alle anderen fallen raus, weil die (alte) Hardware das angeblich nicht packt.
Für X10/X10S und vielleicht auch die X12S wird es ein ACCESS fähiges HF-Modul zum nachrüsten geben.
Neue nur-ACCESS fähige RXe sind in der Mache.
Für X10/X10S und vielleicht auch die X12S wird es ein ACCESS fähiges HF-Modul zum nachrüsten geben.
Neue nur-ACCESS fähige RXe sind in der Mache.
