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

[DerCamperHB]

Nur kommst du mit einem Master Modul wohl nicht mit einem Handy drauf, oder hast du das schon versucht, ich nutze das bisher nur als Brücke, ist deswegen falscher Stecker dran

 

[Rangarid]

Naja, wenn du 1 Master und 1 Slave hast brauchst du kein Handy, weil du ja ne direkte Verbindung zwischen Driver und Funke hast.

 

[DerCamperHB]

Das ist mir klar, nur wollen ja einige noch zusätzlich vom Handy auf die Funke und auf dem ATT
Wie ist das eigentlich mit dem Schnitstellenverteiler, laufen die alle auf die gleichen RX/TX auf, oder sind da mehrere, ansonsten würde das anshcliessen vom BT und GPS gleichzeitig keinen Sinn ergeben, und genau dafür ist doch der Verteiler
oder kann das BT dann nur Senden, vom GPS wird nur Empfangen?

Ansonsten könnte man ja das BT Slave am ATT fürs Handy vorsehen, und zusätzlich ein Master mit Logindaten für Senderslave, da kann dann halt nur mit Handy drauf, wenn der ATT nicht läuft

 

[muerzi]

@Rangarid: am besten du erstelltst ein gerüst, und ich bastel das hott dazu. Danach können wir nach wunsch ausbauen

 

[Rangarid]

Camper...du willst also 3 Bluetooth Module betreiben, dazu den RC-Funk (der bidirektional ist, was nicht ganz unbedeutend ist) und dann noch den Videofunk drüber...meinste nicht, dass selbst 2 BT Module schon eigentlich zuviel sind für sowas? Eventuell wird das was an der Funke grad so noch ankommt ja schon durch das BT beeinflusst, also sollte man da so wenig Störquellen wie möglich haben.

Meiner Meinung nach läuft das so: Wer Telemetrie will nutzt BT. Wer Telemetrie und Tracken will nimmt ein Kabel und BT für Telemetrie. Wer nur Tracken ohne Telemetrie will kann 2x BT benutzen, was aber zu testen wäre, ob BT nicht den Rückkanal beeinflusst.

@Rangarid: am besten du erstelltst ein gerüst, und ich bastel das hott dazu. Danach können wir nach wunsch ausbauen

Dann sag mir wie du dir den Aufbau vorstellst, dann kann ich dir sagen wie ich es haben will

 

[DerCamperHB]

Vorteil ist, selbst wenn der Empfang weg ist, kann nach dem nächsten Datenempfang wieder getrackt werden
Wenn du über Audio Daten übermittelst, darf die Verbindung nicht abreissen.
Das hat mich bisher von dem Tracker abgehalten, die Wahrscheinlichkeit ist wohl nicht groß, sonst würden sich Einige drüber aufregen, aber die Gefahr ist mir einfach zu groß
Bei Frsky bekommst du einfach sicher die Daten übertragen, und müssen "nur noch" an den Tracker übergeben werden.

 

[Rangarid]

Es ging nicht darum das Audio auszutauschen, weil es unsicher ist, sondern mit dieser Methode auch die Übertragung von anderen OSDs und Autopiloten zu ermöglichen. Also z.B. dass man mit dem APM tracken kann oder eben einfach nur über FrSky mit GPS am Empfänger oder eben über HoTT. Das sind alles Sachen, die man grad da hat und wenn man z.B. einen APM drin hat ist ein TFOSD einfach überflüssig, wenn man schon das MinimOSD benutzt.

Wenn du bei Audio ein Paket verlierst nimmst du einfach das nächste. Das geht solange bis du garkeinen Empfang mehr hast. Das dürfte dann ungefähr da sein wo der Empfangskegel deiner Antenne so groß ist, dass es keinen unterschied macht ob du fürs wenden mal 10m oder eben 200m brauchst. Also keine Panik. Selbst mit Audio kommt man weit genug. Und mit HoTT oder FrSky wirst du auch nur richtig weit kommen, wenn du das Sendemodul mit auf den Tracker packst und zum Empfangen eine Patch nimmst. Bringt sonst nämlich eigentlich nur im Nahbereich <2km was. Und bis dahin sollte Audio locker reichen.

