Hallo! Ich arbeite aktuell an einem GPS Tracker der seine Daten per LoRa an einen ESP32 sendet der die GPS Daten dann wiederrum an mein Handy überträgt. Sieht dann also etwa so aus: GPS Modul mit LoRa Sender -> LoRa Empfänger mit ESP32 und BT -> Handy mit Bluetooth GPS App Folgendes Problem tritt auf, obwohl die ausgewählten Sentences (GGA, RMC, GSA) fehlerfrei übertragen werden und vom Telefon empfangen werden (kann ich mit der App im BT Terminal einsehen), kann das Telefon damit nichts anfangen. Wenn sich mein Handy mit dem ESP verbindet, dann wird sofort alles aktualisiert, also Uhrzeit Position, GEschwindigkeit usw. aber danach kommt keine aktualisierung. Ich dachte erst, es läge an den Intervallen in denen gesendet wird, da der GPS Tracker ja stromsparend sein muss, werden nur ca. alle 20 Sekunden Daten gesendet und habe die mal runtergeschraubt, aber Fehlanzeige, keine Besserung. Wenn ich die GPS Daten so wie sie vom Modul kommen auslese (GPS direkt am ESP) und 1:1 per BT weiterleite, funktioniert alles tadellos. Kann das vielleicht an der langsamen Übertragung liegen? Gibt es bei NMEA Timeouts? Die niedrigste spezifizierte Baudrate liegt ja bei 4800b/s, ist das vielleicht das Problem? Ich hab auch schon versucht, auf dem ESP zu puffern und die gepufferten Sentences immerwieder rauszusenden, bis neue per LoRa eintreffen, aber Fehlanzeige.
Yves E. schrieb: > Wenn ich die GPS Daten so wie sie vom Modul kommen auslese (GPS direkt > am ESP) und 1:1 per BT weiterleite, funktioniert alles tadellos. Dann liegt es wohl kaum an NMEA. Deine LoRa-Verbindung zickt rum.
Aber die Sentences kommen fehlerfrei an, somit kann es nicht an der LoRa Verbindung liegen und am BT auch nicht. EDIT: Ok, echt schräg, ich habe nun mal im Code des ESP statt der write() Methode, der ich den Pointer zum schreibenden puffer und dessen Größe übergeben habe, die print() Methode verwendet. Plötzlich funktioniert es tadellos... Tatsächlich war das auch ein Unterschied zu vorher als ich das Modul direkt am ESP hatte. Merkwürdig, vielleicht hat der Interpreter auf dem Telefon ein Problem damit, wenn er mehr als ein NULL bekommt. Die Sentences sind ja nicht immer gleich lang, daher habe ich vor dem beschreiben des Puffers diesen immer mit memset(puffer, '\0', 82) mit NULLs beschrieben. print hört ja beim ersten \0 mit dem ausgeben auf. Das ist meines Wissens hier der einzige Unterschied. Wieder was gelernt. Ich denke das Problem ist damit gelöst.
Yves E. schrieb: > Die Sentences sind ja nicht immer gleich lang, daher habe ich vor dem > beschreiben des Puffers diesen immer mit memset(puffer, '\0', 82) mit > NULLs beschrieben. > print hört ja beim ersten \0 mit dem ausgeben auf. Das ist meines > Wissens hier der einzige Unterschied. > Wieder was gelernt. Ich denke das Problem ist damit gelöst. Die Sentences enden mit <CR><LF> (in C-Nomenklatur "\r\n"). Vielleicht wurden die "verschluckt".
Dachte ich auch erst, aber das kann eigentlich nicht sein. Ich habe eine Methode geschrieben, welche anfängt ein char array mit den ankommenden Daten vom GPS Modul Byteweise zu beschreiben, sobald ein "$" oder "!" kommt. Das wird dann solange fortgesetzt bis der line feed kommt, da habe ich zum vergleichen den Hexwert 0x0A verwendet. Hätte man natürlich auch mit "\n" machen können, aber das hat ebenso gut funktioniert. Das \n muss angekommen sein, sonst hätte beim Empfänger nicht mit jedem neuen Sentence eine neue Zeile begonnen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.