Ja wollte ich noch nachschieben, falls es Nachfragen dazu gibt. Wollte jetzt nicht deine Fotos ungefragt benutzen. Wenn es dann auch noch Bedarf bzgl. der X9d gibt, dann müsstest du sowieso mit einsteigen, ich habe ja keinen ACCESS Sender mit grossem Display. Denke, dass das dann bei der ACCESS-Horus wohl auch so ist. Auch habe ich jetzt den Telemetrieausfall-Effekt beider Empfänger mit Re-Aktivierung über Öffnen des Optionsmenüs bewusst weggelassen. Hat vielleicht auch nichts miteinander zu tun und ist auch schwierig, korrekt zu beschreiben.
OTX Details zur Receiver Redundancy - GitHub issue #8515
- Themenstarter Merak
- Beginndatum
https://frsky-forum.de/index.php?thread/5410-x12s-upgrade-auf-access-mit-isrm-nachrüstmodul-für-die-x10-x10s-sensoren-id-ab-1/&postID=71087#post71087
Wenn ich den Beitrag im Engel Forum richtig deute sind auch die Sender mit Farbfernseher betroffen.
D.H. es gibt unter OTX 256 ID, wie vermutet in Kombination aus alter 2 Stelliger ID und einem Faktor ( x * 32 ) abhängig von der verwendeten Modul und Empfängerquelle.
Wenn ich den Beitrag im Engel Forum richtig deute sind auch die Sender mit Farbfernseher betroffen.
D.H. es gibt unter OTX 256 ID, wie vermutet in Kombination aus alter 2 Stelliger ID und einem Faktor ( x * 32 ) abhängig von der verwendeten Modul und Empfängerquelle.
Open TX wird doch jetzt auch bei Multiplex verwendet.
BeastTX – The ultimate UAV controller
RC Core: OpenTX installed
BeastTX – The ultimate UAV controller
RC Core: OpenTX installed
Multiplex gibt es einmal als Consumer-Sparte und einmal für den Profi-Bereich. Letztere hatte diesen Flyer zum BeastTX aus dem Du Deine Infos hast, im Dezember 2019 veröffentlich. Das ist also nicht brandneu ...
Multiplex ist aber nicht der Hersteller, sondern die verkaufen die BeastTX im Profi-Bereich weil diese M-Link unterstützen. Ähnlich wie Multiplex Consumer, welche die Core mit M-Link im Programm haben.
OpenTX beim BeastTX bezieht sich auf das RC Core System, vermutlich steckt dort eine X7 o.ä. Systemplatine drin. Windows o. Android ist nur für das angepasst QGroundControl.
Den UAV-Controller finde ich nach wie vor technisch interessant. Aber es ist klar ein UAV-Controller, keine übliche RC-Fernbedienung. Normale Modellflieger können damit nichts anfangen, weil ein Flight Controller mit ArduPilot zwingend benötigt wird.
Multiplex ist aber nicht der Hersteller, sondern die verkaufen die BeastTX im Profi-Bereich weil diese M-Link unterstützen. Ähnlich wie Multiplex Consumer, welche die Core mit M-Link im Programm haben.
OpenTX beim BeastTX bezieht sich auf das RC Core System, vermutlich steckt dort eine X7 o.ä. Systemplatine drin. Windows o. Android ist nur für das angepasst QGroundControl.
Den UAV-Controller finde ich nach wie vor technisch interessant. Aber es ist klar ein UAV-Controller, keine übliche RC-Fernbedienung. Normale Modellflieger können damit nichts anfangen, weil ein Flight Controller mit ArduPilot zwingend benötigt wird.
@Carbonator
Hallo Bernd, kannst du nochmal nen Blick auf den github issue werfen (Link hier in #59)? Ich versteh's nicht so ganz, ob das jetzt ein bekannter Bug seitens FrSky oder OTx ist. Und wenn OTx, warum das nicht korrigiert wird.
Hallo Bernd, kannst du nochmal nen Blick auf den github issue werfen (Link hier in #59)? Ich versteh's nicht so ganz, ob das jetzt ein bekannter Bug seitens FrSky oder OTx ist. Und wenn OTx, warum das nicht korrigiert wird.
Hallo FJ,
da kann ich nicht viel zu sagen, da ich die Hardware nicht habe.
Es würde Sinn machen, die 28 Sensor IDs, die im S-Port abgefragt werden, noch mit einer Erweiterung zu versehen, aus der hervorgeht, wo die Sensorinformation herkommt. Jeder Empfänger kann ja 28 IDs abfragen und "manipuliert" dann die Sensor ID so, dass im Sender klar wird, wer gepollt hat.
Das nächste Thema ist, wie man den "Versand" der Daten OTA regelt, die Bandbreite ist ja begrenzt und es kann nur ein Empfänger Telemetrie senden.
Ich vermute, dass FrSky an der Stelle protokolltechnisch gescheitert ist. Zumindest interpretiere ich die Aussagen von 3djc so. OpenTX könnte jedenfalls Stand jetzt die Sensoren unterscheiden, aber offensichtlich kommen sie nicht OTA (mit Fragezeichen, s.o.)
Ich würde einfach mal abwarten und so lange Kram nutzen, der ohne Redundanz zuverlässig funktioniert. Eine Redundanz, die man nicht prüfen kann, ist genausogut wie keine Redundanz. Zumindest gilt das bei mir im Job
da kann ich nicht viel zu sagen, da ich die Hardware nicht habe.
Es würde Sinn machen, die 28 Sensor IDs, die im S-Port abgefragt werden, noch mit einer Erweiterung zu versehen, aus der hervorgeht, wo die Sensorinformation herkommt. Jeder Empfänger kann ja 28 IDs abfragen und "manipuliert" dann die Sensor ID so, dass im Sender klar wird, wer gepollt hat.
Das nächste Thema ist, wie man den "Versand" der Daten OTA regelt, die Bandbreite ist ja begrenzt und es kann nur ein Empfänger Telemetrie senden.
Ich vermute, dass FrSky an der Stelle protokolltechnisch gescheitert ist. Zumindest interpretiere ich die Aussagen von 3djc so. OpenTX könnte jedenfalls Stand jetzt die Sensoren unterscheiden, aber offensichtlich kommen sie nicht OTA (mit Fragezeichen, s.o.)
Ich würde einfach mal abwarten und so lange Kram nutzen, der ohne Redundanz zuverlässig funktioniert. Eine Redundanz, die man nicht prüfen kann, ist genausogut wie keine Redundanz. Zumindest gilt das bei mir im Job
