GPX-/GPS-Logger

Ich hätte übrigens auch noch geringe Anzahl Platinen für den Logger 
übrig. Bei Interesse bitte melden.

Gruß
Arne

Hallo,

hab die bei HAKA als XXS Zwilling fertigen lassen und habe 8 Platinen 
für insges. 48€ bekommen. Ich würde sie für 6€/Stück plus Porto abgeben.

Grüße
Arne

ja, sind noch welche da. Bitte kurze Mail.

@Johannes: Fotos der Platine kann ich morgen noch mal posten. Sonst 
evtl. mal das Layout mit Eagle ausdrucken und testen. Zumindest der 
SD-Sockel von Pollin passt.

Gruß
Arne

@ado: ja, im GPX kann man sogenannte Waypoints speichern, allerdings nur 
außerhalb einer Trackaufzeichnung. D.h. entweder müsste man die 
Trackaufzeichnung kurz unterbrechen, einen Waypoint speichern und danach 
einen neuen Track beginnen. Oder man könnte innerhalb eines Tracks 
bestimme Trackpoints gesondert markieren.

hier nochmal wie versprochen ein Foto beider Platinenseiten (das Kriseln 
sind keine Fehler in der Platine, sondern JPG-Artefakte). Die Rückseite 
habe ich an zwei verschiedene SD-Kartenhalter angepasst, einer davon der 
von Pollin für 1,50€.

Hallo,

die SW läuft bei mir mit mehreren verschiedenen Karten, hatte aber keine 
Karte < 1GB zum Testen.
2 Blöde Fragen:
- Ist es eine SD oder MMC Karte?
- Verwendet die andere Lib dieselben Pins (insb. für SD Chip Select)?
Kommt der Fehler sofort, oder erst nach einiger Verzögerung?
Evtl. braucht die Karte länger zum Initialisieren. Ich würde zum Test 
mal die SPI-Geschwindigkeit auf Minimum setzen und die SD-Traces 
ansehen:
#define SDC_ENABLE_ERROR_TRACE
#define SDC_ENABLE_DEBUG_TRACE

Falls die Karte sich gar nicht meldet, ggf. das Timing in SDC_init() 
entschärfen und SDC_MAX_RETRIES hochsetzen:

1

uint8 SDC_Init()

2

{

3

  SDC_TRACE_DEBUG_STRING("SDC_Init\r\n");

4

5

  uint8 tries = SDC_MAX_RETRIES;

6

7

  // init SPI

8

  SPI_Init();

9

10

  // wait 10ms and send > 74 clock cycles to enter SD card SPI mode

11

  _delay_ms(10);

12

  uint8 i;

13

  for (i=0; i<20; i++)

14

  {

15

    _delay_us(5); 

16

    SPI_WriteChar(0xff);

17

  }

Gruß
Arne

Hab' hier grad noch eine 512MB MMC Plus Karte gefunden, mit der läuft's 
auch einwandfrei. Wie sieht denn die Schaltung aus? Wird der µC mit 3,3V 
betrieben? Taktfrequenz?

Bin gerade auch auf das Projekt gestossen und würde gerne auch eine LP 
nehmen, wenn's noch welche gibt!

Helmut.

Hallo,

@ conquistador: ja, wie beschrieben mit "-Os" compilieren, dann macht 
WinAVR ca. 7,5KB Code daraus (wobei das Hexfile an sich als Datei 
durchaus eine Größe von 20KB hat, das entspricht nicht der Codesize)

@Michael,Helmut: Ich habe noch 1-2 Platinen da, bei Interesse bitte 
kurze Mail.
Falls es wider Erwarten doch noch mehr Interessenten gibt, könnte ich 
auch noch mal welche machen lassen.

Grüße
Arne

Hi,

SEHR FEIN ;)
Ernsthaft... inspiriert durch den GLogger hier aus dem Forum wollte ich 
schon seit geraumer Zeit meinen eigenen GPS Logger bauen.
Ich bin dieser Tage genaugenommen dabei die letzten "Vorbereitungen" zu 
treffen (Entwurf der fehlenden Bauteile und Sockel in Eagle, 
zusammentragen der Materialien etc).
Anders als bei dessen Nachfolger wollte ich jedoch unbedingt bei FAT nd 
Standart-Daten bleiben.

Da kommt mir Dein Projekt gerade recht... FAT16, das gleiche GPS Module 
das ich auch schon hier liegen habe, MAX1811 Aufbau ähnlich (ich hab mir 
die MIC2920A aus dem Glogger Projekt besorgt)... wir funken auf der 
selben Welle ™ ;)

Ich freue mich schon darauf mich die Tage durch Deinen Code/Schaltplan 
zu lesen.
Ich bedanke mich schon jetzt parallel zu den GLogger-Nasen ;) auch bei 
Dir herzlichst, immerhin sollte ich mit so viel guter Vorarbeit meinen 
eigenen Logger inklusive meiner "Modifikationen" bzw. Änderungen in 
einem Bruchteil der Zeit (verglichen damit, Hard- und Software von Grund 
auf komplett selbst auf die Beine zu stellen) fertig stellen können.

Ich habe mir damals sicherheitshalber ein Sortiment größerer AVRs 
zugelegt, ich denke ich werde da einen 32k oder 64k Typ und evtl. ein 
paar zugängliche I/Os auf der Platine vormerken. Das lässt Platz für 
spätere Erweiterungen der Funktionalität...Nichts desto trotz Respekt 
davor, das ganze in einen Mega8 unterzubringen!

Am überlegen bin ich, ob ich den USB Anschluß zum Laden des Akkus nicht 
gleich voll Nutze um - entweder via FT232 oder softwarebasiert - Daten 
auch direkt übertragen zu können.

Wer ähnliches vor hat und evtl. noch das eine oder andere alternative 
Package braucht - ich hab ein paar SD und mircoSD Halter von ATTEND in 
eagle erstellt - ebenso einige andere Packages die ich nicht finden 
konnte.

Ich merke mir den Thread jedenfalls mal vor und werde mein Ergebnis 
posten, sobald ich weiter fortgeschritten bin.

Ciao...

Hi,

mal eine kurze Zwischenfrage an die Profis ;)

Ich hab heute den ersten Prototypen aufgebaut und soweit scheint meine 
Variante (100% SMD, 501ETTL und diverse andere Abweichungen vom 
Originalentwurf) zu funktionieren.

Gut finde ich die Wahl des Spannungsreglers mit Shutdown, allerdings 
werde ich den wohl nicht mehr rechtzeitig hier haben (Samstag steht eine 
einwöchige Reise an und da soll die "Version 2" des Prototyps schon 
mitloggen). Danach ist genug Zeit um die finale Version in Ruhe und 
"professioneller" aufzubauen.

Wie auch immer, ich werde wohl den ZLDO330 nicht schnell genug bekommen 
und wollte auch V2 mit dem MIC2920A (von denen ich genug habe) aufbauen, 
allerdings um eine Ein- bzw. Abschaltung erweitert wie im Original 
implementiert.
BSS138 habe ich ebenfalls ausreichend, daher frage ich mich, ob zu 
Überbrückung eine möglichst einfache Ersatzschaltung realisierbar wäre.
Auf anhieb fällt mir jedoch keine Lösung ein die das auch nur mit einem 
Taster erledigt - vielleicht sehe ich ja aber auch nur den 
sprichwörtlichen Wald vor lauter Bäumen nicht ^^
Denkbar wäre sonst wohl einfach einen zweiten Aus-Taster vorzusehen. Der 
Bisherige Eingang hält nach dem Einschalten durch seinen Pullup wie 
gehabt den BSS138 aktiv, den Aus-Taster gegen Masse frage ich über den 
nächsten freien Pin des gleichen Ports ab und veranlasse damit die 
Abschaltung.
Wäre das ein brauchbarer Ansatz?

Die Akkuladung via MAX1555 oder MAX1811 würde 1:1 umgesetzt bleiben. 
Lediglich der Spannungsregler der parallel zum LIPO die restliche 
Schaltung versorgt soll per Taster zugeschaltet werden und sich dann 
über den AVR bis zum Shutdown selbst halten.

Neben dem 501ETTL (ca 65mA) und der SD Card wären es noch der AVR und 
maximal 2 (ggf. 3) gleichzeitig betriebene LEDs. der Gesamtstrom sollte 
vorsichtig geschätzt noch deutlich unter 200mA liegen.
Da der BSS138 220mA Dauerstrom kann, sollte das doch im grünen Bereich 
liegen, oder?

Wie gesagt, den ZLDO330 halte ich nicht zuletzt wegen seiner 
Verfügbarkeit bei Reichelt für eine sehr gute Wahl, aber wenn ich 
optimistisch 2-3 Tage Lieferzeit ansetze bleibt mir kaum Zeit die 
Schaltung aufzubauen und ausreichend zu testen bevor es am Samstag auf 
Tour gehen soll.
Daher plane ich diesen erst für die dritte und vermutlich endgültige 
Version des Loggers ein.
Eine vorrübergehende Ersatzschaltung mit verfügbaren Bauteilen könnte 
ich dagegen schon im Laufe des Dienstags fertigstellen (bei reinen SMD 
Schaltung geht das Layouten, Ätzen und Löten glücklicherweise sehr fix 
und sauber, (sauberes) Bohren hat mich schon immer anteilig die meiste 
Zeit und Nerven gekostet ;) ) und hätte gleich mehrere Tage um ggf. am 
Code zu feilen und Dauertests durchzuführen.

Für Ratschläge und/oder konstruktive Kritik in Punkto 
Ersatz-"Ein"Schaltung wäre ich euch dankbar...

Ciao...

Hi nochmal...

während ich über meine Selbsthaltung meditiere ^^ hab ich mich weiter 
durch die einzelnen Projektdateien gelesen...
Bin ich reif fürs Bett oder stimmt da was mit der Baudrate nicht ganz?

Laut Datenblatt (Formel wie auch die Tabelle der gebräuchlichen 
Baudraten) sollte bei 2MHz und 9600 UBBRn=25 sein um auf 0.2% Fehler zu 
kommen, also demnach doch
UBRRL = 25
UBRRH = 0 ?

die USART.c enthält aber
  UBRRL = 24;  // 9600 Baud @ 2 MHz @ 3,3V
  UBRRH = 0;

Stehe ich jetzt so sehr auf dem Schlauch oder müsste dieser Wert nicht 
eine erheblich größere Abweichung im Bereich 4.2% ergeben?
Das läge doch erheblich neben der Soll-Baudrate, oder wo liegt mein 
Denkfehler?

Hallo Maxx M.

die Werte für UBRRL sind bewusst so gewählt. Die Baudrate ist abhängig 
von der Versorgungsspannung, daher war für 3.3V eine Anpassung von 25 
auf 24 notwendig. Ich erinnere mich vage an ein Diagramm im Datenblatt, 
kann das aber auf die Schnelle nicht finden.
Ich hatte vor dem Einsatz des ZLDO330 auch diverse andere Varianten 
durchdacht/durchprobiert, u.a. Pufferung/Verzögertes Ausschalten mit 
Goldcap - hat sich aber alles nicht wirklich bewährt.

@Bernhard: ja, mit einem Quartz ist man auf der sicheren Seite. Ich 
hatte aber mit der Genauigkeit des internen Oszillators (wie auch der 
interen ADC-Referenz) auch bei Temperaturschwankungen bisher nie 
Probleme, daher habe ich drauf verzichtet.
Bei evtl. größerer Ungenauigkeit durch Serienstreuung sollte sich das 
durch Setzen des Oscillator Calibration Value (oder notfalls halt auch 
UBRRL) kompensieren lassen.

Gruß
Arne

Hallo Maxx M.,

ich sehe gerade, dass Du den NL 501 ETTL verwendest. Dieser arbeitet 
laut Spec mit einer Versorgungsspannung von 3,3V-4,2V. Der Logger geht 
bis zum Abschalten wg. niedriger Batteriespannung noch bis 3.0V 
herunter. Funktioniert der Empfänger bei 3V noch zuverlässig?

Arne

Hi,

habe ich bisher noch nicht "ausgereizt".
Ich kann das aber bei nächster Gelegenheit einfach "künstlich" erzeugen 
und testen.
Zuvor steht erstmal der neue Prototyp an, nachdem ich nun auch ein paar 
ZLDO hier habe.
Ausserdem hatte ich beim ersten Aufbau meinen "eigenen" tKeepOut bei dem 
einfachen MicroSD-Verbinder nicht eingehalten. Erst als der Logger zwar 
nitialisierte aber mit der SDCard Probleme hatte fiel mir das auf.
Mal sehen wie ich das Routing drum herum hinbekomme, ansonsten nehm ich 
eben einen der anderen (hatte mir vor einiger Zeit ein paar einfache 
"hinged" (also mit Schiebe-Verriegelung) und push-push besorgt und die 
Packages dank der freundlichen Zusendung der Datenblätter in einer 
eigenen Eagle-lib zusammengefasst).
Die hinged sind einfacher zu Löten und boten sich fuer Prototypen an - 
da muss es ja nicht immer Luxus sein ;)

Ich hatte sowieso einige kleine Änderungen vorgesehen und mir auch den 
Punkt mit der unteren Akkuspannung bereits zwecks kleiner Anpassung 
vorgemerkt.

Hallo,

ich habe nun Feedback von jemanden bekommen, der den Navilock NL-507 
ETTL verwendet. Obwohl dieser für 3.3-4.2V ausgelegt ist, scheint er 
auch bis knapp unter 3V noch stabil zu laufen.
Da der u-blox Chipsatz leicht unterschiedliche Koordinatenformate 
verwendet (mehr Dezimalstellen) und die NMEA-Sentences in anderer 
Reihenfolge sendet, habe ich bei der Gelegenheit die Software angepasst. 
Sie ist nun generischer und dadurch auch zu anderen GPS-Modulen 
kompatibel.
Außerdem habe ich noch eine Testsoftware ergänzt, die nur die LEDs 
blinken lässt, das hilft u.U. bei der Inbetriebnahme der Platine.

Grüße
Arne

Falls man den internen Oszillator verwendet um den Quarz zu sparen , 
sollte man sich einen 32kHz quarz goennen, und den internen Oszillator 
auf den synchronisieren. Sonst wird das mit der Baudrate nie was. 
Advanced waere natuerlich auf das GPS zu synchronisieren. Mit einem 
Timer auf die Meldungen warten.

Hallo,

Quint Oschi schrieb:
> Sonst wird das mit der Baudrate nie was.
Gewagte These... Ich habe nun drei von den Dingern gebaut, und alle 
laufen zuverlässig. Kalibrierung des internen Oszillators macht auf 
jedem Fall Sinn, war bei mir aber in keinem Fall notwendig. Man kann 
sich viele schöne Sachen überlegen, das im laufenden Betrieb automatisch 
zu kalibrieren, habe ich damals auch drüber nachgedacht, aber letztlich 
verworfen, weil es auch so problemlos lief. Sonst lieber gleich einen 
Quartz einbauen und fertig.
Würde mich natürlich trotzdem mal interessieren, ob ob jemand, der die 
Schaltung nachgebaut hat, mit der Baudrate (mit/ohne Kalibrierung des 
internen Oszis) Probleme hatte.

Arne

Der interne Oszillator ist nicht genau genug spezifiziert fuer serielle 
Kommunikation. Die Frequenz haengt von der Spannung, sowie von der 
Temperatur ab. Zur Powerup Kalibration mit einem Uhrenquarz ...
http://www.ibrtses.com/embedded/avrosccal.html
.. koennte auch zur laufenden Kalibration umgebaut werden. Es macht 
durchaus Sinn fuer Stromsparanwendungen nur mit dem Uhrenquarz zu 
arbeiten und nicht mit einem richtigen.

Wenn man den Diagrammen im Datenblatt glauben mag, hat der interne 
Oszillator bei -20° bis +60° und 3-3,3V eine Drift von ca. +/-3%. Klingt 
für mich ganz annehmbar. Hat da jemand genauere Erfahrungen?
Das mit dem Uhrenquartz mag für Stromsparanwendungen sinnvoll sein. Bei 
den 50-70mA, die das GPS-Modul verbrät, fiele wohl der 2MHz Quartz nicht 
mehr ins Gewicht. Eine einfache Möglichkeit zur automatischen 
Kalibrierung wäre natürlich das PPS (Pulse-Per-Second) Signal, leider 
bieten das diese GPS Module nicht...

Arne

Die seriellen Schnittstellen benoetigen eine Frequenzgenauigkeit von 
kleiner 2%, strikt.
Das GPS Modul laesst man doch nicht durchlaufen... das hat doch einen 
Standby. Nein ?

Solange der Logger läuft, ist natürlich auch das GPS Modul aktiv. Ich 
schalte hier nicht den µC in Standby, sondern den Spannungsregler. Der 
ist angegeben mit 11µA, mehr sparen geht wohl kaum :-)

Interessant. Mein Modul zieht gemaess Datenblatt 25mA tracking, 50mA 
acquisition, 75mA enhanced acquisition. Was auch immer das nun bedeutet. 
Fuer einen Hot Start benoetigt es 1 sekunde. Dh wenn ich alle 15 
sekunden einen Punkt nehme, kann ich es 14 sekunden schlafen legen.

Da hab' ich halt andere Anforderungen, ich möchte wirklich jede Sekunde 
die Position aufzeichnen und 12-15h Batterielaufzeit sind für mich 
allemal ausreichend.
Nur für eine von 15 Sekunden einschalten halte ich für nicht realistisch 
(der NL504 braucht länger), zumindest wird's der Genauigkeit nicht 
dienlich sein.

Dann wuerd ich dir mein Modul empfehlen. Zumindest vom Datenblatt her. 
Es braucht die Haelfte, und das PPS Signal ist auch moeglich. Es ist das 
Skytrack ST-22. Hab's aber noch nicht verbaut.

Ja, das Datenblatt klingt recht vielversprechend. Wo kann man diese 
Module beziehen?

Einse Suche nach GPS im Markt Forum hier :
Beitrag "[V] Mini GPS Module - SkyTraq Venus 6 (22x22x8mm)"
Der erste Post enthaelt die email. Um die 22 Euro.

Den Beitrag habe ich gestern Abend noch gefunden. Was mich etwas stutzig 
macht: wenn die Teile so gut sind, warum hört/findet man sonst kaum was 
darüber?
Bei den dort angebotenen Modulen handelt es sich um die Variante ohne 
"Backup Supply"? Dann wird es wohl etwas schwierig mit einem Hot Fix in 
1sec, oder hast Du etwas nachgerüstet? Ob dafür nur eine Batterie oder 
auch Flash benötigt wird, wurde mir zumindest auf den ersten Blick nicht 
klar.
Hattest Du das Modul schonmal in Betrieb? Hat sonst schon jemand 
Erfahrung mit den Dingern?

Es gibt den Power Save mode. Dann kann man Parameter lesen und 
schreiben. Dh wenn ich neu starte und das Datum, sowie die Ephimeris 
Daten schreibe, dann muss die Einheit das schon mal nicht rausfinden. 
Den AVR Controller lasse ich natuerlich durchlaufen, der kann sich das 
alles merken.

Ich hab die Hardware, aber noch nicht eingeschaltet. Liegt wegen 
Dringenderem zZ auf Eis.

Ich hab grad bei u-Blox nachgeschaut. Deren (zB Lea6) Verbrauch und 
Ansprechzeiten liegen auch in diesem Rahmen. Ich hab das ST22 wegen dem 
Sekundenpuls fuer eine Timinganwendung gewaehlt, und mach noch einen 
Tracker nebenher, ohne dringend darauf angewiesen zu sein.

Ich würde u.U. noch mal Platinen machen lassen. Hätte jemand Interesse? 
(6€ + Porto)

Hab mir nun auch mal ein Skytrack ST-22 bestellt. Zitieren hier alle nur 
aus dem Datenblatt, oder hat den auch schonmal jemand ausprobiert? Ok, 
ist sehr klein und günstig. Aber habe heute mal eine erste Fahrt damit 
aufgezeichnet und muss sagen, dass  es mich nicht vom Hocker gehauen 
hat: auf der Autobahn war die Position für einige Zeit > 100-200m im 
Off, deutliche Überschwinger und Geschwindigkeit gemessen 170km/h bei 
gefahrenen 100km/h. Hat jemand ähnliche oder bessere Erfahrung damit?
Werde bei Gelegenheit mal beide Logger mit verschiedenen Empfängern 
parallel fahren.

-> Preissuchmaschine, ca. 30-35€
Hab jedesmal woanders geordert, gibt wohl keinen konstant günstigen 
Händler.

Nochmal Feedback zum SkyTraq ST22:

Nach Umkonfiguration auf "enhanced acquisition mode" und 
Backup-Versorgung über einen Goldcap sieht das Ergebnis nun ganz 
passabel aus. Insbesondere was die aufgezeichnete Höhe anging, war er im 
Vergleich zum NL-504 aber etwas unruhiger. Für meinen Anwendungsfall 
aber allemal ausreichend.

Ohne Backup-Versorgung initialisiert der Empfänger Datum/Zeit immer mit 
28.06.2006 11:59. Was insofern nervig ist, da ich aus der Uhrzeit den 
Dateinamen erzeuge. Es gibt im NMEA auch kein Flag, das die Gültigkeit 
der Uhrzeit anzeigt. Man muss dann also auf den ersten GPX-Fix warten, 
um eine gültige Zeit zu bekommen.
Daher macht das Nachrüsten einer Backup-Versorgung auf jeden Fall Sinn.

Ich lade demnächst noch eine aktualisierte Firmware für den Logger hoch, 
die das Problem mit gleichem Startdatum/-zeit des ST22 umgeht.

Hallo Achim,

eine Layoutänderung sollte nicht nötig sein. Ich habe bewusst GPS-Modul, 
Ladebuche, Taster etc. über Kabel mit der Platine Verbunden, um nicht 
von ganz bestimmten Bauteilen abhängig zu sein.
Ich kenne den Skytraq ST01 nicht. Laut Datenblattblatt Vcc 3,3V, RX/TX 
vermutlich TTL level, (zusätzlich sogar SPI), NMEA u.a. GGA und RMC, 
sollte also passen - nichts, was sich nicht notfalls in der SW ändern 
lassen sollte.
Platinen habe ich noch nicht machen lassen, bisher haben sich noch keine 
weiteren Interessenten gemeldet. Ich bräuchte aber auch noch eine, da 
mein Logger zusammen mit meiner Kompaktkamera 'verschwunden' ist... :-(

Also wer noch Interesse an Leerplatinen hat, bitte melden. Bei genügend 
Interessenten würde ich nochmal ordern.

Grüße
Arne

Ich habe nun doch noch eine automatische Kalibrierung des RC-Oszillators 
implementiert.
Zuerst habe ich probiert, die Kalibrierung anhand der Pulsweiten des 
seriellen Signals durchzuführen. Während das mit dem Skytraq einwandfrei 
funktionierte, hatte ich mit dem NL-Modul Probleme. Stattdessen 
synchronisiere ich nun auf die sekündliche GPS-Datenübertragung (in der 
Annahme, dass diese gemittelt über mehrere Sekunden hinreichend genau 
ist) und führe OSCCAL laufend nach. Hierzu muss INT1 mit RXD verbunden 
werden, alternativ könnte natürlich auch ein evtl. vorhandener 1PPS 
Ausgang des GPS-Moduls verwendet werden.
Das funktioniert nun sehr gut. Beim Testen hat sich aber gezeigt, in 
welchem weiten Bereich von OSCCAL-Werten die USART-Übertragung dennoch 
fehlerfrei funktioniert, so dass auch ein einmalig abgestimmter 
Oszillator bei der zu erwartenden Temperaturdrift wohl ausreichend genau 
wäre, aber so ist es natürlich noch schöner.
Als weitere Änderung werden die USART-Daten nun gepuffert über 
Interrupts eingelesen.

Die neue Software gibt's wieder hier:
http://friedrichs-bs.net/GPX-Logger.html

So, nun ist der mega8 endgültig ausgelutscht, mehr passt wohl wirklich 
nicht... Falls ich noch mal einen baue, kommt da wohl gleich ein mega328 
drauf ;-)

