Neue Übertragungswege für den MyFlyDream AAT Auto Antenna Tracker

Status
Nicht offen für weitere Antworten.

Rangarid

Erfahrener Benutzer
#1
Da mit dem neuen V4 Driver die Möglichkeit besteht, GPS und Bluetooth am Driver anzuschließen, besteht nun auch die Möglichkeit, andere Quellen für das Tracking zu verwenden. Dies ist vorallem für diejenigen von Vorteil, die starke Probleme mit der Übertragung über das Audiosignal haben.

Eine weitere Möglichkeit, die sich dadurch auftut, ist die Nutzung des AAT (meiner Meinung nach der Tracker mit dem Besten Konzept) zusammen mit dem APM, Telemetriesystemen wie HoTT und FrSky oder allem anderen was Daten übertragen kann. Man kann also die im Flieger vorhandenen Systeme nutzen, ohne noch zusätzlichen Kram reinmachen zu müssen. Das MFD OSD ist dadurch nicht mehr Pflicht.

Folgende Möglichkeiten sind mir bisher durch den Kopf gegangen:

3DR Funkmodul für APM - benötigt Mavlink-fähiges Gerät im Flieger mit GPS - 433Mhz
FrSky Telemetrie - benötigt GPS und Sensor Hub - 2.4Ghz
HoTT Telemetrie - benötigt GPS - 2.4Ghz
OpenLRS - benötigt GPS - 433Mhz

Bei FrSky und HoTT könnte man die benötigten Daten per Bluetooth an den Driver übertragen. Dazu braucht man ein BT-Modul an der Funke und eins am AAT Driver.
Das 3DR Modul könnte man direkt am Driver anschließen. Der Vorteil am 3DR ist, dass man das Empfangsmodul mit einer Richtfunkantenne ausstatten kann - wenn das Modul nur als Empfänger genutzt wird - und damit bestimmt nie den Empfang verliert. Nachteil ist aber, dass man entweder einen APM/Clone/Mavlink-unterstützende Flightcontrol hat oder einen Arduino der GPS auslesen und das 3DR Sendemodul bedienen kann.
OpenLRS is ne Mischung aus 3DR und FrSky/HoTT, GPS kann direkt am Empfänger angeschlossen werden.

Jede Lösung hätte so seine Vor- und Nachteile. Eine perfekte Lösung, die garkeine Nachteile hat ist mir bisher aber noch nicht eingefallen. Vielleicht hat ja jemand noch andere Ideen.

Bisher gibt es für die oben genannten Methoden keine Plug&Play Version (eigentlich auch keine Bastellösung). Ich stehe aber in Kontakt mit Charles von MyFlyDream und habe Zugriff auf das Protokoll zur Steuerung des Trackers. Jetzt haben wir für eine der oben genannten Ansätze folgende Möglichkeiten:

1. AAT Driver Firmware so umschreiben, dass sie die Methoden oben unterstützt
2. Einen Arduino oder sonstwas an den Port hängen, der die Methoden unterstützt und in das umwandelt, was der AAT Driver versteht.

Nachteil an Nr. 2 ist, dass der Arduino 2 serielle Ports haben muss, einen für Daten an AAT und einen für Telemetrieeingang. Die kleineren Arduinos aber haben alle nur einen Seriellen Port.

Optimal wäre also Lösung 1. Hier muss ich mal kucken, ob ich vielleicht Erlaubnis von Charles bekomme, die Firmware umzuändern.

Ich kann nicht versprechen, dass nachher alles so funktioniert, aber alternativen zur Audioübertragung hören sich natürlich nicht schlecht an.


Vorerst bitte ich euch also, nicht nach einer fertigen Lösung zu fragen, sondern eher Ideen beizusteuern, wie das ganze möglichst einfach realisiert werden kann, damit jeder damit klarkommt. Oft ist es ja so, dass man selber die einfachste Lösung übersieht ;).


