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

Status
Nicht offen für weitere Antworten.

ApoC

Moderator
#61
Bitte bedenken, beim Foxtechsender auch Poti und Mikro auszulöten, sonst is Essig mit Audio.
 

Rangarid

Erfahrener Benutzer
#62
Richtig das stimmt. Wenn weiterhin Audio genutzt werden soll muss der ab. Für diejenigen, die aber eben diese anderen Übertragungswege nutzen möchten kann das Mikro vorerst dranbleiben.

Habe mir nochmal genauer die seriellen Schnittstellen angeschaut. Charles hat das wie folgt gelöst:

UART1 ist zuständig für das Audiomodem und die Ausgabe der GPS-Daten über Bluetooth:
-RX1 empfängt Daten vom Modem
-TX1 sendet Daten (anscheinend 1:1) ans BT Modul
Baudrate 1200bps bedingt durch das Audio Modem

UART0 ist zuständig für ein externes GPS und für die Übertragung der Daten an den AAT:
-RX0 empfängt Daten [hier können wir z.B. unsere Daten einspeisen]
-TX0 sendet die Daten zum AAT
Baudrate 19200 oder 38400, default 19200 aber 38400 wenn GPS angeschlossen. Der AAT geht dann anscheinend in den "High Speed Mode", wie man dem AAT das aber sagt ist mir nicht bekannt (steht nicht im Protokoll). Das muss ich noch in Erfahrung bringen.

Das Fazit daraus ist, dass wir entweder nur Daten per 19200baud empfangen können, oder das Audiomodem entfernen/Leiterbahn trennen müssen um UART0 nutzen zu können.

FrSky, 3DR Radio/Mavlink und NMEA über was auch immer geben die Daten aus, ohne dass man nach bestimmten Daten fragen muss. Bei diesen dreien ist es also kein Problem, einfach nur RX0 zu benutzen. Problem hier ist aber die Baudrate...

Bei Hott muss mandie Daten anfordern wenn ich das richtig verstanden habe. Das könnte man machen, indem man die Baudrate von UART1 hochsetzt, mit TX1 sendet und mit RX0 das Ergebnis empfängt. Dann bekommt man zwar keine Daten mehr vom Audiomodem, weil die Baudrate falsch ist, aber wenn man RX1 eh nicht auswertet ist das auch nicht schlimm...
 
Zuletzt bearbeitet:

muerzi

Erfahrener Benutzer
#63
Bei hott müssen die daten angefordert werden. Ist richtig.
Allerdings übernimmt diesen Part ja die funke und die daten müssen vom treiber nur "mitgelauscht" werden. Ob mit kabel oder bt is dabei egal

EDIT: hast du schon die driver firmware rangarid?
 

Rangarid

Erfahrener Benutzer
#64
Ja aber ich darf die nicht weitergeben.

Ok dann geht bei HoTT quasi auch einfach lauschen wie bei den anderen Protokollen.

Jetzt haben wir nurnoch das Problem, dass der Driver mit 19200 empfängt, und FrSky auf 9600 sendet. Wieviel macht HoTT?
 

Rangarid

Erfahrener Benutzer
#66
Also wenn man das original BT Modul benutzt muss man laut Helmut auch Daten anfordern...Hast du schon ausprobiert ob der einfach so Daten ausspuckt?

Hm...naja sieht so aus als müsste man Audio doch kappen wenn die Baudrate nicht 19200 entspricht...Ist ja blöd.
 
Zuletzt bearbeitet:

ApoC

Moderator
#67
Wie man Driver und Tracker in den Highspeed Mode / GPS Mode versetzt, steht im Handbuch.

EDIT: Wie das geht, sieht man in den Videos.

https://www.youtube.com/user/MyFlyDream/videos?view=0

Da sind die beiden Videos dazu.

EDIT2: Wir sollten auch drauf achten, das einige auch ein GPS am Driver haben, nicht das wir diese Schnittstelle dann blockieren.
 

muerzi

Erfahrener Benutzer
#68
Ja, die daten müssen angefordert werden stimmt. Hatte nen denkfehler. Müsste alles mit uart1 laufen. Dazu muss man halt das modem ic abklemmen.
 

Rangarid

Erfahrener Benutzer
#69
Hm das ist blöd, ich denke die meisten wollen sich diese Option offen lassen, falls das nicht ganz dem entspricht was man sich vorher vorgestellt hat...

