FRSKY Das neue FrSky ACCESS Protokoll

[Carbonator]

So, ich war mal im Keller. Den RX8R RSSI habe ich in den RX4R Log reingepappt. Man sieht wieder die bekloppte RSSI-Differenz. Von der Performance nehmen sie sich bei dem einfachen Test nicht viel. Das wird sich auf dem Copter zeigen. Gefühlt ist D16 nach wie vor leicht im Vorteil, wenn man bedenkt, dass der RX4R deutlich empfindlicher ist.

T16 mit ACCESS Modul, einmal im D16 Modus dann mit ACCESS.

 

[FJH]

Grün und rot sind also RX4R ACCESS-Daten und blau ist RX8R ACCST, wobei beide mit dem in die T16 eingepflanzten ISRM Board geloggt sind und jeweils alles mit letztaktueller Firmware von der github Testseite. Richtig?

Fehlt noch das "fahren" in den FS, wobei Reinhard ja schon mal gemessen und RSSI bei ACCESS bei ca. 25 dB gesehen hat.

 

[Carbonator]

Ja, korrekt. Den Failsafe Wert werde ich erfliegen.

Ich hatte übrigens auch wieder einen "FrSky - let you see the limits" Moment, als ich das RX4R frsk-File flashen wollte. Dass es mit der T16 nicht geht, ist ja nachvollziehbar Dass FrSky STK und Airlink nicht gehen aber weniger. Meine 2013er X9D konnte es dann zum Glück - dafür kann sie kein ACCESS.

 

[RayX]

Anscheinend gibt es auch ein neues Flash Tool Vielleicht klappt es ja damit.
Was da anders / besser / schlechter ist.... kein Ahnung

 

[Carbonator]

Das sieht gut aus, da habe ich natürlich nicht nachgeschaut.

 

[r41065]

laut Adela braucht man die .frsk nur in .frk umbenennen, dann funktionieren auch die alten Tools / Sender.
Das neue kann dann die neue Dateiendung....

Ralf

 

[Carbonator]

Die Idee hatte ich auch, dann habe ich diesen Beitrag von Kilrah gefunden.

FrSky have not released a tool for flashing frsk files using a computer at this time. Need to use the radio.

Diese Aussage gibt es auch:

The frsk file format is the file type FrSky is using on all new firmware. It has the ability to detect the device type and that should help prevent flashing a device with the wrong firmware.

Da bin ich lieber vorsichtig - und lasse anderen den Vortritt

 

[Carbonator]

Die Treppen hoch- und runterlatschen ist natürlich kein amtlicher Test. Da aber nicht wirklich Flugwetter ist, habe ich noch eine ganz alte Kombination reingepappt. X9D mit X4R ACCST D16 FCC. Den 5100 habe ich umgerechnet (100-x), um auf den FLR% Maßstab zu kommen. Man sieht, dass ACCESS LBT ähnlich liegt, das höhere "Rauschen" mag vom Inhouse Test kommen, da sind immer ein paar Geräte auf den Etagen aktiv. Man sieht auch die bessere zeitliche Auflösung des Tadango Sensors, aber da will ich eher kein Thema draus machen.
Hellblau ist der X4R RSSI und Purpur die X4R LFR%.

 

[FJH]

Heute von @camber2reflex erfahren, dass er immer mit zwei G-RX8 unterwegs ist in einem Master/Satellit Setup der beiden. Beide hat er mit aktiver Telemetrie gebunden, die beiden SmartPorts der G-RX8 hat er nicht untereinander verbunden. @Jet_Flyer hat ja die verschiedenen Setup-Optionen für Telemetrie bei ACCESS in seinem Setup-Beschreibung beschrieben, hier als Download zu finden => RC Groups - View Single Post - FrSky - New - Taranis X-Lite - S and Pro - X9 Lite - S - R9M Lite and Pro - MPM Lite
Leider sieht man bislang ja immer nur ein Telemetrie-Datenset, wird wohl das vom Master sein. Frage ist, ob und wann man im Flug die Telemetriedaten des Slave sieht und diese geloggt werden.

 

[Carbonator]

Da übermittelt der erste von bis zu drei Receivern, der einen Link hat, seine Telemetrie. Wenn die SPort verbunden sind, gilt das auch für die externen Sensoren. Man kann aber (noch) nicht gleichzeitig mit einem Sendemodul von zwei RX Telemetrie empfangen. Die internen Sensoren tauchen auf dem SPort Anschluss leider nicht auf, sonst wären die Spatzen schon gefangen. Zumindest bei ACCST, bei ACCESS habe ich noch nicht geschaut, aber das hätte der Vorbeter erwähnt.

Aber die Idee den externen Lost Frames Sensor eines zweiten RX an den ersten anzuschließen wird funktionieren. Nur den RSSI bekommt man so nicht. Aber man kriegt raus, ob nur der G-RX8 so schrottig ist (wenn der zweite kein G-RX8 ist ).

 

[Carbonator]

Hier noch ein Log mit dem Vergleich von LFR und Tadango. Man sieht, dass die SBus Lost Frames in der Praxis erst ab 25% Frameverlust zu zucken beginnen und erst ab 50% sieht man richtig etwas.
Das RSSI Niveau ist bei ACCESS tatsächlich einfach um 10dB niedriger - mit Failsafe bei 25/26dB. Und das scheinbar nur, weil sich ein paar Prozentgläubige an den 115dB im Nahbereich gestört haben. Aber so ist das heute, es wird das gemacht, was die Mehrheit verstanden zu haben glaubt.

 

[FJH]

Moin Bernd, du hast doch bestimmt schon den letzten Kommentar von @choochoo22 gelesen? Der wirft die Frage auf, ob denn bei der aktuellen Firmware FrSky vielleicht das FS-Kriterium von 100 LFs auf vielleicht mehr LFs angehoben hat. Könntest Du doch bestimmt mal testen, ob FS nach wie vor nach 100 LFs kommt oder erst später nach noch mehr LFs.

 

[Carbonator]

Das wird schwierig. Beim vielen RX kommen überhaupt keine lost frame bits mehr auf dem SBus mit 2.1.0. Ich denke man sollte abwarten, ob FrSky in den nächsten Tagen wieder die Kurve kriegt. Zur Zeit ist das eher Aktionismus gepaart mit Slapstik, Inkompetenz und Arroganz.

Neue Firmwares sind ja für einen Teil der RX draußen, die bei ACCST den Failsafe und bei ACCESS "telemetry lost" fixen sollen. Die Tester bei RCG fühlen sich aber langsam verschaukelt. Es ist schade, dass bei FrSky keiner die Eier hat, mal Klartext zu reden. Jetzt wäre ein guter Zeitpunkt.

 

[Carbonator]

Ich hab mir mal im Händlerforum einen ACCESS Log geklaut X-Lite pro und G-RX8. Da kam es bei kleinen Entfernungen zu sehr niedrigem RSSI. Das Interessante ist, dass trotzdem kaum Frames verloren gingen.

Es könnte sein, dass die ACCESS Firmware den RSSI weniger stark filtert/glättet im Vergleich zur ACCST Firmware. Ein nachträglich gerechneter gleitender Durchschnitt (2s-blau) zeigt, dass die tiefen Spikes sehr kurz sind. Das mittlere RSSI Niveau ist etwa dort, wo man es erwarten kann - das spricht für eine andere Filterung. Wenn man die 10dB draufpackt, dann passt es wieder.

Angeblich soll ja der kleine ACCESS Reichweitennachteil mit 2.1.0 nicht mehr bestehen, das kriege ich aber noch raus.

 

[heikop]

Es ist schade, dass bei FrSky keiner die Eier hat, mal Klartext zu reden. Jetzt wäre ein guter Zeitpunkt.

Wird schwierig, AdelaXie weiß ja offensichtlich nicht mal was ein Changelog ist.

 

[Carbonator]

Wird schwierig, AdelaXie weiß ja offensichtlich nicht mal was ein Changelog ist.

Mein spezieller Freund Webbsolution hat ja gerade ausgerechnet was FrSky an Geld spart, weil sie alpha und beta Tests, Qualitätskontrolle und das Versionsmanagement an die User outgesourced haben. Das dürfte mittlerweile ein siebenstelliger $-Betrag sein. Da ist OpenTX noch gar nicht eingerechnet

 

[QuadCrash]

Wenn sie jetzt den Source der Firmware(s) auch noch rausrücken, könnte es was vernünftiges werden …

 

[helle]

und wäre in wenigen Tagen erledigt.

Oder man wäre überrascht welche Murks man da zusammenprogrammiert hat.

 

[RSO]

und wäre in wenigen Tagen erledigt.

Oder man wäre überrascht welche Murks man da zusammenprogrmmiert hat.

Selbsterkenntnis ist der erste Weg zur Besserung 😉

 

[Carbonator]

Bei vielen RX kommen überhaupt keine lost frame bits mehr auf dem SBus mit 2.1.0. Ich denke man sollte abwarten, ob FrSky in den nächsten Tagen wieder die Kurve kriegt. Zur Zeit ist das eher Aktionismus gepaart mit Slapstik, Inkompetenz und Arroganz.

Immerhin hat der Issue nach 4 Tagen mal das "Bug"-Label bekommen.