Hallo,

ich habe ein Problem bei der Auswertung der NMEA Daten.
Habe die Software auf ATmega88PA portiert. Soweit funktioniert auch 
alles gut. Bis auf die Auswertung der GGA/RMC Daten.
Ich sende über UART NMEA Testdaten an den Controller. Allerdings schlägt 
der Vergleich in NMEA_IsDataComplete() immer fehl. (Füge ich hier ein 
return 1 ein, dann werden Daten auf die Karte geschrieben)


Mit folgender Debug Ausgabe in NMEA_IsDataComplete():
--------------
USART_WriteChar(nmea_time_rmc[0]);
USART_WriteChar(nmea_time_rmc[1]);
USART_WriteChar(nmea_time_rmc[2]);
USART_WriteChar(nmea_time_rmc[3]);
USART_WriteChar(nmea_time_rmc[4]);
USART_WriteChar(nmea_time_rmc[5]);
USART_WriteString("-");
USART_WriteChar(nmea_time_gga[0]);
USART_WriteChar(nmea_time_gga[1]);
USART_WriteChar(nmea_time_gga[2]);
USART_WriteChar(nmea_time_gga[3]);
USART_WriteChar(nmea_time_gga[4]);
USART_WriteChar(nmea_time_gga[5]);
USART_WriteString("\n");

    if ( (nmea_time_rmc[....
-------------

bekomme ich bei diesem Datensatz:
$GPGGA,100052.939,5408.0683,N,01346.0447,E,1,07,1.2,36.8,M,,M,,*7D
$GPRMC,100052.939,A,5408.0683,N,01346.0447,E,2.794507,126.959198,200804, 
,*01

folgendes (terminalprog.):
100052-100052
100052-7<\0>0052
100052-100052
100052-7<\0>0052
100052-100052
100052-7<\0>0052
100052-100052
100052-7<\0>0052

Obwohl die gesendeten Daten immer zusmamen passen hakt es irgendwie. 1x 
greift der Vergleich und es werden Daten auf die Karte geschrieben aber 
anschließend ist die GGA timestamp irgendwie verstümmelt.

Woran kann das denn liegen? Bzw. wo kann ich ansetzen um eine Lösung zu 
finden?

Danke!

Ich verwende Version 1.2 und hab die Schaltung + Software auf den mega88 
angepasst. (1.1V Referenz, 8MHz int. RC Osc ...)
Änderungen SW: SPI config auf 1MHz, UART Registernamen, Vcc_min 218,
HW: R4-4k7, R2-100k, R1-220k

Alles was SD-Card schreiben und Schalter ON/OFF betrifft, funktioniert 
schon. Lediglich die Sache mit den den Daten nicht.
Ich sende momentan per PC (Terminalprogramm HTerm), da ich das GPS Modul 
nich nicht hab.
Wenn ich wie beschrieben die Funktion NMEA_IsDataComplete() auf return 1 
setze, dann schreibt er mir alle Datensätze richtig in das GPX File auf 
der SD Karte.

Hallo Rainer,

nein, es spricht nichts gegen einen Quartz. Hatte nur keinen vorgesehen 
und es geht halt auch ohne.

Gruß
Arne

Hallo unrouted,

ich würde testweise den µC auf 2MHz einstellen, zumindest die 
Kalibierung ist darauf ausgelegt.
Die Kal. kannst Du dann auch mal abschalten -> #define 
CLKCAL_FEAT_OSC_CALIBRATION auskommentieren.
Wie sendest Du die Daten über das Terminalprog.? Ganze Datei in einem 
Rutsch oder hast Du irgendein Timing? --> evtl. probehalber Zeilenweise 
von Hand reinkopieren, so dass der µC nicht komplett geflutet wird.

Gruß
Arne

Hallo Arne,
die Kalibrierung hab ich gleich am Anfang komplett rausgeschmissen.
Habe mehrere Varianten probiert. Komplettes File auf einmal und auch 
GGA+RMC-->lange_Pause-->GGA+RMC-->lange_Pause...
Auch RMC und GGA vertauscht. Hat anscheinedn ein wenig Einfluss.

Habe nun außerdem die Debug-Ausgabe über UART direkt in parse_RMC/GGA 
eingebaut und dann bringt er immer die richtige Uhrzeit.

So einfach geht das mit den 2MHz nicht, da sich der interne Oszillator 
nicht auf 2 stellen lässt.

Habe zumindest noch ein Problem gefunden:

die Arrays nmea_speed und nmea_course sind für Dein NMEA-Format zu klein 
dimensioniert (wer rechnet schon mit 6 Nachkommastellen... ;-).  Für die 
anderen Felder habe ich die Array-Size beim Lesen berücksichtigt, bei 
diesen steht leider noch ein 'todo' im Code - ärgerlich --> dann wird's 
wohl doch noch mal ein neues Release geben...

Die letzte Ziffer von Speed "2.794507" schreibt dir vermutlich den 
GGA-Timestamp kaputt.
Zwei Möglichkeiten: Entweder die Arrays auf mindestens 11 Zeichen 
vergrößern, oder besser das memcpy für speed und course in NMEA_ParseRMC 
auskommentieren. Die Felder werden ohnehin nicht verwendet (gleiches 
gilt für hdop und satellites).

Reihenfolge von RMC und GGA ist egal: Mittels NMEA_IsDataComplete() wird 
nach jedem Datensatz geprüft, ob RMC und GGA denselben Zeitstempel 
haben. Daher jedes 2. Mal NMEA_IsDataComplete()==0! Nur bei gleichem 
Zeitstempel werden Daten ausgewertet und auf SD-Karte geschrieben.

Danke!

Das war ein guter Tip! Hab beides auskommentiert. Funktioniert nun 
einwandfrei!

na wunderbar! Für den Fall, dass ich evtl. doch mal einen mega 168/328 
verbauen sollte: könntest Du mir den an den mega88 angepassten Quellcode 
per Mail schicken? Würde mir etwas Arbeit ersparen - danke.

Habe wg. des möglichen Array-Überschreibers eine neue Software Version 
1.3 hochgeladen (Link s.o.). Wer ebenfalls ein GPS-Modul verwendet, dass 
sich zutraut, Kurs und Geschwindigkeit mit mindestens 6 Nachkommastellen 
zu berechnen, sollte die neue Software verwenden - alle anderen können 
getrost darauf verzichten... ;-)

Ich hätte grad noch eine Platine übrig. AT mega8 ist bestückt und 
programmiert, sonst nackt (s. Bild). Würde ich für 10€ inkl. Porto 
(Brief, D) abgeben, bei Interesse bitte melden.

Die Platine ist verkauft.

Ich habe heute einen wichtigen Hinweis erhalten:
In die ursprüngliche Beschreibung der Fuses hatte sich ein Fehler 
eingeschlichen. Das Fuse High Byte darf natürlich nicht 00 sein, sondern 
wurde von mir gar nicht programmiert. Richtig sind folgende 
Einstellungen:

- Int. RC Osc. 2 MHz; Start-up time: 6 CK + 64ms
- enable Brown-out detection at VCC=2.7 V

Fuse bytes:
low:  0xA2
high: 0xD9