Wenn man Audio abklemmt hat man dafür aber den Vorteil, dass man sämtliche Baudraten einstellen kann, die man für irgendwelche Protokolle benötigt...Dann kann man GPS anstecken UND die bevorzugte Übertragungsmethode nutzen.

Eventuell können wir ja ein paar alte Driver bekommen. Die werden eh nichtmehr verkauft und da wäre die Modifikation nicht schlimm...

Ich habe schonmal für den Atmega162 alles zusammengestellt, damit man ihn mit Arduino benutzen kann:
Anhang anzeigen atmega162.rar
Einfach irgendwohin entpacken, denn ordner "hardware" in den Arduino Ordner kopieren (überschreiben des Ordners bestätigen) und die Datei <arduino>\hardware\arduino\boards.txt mit folgendem Text erweitern:
Code:
##############################################################

atmega162.name= ATmega162

atmega162.upload.protocol=arduino
atmega162.upload.maximum_size=14336
atmega162.upload.speed=57600

atmega162.bootloader.low_fuses=0xFF
atmega162.bootloader.high_fuses=0xD8
atmega162.bootloader.extended_fuses=0xFB
atmega162.bootloader.path=optiboot
atmega162.bootloader.file=optiboot_atmega162.hex
atmega162.bootloader.unlock_bits=0x3F
atmega162.bootloader.lock_bits=0x0F

atmega162.build.mcu=atmega162
atmega162.build.f_cpu=16000000L
atmega162.build.core=arduino
atmega162.build.variant=atmega162

##############################################################
Nur für Entwickler geeignet zu diesem Zeitpunk!!!

Ich arbeite gerade an einem Grundgerüst für den AAT Driver wo grundlegende Sachen wie Pindefinitionen, LED Blinken, Kommandos usw. drin sind, sodass man quasi nurnoch das einlesen der Daten implementieren muss. Wenn ich soweit fertig bin werde ich die Firmware hier hochladen. Dann kann jeder sein Protokoll implementieren wie es gewünscht ist.
 
Zuletzt bearbeitet:

ApoC

Moderator
#70
Hab heute, auf der Suche nach einer BT Alternative für meine MX-20 gelesen, das jemand ein stinknormales BT Modul an den Datapin (Da wo die Smartbox drankommt) gehangen hat (natuerlich VCC und GND auch verbunden). BT Verbindung zum PC hat da wohl geklappt. Ohne löten, einfach mitm Servokabel. 19,2k Baud, denke ich mal müsste man am BT Modul einstellen, sagte muerzi ja schon, das HOTT so schnell sendet.

Bin leider auf Baustelle und kanns nicht testen. Kann das mal wer probieren?

Aber wenn das so ginge, haette man die GPS Daten ja quasi verfügbar. Die Frage ist, ob die Daten noch verarbeitet werden müssten, oder ob der Driver rohe GPS Daten versteht.
 

Rangarid

Erfahrener Benutzer
#71
Zuletzt bearbeitet:

ApoC

Moderator
#72
Nee, ich hatte beim Flashen der Funke mit FTDI auch schon Erfolge, indem ich RX und TX einfach verbunden habe. Dann wars nurnoch eine Wire.

Spielt aber keine Rolle in unserem Fall, da die Funke eh nur Daten sendet und mit dem DIY BT Modul nix empfängt.

Also brauch man am BT Modul nur TX. Zumindest liest sich das so, das zwischen dem BT Modul und der Funke nix extra dazwischen ist. (http://www.flugsachen.de/178-hott-bluetooth)

Aber muerzi hat doch schon am RX espielt. Das dürfte doch am Sender ähnlich sein.

Man, ich muss nach Hause, muss das ma testen. ;)

http://www.youtube.com/watch?v=IGSm0KtcKU4&feature=youtu.be
 
Zuletzt bearbeitet:

Rangarid

Erfahrener Benutzer
#73
Also wenn es tatsächlich so ist, dass du nur das RX vom Bluetooth anschließen musst dann hast du natürlich Glück und die Variante ist ultra einfach. Das kann ich dir in einem Tag dann machen (oder mürzi ;)).