Falls es zu einer Implementierung einer oder aller dieser Features kommen sollte würde ich mich über eure Unterstützung freuen. Ich brauche folgende Komponenten, damit ich überhaupt mit einem Versuch anfangen kann:
1x RC305 (habe zur Zeit nur einen Empfänger in der Fatshark eingebaut)
1x Helix passend zu den CL/SPW von Rabe [>6 Turn]
Falls jemand was davon hat macht mir einfach mal ein gutes Angebot. Spenden sind natürlich auch gern gesehen :)
 

Anhänge

Zuletzt bearbeitet:

ApoC

Moderator
#2
Coole Idee. Abo!

Ich bin dann dein Tester. ;)

Bei mir wäre das dann die HOTT Variante. Der Rückkanal und BT in der Funke klingt gut.
 

muerzi

Erfahrener Benutzer
#3
Hab zwar den tracker nicht, könnte aber helfen die firmware für hott zu erweitern.

2Uart brauchst du nicht. Mein DiyHoTTGps kommt auch nur mit einem aus und klappt wunderbar.
 

Rangarid

Erfahrener Benutzer
#4
Hab zwar den tracker nicht, könnte aber helfen die firmware für hott zu erweitern.

2Uart brauchst du nicht. Mein DiyHoTTGps kommt auch nur mit einem aus und klappt wunderbar.
Wie soll das dann gehen? Irgendwo kommen die Daten an, werden verarbeitet und wieder ausgegeben. Der Eingang und Ausgang kann ja nicht identisch sein...

Einzige Möglichkeit wäre doch dann RX zur Funke und TX zum Driver. Würde bei FrSky funktionieren. Bei HoTT auch?
 
Zuletzt bearbeitet:

ApoC

Moderator
#5
Ich glaube muerzi meint den UART dort, wo die GPS Daten erzeugt werden. Rangarid meint aber den Arduino am Boden, der ja auf einem UART die GPS Daten empfängt - verarbeitet - und sie dann auf dem 2. UART an den Tracker / Driver übergibt. Beikspielsweise über Bluetooth.
 

muerzi

Erfahrener Benutzer
#6
Bei meinem Projekt funktionierts so: GPS Daten kommen bei der Uart an, Daten werden verarbeitet und dann über einen Pin (Softserial TX Pin) ausgegeben. Die zweite Uart (ausgabe via SoftSerial) erfolgt auf einem beliebigen Pin.

Bei diesem Projekt kann man das selbe Schema anwenden.
Daten werden von der Uart empfangen, verarbeitet und über einen Beliebigen Pin (SoftSerial TX) an den Driver übergeben.
 

nachbrenner

Erfahrener Pfuscher
#7
Genau, mit der Softserial-Lib braucht es keine zwei UARTS, habe die selbst schon öfters genutzt, geht super:

http://arduino.cc/en/Reference/SoftwareSerial

Am einfachsten wäre wohl einen Arduino vor den Driver zu Klemmen der dann idealerweise alle dreimMöglichkeuten (APM, Hott, Frsky) unterstützt.

Ich hatte den Driver mal ferngesteuert indem ich einfach ein Telefly am Boden direkt dran geklemmt habe. Dann konnte ich dem Telefly normal GPS-Daten wie sie die Module senden vorgeben. Deine Methode jetzt ist aber natürlich einfacher :)
 
Zuletzt bearbeitet:

Rangarid

Erfahrener Benutzer
#8
Ah stimmt die gibt es ja auch noch...Hatte ich ganz vergessen. Ging aber frueher nur mit wenig Speed. Jetzt scheint mehr zu gehen.

Womit hast du deine Daten übertragen, nachbrenner?
 
Zuletzt bearbeitet:
#10
Methode 2 ist doch viel einfacher und man kann den Altbestand schützen ;) . Einfach nen 128er Atmega oder gleich nen Xmega verwenden un ab gehts. Da kann man sogar dann das OSD wegfallen lassen und das GPS direkt an den AVR hängen.

Software Uart würde auch gehn, nimmt aber etwas Programmperformance weg
 

Rangarid

Erfahrener Benutzer
#11
Ok ich bekomm die Driver Firmware. Das ist natürlich noch besser, da das ganze dann Plug&Play bleibt.