Hier geht es also nicht darum etwas auszutauschen was unsicher erscheint - denn die Funktion des AATs über Audio ist ja bereits bekannt. Im übrigen benutzt das EzOSD ebenfalls Audio, das RVOSD Video und das EagleTree auch Audio. Wenn alle Audio benutzen (außer RVOSD Video, was aber vom Prinzip fast aufs gleiche rauskommt) kann es doch nicht so schlimm sein, oder?

 

[Rangarid]

Hm ich dachte ET benutzt auch Audio...naja egal .

Hm, du meinst also es wäre besser, statt am Boden alternative Empfangswege zu basteln, lieber etwas zu bauen, was man in den Flieger legt?
Würde natürlich auch gehen, dann kann man das Audio beibehalten und trotzdem mehrere verschiedene OSDs nutzen. Dafür müsste man halt ein Audiomodem basteln. Schade, dass es das minimale Audiomodem von MFD nichtmehr gibt.

 

[muerzi]

Ich send die gps daten mit hott zu boden. Vorteil: kein gerümmpel im fluggerät. Auch das osd is am boden. Muss man nicht ständig umbauen. 1 arduino und 1 gps im flieger reichen voll aus. Alles andere geschieht am boden...

 

[Rangarid]

Ich mach erstmal die Android App fertig. Sobald Version 1 verfügbar ist warte ich erstmal die Verbesserungsvorschläge und Bugs ab und in der Zeit kümmere ich mich dann hier drum. Sollte so in den nächsten Tagen fertig sein.

 

[Rangarid]

So, die BT App ist vorerst fertig...packen wirs an.

Mein Vorschlag wäre einfach am Driver das NMEA Protokoll zu implementieren. Dann kann man durch welchen Übertragungsweg auch immer einfach das GPS übertragen. Bei FrSky wär das recht einfach, da man 1:1 NMEA übertragen kann, bei HoTT müsste man einen NMEA String erstellen, aber mürzi wollte ja eh einen Arduino dazwischen haben.

Ich würde also vorschlagen mürzi du erstellst eine Arduino Firmware, die GPS von Hott ausliest und daraus einen NMEA String erzeugt. Wir brauchen GPGGA und GPRMC. Alle anderen NMEA-Strings sind überflüssig. 5Hz sollte reichen.

 

[muerzi]

Ich würde also vorschlagen mürzi du erstellst eine Arduino Firmware, die GPS von Hott ausliest und daraus einen NMEA String erzeugt. Wir brauchen GPGGA und GPRMC. Alle anderen NMEA-Strings sind überflüssig. 5Hz sollte reichen.

GPGGA und GPRMC lassen sich prima erzeugen.
Eventuell nicht in allen Details (HDOP usw), aber die daten die du brauchst sind ja nur koordinaten und höhe.

 

[Rangarid]

Richtig und Geschwindigkeit. Ich kuck später nochmal im Detail was genau ich brauche.

Also ich brauche im Detail
Lat
Lon
Speed
Kurs
Alt

Die Checksum musst du natürlich auch erzeugen, damit es kompatibel bleibt zu andern GPS-Übertragungen.

Hm, da fällt mir grad ein...wenn wir NMEA als Input wählen dann kann der Driver kein MFD-Protokoll mehr ausgeben für die App...Ist also dann nichtmehr kompatibel zur Android App. Ich frag mal ob wir das MFD-Protokoll benutzen dürfen. Ist auch sehr simpel.

 

[Rangarid]

Ok ich hab das Go bekommen, das MFD Protokoll sieht so au:

//0xCC | 0x?? 0x?? 0x?? 0x?? | 0x?? 0x?? 0x?? 0x?? | 0x?? 0x?? | 0x??                                              | 0x??       | 0x?? | 0x?? 0x?? | 0xCC
//start| lat                 | lon                 | alt       | sat (4bit) NS(1) EW(1) home set(1) course high(1) | course low | speed| check sum | end

Start 0xCC
Lat 4 Byte
Lon 4 Byte
Alt 2 Byte
Sats 4 bits
NS 1bit
EW 1 bit
home set 1 bit
course HIGH 1 bit
course LOW 1 byte
speed 1 byte
checksum 2 byte
end 0xCC

Wenn wir das nehmen, können wir die Daten direkt in den MFD machen ohne die Firmware zu ändern. Es muss lediglich der 0Ohm Widerstand entfernt werden.

 

[ApoC]

Das wäre perfekt.

Was sagt Charles eigentlich zu unseren Ideen? Ich mein, er findets bestimmt cool, das wir uns soviele Gedanken machen, oder?

 

[Rangarid]

Ka, er findets jedenfalls gut, dass wir auch andere Übertragungswege reinbauen wollen, davon profitiert er ja auch. Aber was im Detail wir jetzt hier reden erzähl ich ihm nicht. Erst wenn was bei rumgekommen ist

 

[muerzi]

So. Ein netter Kollege hilft mir die Kommunikation zwischen Smartbox und Funke zu belauschen. Bin schon neigierig auf die logs...

 

[Rangarid]

Ich bekomm die Tage den Quellcode wie man ein MFD-Paket erzeugt...Dann haben wir ja quasi alles zusammen.

 

[wortex343]

Also es geht bei der Methode nur 115,2k, weil die Funke die Daten intern so verarbeitet. Nur am Data Pin, da müssen 19,2k sein. Und da muss man auch requesten. Zb mit Arduino / Smartbox. Bei Smartbox könnte man das BT Modul mit einschleifen, da muss es dann aber auf 19,2k stehen.

Anhang anzeigen 57131


Ob es an der Stelle auch mit 19,2k Baud geht, muss ich noch testen. Aber dieses WE nimmer, muss morgen früh raus. Muss dazu das BT Modul auf 19,2k stellen und die App kann man auch einstellen.

Wenn man das BT Modul intern verbaut, so wie ich, braucht man nix requesten, zumindest nicht mit der App, die macht das alleine. Aber man muss RX und TX vom BT Modul anschliessen, denn die Handy App schickt ein 0x80 zur Funke - darum brauchen wir auch TX. Die Funke antwortet dann mit den entsprechenden Daten, die die App anfordert. Verhält sich dann ja auch quasi wie die Smartbox / ein Request.

Da man die entsprechenden Meldungen ja einzeln in der App einstellen / auswählen kann, werde ich mitm Serial Port Monitor mal mithören und kann so jeden Request aufspüren.

Zumindest habe ich jetzt alle Daten der Sensoren aufm Handy per BT. Habe nur n GAM und den RX. GPS Daten habe ich noch keine, da ich noch kein DIY GPS gebaut habe.

Hier das Anschlusschema.

Anhang anzeigen 57119 Anhang anzeigen 57120 Anhang anzeigen 57121 Anhang anzeigen 57122

Hoffe man erkennt was.

Die beiden kleinen Platinen sind im rückwärtigen Deckel. Einmal die USB Schnittstelle und einmal die DSC Buchse + Data Port. An dem klauen wir uns auch die 5V für das BT Modul.

Ist aber eher suboptimal - ich bevorzuge lieber die "muerzi Variante", am Data Pin mit Arduino.
So muss man nix löten.

Verdammt, ich glaube, meine MX 16 Hott ist hinüber. Ich habe sie nach Apoc´s Anleitung verkabelt, noch extra mit dem Multimeter geprüft und dann den Akku angeschlossen und den Sender eingeschaltet.

Seit dem blinkt die Hott beim Einschalten nur noch vor sich hin, selbst ausschalten lässt sie sich nicht mehr.

Bitte helft mir!

Herzlichsten Dank im Vorraus!
Tom

 

[ApoC]

Hey Tom

Das klingt natürlich nicht gut. Prüfe bitte, ob du nicht irgendwo einen Kurzschluss drin hast.

PS: Ich habe eine MX-20. Vielleicht ist der Kontakt für das BT Modul bei der MX-16 anders. (Was ich mir aber nicht vorstellen kann)