Hab grad noch das Video gesehen. Sieht gut aus...Ihr glücklichen HoTT Leute...warum kann FrSky nich auch 19200baud holen???
 
Zuletzt bearbeitet:

ApoC

Moderator
#74
Ja, man sollte bedenken, das er keine MX-20, sondern ne ältere Funke hat, mit HOTT Modul.

Erstmal testen, kann sein, das am Datapin der neuen HOTT Sender nix anliegt - Zumindest solange nicht, wie man nix anfordert. Jemand hatte auch geschrieben, sich in den Weg Smartbox <--> Funke mit einem Y Kabel "reingehackt" hat, mit einem BT Modul only, also ohne Arduino usw.

Kann also sein, das man dochn Arduino brauch, da die Smartbox ja Daten anfordert, die man belauschen kann. Ohne Smartbox / Arduino wird da sicher nix passieren.

Kann das erst nächsten Mittwoch testen, denn erst ab da bin ich wieder zuhause. Hab zwar meine Funke und Flieger mit auf Baustelle, aber das BT Modul nicht. ;)
 
Zuletzt bearbeitet:

ApoC

Moderator
#77
Muerzi - dann wäre es ja mal cool, zu wissen, ob man an der Funke am Datapin auch "anfordern" muss, was eigentlich so sein muesste, da da sonst ja die Smartbox dranhängt, die ja auch anfordert.

Ich kanns leider noch nicht testen, da ich nicht zuhause bin.

1. Ich sah Infos, das es an einer MX24s mit nachgerüstetem HOTT Modul mit BT only am Datapin ging
2. Jemand anderes schleifte sich zwischen Funke und Smartbox ein
3. Der Dritte im Bunde hatte es intern verlötet

Wir müssten erstmal eine diese Möglichkeiten gegentesten, bevor wir da weitere Schritte planen.

Was sagt Graupner an der Funke? Muss man da auch anfordern? Wenn ja, wieso funzt es dann bei jemandem mit BT only an der Funke? Verhalten sich Nachrüstmodule anders? Haben die mehr / andere Pins an die man "ran kann"?

An der Funke müsste der Datapin ja 5V Pegel haben, am RX ist es ja nur 3,3V.

Am RX muss man ja auch "Bescheid sagen", das man Daten senden will. Du hast den Code ja geschrieben für dein DIY GPS. WIe genau funzt das am RX? Könnte das an der Funke auch so sein?

Man müsste mal ein Testprogramm haben, für den Arduino, um mal zu gucken, was da rauskommt an der Funke.
 

Rangarid

Erfahrener Benutzer
#79
Dank dem Log von nachbrenner hab ich auch endlich rausgefunden wie das mit der Cheksum läuft. Hier mal ein Stück Code damit man es leichter versteht:
Code:
String s = CMD_DISTANCE + dist + CMD_ALT + alt + CMD_AZIMUTH + azi;

uint8_t cs = 0;
for (int i = 0; i < s.length(); i++)
{
    cs += s.charAt(i);
}
//s = D***H***A*
Serial.println(s + '*' + cs);
Die Stringklasse nimmt ganz schön viel Platz weg...wird noch ersetzt durch char array :)
 
Zuletzt bearbeitet:

Rangarid

Erfahrener Benutzer
#80
So und schon ist das ganze als char array. Damit hab ich schonmal mindestens 1kb gespart.

Eine positive Nachricht gibt es auch noch, der Driver hat ein 0Ohm Resistor, der die Datenleitung vom Audio Modem mit dem Controller verbindet. Wenn man diesen Widerstand auslötet dann gibt das Modem keinen Mucks mehr von sich und man kann die zweite Serielle schnittstelle nutzen, ohne das Modem abzuklemmen. Später wenn man Audio wieder haben will kann man einfach nen Lötpunkt drauf setzen und das ganze wieder verbinden.

Habe grad mal den original Code von Charles in Arduino probiert:
Binäre Sketchgröße: 14.746 Bytes (von einem Maximum von 15.360 Bytes)

Da sind viele Sachen drin, die wir für unsere Firmware nicht brauchen (z.B. die Auswertung des Audiomodems, Ausgabe der GPS-Daten vom Audiomodem usw). Ich werde das ganze mal etwas in Arduino-Style umbauen und dann kucken wir mal weiter. Von der Größe her jedenfalls gibt es keine Probleme.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten