EdgeTX
- Ersteller apocalypsedude
- Erstellt am
kalle123
User
Sehr viel mehr wird da auch nicht kommen
Wo es m.E. noch etwas hapert bei Companion ist sind vielleicht die Möglichkeiten der Displaygrafik am Sender, aber sonst?Wenn du im aufgeführten EdgeTX Handbuch mal auf Seite 25 nach schaust, wird du da was von Labels (Modellkategorien) finden und nichts anderes wird da in Companion dargestellt.
KH, der 2014 wegen OTX und Companion seine MPX Sender ins Regal gestellt hat und sich eine Taranis X9D angeschafft hat.
gert
User
Hallo ETX-Nutzer,
im Moment versuche ich mit ETX meinen Empfänger FrSky SR10PRO zu konfigurieren.
Der Empfänger hat die neueste FW 2.1.14, auf meiner FrSky Taranis XLITE S und PRO mit ETX 2.10.5 läuft das neueste LUA Script 2.03.
Der Gyro hat unter OTX unauffällig funktioniert.
Mit ETX kann ich nun den Empfänger konfigurieren, auch der Selbsttest über LUA-Scrip läuft.
Das Einzige was nicht einstellbar ist beschränkt sich auf den Autolevelmodus.
Autolevel Offset Höhe lässt sich konfigurieren.
Autolevel Offset Quer spricht nicht an
Autolevelmode schlägt auf Quer unkontrolliert bei Bewegung des Modells aus.
Die Einstellung mit AirLink verlangt OTX beim Bluetooth-Verbindungsaufbau.
Hat Jemand Ansätze zur Problemlösung oder ähnliche Erfahrungen?
im Moment versuche ich mit ETX meinen Empfänger FrSky SR10PRO zu konfigurieren.
Der Empfänger hat die neueste FW 2.1.14, auf meiner FrSky Taranis XLITE S und PRO mit ETX 2.10.5 läuft das neueste LUA Script 2.03.
Der Gyro hat unter OTX unauffällig funktioniert.
Mit ETX kann ich nun den Empfänger konfigurieren, auch der Selbsttest über LUA-Scrip läuft.
Das Einzige was nicht einstellbar ist beschränkt sich auf den Autolevelmodus.
Autolevel Offset Höhe lässt sich konfigurieren.
Autolevel Offset Quer spricht nicht an
Autolevelmode schlägt auf Quer unkontrolliert bei Bewegung des Modells aus.
Die Einstellung mit AirLink verlangt OTX beim Bluetooth-Verbindungsaufbau.
Hat Jemand Ansätze zur Problemlösung oder ähnliche Erfahrungen?
FlyingNuri
User
Gibt es einen Unterschied bei der Belegung von Pin 5 im Modulschacht zwischen einer Taranis X9D+ SE 2019 und einem Sender mit integriertem ELRS, bspw. eine Jumper T15?
Ich will S.Port Telemetrie dort einspeisen. Bei der Taranis funktioniert es, bei der T15 nicht ...
Ich will S.Port Telemetrie dort einspeisen. Bei der Taranis funktioniert es, bei der T15 nicht ...
madmao
User
Ich kann's nicht lassen: Wer gerne Bier, Popcorn und Jeti-Fanboys die sich bekabbeln hat, ist aktuell hier gut aufgehoben:
www.rc-network.de
Die Stimmung kippt glaub ich langsam.... Ich verfolge den Thread seit Wochen und krieg mein Grinsen nicht aus dem Gesicht. Ich musste mich schon mehrfach zusammenreissen, dort nicht zu posten...
Gottseidank haben wir eine Community, die aktiv mittut, testet und Sender, OS und Funkstrecke vorantreibt. Danke euch allen. Und ja: Spenden für ETX und ELRS ist wieder mal angesagt.
Grüsse
Florian
Jeti DS-24 II - Erste Informationen
Das Video vom Zusammenbau ist interessant. ESD Schutz ist da nicht zu erkennen. Wahrscheinlich haben sie die passenden ESD Schuhe an ;-)
Die Stimmung kippt glaub ich langsam.... Ich verfolge den Thread seit Wochen und krieg mein Grinsen nicht aus dem Gesicht. Ich musste mich schon mehrfach zusammenreissen, dort nicht zu posten...
Gottseidank haben wir eine Community, die aktiv mittut, testet und Sender, OS und Funkstrecke vorantreibt. Danke euch allen. Und ja: Spenden für ETX und ELRS ist wieder mal angesagt.
Grüsse
Florian
FlyingNuri
User
Der besagte Thread ist völlig uninteressant ... wichtiger wäre 'ne Antwort auf meine Frage in #1324, das ist dann auch OnTopic.
Beide auf 2.10?
FlyingNuri
User
Nein. Die Taranis hat noch OpenTX 2.3.15, die T15 EdgeTX 2.10.4.
Ich hab die Vermutung, dass ein Sender mit integriertem ELRS evtl. kein S.Port mehr auf dem Pin kann, habe dazu aber nichts konkretes gefunden, daher die Frage.
Bei einer RM TX16S (MPM intern) mit älterem EdgeTX (2.9.0) funktioniert das nämlich noch.
Ich hab die Vermutung, dass ein Sender mit integriertem ELRS evtl. kein S.Port mehr auf dem Pin kann, habe dazu aber nichts konkretes gefunden, daher die Frage.
Bei einer RM TX16S (MPM intern) mit älterem EdgeTX (2.9.0) funktioniert das nämlich noch.
Was möchtest Du machen?
Doch, SPort ist bei allen da. Dass Sport Telemetrie_in ohne weitere Konfiguration funktionierte war eher Zufall als Design. Mit Umbau in der 2.10 war das vorbei. Ich kann nicht genau sagen, ob das wieder aktiv eingebaut wurde, aber denke eher nicht.
Versuch macht kluch:
2.10.x: PPM/no Telemetry
2.11.: PPM/no Telemetry
Beides probieren
FlyingNuri
User
Ein Kollege möchte die S.Port Telemetrie über einen Dragonlink TX direkt im Sender einspeisen. Bei ihm (Horus X12S mit OpenTX 2.3.15) funktioniert das nicht.
Selbst habe ich einiges an Erfahrung mit DL, sowohl direkt als auch über ein Relay mit einem X8R RX gibt es keine Probleme mit der Taranis bzw. der RM TX16S. Und beim Test kam auch die T15 zum Zuge, wo eben nix ging (direkt nicht und den Relay RX kann sie natürlich nicht binden).
Interessant, wie gesagt habe ich lange Zeit genutzt, wenn auch mit OpenTX. Wenn es mit EdgeTX ab 2.10.x nicht mehr geht, ist das nicht so schlimm, weil ich auch das Relay nutzen könnte. Solange ich einen SBUS-RX mit S.Port Eingang nutzen kann läuft es hier auf jeden Fall. Dem Kollegen habe ich nun geraten, via Relay zu probieren, wenn das klappt ist es gut, wenn nicht, gucken wir mal weiter.
Deine Aussage verstehe ich jetzt so, dass es über die ganzen Jahre und verschiedenen OpenTX- bzw. EdgeTX-Versionen es durchaus sein kann, dass Telemetrie-IN bei verschiedenen Sendern nicht funktionierte. Ist das so korrekt verstanden? Kann man dazu irgendwo noch etwas nachlesen?
Selbst habe ich erfolgreich mit Horus X10S, Q X7S, X9D+, X9D+ 2019 SE (alle mit OpenTX) und eben der RM TX16S (erst OpenTX, dann EdgeTX) gearbeitet, also schon 'ne größere Auswahl und da gab es keine Probleme. Wobei ich im Rückblick auch nicht mehr sagen kann, wo ein DL nun direkt am Sender hing oder via Relay betrieben wurde.
@FlyingNuri Vielleicht hilft Dir das: https://github.com/EdgeTX/edgetx/issues/5064
FlyingNuri
User
kalle123
User
Interessanter issue. Danke für den Link. Ich hab hier so was in der dort aufgeführten Richtung.
Problem: Das Radiomaster MPM Modul RM 4IN1 will nicht mir meiner FrSky X10S Express.
Siehe hier https://www.rc-network.de/threads/h...aster-4in1-modul-graupner-gr-24-pro.12037537/
Der 'Effekt' zeigt sich ganz gut in den Logic Analyzer Bilder hier
Horus X10S (ACCST) <-> Radiomaster 4in1 Modul <-> Graupner GR-24 Pro
Guten Morgen. Trotz tagelanger Suche im Netz finde ich keine Informationen darüber, ob die oben benannte Kombination in der Praxis tatsächlich funktioniert. Der Hintergrund ist der, das es für mein "altes" System keine neuen Stabi-Empfänger mehr zu kaufen gibt, ich aber einen Systemwechsel...
SPORT kommt nicht in der Kombination X10 <> RM 4IN1.
Bin früher schon mal mit der X10 auf OTX 2.3.15 zurückgegangen und hab jetzt auf Edge 2.8.0 und 2.9.0 zurück, aber das Alles bringt nichts ....
Gruß Kalle
So richtig habe ich noch nicht verstanden was geht und was nicht. Vorab: Mein Verständnis ist, dass DragonLink über SBUS (am CPPM pin) Daten bekommt und Telemetrie mit S.Port Protokoll am S.Port Pin loswerden will. Deshalb wählst Du als externes Modul SBUS an. Soweit richtig?
Wenn ich mir die EdgeTX 2.10 und 2.11 Implementierung anschaue sollte das DL damit funktionieren, aber ohne Telemetrie. Egal ob T15 oder TX16s. Richtig?
Dein Problem ist ein anderes und wahrscheinlich in der HW der X10s begründet. Das MPM bekommt über den CPPM nicht PPM, sondern serielle Daten in einem MPM eigenen Format. Ebenso liefert es serielle Daten in einem eigenen Format (nicht S.Port Protokoll!) am S.Port Pin mit glaube ich 100KBaud ab. Das funktioniert an der TX16s und der T15 usw. einwandfrei.
Mit FrSky Zeug bin ich auf dünnem Eis. Deshalb alles was jetzt kommt ist nicht so wirklich fundiert und ich kann auch total falsch liegen. Korrekturen werden gerne genommen.
Historisch hat FrSky diesen elenden Schwachsinn implementiert die Pegel der seriellen Schnittstelle zu invertieren. Der physical layer des S.Port Protokolls ist active high (= idle low, sieht man auch in Deinem LA Screenshot). Damit ein normaler UART eines Microcontrollers, der idle high erwaretet, damit umgehen kann braucht es Inverter zwischen dem UART und S.Port Pin. Auch die TX16s hat die auf der Platine. Damit man höhere Datenraten fahren kann braucht es entsprechend schnelle Inverter. Und da war FrSky einfach zu geizig ein paar Cent mehr zu investieren. Das ist auch der Grund warum TBS Crossfire oder ELRS Module an manchen FrSky Sendern nicht mit schnelleren packet rates zu betreiben sind, siehe https://blog.seidel-philipp.de/fixed-inverter-mod-for-tbs-crossfire-and-frsky-qx7/
Ob das auch der Grunbd ist warum Dein MPM an der X10s nicht tut weiß ich nicht, kann aber gut sein.
FlyingNuri
User
Korrekt.
Auch korrekt. Die Telemetrie ist aber erwünscht und die funktioniert halt nicht.
Zum besseren Verständnis: der Use-Case ist zwar nicht Mainstream aber durchaus gängig, insbesondere im Ardupilot-Umfeld. Das betrifft nicht nur Dragonlink, sondern auch andere Systeme wie z.B. RFD TxMod. Dieses liefert kein normales S.Port sondern S.Port Passthrough damit das Yaapu Telemetrie-Widget läuft. Das geht mit Dragonlink auch, weil DL ein ESP32 integriert hat, wo man mav2pt installieren kann und DL dann ebenfalls S.Port Passthrough ausgeben kann.
Anstatt nun Dragonlink oder RFD TxMod direkt an den Sender zu hängen, kann man auch einfach einen FrSky-Empfänger nehmen, den SBUS-Ausgang auf die TX-Module legen und von dort die Telemetrie-Daten auf den S.Port des Empfängers geben. Ist auch sehr gängig und läuft mit OpenTX, EdgeTX oder Ethos.
Der o.g. Kollege aus SWE hat es halt direkt am Sender versucht und verwendet auch noch INAV und dann wird es etwas speziell
.Letztendlich müsste EdgeTX "nur" den Telemetrie-Eingang auch dann freischalten wenn für ein externes Modul SBUS oder PPM gewählt wird. Vermutlich hat man sich gedacht, SBUS ist ein reines RC-Protokoll dann braucht man keine Telemetrie. Die Entwickler werden aber eher nicht alle Anwendungsmöglichkeiten im Blickfeld haben oder überhaupt kennen.
FlyingNuri
User
Ich vermute, die haben sich damals an SBUS orientiert und S.Port so implementiert.
Genau so ist es auch in 2.10 und 2.11 implementiert. Wenn Du External RF/Mode SBUS anwählst (und damit EdgeTX sagst dass Du ein SBUS Modul angeschlossen hast) werden nur SBUS Daten ausgegeben. SBUS kennt keine Telemetrie, ist ja kein SBUS2. Und wenn es SBUS2 wäre, könntest Du damit auch nichts anfangen, weil Du ja Telemetriedaten im S.Port Protokoll und nicht SBUS2 Protokoll schickst. Ich denke in OTX und vielleicht auch 2.9. noch war S.Port Protokoll am S.Port Pin ein mehr oder weniger sinnvoller default wenn ein Mode keine eigene Telemetrie definiert hatte. S.Port als Lumpensammler sozusagen. Mit dem internen module port Umbau in 2.10 gibt es keine Voreinstellung mehr. Ein Modul(typ) (= External RF/Mode) definiert wie mit einem externen Modul umgegangen wird. Und das hat entweder Telemetrie oder nicht. SBUS und PPM haben keine Telemetrie (außer PPM/Mlink für externe MLink module). Was es bräuchte wäre einen zusätzlichen Mode SBUS/S.Port zu implementieren der SBUS schickt und SPort Telemetrie empfängt. Oder für andere Basteleien PPM/S.Port.
Muss halt einer machen. Ich habe ähnliches letztes Jahr für MLink gemacht. Mode PPM mit einem Untermenü versehen (No Telemetry und MLink), das im Mlink Modus den Sport Pin nutzt um MLink Telemetrie zu empfangen, um sie danach an den MLink Telemetriedekoder zu schicken (https://github.com/EdgeTX/edgetx/pull/3352).
Und dafür gab es auch keinen guten Grund meine ich. Das ist nur eine Hürde für die Nachbauer und Bastler, die man eingebaut hat.
