Neue Übertragungswege für den MyFlyDream AAT Auto Antenna Tracker
- Themenstarter Rangarid
- Beginndatum
- Status
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...
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:
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.
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.
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:
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.
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
##############################################################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:
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.
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.
Hott benutzt 1-Wire. Glaub kaum, dass das mit dem BT Modul geht. Da müsste man was zwischenbasteln oder so. Aber es benutzt auch TTL, vielleicht gehts ja doch wenn man nur lauschen möchte...
http://jlog.hacknet.eu/jlog2/faq/artverwandt-graupner-hott-technische-hintergrundinfos/
Kann aber auch z.B. mit Arduino verarbeitet werden:
http://playground.arduino.cc/Learning/OneWire
Ist wohl aber etwas mehr Aufwand...
http://jlog.hacknet.eu/jlog2/faq/artverwandt-graupner-hott-technische-hintergrundinfos/
Kann aber auch z.B. mit Arduino verarbeitet werden:
http://playground.arduino.cc/Learning/OneWire
Ist wohl aber etwas mehr Aufwand...
Zuletzt bearbeitet:
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
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:
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???
).Hab grad noch das Video gesehen. Sieht gut aus...Ihr glücklichen HoTT Leute...warum kann FrSky nich auch 19200baud holen???
Zuletzt bearbeitet:
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.
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:
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.
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.
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:
Die Stringklasse nimmt ganz schön viel Platz weg...wird noch ersetzt durch char array
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);
Zuletzt bearbeitet:
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.
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
