FRSKY Multiprotokoll-Modul für Taranis und openTxV2.2 mit 4 HF-Chips und Arduino

Im Gegenteil, ist ja das * bessere * Modul, da mehr Speicherplatz.

Hallo,

ich habe das Multiprotokoll Modul 4in1 für die Taranis X7 von Banggood.
Nun wollte ich meinen Flysky Eachine QX95 binden was ich leider nicht hinbekommen habe:-(
Ich denke das liegt an dem AFHDS 2A Protokoll dass das Multiprotokoll Modul wohl nicht hat.
Gibt es da eine Möglichkeit das AFHDS 2A Protokoll nachträglich aufzuspielen?
Das AFHDS funktioniert dagegen Problemlos.

Gruß
Roger

Je nachdem welches von den beiden Modulen Du hast, suche Dir das passende Video zum Firmware-Upgrade bei https://www.rcgroups.com/forums/showthread.php?2165676-DIY-Multiprotocol-TX-Module aus und spiele die passende Version von https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/releases auf. Laut den Hinweisen sollte das AFHDS2A seit der letzten Version 1.1.6 funktionieren.

Gruß Matthias

Hallo Matthias,

vielen Dank, sieht aber reichlich kompliziert aus
Leider fehlt mir auch ein Programmer dafür.
Schade.

Gruß Roger

Diese usbasp, oder ftdi Adapter kosten etwa 5 €
So kompliziert ist das gar nicht

OK

Würde dieser passen: https://www.amazon.de/gp/aw/d/B00AF...r=8-14&pi=AC_SX236_SY340_QL65&keywords=usbasp

Gruß
Roger

Welches Modul hast du denn?

Dieses: https://www.banggood.com/de/IRangeX...-Module-With-Case-p-1139049.html?rmmds=search

Das IRangeX IRX4.

Ja, ich glaube das dürfte funktionieren

Dann werde ich mir das mal bestellen

Habe mir jetzt mal das Video für "STM32 flashen" auf rcgroups angeschaut. Wäre das so überhaupt nötig wenn ich das "precompiled" Multiprotocol_V1.1.6_STM32_INV.bin von der Seite https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/releases nehme?
Auf dieser Seite https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Compiling_STM32.md ganz unten ist der Flashvorgang für "precompiled binaries" beschrieben.
Das "Multiprotocol_V1.1.6_STM32_INV.bin" ist ja "precompiled" so wie ich das verstehe.

Würde das dann so funktionieren bzw. reicht das aus?

Ist in der "Multiprotocol_V1.1.6_STM32_INV.bin" alle anderen Protokolle welche aktuell schon drauf sind, auch mit vorhanden!?

Kenne mich halt mit den Sachen leider nicht aus:-(


Gruß
Roger

Ich weiß nicht warum dein Modul Upgrade möchtest. Laut Bangood ist auf deinem. Protokoll die Version vom 19.12.2016 drauf. Das ist die aktuelle. Desweiteren mehrmals in roter Schrift :
Upgraded STM32 board,all protocols are included.

Hast du ne aktuelle Version auf deiner Taranis?
Ich kann das Protokoll bei meiner auswählen

Ich habe so einen Empfänger nicht hier, aber das sollte es wohl sein

Du bist mein Retter
Hast mein Modul sicher vor dem Flashtod bewahrt!

Mir hat das "FS 2A" nichts gesagt und habe mich immer am "Flysky" Protokoll versucht.

Vielen Dank für Deine Mühe, funktioniert jetzt bestens!

Gruß Roger

Sehr gerne doch

Ja, die Länge der Strings ist da arg knapp. AFHDS2A ist einfach zu lang

Default channel order, wenn du das eh die Firmware updatest, kannst du jede Variante kaufen

DSM2 Kanal Zurodnung durcheinander

Mein Multiprotocol-Modul in STM32-Ausführung ist auch mittlerweile angekommen. Da ich versuche alle Modelle mit der Zeit auf OpenTX umzustellen, dachte ich, dass ich mit etwas einfachem anfange. Ein paar DSM2 "Altlasten" habe ich noch, die von dem Modul angesteuert werden sollten. OpenTX 2.2 (final) ist auf einer X9D+.

Spektrum hat ja eine Kanalzuordnung von TAER. Mode 1 ist in den Sender-Grundeinstellungen ausgewählt.

Die RX-Ausgänge sind TAER gesteckt. Wenn ich jetzt den DSM2-Rx mit dem Modul binde, bekomme ich aber eine ETAR Reihenfolge (Gegentest mit Mode 2 ergibt TEAR). D.h. der Mode ändert das Mapping und das Mapping scheint zudem noch die falsche Reihenfolge (CH2 und CH3 getauscht) zu haben.

Das wäre alles nicht weiter schlimm, wenn nicht die alten Empfänger den Failsafe-Wert beim Binden übertragen würden. Allein diese Kleinigkeit kann zum Anlaufen des Motors führen !

Ich kann jetzt die Zuordnung anpassen und auch mit angepasstem Gasknüppel und Höhenruder binden, aber diese Problematik kommt mir von Deviationtx irgendwie bekannt vor. Dort war, ich glaube mich zu erinnern, vor ca. 2 Jahren ein ähnliches Problem, was zu einer kompletten Überarbeitung des Codes geführt hat.

Hat jemand das gleiche "Problem" oder mache ich einfach etwas falsch?

Gruß Matthias

Das Modul mappt intern von AETR auf TAER, d.h. entweder Sender auf AETR programmieren oder Modul neu flashen und dem Modul dabei sagen, dass der Sender TAER sendet.

Danke, nee, auf neu flashen und davor noch kompilieren habe ich (noch) keine Lust. Aber so ist es klar.

Ich hatte mich noch ein wenig gewundert, da der Bindevorgang wohl anders gemappt ist als die normale Übertragung. Beim Binden muss Querruder für Gas gehalten werden um Failsafe zu programmieren.