Es sollte auch kein Problem sein, ein BT Modul an die älteren Driver anzuschließen, falls das deine Sorge war ;)
 
Zuletzt bearbeitet:

ApoC

Moderator
#13
Oh man, ihr seid Spitze. ;)

Wenn das klappt, AAT Daten vom Flieger über HOTT - das ist n Meilenstein. ;)

EDIT: Nochmal ne Frage zum Verständnis. Sendet das TFOSD die GPS Daten einfach roh runter oder bearbeitet es die noch?

Also könnte man ja muerzi´s DIY HOTT GPS nehmen und am Boden dann das andere Zeugs.
 
Zuletzt bearbeitet:

DerCamperHB

Erfahrener Benutzer
#14
FrSky ist auf jeden Fall nicht unwichtig, fliegen ja auch einige hier
Wäre es evtl möglich einen Freihes Protokol mit zu Integrieren, oder auch die älteren FrSky Protokolle zu berücksichtigen?
Im Bixler nutze ich den Flytron Simple OSD V2, mit FrSky Telemetrieausgabe, also eigentlich Perfekt, nur leider gibt das nur das erste Protokol aus, ist schon mit den aktuellen Softwaren nicht mehr Kompatibel, leider ist auch kein Update dafür geplant (schon angefragt)

Wenn die Firmware schon überarbeitet wird,ist auch eine Nutzung mittels Rssi Tragging geplant, um mal andere Fluggeräte zu Folgen, die nicht entsprechend ausgerüstet sind (auf Treffen usw)
 

Rangarid

Erfahrener Benutzer
#15
Rssi war nicht geplant. Kann aber irgendwer mal machen wenn Bedarf besteht. Ich machs jedenfalls nicht.

Ich habe mir das ganze so gedacht, dass die einzelnen Protokolle alle die Selbe Struktur haben:

Daten auslesen
Aus den Daten die für den AAT wichtigen Daten erzeugen
Daten an AAT senden

Wie die drei Teile im einzelnen Softwaretechnisch gelöst werden, kann jeder selbst entscheiden. Wichtig ist nur, dass die Daten am Ende der drei Teile so ist, wie sie der Rest des Programms haben will. Das Programm an sich läuft also immer und dann muss man sich nur selber um das Protokoll kümmern.
Ich denke jedes einzelne Protokoll was es gibt zu implementieren wäre etwas aufwendig und vorallem auch garnich zu testen, da man als Entwickler ja meistens auch nur ein System benutzt. Aber jeder der sich beteiligen möchte ist natürlich gerne gesehen. Gegen eine kleine Spende wird der ein oder andere Entwickler vermutlich auch Protokolle mit reinnehmen die sonst nicht den Weg zum AAT finden würden ;).
 

muerzi

Erfahrener Benutzer
#16
Wie Kommuniziert der AAT Driver denn mit dem Tracker? Servosignale, Serial 1Wire, I2C? Im Tracker (das Teil das sich dreht) wird ja auch elektronik stecken oder?

Lg
 

Rangarid

Erfahrener Benutzer
#17
Seriell nur mit der TX Leitung vom Driver glaub ich. Ich bin grad an der Übersetzung dran. Dafür braucht man keinen chinesischen Übersetzer :D
 
Zuletzt bearbeitet:

muerzi

Erfahrener Benutzer
#18
Send mir die Doku bitte wenn du fertig bist. Meine Mail schick ich dir per PN. Hast du schon die Firmware für den AAT Driver?
 

Rangarid

Erfahrener Benutzer
#19
Nein die Firmware kommt im laufe des Tages. Eine Sache ist noch rätselhalft an der Doku, es wird eine Checksumme berechnet, um die Daten die zum AAT gehen zu überprüfen. Leider kann ich aus der Übersetzung heraus nicht feststellen, wie er das macht, da muss ich ihn dann persönlich noch fragen.

Rest ist aber schon fertig. Wenn ich das mit der Checksum dann hab schick ich dir die Doku.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten