mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik GPX-/GPS-Logger


Autor: arne (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hätte den Beitrag wohl auch 'just another GPS-Logger' nennen können 
;-)
Das ist sicher nicht der erste GPS-Logger, da ich mir hier aber vor 
einiger Zeit ein paar sinnvolle Tipps geholt habe, möchte ich das 
fertige Ergebnis nun nicht vorenthalten. Außerdem denke ich, dass es 
doch eine runde Sache geworden ist und würde mich freuen, wenn es noch 
jemand anders nützlich findet.

Features:
- ATmega8 konvertiert GPS-Daten ins GPX Format und speichert auf 
FAT16-formatierter SD-Karte
- Versorgung über Li-Ion Handyakku
- selbsttätiges Abschalten bei niedriger Batteriespannung
- Laden des Akkus in der Schaltung
- kompakte Abmessungen (ca. 8 x 5,5 x 2,5cm)

Details unter http://friedrichs-bs.net/GPX-Logger.html
hier kann man bei Interesse auch die Software sowie das Layout 
herunterladen.

Schönen Abend noch!
Arne

Autor: Arne F. (-arne-)
Datum:

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

Gruß
Arne

Autor: Johannes G. (johannesg00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ein schönes Projekt :) Genau das wollte ich als nächstes auch bauen..

Ich hätte Interesse an 1-2 Platinen ;)
Wieviel soll da eine kosten?

Viele Grüße,
  Johannes

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes G. (johannesg00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, danke, ich melde mich dann mal per email bei dir ;)

Hast du vielleicht noch ein Bild von der unterseite der Platine? Also 
die Seite, auf der die SD Karte sitzt, weil ich überlege ob meine 
SD-Sockel bei deiner Platine passen ;)

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich will auch eine, wenn noch verfügbar

Bernhard

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ado (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man bei dem GPX-Standard auch PIOs mit abspeichern ?

Für mich wäre es interessant, wenn man den Weg mitlogt und durch einen 
Tastendruck die aktuelle Position zusätzlich in einer Liste abspeichern 
könnte.

IO-Kanäle für den Taster wären ja genug da.


Gratuliere zu diesem sehr schönen Project.

Autor: Johannes G. (johannesg00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich bin nur gerade an einem PC ohne Eagle, deshalb kann ich das 
Layout gerade nicht anschaun...
Ich schreib dir dann morgen noch eine email ;)

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Arne F. (-arne-)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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€.

Autor: Ed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hat die Software schon jemand getestet? Die FAT_Init() Funktion läuft 
nicht. Nach aktivieren von

#define FAT_ENABLE_ERROR_TRACE 1
#define FAT_ENABLE_DEBUG_TRACE 1
#define USART_FEAT_WRITE_ACCESS 1

meldet es mir übers Terminal:
FAT_Init<\r><\n>
SD init failed!<\r><\n>

Studenlange Fehlersuche. Verkabelungsfehler kann ich auschließen, da 
eine andere FAT Library problemlos läuft! Karte (256MB) habe ich als 
FAT16 formatiert (sowohl unter Linux als auch unter Windows).

Ed

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
uint8 SDC_Init()
{
  SDC_TRACE_DEBUG_STRING("SDC_Init\r\n");

  uint8 tries = SDC_MAX_RETRIES;

  // init SPI
  SPI_Init();
 
  // wait 10ms and send > 74 clock cycles to enter SD card SPI mode
  _delay_ms(10);
  uint8 i;
  for (i=0; i<20; i++)
  {
    _delay_us(5); 
    SPI_WriteChar(0xff);
  }

Gruß
Arne

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Arne,

danke vielmals für deine Tips! Es war die Lösung dabei! Alles 
funktioniert bestens.

Der Hinweis mit den Pins war goldrichtig. Ich bin zwecks Codegröße auf 
einen Atmega32 ungestiegen und habe nicht darauf geachtet, dass der SPI 
Port da woanders liegt. Blöder Fehler, ich dachte die sind noch 
Pinkompatibel!

In der sdcard.h die Pins angepasst und nun läuft es EINWANDFREI! Echt 
nettes und einfaches Stück Software. Vielen Dank dafür und für deine 
Hilfe.

Besten Dank,
mit freundlichen Grüßen
Ed

Autor: ado (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eben versucht Waypoints einzutragen.

Prinzipiell funktioniert die geänderte GPX-Datei.

Nur die automatisch generierten Trackpunkt-Namen bei Google Earth, sind

nicht ideal.

Bei jeder neuen Sequenz fängt die Namensnummer wieder bei 0 an.

Aber die Namen der Trackpoints sind, so glaube ich, auch nicht so

wirklich interessant.

Ansonsten kann man diese ja bei der Erzeugung der GPX-Datei geziehlt

angeben.

In der neuen Sequenz nach einem Waypoint muß die letzte Position

nocheinmal eingetragen werden.

Sonst gibt es eine Unterbrechung des Tracks.


Ich hoffe ich finde demnächst Zeit diese Schaltung nachzubauen.

Autor: conquistador (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arne,

tolles Projekt.
Eine Frage habe ich:  wie bekomme ich den code in ein hex file welches 
in die 8k im mega8 paßt? Irgendwie komme ich nicht unter 20k.

Autor: SilentWarrior (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@conquistador: Falls du mit dem AVRStudio compilierst, dann kann man 
Optimierung einschalten. Höchste Stufe (ich glaube ist -os) wenns keine 
Probleme macht.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

gibt es denn noch eine Platine - dann würde ich gerne eine oder zwei 
nehmen!?

Beste Grüsse
Michael

Autor: Helmut -dc3yc (dc3yc)
Datum:

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

Helmut.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: conquistador (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Arne and warrior,

Ja, danke, ich bin einfach nur ein Trottel, das hex paßt hervorragend in 
den mega8 und am Ende sind noch jede Menge Freie Felder  FF
:-).

Autor: Maxx M. (maxx2206)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mein Nachbau mit der Platine von Arne läuft seit heute.
Gelötet hatte ich schon letztes Wochenende, aber es funktionierte nicht.
Nach längerem Suchen mit dem Oszi merkte ich, daß der Logger die 
seriellen Daten des GPS Moduls (9600 Baud) nicht richtig verstand.

Offensichtlich sind die 2Mhz des internen Oszillators nicht genau genug.

Bei meinen eigenen Projekten setze ich schon seit längerem aus diesem 
Grund Quarz ein, wenn ich RS232 brauche. Jetzt weis ich wieder, warum 
;-))

Werde den Logger heute noch ernsthaft ausprobieren.

Gruß und Danke an Arne

Bernhard

Autor: Maxx M. (maxx2206)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Maxx M. (maxx2206)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maxx M. (maxx2206)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zwölf Mal Acht (hacky)
Datum:

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

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das Datenblatt klingt recht vielversprechend. Wo kann man diese 
Module beziehen?

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

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

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: stiller Beobachter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
falls es weitere Erfahrungen gibt, nur zu. Wir lesen sehr interessiert 
mit.

Wo kauft man günstig ein NL-504ETTL?

Autor: Arne F. (-arne-)
Datum:

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

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: stiller Beobachter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prima, das sieht doch gut aus.

Autor: Gps'ler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arne,

super Projekt! Ich habe für Testzwecke noch ein SkyTraq ST01 Modul auf 
einer Prototypplatine ständig am Fenster liegen.
Ich hätte eventuell auch Interesse an 1/2 Platinen. Nimmst du da noch 
eine Layoutänderung bezüglich den Skytraqs vor? Ist ja aber eigentlich 
nicht notwendig.
Kennt jemand den Unterschied zwischen dem ST01 und dem ST22 ohne groß 
die Datenblätter zu wälzen.
SD-Kartenhalter habe ich auch einige und müßte vorher noch prüfen ob ich 
die da ranbringe.

So könnte ich mein gefrickel etwas ordnen. Ich benutze bisher nur die 
serielle Schnittstelle zum PC (mit Adapter) für PC Testzwecke....

MfG
Achim

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: __ __ (unrouted)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: arne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche SW-Version verwendest Du?
Welches GPS-Modul? Oder sendest Du direkt vom PC an den Controller?

Schaue ich mir heute Abend im Code mal genauer an.

BTW: die Mega 88/168/328 haben meines Wissens eine abweichende interne 
ADC Referenzspannung (1,1V ?) Der Spannungsteiler zur Messung von Vcc 
muss entsprechend angepasst werden.

Autor: __ __ (unrouted)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Neugiriger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arne,

nur aus Neugierde. Wäre es da wegen dem Timing nicht einfacher gewsen 
noch einen Quarz (SMD) drauf zu machen, Platz wäre doch noch da?
Oder was spricht dagegen?

Vielen Dank
Rainer

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

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

Gruß
Arne

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: __ __ (unrouted)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: __ __ (unrouted)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

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

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Arne F. (-arne-)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Platine ist verkauft.

Autor: Arne F. (-arne-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.