MavLink & Frsky Telemetrie (für APM & MPNG)
- Themenstarter kornetto
- Beginndatum
hi,
so sieht die taranis telemetrie anzeige bei mir aus. wolkstein fork mit oder ohne einzelzellenüberwchung bis 6s.
da das script nicht unbedingt zum fpv fliegen gedacht ist habe ich auf eine gauge verzichtet. für mich standen bei diesem skript mehr orientierung und modell kritische werte im vordergrund. vor allen dingen die akku überwachung. dieses skript verwende ich an dem von mir kommerziell genutzten fluggeräten. wir fliegen diese mit entsprechender aufstiegsgenehmigungen auch über bewohnten gebieten oder an filmsets. deswegen kann man mal sagen es handelt sich hier eher um eine etwas drögere optik aber mit den wichtigsten übersichtlich angeordneten infos.
zum schluss noch das radar
edit:
hatte ich vergessen. das script spricht auch die wichtigsten status nachrichten der apm. außerdem fehler zb. pre arm fehler wie sensoren probleme und so etwas eben. wegpunkte in missionen werden auch angesagt.
wer das skript schon verwendet hat bestimmt gemerkt das es gelegentlich beim initialisieren zum script error kam. diesen fehler habe ich nun in der letzten revision behoben.
/g
wolke
so sieht die taranis telemetrie anzeige bei mir aus. wolkstein fork mit oder ohne einzelzellenüberwchung bis 6s.
da das script nicht unbedingt zum fpv fliegen gedacht ist habe ich auf eine gauge verzichtet. für mich standen bei diesem skript mehr orientierung und modell kritische werte im vordergrund. vor allen dingen die akku überwachung. dieses skript verwende ich an dem von mir kommerziell genutzten fluggeräten. wir fliegen diese mit entsprechender aufstiegsgenehmigungen auch über bewohnten gebieten oder an filmsets. deswegen kann man mal sagen es handelt sich hier eher um eine etwas drögere optik aber mit den wichtigsten übersichtlich angeordneten infos.
- A = flugmode, die flugmodi werden auch über den lautsprecher angesagt
- B = Wh füllstands - anzeige, die angezeigte energie menge in wh kann in einem extra model script eingestellt werden. ebenso kann die anzeige in diesen script auch kalibriert werden. so das die wh und mah den werten eurer ladegeräte entsprechen und man so sehr sicher den akku-tank leer fliegen kann ohne das modell oder den lipo zu gefährden.
- C = spannung sender akku
- D = rssi
- E = gesamt zellenspannung des flugakkus, kann wahlweise, im teensy code einstellbar, die mavlink werte verwenden oder die von der einzelzellenüberwachung Teensy A0-A5
- F = strom (Mavlink)
- G = entnahme leistung in watt (Mavlink)
- H = entnommene mah (Mavlink + abweichungs-kalibrierung mittels taranis model script)
- I = entnommene leistung in Wh (berechnet im lua script und kalibrierbar mittels taranis model script)
- J = zellenspannung der niedrigsten lipo zelle. macht sinn wenn die einzelspannung gemessen wird wenn nicht erscheint hier der berechnete einzelzellen wert aus der gesamt akku spannung. die einzelzellen spannung wird auch über lautsprecher wiedergegeben. es kann ein warnwert und ein alarmwert gesetzt werden. zudem kann man einstellen bei welchen spannungsabfall die nächste spannung angesagt wird. zb. alle 0.2 volt. so hat man die zellenspannung gut im gehör
. - K = kompass
- L = barometer höhe in metern W = steigrate "==0 bedeutet keine steigrate
- M = maximal erreichte höhe
- N = zeit im "armed" zustand. model timer 1
- O = geschwindigkeit in km/h
- P = GPS Look
- Q = gps abweichung
- R = anzahl der satelliten
zum schluss noch das radar
- V = ortungs und orientierungs-radar
- S = zur zeit versteckt unter dem modell pfeil ein kreis der den piloten standort darstellt
- T = modell pfeil. dieser kann sich ensprechend der orientierung zum piloten um die eigene achse drehen. außerdem wandert der pfeil innerhalb der viereckigen radar umgrenzung je nach modell ortung umher. das radar stellt dabei automatische zoom werte ein. wenn der pfeil die begrenzung erreicht wird das nächste zoom level eingestellt. kalibriert wird das radar wenn ihr das fluggerät "Armed"(aktiv schaltet). dann wird angenommen der pilot steht HINTER dem modell. ab dem momment der aktivierung(Armed) orentiert sich der pfeil zum piloten. fliegt ihr nach vorne bewegt sich der pfeil nach vorne. seitwärts entsprechend genauso. dreht ihr das modell in der luft dreht sich der pfeil entsprechend. die pfeilspitze stellt dabei die modell nase dar.
- U = luftlinie, pilot -> modell in metern
edit:
hatte ich vergessen. das script spricht auch die wichtigsten status nachrichten der apm. außerdem fehler zb. pre arm fehler wie sensoren probleme und so etwas eben. wegpunkte in missionen werden auch angesagt.
wer das skript schon verwendet hat bestimmt gemerkt das es gelegentlich beim initialisieren zum script error kam. diesen fehler habe ich nun in der letzten revision behoben.
/g
wolke
Zuletzt bearbeitet:
Hilfe,,,
ich versuche seit Tagen ein pro mini 328 mit dem Programm JD IO Board- Frsky MAVlink in Betrieb zu nehmen.
Zusätzliche Hardware USB to TTL Converter.
Das Uploaden steigt immer mit der Fehlermeldung:
aus.
Ich habe auch schon ein zweites Board versucht, mit der gleichen Fehlermeldung.
Im Grätemanager wird com/lpt als fehlerfrei angezeigt.
Wenn mir jemand helfen kann, bin ich sehr dankbar.
Gruß
Peter Thaysen
ich versuche seit Tagen ein pro mini 328 mit dem Programm JD IO Board- Frsky MAVlink in Betrieb zu nehmen.
Zusätzliche Hardware USB to TTL Converter.
Das Uploaden steigt immer mit der Fehlermeldung:
aus.
Ich habe auch schon ein zweites Board versucht, mit der gleichen Fehlermeldung.
Im Grätemanager wird com/lpt als fehlerfrei angezeigt.
Wenn mir jemand helfen kann, bin ich sehr dankbar.
Gruß
Peter Thaysen
Wenn du nur Spannung TX und RX angeschlossen hast, hast du am Schreiben Anfang die Reset Taste gedrückt, ein FTDI macht das ja selber
Was dir angezeigt wird ist nur der Wandler, ob das Board in Ordnung ist kannst du so nicht sehen
Die Fehlermeldung schaut aber auch eher nach Fehler im Programm aus, das es nicht umgewandelt werden kann
Das habe ich auch mit der J_k geänderten er9x Version, die hex kann ich zwar aufspielen, selbst unter Arduino schreiben und Überspielen lassen geht nicht, da mehrere Fehler im Programm sind.
Es werden sicher noch Library fehlen, wo Programmteile drin sein dürften, die angegebenen habe ich allerdings kopiert, als würde da noch was fehlen, was für einige schon im Standardsortiment gehören, und die nicht beachtet wurden
Was dir angezeigt wird ist nur der Wandler, ob das Board in Ordnung ist kannst du so nicht sehen
Die Fehlermeldung schaut aber auch eher nach Fehler im Programm aus, das es nicht umgewandelt werden kann
Das habe ich auch mit der J_k geänderten er9x Version, die hex kann ich zwar aufspielen, selbst unter Arduino schreiben und Überspielen lassen geht nicht, da mehrere Fehler im Programm sind.
Es werden sicher noch Library fehlen, wo Programmteile drin sein dürften, die angegebenen habe ich allerdings kopiert, als würde da noch was fehlen, was für einige schon im Standardsortiment gehören, und die nicht beachtet wurden
Ich habe mal ne frage zu euren GPS Problem
Wo liegt der Fehler genau, ich habe extra die j_k version drauf gespielt und habe es heute getestet
Angezeigt wurden die Koordinaten, leider unter T2 nur "10", keine ahnung was das mir sagen soll, Fix war ja Augenscheinlich da
Als Koordinaten Kontrolle nutze ich "GPS Compass"
https://play.google.com/store/apps/details?id=com.embedia.gps_compass_basic&hl=de
Jetzt das Problem, laut der App war mein Copter in 3.6 Kilometer Entfernung, nehme ich die Koordinaten vom Zaggo/Naza liege ich aber innerhalb der Meßungenauigkeit der 2 GPS Empfänger, also innerhalb von weniger Metern, wenn nicht Teilweise nur cm daneben
Auch bei der Suche von Satsepps Flieger in Verbindung mit dem Frsky Original GPS lag die Genauigkeit sehr hoch
Kann mir das jetzt nur so erklären, das die Angabe der Taranis Richtig war, und ihr die mit Tricks so verdreht habt, das die für euch jetzt Richtig ist, aber im Grunde falsch angezeigt wird, oder habt ihr ne andere Idee?
Ich bin mir nicht Sicher, aber meine auch mal gelesen zu haben, das die Koordinaten Übertragung von Frsky in Dezimal ist, und erst die Taranis/Opentx daraus Sekunden macht.
Dazu ne kleine Offtoppig frage, werde erst morgen das Minimosd einbauen, in Welchen Format wird das im OSD/Mission Planer angezeigt, bzw kann man das Umstellen?
Wo liegt der Fehler genau, ich habe extra die j_k version drauf gespielt und habe es heute getestet
Angezeigt wurden die Koordinaten, leider unter T2 nur "10", keine ahnung was das mir sagen soll, Fix war ja Augenscheinlich da
Als Koordinaten Kontrolle nutze ich "GPS Compass"
https://play.google.com/store/apps/details?id=com.embedia.gps_compass_basic&hl=de
Jetzt das Problem, laut der App war mein Copter in 3.6 Kilometer Entfernung, nehme ich die Koordinaten vom Zaggo/Naza liege ich aber innerhalb der Meßungenauigkeit der 2 GPS Empfänger, also innerhalb von weniger Metern, wenn nicht Teilweise nur cm daneben
Auch bei der Suche von Satsepps Flieger in Verbindung mit dem Frsky Original GPS lag die Genauigkeit sehr hoch
Kann mir das jetzt nur so erklären, das die Angabe der Taranis Richtig war, und ihr die mit Tricks so verdreht habt, das die für euch jetzt Richtig ist, aber im Grunde falsch angezeigt wird, oder habt ihr ne andere Idee?
Ich bin mir nicht Sicher, aber meine auch mal gelesen zu haben, das die Koordinaten Übertragung von Frsky in Dezimal ist, und erst die Taranis/Opentx daraus Sekunden macht.
Dazu ne kleine Offtoppig frage, werde erst morgen das Minimosd einbauen, in Welchen Format wird das im OSD/Mission Planer angezeigt, bzw kann man das Umstellen?
Die GPS Kooridinaten werden bei der alten Version nicht als Grad Minuten sondern als Dezimalgrad übertragen.
Du musst ein anderes Projekt nehmen, das hier scheint 1A zu klappen:
http://fpv-community.de/showthread....-APM-amp-MPNG)&p=671674&viewfull=1#post671674
Nutze ich seit kurzem jetzt auch und bin mehr als zufrieden - Danke j_k für die Anpassungen.
Du musst ein anderes Projekt nehmen, das hier scheint 1A zu klappen:
http://fpv-community.de/showthread....-APM-amp-MPNG)&p=671674&viewfull=1#post671674
Nutze ich seit kurzem jetzt auch und bin mehr als zufrieden - Danke j_k für die Anpassungen.
aargau du hast glaube ich nicht richtig gelesen, genau die Version habe ich auf dem Promini drauf
und genau da liegt meiner Meinung der Knackpunkt, ich meine Dezimalgrad ist Richtig als Übertragung
Allerdings habe ich eben nochmal im gps compass rein gesehen, da wird der letzte Wegpunkt sehr genau auf der Karte angezeigt, fürchte ich habe vergessen das mit eintragen vom nächsten Waypoint der nicht automatisch aktiv ist
Dann könnte es doch passen
Was bleibt ist dann noch die T2 anzeige, läuft die bei dir?
Gibt es eigentlich eine Übersicht der T1 / Flugmodusanzeige, das habe ich bisher nicht gsehen
und genau da liegt meiner Meinung der Knackpunkt, ich meine Dezimalgrad ist Richtig als Übertragung
Allerdings habe ich eben nochmal im gps compass rein gesehen, da wird der letzte Wegpunkt sehr genau auf der Karte angezeigt, fürchte ich habe vergessen das mit eintragen vom nächsten Waypoint der nicht automatisch aktiv ist
Dann könnte es doch passen
Was bleibt ist dann noch die T2 anzeige, läuft die bei dir?
Gibt es eigentlich eine Übersicht der T1 / Flugmodusanzeige, das habe ich bisher nicht gsehen
Sorry, da habe ich wirklich zu ungenau gelesen!
Übertragen vom FrSky Empfänger muss auf jedenfall Grad Minuten werden ( 4732.1245 z.B. ) = 47° 32.1245' (gibt in Dec: 47.535408)
Zum testen / umrechnen habe ich bei meinen eigenen Anpassungen für die Naza Telemetrie diese Seite genommen:
http://www.deine-berge.de/umrechner_koordinaten.php
Ich muss aber zugeben, dass ich die Koordinaten von j_k bis her noch nicht überprüft habe und das mal noch nachholen muss.
Bezüglich T1/T2 habe ich mich nie wirklich darauf geachtet. Für mich waren eig. immer nur Koordinaten + Höhe sowie Spannung und Strom wichtig
Gemäss Code (nur kurz überflogen)
Müsste Aber Temp1 def. der Flugmodus in Zahl sein wie man ihn im APM "definiert".
Temp2 = gpsStatus * 10 + numberOfSatelites;
Also müsste die erste Zahl der Status des Fixes angeben und die 2. Zahl die Sat anzahl.
bei dir wäre "10" also Fix 1 0 Sats, was aber ja nicht zu stimmen scheint.
Werde das sobald ich dazu komme auch mal prüfen und mir sonst den Code auch nochmals genauer ansehen wenn es bei mir auch daneben liegt
Übertragen vom FrSky Empfänger muss auf jedenfall Grad Minuten werden ( 4732.1245 z.B. ) = 47° 32.1245' (gibt in Dec: 47.535408)
Zum testen / umrechnen habe ich bei meinen eigenen Anpassungen für die Naza Telemetrie diese Seite genommen:
http://www.deine-berge.de/umrechner_koordinaten.php
Ich muss aber zugeben, dass ich die Koordinaten von j_k bis her noch nicht überprüft habe und das mal noch nachholen muss.
Bezüglich T1/T2 habe ich mich nie wirklich darauf geachtet. Für mich waren eig. immer nur Koordinaten + Höhe sowie Spannung und Strom wichtig
Gemäss Code (nur kurz überflogen)
Müsste Aber Temp1 def. der Flugmodus in Zahl sein wie man ihn im APM "definiert".
Temp2 = gpsStatus * 10 + numberOfSatelites;
Also müsste die erste Zahl der Status des Fixes angeben und die 2. Zahl die Sat anzahl.
bei dir wäre "10" also Fix 1 0 Sats, was aber ja nicht zu stimmen scheint.
Werde das sobald ich dazu komme auch mal prüfen und mir sonst den Code auch nochmals genauer ansehen wenn es bei mir auch daneben liegt
Die 10 erscheint bei mir immer, auch hier zu Hause wo kein Fix möglich ist, und dann wenn der Fix vorhanden ist
T1 muss feste Werte sein, Stabi habe ich 2 mal (noch Standard, nicht angepasst) und da wird auch gleiche Zahl angegeben, und der Letzte Status ist 16, deswegen wäre ne Nummerierte Statusübersicht nicht schlecht.
Und wie gesagt, wenn ich den letzten Waypoint bei mir anschaue dann stimmt das auch, die 3.6 Kilometer waren sicher zu unseren 2. Flugort, da hatte ich das mit der Naza/Zaggo getestet
T1 muss feste Werte sein, Stabi habe ich 2 mal (noch Standard, nicht angepasst) und da wird auch gleiche Zahl angegeben, und der Letzte Status ist 16, deswegen wäre ne Nummerierte Statusübersicht nicht schlecht.
Und wie gesagt, wenn ich den letzten Waypoint bei mir anschaue dann stimmt das auch, die 3.6 Kilometer waren sicher zu unseren 2. Flugort, da hatte ich das mit der Naza/Zaggo getestet
So eben erneuten Test gemacht
SatFix und Sat Anzahl wird auf Taranis und OSD gleich angezeigt (36-37, schlechtes Wetter)
Keine ahnung warum ich das Vorgestern nicht hatte, oder ob ich das in dem Sturm falsch abgelesen habe
Koordinaten stimmen auch Überein, es geht wohl dann nur um GPS Ungenauigkeiten
Was mich aber noch Stört ist die Distanz, gibt es da eine Lösung die mir die Suche nicht angezeigt hat?
Dachte die wird von der Taranis berechnet, und mit Telemetrie Zurücksetzen könnte ich den Startpunkt neu setzen, angezeigt wurde mir eben fast 4000, denke damit sind 4 km gemeint (letzter Versuchsort war 12.6km laut GPS Kompass entfernt).
Es wurde alles zurück gesetzt, die Anzeige erschien aber sofort wieder (genauen Wert nicht drauf geachtet)
SatFix und Sat Anzahl wird auf Taranis und OSD gleich angezeigt (36-37, schlechtes Wetter)
Keine ahnung warum ich das Vorgestern nicht hatte, oder ob ich das in dem Sturm falsch abgelesen habe
Koordinaten stimmen auch Überein, es geht wohl dann nur um GPS Ungenauigkeiten
Was mich aber noch Stört ist die Distanz, gibt es da eine Lösung die mir die Suche nicht angezeigt hat?
Dachte die wird von der Taranis berechnet, und mit Telemetrie Zurücksetzen könnte ich den Startpunkt neu setzen, angezeigt wurde mir eben fast 4000, denke damit sind 4 km gemeint (letzter Versuchsort war 12.6km laut GPS Kompass entfernt).
Es wurde alles zurück gesetzt, die Anzeige erschien aber sofort wieder (genauen Wert nicht drauf geachtet)
ok, super das es geht. Eigentlich sollte ein Reset der Telemetriedaten auf der Taranis ausreichen. Ab dann berechnet er diese anhand der Koordinaten. Ich muss aber auch sagen, dass das bei mir noch nie (egal welcher Code) so 100% richtig geklappt hat. Hab das aber auch nie weiter angesehen, da es mir nicht wichtig ist
hallo,
also die distanz ("pilot-latitude" , "pilot-longitude") -> ("latitude" , "longitude") ist deswegen ungenau weil die taranis pilot-latitude und pilot-longitude dann festlegt wenn die ersten gps-koordinaten gesendet werden. also recht schnell nach dem einschalten der flugsteuerung am modell. die taranis legt dabei keinen besonderen wert auf genauigkeit. meistens werden ja schon koordinaten übermittelt obwohl das gps noch gar keinen richtigen fix hat. diese werte, also pilot-latitude&pilot-longitude werden scheinbar bis zum nächsten reboot in der taranis gespeichert. keine ahnung ob es sich hierbei um einen bug in opentx handelt. das bedeutet aber telemetrie oder flug resetten überschreibt diese werte leider nicht. deswegen kommt es bei dieser methode immer zu großen ungenauigkeiten. mehr sinn macht es wenn ihr euch ein eigenes script schreibt in dem "eure-pilot-latitude" &"eure-pilot-longitude" in dem moment festgelegt werden, wenn ihr zb. das modell armed. so mache ich das auf jeden fall und habe eine sehr genaue distanz berechnung bzw. anzeige. bei guten gps signal im prinziep auf den meter genau.
edit:
ein beispiel dafür findet ihr hier.
https://github.com/wolkstein/MavLin...playApmPosition/SCRIPTS/Model_Name/telem1.lua
die berechnung der distanz in metern findet von zeile 245 bis zeile 259 statt.
wobei "pilotlat" & "pilotlon" immer dann festgelegt werden wenn die flug-steuerung in den zustand "armed" versetzt wird. zeile 434 & 435.
/g
wolke
also die distanz ("pilot-latitude" , "pilot-longitude") -> ("latitude" , "longitude") ist deswegen ungenau weil die taranis pilot-latitude und pilot-longitude dann festlegt wenn die ersten gps-koordinaten gesendet werden. also recht schnell nach dem einschalten der flugsteuerung am modell. die taranis legt dabei keinen besonderen wert auf genauigkeit. meistens werden ja schon koordinaten übermittelt obwohl das gps noch gar keinen richtigen fix hat. diese werte, also pilot-latitude&pilot-longitude werden scheinbar bis zum nächsten reboot in der taranis gespeichert. keine ahnung ob es sich hierbei um einen bug in opentx handelt. das bedeutet aber telemetrie oder flug resetten überschreibt diese werte leider nicht. deswegen kommt es bei dieser methode immer zu großen ungenauigkeiten. mehr sinn macht es wenn ihr euch ein eigenes script schreibt in dem "eure-pilot-latitude" &"eure-pilot-longitude" in dem moment festgelegt werden, wenn ihr zb. das modell armed. so mache ich das auf jeden fall und habe eine sehr genaue distanz berechnung bzw. anzeige. bei guten gps signal im prinziep auf den meter genau.
edit:
ein beispiel dafür findet ihr hier.
https://github.com/wolkstein/MavLin...playApmPosition/SCRIPTS/Model_Name/telem1.lua
die berechnung der distanz in metern findet von zeile 245 bis zeile 259 statt.
wobei "pilotlat" & "pilotlon" immer dann festgelegt werden wenn die flug-steuerung in den zustand "armed" versetzt wird. zeile 434 & 435.
/g
wolke
Zuletzt bearbeitet:
Verstehe im coden leider sehr wenig, wie wertest du aus, das der Copter gearmt wurde, ich würde das so interretieren das du das über T2 (temp2) machst, leider liefert j_k seine Version kein Arm/Disarm Status, nur Flugmodus
Oder habe ich das übersehen letzte test waren alle disarm da mir nur Satstatus wichtig war
Oder habe ich das übersehen letzte test waren alle disarm da mir nur Satstatus wichtig war
ok,
T2 ist richtig. ich kenne die j_k firmware nicht deswegen kann ich nicht viel dazu sagen.
aber in dem fall kann man zb. einfach einen schalter dafür nehmen um seine lieblings-piloten position zu setzten?
im prinziep ist die verwendung eines schalters noch besser da so die distanz auch noch angezeigt wird wenn du z.b. eine notlandung weit ab von zu hause hattest und das modell automatisch disarmed wird. in dem fall würde bei mir z.b. dann wieder 0 dort stehen.
/g
wolke
T2 ist richtig. ich kenne die j_k firmware nicht deswegen kann ich nicht viel dazu sagen.
aber in dem fall kann man zb. einfach einen schalter dafür nehmen um seine lieblings-piloten position zu setzten?
im prinziep ist die verwendung eines schalters noch besser da so die distanz auch noch angezeigt wird wenn du z.b. eine notlandung weit ab von zu hause hattest und das modell automatisch disarmed wird. in dem fall würde bei mir z.b. dann wieder 0 dort stehen.
/g
wolke
Ich habe mich jetzt zwar durch den Threat gelesen, bin aber irgendwie nicht so viel schlauer als vorher.
Folgende Hardware habe ich:
APM 2.6 mit Spannungsreglermod
ATmega328P Nano V3 Controller Board Compatible Arduino Improved Version
FrSKY X8R
Ist in dieser Kombination der Anschluss über SBUS möglich?
Welche Firmware für den ATmega328P benötige ich? Momentan habe ich die vom ersten Post drauf.
Der Anschluss vom APM zu ATmega ist mir klar, nur der Anschluss vom ATmega zum X8R nicht.
In welchen Kanal muss ich das Anschließen?
Kann ich dann gleichzeitig die Spannungsversorgung vom X8R für den ATmega verwenden, oder soll ich lieber einen 2. uBEC verwenden?
Ich hoffe Ihr könnt mir dabei helfen, da ich gerade echt nicht mehr durchblicke.
Mit nem Teensy 3.1 wäre es wahrscheinlich einfacher gewesen, da gibt es sehr viele Anleitungen dazu...
Folgende Hardware habe ich:
APM 2.6 mit Spannungsreglermod
ATmega328P Nano V3 Controller Board Compatible Arduino Improved Version
FrSKY X8R
Ist in dieser Kombination der Anschluss über SBUS möglich?
Welche Firmware für den ATmega328P benötige ich? Momentan habe ich die vom ersten Post drauf.
Der Anschluss vom APM zu ATmega ist mir klar, nur der Anschluss vom ATmega zum X8R nicht.
In welchen Kanal muss ich das Anschließen?
Kann ich dann gleichzeitig die Spannungsversorgung vom X8R für den ATmega verwenden, oder soll ich lieber einen 2. uBEC verwenden?
Ich hoffe Ihr könnt mir dabei helfen, da ich gerade echt nicht mehr durchblicke.
Mit nem Teensy 3.1 wäre es wahrscheinlich einfacher gewesen, da gibt es sehr viele Anleitungen dazu...
Die sind für die D Serie
Du kannst aktuell nur dieses nehmen
https://github.com/rotcehdnih/Mavlink2Frsky
Für Sbus musst du den Signaleingangschip neu flashen,
http://fpv-community.de/showthread....S-User-(besonders-mit-APM)&highlight=sbus+apm
Du kannst aktuell nur dieses nehmen
https://github.com/rotcehdnih/Mavlink2Frsky
Für Sbus musst du den Signaleingangschip neu flashen,
http://fpv-community.de/showthread....S-User-(besonders-mit-APM)&highlight=sbus+apm
