FRSKY Das neue FrSky ACCESS Protokoll

[Carbonator]

Langsam scheint das neue Protokoll in die Gänge zu kommen.

ACCESS heißt lt. FrSky: Advanced Communication Control, Elevated Spread Spectrum, Allerhopp sag ich da nur

Vorteile: geringere Verzögerung, bis herab zu 12ms Ende-Ende Laufzeit. Also grob die Hälfte der bisherigen Latenz. "High-speed digital interface of internal and external modules (Baud rate: 450K)" Bis zu 24 Kanäle je Modul anstelle 16. Dann wird von 40% mehr Reichweite geredet, aber ich gehe davon aus, dass sich das nur auf die Telemetrie der neuen Sendemodule bezieht, vermutlich haben sie dort jetzt den gleichen, empfindlicheren Chip drin, wie in den neuen Empfängern.

Wenn ich es richtig verstehe, ist auch das drahtlose Firmwareupdate der Empfänger damit möglich.

Es sollen alle Sender und Empfänger, die das D16 Protokoll beherrschen, nach und nach auch auf das neue Protokoll umgestellt werden können. R9 ist noch offen, es wäre aber Quatsch, R9 auszulassen. Kommt also sehr wahrscheinlich auch.

Wenn man bei der X-Lite mal schaut, an wie vielen Schrauben die Entwickler gerade drehen, wird einem beim Lesen schon schwindlig. Wahnsinn, dass die Jungs da noch durchblicken. Wird sicher ein interessanter Rollout.

Es bleibt spannend .....

 

[FJH]

Interessant ist, ob es dann ein weltweit gleiches Protokoll wird, das müsste dann ja zwangsläufig ein LBT-EU-konformes sein. Oder gibt's dann wieder eines für die EU und ein anderes für den Rest der Welt? Letzteres kann/mag ich mir eigentlich nicht vorstellen.

 

[Carbonator]

Schwierige Frage. LBT funktioniert, wenn sich alle daran halten. In Märkten, wo LBT nicht verpflichtend ist, wäre ich vorsichtig. Kilrah ist kein Freund von LBT für Fernsteuerzwecke. Wenn er Einfluss hat(te), bleibt es bei zwei Systemen.

 

[Carbonator]

Von renatoa gibt es erweiterte Infos, die mal bei FrSky kurz online waren und dann wieder entfernt wurden

Da werden einige Wünsche wahr ....

 

[QuadCrash]

Da werden einige Wünsche wahr ....

Na endlich, muss nur noch alles funktionieren ...

 

[Deleted member 51580]

Wo habt ihr das mit 40% mehr Reichweite gelesen ?
Wurde das vielleicht verwechselt mit dem Untenstehenden?
Ich habe nur gefunden das die Telemetrie Übertragung 40% im upstream schneller wird und 60% im downstream sogar 60%.


Hier mal ein Auszug von der Frsky Seite:

Features
Increased transmission rate and lower latency Supports 24 channels (Full range)
8 channel mode: Latency 11ms / Telemetry upstream rate increased 40% / Telemetry downstream rate increased 60%
16 channel mode: Latency 22ms / Telemetry upstream rate increased 40% / Telemetry downstream rate increased 60%
24 channel mode: Latency 22ms / Telemetry upstream rate increased 40%

 

[Carbonator]

In der Ankündigung der neuen X-lite Versionen steht es drin.

✧ More sensitive and lower latency (down to 12ms)
✧ High-speed digital interface of internal and external modules (Baud rate: 450K)
✧ Longer range with 40% enhanced performance
✧ Accurate SWR indicator
✧ Supports power meter function
✧ Supports spectrum analyzer function

 

[Deleted member 51580]

Ahh... super und danke

 

[FJH]

Schwierige Frage. LBT funktioniert, wenn sich alle daran halten. In Märkten, wo LBT nicht verpflichtend ist, wäre ich vorsichtig. Kilrah ist kein Freund von LBT für Fernsteuerzwecke. Wenn er Einfluss hat(te), bleibt es bei zwei Systemen.

In der Tat plant FrSky wieder separate FW Versionen, wie gehabt. Ich bin zwar kein Freund von LBT, aber das neue Protokoll bietet natürlich die Gelegenheit dann eine gemeinsame FW für alle zu haben mit Vorteilen für FrSky selber als auch für die User. Habe die Überlegung dazu bei FrSky mal angestossen, Ergebnis offen.

 

[FJH]

Andere Frage ist auch, ob das neue Protokoll abwärtskompatibel geplant ist. In dem Fall müsste es zumindest für die Sender die zwei bekannten Versionen LBT/FCC geben. Ohne Abwärtskompatibilität wäre die Voraussetzung zum Flashen des neuen Protokolls, dass es entsprechende FWs für alle Empfänger gibt. Das aber ist zum Start erstmal nicht zu erwarten, wird auch so von FrSky kommuniziert. Darum wird sich jeder, der verschiedene Empfänger im Einsatz hat (und wer hat das nicht), ein Umflashen sicher dreimal überlegen.

 

[Knuspel]

Ich freue mich schon darauf wieder als Beta-Tester eingesetzt zu werden

 

[Carbonator]

Dieser Kollege hat eine sehr ausführliche Beschreibung gepostet, keine Ahnung wo die herkommt. Liest sich aber halbwegs offiziell ....

 

[Deleted member 51580]

Das hört sich alles super an und sind dinge die ich sehr gerne hätte, ich denke damit schupst Frsky die Konkurrenz endgültig aus dem Rennen.

Das einzigste was mir nicht so gefällt ist dieser Punkt.

Q: Does ACCESS protocol support rollbacking to the ACCST?
A: No, this is the one-way update.

 

[Carbonator]

Der FrSky Bootloader, der die Firmware entschlüsselt, wird dabei wohl überschrieben. Diesen Bootloader rückt FrSky natürlich nicht raus. Nur FrSky könnte die alte Firmware wieder draufspielen. Beim Update over the air lädt ja dann die "alte" Firmware die neue und beide müssen gleichzeitig im Speicher sein. Dann wird die alte überschrieben. Das ist ein komplett anderer Prozess. Beim (i)XJT könnte man die alte Bootloader-Methode allerdings beibehalten. Mal sehen, ob das vielleicht nur die Empfänger betrifft.

 

[FJH]

Offenbar arbeitet FrSky auch an einer Updatefunktion für Firmware, die dem User dann das lästige suchen der passenden aktuellen Firmware abnehmen soll. Details dazu kenne ich jetzt noch nicht, habe aber mal vorgeschlagen, eine PC-Software ähnlich dem Jeti Studio zu entwickeln. Ob sowas dann nur für die neue Access-Firmware gehen wird oder auch für die jetzige Firmware nutzbar sein wird - grosses Fragezeichen. Letzteres würde nach meinem Verständnis aber für jede Komponente (Empfänger, Sensor, etc) ein neues Firmwarerelease nötig machen, da ja dann Firmware auslesbar sein muss, was bislang leider nicht der Fall ist.

 

[Carbonator]

Es gibt Aufnahmen von der ACCESS Entwicklerkonferenz. FrSky sieht sich im "World domination business" - und wie immer bei so etwas - sind die Holländer vorne dabei.

 

[Carbonator]

Kilrah schreibt hier, dass es möglich ist, das XJT Modul zwischen ACCESS und ACCST umzuflashen.

Mein Eindruck scheint bestätigt:

Beim (i)XJT könnte man die alte Bootloader-Methode allerdings beibehalten. Mal sehen, ob das vielleicht nur die Empfänger betrifft.

Was ich aber nicht zu hoffen gewagt habe, ist dass OpenTX parallel PXX und PXX2 unterstützt, die Antwort von 3djc ist aber auch nicht 100% eindeutig. Oder?

 

[markus1234]

Ich bin schon sehr gespannt darauf. Wenn ich den rcg thread lese, wird mir nicht so richtig klar wer da was entwickelt. Einen Zeitplan gibt es auch nicht , oder? Nach meinen r9m(m) Erfahrungen werde ich etwas vorsichtiger sein, aber ich habe ja noch ein externes xjt zum testen....

 

[FJH]

Ich lese 3djc eindeutig, dass OTx weiterhin das aktuelle Protokoll und dann zusätzlich das neue Protokoll unterstützen wird. Die von Kilrah genannte Option hin- und herzuflashen ist zwar machbar, ist aber doof, auch wenn's prinzipiell in 2 Minuten gemacht ist.

 

[Carbonator]

Bedeutet das, dass ein und dasselbe OpenTX PXX und PXX2 kann? Ich bin immer davon ausgegangen, dass die Änderungen so gewaltig sind, dass entweder PXX oder PXX2 von OpenTX unterstützt werden. Ich dachte, man muss auch OpenTX neu aufspielen, mit der entsprechenden Protokolloption, wenn man das XJT umflasht.

Bin noch nicht 100% sicher. Diese Ungewissheit hält mich mindestens noch 11 Stunden wach