Habe in der "History" nix Passendes gefunden, auch Gugel mit "NMEA-Zeilenlänge" bringt kein brauchbares Ergebnis: Wie lang (Zeichenzahl incl. \r\n) können die Standard- NMEA-Zeilen maximal werden? Das wären $GPGGA, $GPGSA, $GPRMC, $GPVTG und $GPGSV. Bin ich mit 128 Byte für den Zeilen-Puffer auf der sicheren Seite? Ich möchte mit einem Tiny84 die Daten eines GPS-Moduls auswerten und anzeigen. Konkret: Es soll eine kompakte "Uhr" für Hobby-Astronomen werden, die wichtige Daten für die Sternbeobachtung anzeigt: - Geograf. Position - Datum und Zeit UTC - daraus berechnet: - Julianisches Datum - kulminierende Rektaszension (örtl. Sternzeit) Der knappe Speicherplatz und SW-USART ist die GEWOLLTE Herausforderung! Auch sonst sehe ich keine unlösbaren Probleme, also brauche ich keine Tipps für Handy-Apps (es soll auch im "Nirgendwo mit Himmelssicht" funktionieren), oder "bessere" Hardware etc. Vielen Dank für sachdienliche Antworten, oder auch Anregungen!
Hey, ich hab mich damals daran gerichtet: http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf (also quasi für die einzelnen Pakete die maximale anzahl gezählt). Bin mir aber auch nicht sicher ob das verlinkte PDF die absolut maximale Anzahl beinhaltet. Gruß,
So eine FiFo ist doch nur dafür da, dass keine Zeichen verloren gehen. Also reichen 16 Bytes aus. Das Protokoll ist hinreichend bekannt; # http://www.kowoma.de/gps/zusatzerklaerungen/NMEA.htm Man baue sich einen endlichen Automaten, der deine angegebenen Prefixe erkennt und die nachfolgenden Daten auswertete. $GPGGA, $GPGSA, $GPRMC, $GPVTG und $GPGSV Ich lese nur aus dem FiFo ein Byte, das wird dann in einem DEA ausgewertet und so der gesamte Datensatz analysiert.
Jakob schrieb: > Wie lang (Zeichenzahl incl. \r\n) können die Standard- > NMEA-Zeilen maximal werden? Der NMEA 0183 Standard sagt: "A sentence may contain up to 80 characters plus "$" and CR/LF". > Wie lang (Zeichenzahl incl. \r\n) können die Standard- > NMEA-Zeilen maximal werden? > Das wären $GPGGA, $GPGSA, $GPRMC, $GPVTG und $GPGSV. In wie weit das von einzelnen Sentences ausgenutzt wird, lässt sich schlecht sagen, weil schon von Empfänger zu Empfänger z.B. Unterschiede in der Auflösung der Positionsdaten bestehen.
Endlicher Automat, DEA? Habe - ehrlich gesagt - keine Lust eine "Zustandsmaschine der theoretischen Informatik" zu bauen. Es soll doch NUR praktisch funktionieren und in einen Tiny84 passen. - HW-FiFo ist bei SW-USART auch nicht so DAS Stichwort... @ Tim (Gast) und @ Wolfgang (Gast) Dankeschön! Genau das, was ich brauche :-). Demnach sind 128 Byte Puffer eher verschwenderisch (max. 83), als ausreichend!
Jakob schrieb: > Dankeschön! Genau das, was ich brauche :-). Demnach sind > 128 Byte Puffer eher verschwenderisch (max. 83), als > ausreichend! Du brauchst genau eine Pufferlänge von 80 Zeichen. Der Rahmen mit "$" bzw. "!" und <cr><lf> dient nur der Synchronisation und ist im Puffer überflüssig. Bzgl. der Länge muss ich mich noch korrigieren. Die Längenangabe hatte ich aus einer - wie sich bei genauerer Recherche herausstellt - fehlerhaften Sekundärquelle (S.2 "3. General Sentence Format"). http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf In der Ausgabe NMEA 0183 Standard For Interfacing Marine Electronic Devices Version 3.01 January 1, 2002, die man mit Google (nicht Gugel) findet, ist auf S.13 unter "5.3 Sentences" noch ein Zeichen weniger genannt, i.e. als Pufferlänge sollten, inklusice "\0" 80 Zeichen reichen, wenn man "$" und <cr><lf> nicht mit in den Puffer übernimmt. ("The maximum number of characters in a sentence shall be 82, consisting of a maximum of 79 characters between the starting delimiter "$" or "!" and the terminating <CR><LF>.")
Und was haelt dich davon ab, nicht den gesammten String zu speichern, sondern sofort zu verarbeiten ? Die Bytes kommen ja langsam genug. Allgemein... Hoert doch endlich mal mit diesem Tiny Scheiss auf. Die paar Cents die man am Controller gegenueber einem Mega spart, sind nun nicht wirklich der Bringer. Bei einen Stueckzahl von 100'000 aufwarts macht's ja Sinn zu optimieren. Aber bei Kleinserien bringt's nichts.
:
Bearbeitet durch User
Jakob schrieb: > Endlicher Automat, DEA? > Habe - ehrlich gesagt - keine Lust eine "Zustandsmaschine > der theoretischen Informatik" zu bauen. Es soll doch NUR > praktisch funktionieren und in einen Tiny84 passen. Dir ist schon klar dass Du alleine zum korrekten Parsen von NMEA einen solchen Automaten programmieren musst? Ein Zustandsautomat sieht in C übrigens ungefähr so aus:
1 | switch(zustand) { |
2 | |
3 | case ZUSTAND_1: //... |
4 | if (Bedinging) zustant = ZUSTAND_2; |
5 | break; |
6 | |
7 | case ZUSTAND_2: //... |
8 | break; |
9 | // [...]
|
10 | |
11 | default: ; |
12 | }
|
Man sollte Fachbegriffe vorher ansehen bevor man damit um sich wirft.
Jakob schrieb: > Dankeschön! Genau das, was ich brauche :-). Demnach sind > 128 Byte Puffer eher verschwenderisch (max. 83), als > ausreichend! Jein, das ist die Länge einer Zeile... Aber die Zeilen kommen, zumindest bei den Neo 6M Modulen die ich verwende, nie alleine, sonder gleich drei Stück. hintereinander. Das wäre nicht das Problem, wenn a) der UART einen eigenen FiFo Puffer hätte, und b) Der ATTiny die empfangene Zeile vor dem Beginn des Empfang der nächsten Zeile ausgewertet hätte... Aus eigener Erfahrung mit dem Bau eines GPX Logger, würde ich die einen FIFO Ringpuffer vorschlagen und den ATTiny, sobald ein Zeichen empfangen wurde, damit beginnen dieses direkt auszuwerten... Bei mir waren das so ab 160 Zeichen, wenn ich mich recht erinnere. Ich habe aber auch einen ATMega644 dafür eingesetzt, da war der RAM verbrauch nicht ganz so kritisch und der zweite UART hat den Empfang doch sehr erleichtert. Hier ist wie schon oben beschrieben, eine Zustandsmaschine recht hilfreich, die den Stand der Zeilenauswertung bis zum derzeitigen Zeichen vermerkt. Wichtig ist die CRC über die empfangene Zeile zu bilden, damit man fehlerhafte Daten verwerfen kann!
Wenn Du es nicht änderst, kommen die Daten mit 9600 Bd, also seeehr langsam. Außerdem interessiert man sich normalerweise nicht für alle Sentences bzw. Fields darin. Deswegen kann man mit einem Automaten direkt parsen und nur aus den interessanten Sentences die interessanten Werte speichern (ggf. auch nur als Ascii und später parsen). So ein Protokolladapter macht hier wie in vielen anderen Fällen Sinn. Und ja, es ist ein DEA ...
Jakob schrieb: > Endlicher Automat, DEA? > Habe - ehrlich gesagt - keine Lust eine "Zustandsmaschine > der theoretischen Informatik" zu bauen. Das Schöne ist, wenn man sich mit diesen Dingen etwas auskennt, fallen solche Problemlösungen extrem leicht ;-)
Und wenn nicht, kopiert man sich wenigstens was Schlaues ab, statt nochmal den üblichen Anfängermurks zu fabrizieren.
Endlicher Automat.. Irgendwie bekomm ich das nicht in mein Deutsch integriert. Muss ja auch nicht. Die NEO-6M können auch noch ganz andere Geschichten mit dem UBX Protokoll.. da wird nicht einfach rausgehauen, man fragt es selbst ab.
Ich würde mir erstmal einen NEMAParser ziehen und denn für mein Zielsystem kompilieren lassen.
Reiner_Gast schrieb: > Jein, das ist die Länge einer Zeile... Aber die Zeilen kommen, zumindest > bei den Neo 6M Modulen die ich verwende, nie alleine, sonder gleich drei > Stück. hintereinander. Von den Puffer wird mal wohl entweder zwei verwenden (einen aktiven Empfangspuffer und einen für die Bearbeitung) oder man organisiert ihn als Ringpuffer. Das entspannt die Sache, wenn man sequentiell auswertet. Wilhelm M. schrieb: > Wenn Du es nicht änderst, kommen die Daten mit 9600 Bd, also seeehr > langsam. Es sei denn, es handelt sich um ABM oder BBM Sentences, die meist nach NMEA 0183-HS mit 38.400kBd übertragen werden.
M.N. schrieb: > http://www.kowoma.de/gps/zusatzerklaerungen/NMEA.htm Was hilft jetzt dieser Link auf eine unvollständige NMEA-Beschreibung?
Jakob schrieb: > Der knappe Speicherplatz und SW-USART ist die GEWOLLTE > Herausforderung! Eine GEWOLLTE Herausforderung. Aha. Wenn das SO ist, dann solltest du deine eigene Herausforderung auch SELBST annehmen und nicht andere Leute damit auf Trab halten wollen. Für mich klingt das nämlich ziemlich daneben. W.S.
Warum wird denn hier gleich säuerlich reagiert, wenn man eine KONKRETE Frage stellt und sich mehr für die Antwort, als für "MACHT MAN ABER SO" interessiert? Noch mal vielen Dank für die schnellen hilfreichen Antworten! @ W.S. (Gast) Wenn du die simple Frage (Zeilenlänge) mitten am Tag (14:22) noch nicht einordnen konntest, dann tut es mir leid, dass du dich dummerweise damit auf Trab gebracht fühltest. - Passiert mir auch manchmal, aber eher vor 07:00... ;-) - Und: Mutti hat doch gesagt: Guck nicht so viel µC.net, wenn es dich sooo aufregt!
Ach, übrigens: Letztes Wochenende (ausnahmsweise gutes Wetter) bin ich mit meinem Fernrohr und der selbst gebauten Sternzeituhr in das störlichtarme Havelland gefahren. Sternzeituhr eingeschaltet: Nach < 2 Minuten konnte sie die geogr. Koordinaten, UTC und die daraus berechnete Sternzeit (kulminierende RA - ortsabhängig!) anzeigen. Fernrohrausrichtung nach einem bekannten Stern mit seinen Himmels-Koordinaten war damit NULL Problem und Langzeit- Sternfeldaufnahmen sehr erfolgreich. Nichts gegen "endliche Automaten" - aber klar definierte Ziele lassen sich nun mal auch auf adäquat minimalisierter HW-Basis lösen.
Hallo, ich wüßte jetzt auch nicht, warum das nicht in einen Tiny84 passen sollte. Wenn es in Deinem Programm irgendwo Funktionen gibt, die Abhängig von angekommenden Daten diese Bearbeiten, hast Du soweiso schon einen "endlichen Automaten" oder eine "Statemachine" eingebaut... Die Unart, auf eine konkrete Frage (Länge der NMEA-Pakete) mit Grundsatzdiskussionen zu reagieren, hat leider nicht nur in diesem Forum über die Jahre stark zugenommen. Gruß aus Berlin Michael
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.