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

Rangarid

Erfahrener Benutzer
#21
Checksum: unsigned int, 0 to 255. calculated by the row in front of all the characters in the ASCII encoding as an 8-bit unsigned integer one by one sum, save the results to an 8-bit unsigned integer, intermediate overflow discarded.
 
Zuletzt bearbeitet:

nachbrenner

Erfahrener Pfuscher
#22
Meine Interpretation: Einfach alle zu übermittelnden ASCII-Werte in einen unsigned int addieren. (Klar läuft der dann über aber das ist dem C-Compiler wohl egal, der macht dann einfach wrap-around, also z.B. 250 + 10 = 4)
 

muerzi

Erfahrener Benutzer
#26
Ein paar Datensätze währen wohl ganz hilfreich... um den Pfad der Vermutung verlassen zu können
 
Zuletzt bearbeitet:

nachbrenner

Erfahrener Pfuscher
#28
Von was braucht ihr den Mitschnitt? Das was via Audio-Modem in den Driver kommt oder Driver<->Trackingeinheit?

Auf welchem Pin kann man den Datenstrom abgreifen, welche serielle Geschwindigkeit / Datenbits / Stoppbits / Parität? Woran erkennt man den Start eines neuen Pakets?

(Billig-Logic-Analyser nebst Software hätte ich hier)
 

Rangarid

Erfahrener Benutzer
#29
Geschwindigkeit 19200, Daten von dem Kabel, dass zum Stecker geht der in den AAT geht wo CTRL dran steht (im Driver). Das müssten genau die Daten sein die wir brauchen.

8bit, 1 stop, kein parity.
 
Zuletzt bearbeitet:

nachbrenner

Erfahrener Pfuscher
#30
Also die Verbindung vom Driver zur schwarzen Trackingeinheit? Und auf der Driver Platine steht da irgendwo CTRL dran und den pin dann sniffen?

19200 müsste mein Bus Pirate noch hinbekommen. Ich schaue heute Abend mal, wenn dann würde ich euch ein capture-file im OLS Datafile Format liefern, analysieren müsstet ihr dann selbst.
 

muerzi

Erfahrener Benutzer
#31
Also die Verbindung vom Driver zur schwarzen Trackingeinheit? Und auf der Driver Platine steht da irgendwo CTRL dran und den pin dann sniffen?

19200 müsste mein Bus Pirate noch hinbekommen. Ich schaue heute Abend mal, wenn dann würde ich euch ein capture-file im OLS Datafile Format liefern, analysieren müsstet ihr dann selbst.
Ja die Verbindung vom Driver zur Trackingeinheit.

Das wär toll wenn du das machen könntest.

BTW: hast du zufällig eine NAZA Gps? Wär auch interessant das mal zu reversen. (Wo wir schon dabei sind)
 

Rangarid

Erfahrener Benutzer
#32

Rechte Seite orangenes Kabel. Ob die Farbe dann bei dir auch so ist kann ich dir aber nicht sagen. Es sollte reichen, wenn du uns einen Ausschnitt aus einem Serial Monitor gibst.
 

nachbrenner

Erfahrener Pfuscher
#35
Danke, melde mich falls es etwas wird - wenn dann klappt es heute Abend.

Naza-GPS habe ich leider nicht. Würde auf SPI oder seriell NMEA (mit Heading-Sequenz vom Kompass) tippen - aber hätte wäre wenn ...
 
Zuletzt bearbeitet:

nachbrenner

Erfahrener Pfuscher
#36
So ganz kapiere ich nicht warum ihr das Protokoll Driver<->Tracker ansehen möchtet: Hat Rangarid nicht geschrieben, dass er die Firmware des Drivers bekommt? Da ist dann ja der relevante code drin.

Soweit ich das schnalle ist die aktuelle Richtung:

An den Driver anstatt des Ground-GPS die Ausgabe eines GPS-Moduls das im Flieger ist anschließen. Die Driver-Firmware so umbiegen, dass sie da halt keine Ausgabe vom Ground-GPS erwartet sondern das als Flieger-GPS nimmt. Dazu noch kleinere Übersetzungsaufgaben zwischen den Formaten erledigen.

Oder ist die Driver-Firmware nicht vorhanden und das Ziel ist die Firmware des Drivers komplett neu zu schreiben? Falls das der Fall ist dann wird das schon sportlich, zum Reversen des kompletten Protokolls Driver<->Tracker braucht wohl einer von euch einen Tracker. Ich kann hier und da mal ein snifflog liefern, mehr geht aber zeitlich bei mir nicht.
 

Rangarid

Erfahrener Benutzer
#37
Ich glaube wir wollten ein paar Datensätze haben, um zu gucken, ob das mit der Checksum richtig ist. Selbst wenn man einen Arduino an den Driver macht um die Daten reinzugeben braucht man ja das Protokoll...
 

muerzi

Erfahrener Benutzer
#38
Ich seh das so.
Der Austausch zwischen Tracker und Driver ist deswegen interessanter weil man einen driver v5 entwickeln könnte der die RC Telemetrie beherrscht. Dazu werden sicher änderungen am Layout des Drivers notwendig sein aber es ist zukunftssicher(er).

Edit: ich denke da an anschlüsse für telemetrie (sind meines wissens alle 1wire) und bluetooth für kabellose telemetrie
 

Rangarid

Erfahrener Benutzer
#39
Für BT bidirektional müsste man das Audiomodem abklemmen.

Auf dem Driver ist ein Atmega162, im Arduinoforum gibt es dafür einen Bootloader, man könnte also auch eine neue Driverfirmware in Arduino schreiben, dann wäre das Upgraden und Anpassen der Firmware an die eigenen Bedürfnisse einfacher...
 
RCLogger

FPV1

Banggood

Banggood

Oben