Fragen zum NMEA Protokoll

Yves E. Gast #6342521
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Yves E. Gast #6342577
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
STK500-Besitzer Gast #6342847
Lesenswert?
• ▲
▼ 
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".
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Yves E. Gast #6342889
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren