Hallo Claus,
das sieht doch schon mal ganz gut aus! Jetzt wissen wir zumindest, dass abgesehen vom Protokoll, der Tracker richtig konfiguriert ist, die Hardware-Schnittstelle stimmt usw.
Wenn du die HOME Taste drückst, sollte der Tracker dem virtuellen Flugzeug auch folgen - eine nette Schreibtisch-Spielerei
Fragt sich also, was genau aus deinem Sender herauskommt und warum der Tracker das nicht versteht. Ich bin leider in der Interpretation der Daten auch nicht so fit, was mir aber aufgefallen ist, ist z.B. dieses Zeichenfolge:
Code:
5E12310000007E7EFE62D33879000000007E7EFD061E5E1A0B265E137E7EFD041E08005E1B5E137E7EFE62D43A79000000007E7EFD061F37205E
Wenn man weiß, dass Userdata immer mit 5E beginnen und enden sollten, kann man das ganze etwas lesbarer umbrechen:
Code:
5E12310000007E7EFE62D33879000000007E7EFD061E
5E1A0B26
5E137E7EFD041E0800
5E1B
5E137E7EFE62D43A79000000007E7EFD061F3720
Und jetzt verlässt es mich. Da sind mir zu viele 7E (Beginn und Ende eines gesamten Frames) und zu wenige 5E (Beginn und Ende der reinen Messdaten innerhalb des Frames drin. Die reinen Messdaten wären, meinem Verständnis nach
Code:
5E 12 31 00 00 00
5E 1A 0B 26
5E 13
5E 1B
5E 13
Bedeutet
LAT vor dem Punkt: 31 00 00 00
LAT nach dem Punkt: 0B 26
LON vor dem Punkt: nix
LON nach dem Punkt: nix
Man müsste diese Bytes jetzt noch auswerten/umrechnen, um eine vernünftige GPS-Position daraus erkennen zu können, aber da mMn die Info über LON komplett fehlt, hat das wenig Sinn, sich darüber den Kopf zu zerbrechen.
Aber, das alles ist meine vorsichtige Interpretation und daher ohne Gewähr. Ich fürchte, du müsstest mal jemanden fragen, der das Protokoll besser verstehen kann.
Nachtrag: du könntest mal ausprobieren, ob die Darstellung der einzelnen Datenpakete in HTerm lesbarer wird (soll heißen, sinnvolle Zeilenumbrüche erzeugbar sind), wenn du für "Newline at" und/oder "Newline after ...ms receive pause" etwas einstellst. Wir wollen Zeilen, die nach Möglichkeit mit "7E" anfangen und enden.