Hallo!

Jetzt, wo der Sommer kommt, und ich immer häufiger größere Radtouren
fahre, wollte ich mir einen GPS Tracker bauen, der während der Fahrt
meine Position alle x Sekunden auf eine Speicherkarte schreibt und das
man dann mit zum Beispiel Google Earth / Maps diese Positionen dann auch
auslesen kann.

Hierbei bin ich gerade in der Planungsphase, möchte dann so in ca. 2 - 3
Wochen mit der Arbeit beginnen (Da wir dann Schulferien haben ;-)).

Als Prozessor habe ich an einen AVR gedacht, auch wenn ich bis jetzt nur
mit PICs gearbeitet habe (der Umstieg geschieht aus dem Grund, dass es C
compiler für AVRs gibt, und mir C dann bei so etwas großem doch etwas
lieber ist, als Assembler (Ja, ich weiß, es gibt auch für 16-Bit PICs
einen C-Compiler, aber ich hab das Gefühl AVRs sind irgendwie beliebter
;))). Zum Beispiel ein Atmega8-16.
Das Ganze soll auf Lochrasterplatinen entstehen, da ich noch nie
Platinen geäzt o.ä. habe und mir das Equipment dazu auch fehlt (Ich
glaube das würde sich für mich nicht lohnen, mache nicht soooo viel),
weswegen SMD Bauteile ausgeschlossen sind.

Kommen wir zu meiner ersten Frage: Welches GPS Modul soll ich nehmen?

Die einzigen, die ich bis jetzt gefunden habe, sind von der Firma
NAVILOCK. Diese gibt es auch zu einem relativ günstigen Preis (ab 23€).
Allerdings gibt es dort 3 verschiedene Modelle, mit jeweils ca. 3-4 €
Preisunterschied.
Anhand der technischen Daten konnte ich nur einen Unterschied finden,
nämlich die Anzahl der Kanäle. Ist das überhaupt relevant für mein
Projekt, oder kann ich mit ruhigem gewissen das günstigste Modul nehmen
(NL-507TTL u-blox)?

Außerdem gibt es dann von jedem der 3 Modelle nochmal 3 Anschlussarten,
RS232, TTL und USB. Für die Kommunikation mit einem AVR bräuchte ich
doch die TTL Version, oder?
Denn bei RS232 benötigt man ja zB noch Pegelwandler o.ä., bei TTL könnte
man die PINs einfach direkt mit dem AVR verbinden, richtig?

Die Software für den AVR würde ich mir dann schon irgendwie selber
zusammenbasteln, da gibt es ja zum Glück gute Dokumentationen zu (das
GPS Modul soll über NMEA angesprochen werden, für die SD Karte gab es ja
auch irgendwo eine Homepage wo es ziemlich gut erklärt war).

Nur wie genau sieht es mit der Stromversorgung aus?

Da das ganze auf dem Fahrrad transportiert werden soll, sollte das Gerät
möglichst klein und leicht sein. Ja, SMD wäre da ziemlcih von Vorteil,
aber wie gesagt, meine Erfahrung in dem Bereich ist gleich 0 und ich
denke dass sich das auch nicht so für mich lohnt. Eventuell könnte man
das in einer Aufbewahrungsflasche im Flaschenhalter unterbringen, wo
aauch das Flickzeug drin liegt.
Welche Art von Akku könntet ihr mir empfehlen? Ganz normale NiMH Akku's
oder gibt es da etwas 'spezielles' ;) (Sollte aber ohne großen Aufwand
wieder aufladbar sein).

Ich sehe gerade der Thread ist etwas lang geworden, hier nocheinmal die
Fragen zusammengefasst:
1) Gibt es für mich relevante Unterschiede bei den GPS Modulen von
NAVILOCK?
2) Ist das NL-507TTL u-blox für mein Projekt ausreichend?
3) TTL, RS232 oder USB? Was kann man am einfachsten mit dem AVR
verbinden?
4) Welchen Akku soll ich als Stromversorgung nehmen?

Vielen Dank schonmal für eure Hilfe :-) Ich bin immer für Vorschläge
offen

Martin M.

GPS: du kannst dir bei e?ay ja eine GPS-Maus schiessen, Kabelmäuse sind
halbwegs preiswert... TTL, USB, RS232 spielt erst einmal keine
allzugrosse Rolle, die werkeln die intern (ziemlich) sicher mit TTL,
also nur die ein oder andere Leitung kappen/ersetzen/hinzufügen...


und wenn du übermorgen losfahren möchtest, dann
http://www.reichelt.de/?ARTICLE=80897

Sehr interessantes Projekt - das würde mir auch Spaß machen.
Kann man die Navilock-Module auch als Privatperson problemlos bekommen?
TTL bekommst Du am besten an den AVR dran, Akku ist abhängig von
Stromverbrauch und angepeilter Laufzeit. NiMH sind wohl die
problemlosesten, aber man könnte auch mit einem Lithium-Ionen Akku
arbeiten, die werden langsam auch preislich interessant.

Hallo,
das gleiche habe ich auch vor, gps maus mit ttl ist auch schon da, du
kommt nicht zufällig aus dem raum Leipzig?. da es sehr klein sein soll
werde ich wohl eine kleine platine machen mit einem Atmel mega??. Mit
lochraster platte wollte ich eigentlich nicht erst anfangen.
Ich habe jetzt den genauen typ der GPS maus nicht da, aber es steht was
von 5V 500mA drauf - ich hoffe das braucht sie nicht ständig. Sonst habe
ich auch probleme mit der STromversorgung.
Wo willst du die daten aufzeichnen? ich will es einfach auf eine
SD-karte machen.

sowas:
http://de.youtube.com/watch?v=irDEzQovftM
?

Kauf dir doch ein iPhone 3G!

nachtrag:

das ding habe ich bei ebay für 6€ + versand bekommen.
http://www.dantotec.de/products/GPS-Empfaenger/Roy...

Wow das geht ja schnell mit den Antworten :-)

Nein, komme nicht aus dem Raum Leipzig, ist ca. 600 Km entfernt.

Also die NAVILOCK Module bekommt man bei einem Shop namns HANOBox
relativ günstig (wie gesagt, ab ca. 23€).
Laut Navilock Homepage braucht das Modul :

    * Stromanschluss: 3,3V-4,2V DC
    * Stromaufnahme: ca. 70mA

Zusätzlich käme eben noch der AVR und elektronik für die SD Karte.

Und an 'rotzfrech' : Ja, so etwas in der Art, nur etwas kleiner ;)

Und ein iPhone ist etwas zu teuer finde ich.

NiMH Akkus habe ich hier in AA Batterie Form, jeweils mit 2300 mAh, bei
einer Stromaufnahme von sagen wir mal 250mA insgesamt wären es also fast
10 Stunden, sehe ich das richtig?

iPhone kostet neuerdings 199$ oder weniger.

Ein interessantes projekt, das Du da vor hast... Ein ähnliches Projekt
aus dem OpenSource-Bereich findest Du auf http://www.obico.de

Ein interessantes Projekt, das Du da vor hast... Ein ähnliches Projekt
aus dem OpenSource-Bereich findest Du auf http://www.obico.de

Jo, ist natürlich auch sehr nett, aber mir geht es wirklich nur um den
Tracker, ich brauche also kein Display o.ä. .

Was meint ihr, sollte ich das ganze auf 3,3 V oder auf 5 Volt betreiben
und dann für die SD Karte per Spannungsregler runterregeln?
An sich wäre 3,3V die bessere alternative, oder? Dann bräuchte ich wohl
die L version der AVRs, richtig?

Habt ihr irgendeinen speziellen Vorschlag als µC?

Hi,

klingt interessant, aber ist von der Idee her ja nicht neu.
Hier gibt es auch ein kleines Projekt, allerdings ohne
SD-Kartenunterstüzung.
Beitrag "GPS-Logger mit gpx-Export"
Ich fänd aber eine saubere Platine mit SMD Bestückung schöner.
Aber dazu hast du ja was geschrieben...
Viel Spaß und halt uns auf dem Laufenden...

ich wollte es eigentlich mit einen tiny machen, weil er recht klein ist.
Leider müssen 512Byte für die SD-Karte gepuffert werden. Bei anderne
blockgrößen hängt es von der Karte ab ob es geht. Also entweder die
daten gleich auf die Karte durchschieben oder doch einen mega nehmen mit
mehr als 512byte ram.
Wenn du mit C arbeiten willst sollte es mindestens ein mega sein, leider
sind sie alle smd oder recht gross.

Zum Thema Stromversorgung:

Ich habe mir vor ein paar Tagen eine Schaltung aufgebaut, mit der ich
einen stinknormalen Handyakku laden kann (vom W880i, sehr flach und
günstig!, 950mAh, 3.6V).
Dazu ist noch ein 3V Linearregler drauf (3,3V gibts mit der gleichen
Bauform und Beschaltung), der kann allerdings nur 200mA, was aber doch
eigentlich reichen sollte, oder? Ich weiß ja nicht, wieviel so ein GPS
Modul zieht.

Auf jeden Fall ist die Schaltung sehr klein. Wenn ich das so klein wie
möglich packen und direkt in eine Schaltung integrieren würde, wäre das
nur ca. so groß wie ein Damennagel + Lötanschlüsse für den Akku je nach
Belieben.

Habe die Schaltung noch nicht komplett getestet, aber der Linearregler
arbeitet sauber (auch wenn gleichzeitig geladen wird) und geladen habe
ich den Akku auch schon (wurde exakt bis zur max. Ladespannung geladen,
LED für Ladestatus ist auch drin). Vin zum Laden kann 4,35V-6,5V sein.
Man müsste aber noch zusehen, dass der Akku nicht zu tief entladen wird,
da ist keine automatische Abschaltung drin.

Hallo,
für den Code kannst du den aus der Codesammlung nehmen
Beitrag "GPS an mega8,88 oder 168"

das ist genau das, was du beschreibst: Tracker für SD Karte
Ich habe eigentlich nur vor das Projekt der Condesammlung nachzubauen,
kämpfe aber noch mit dem GPS Modul :(

Gruß
Kai

Daniel Reinke wrote:
> Zum Thema Stromversorgung:
>
> Ich habe mir vor ein paar Tagen eine Schaltung aufgebaut, mit der ich
> einen stinknormalen Handyakku laden kann (vom W880i, sehr flach und
> günstig!, 950mAh, 3.6V).
> Dazu ist noch ein 3V Linearregler drauf (3,3V gibts mit der gleichen
> Bauform und Beschaltung), der kann allerdings nur 200mA, was aber doch
> eigentlich reichen sollte, oder? Ich weiß ja nicht, wieviel so ein GPS
> Modul zieht.

Hi!

Also das Modul alleine zieht laut technischen Daten 70mA. Dazu käme noch
die Schaltung für den µC und das beschreiben der Karte (und evtl. 1 oder
2 Status LEDs). Ich denke 200mA sollte das nicht überschreiten, oder?

Ich wäre sehr interessiert an der Schaltung, Handyakkus gibt es ja in
diversen Läden wirklich recht günstig. Und leichter als AA-Batterien
sind sie allemal.

Packen wollte ich das ganze in eine sog. "Werkzeugdose" fürs Fahrrad.
Sieht aus wie eine normale Trinkflasche, passt auch in Flaschenhalter
nur hat eben einen normalen Deckel.
Das wollte ich dann möglichst so anordnen, dass daneben noch etwas Platz
für Flickzeug o.ä. bleibt, also man könnte in die Dose Mittig eine
Trennwand oder so einbauen.

Den Schraubverschluss kann man dann noch mit einem Gummiring abdichten,
sodass es auch gegen eintretenden Regen geschützt wäre.

Das ist im moment mein Konzept ;) Heute Nachmittag werde ich mich dann
etwas genauer mit der genauen Schaltung auseinandersetzen und planen :)

Das hier mal angeschaut?

Vor allem die Google-Maps-Anbindung find ich interressant...

http://thomaspfeifer.net/gps_tracker.htm

zum Thema 'Strom auf dem Fahrrad' gab es in der c't vor kurzem einen
Artikel:
Peter Röbke-Doerr (roe)
Strom auf'm Fahrrad
Mit dem Nabendynamo Akkus aufladen

Praxis,Bordnetz fürs Fahrrad,Lichtmaschine, Fahrrad, Bauanleitung, c't
Projekt, Mobilität, PDA, Navigation,Energie,Spezial-Elektronik
MAX1771CPA+

c't 23/07, Seite 190


Bei den Preisen für die kompletten Navi's ist aber auch so ein Projekt
schon wieder fraglich, mit Display und Karten wäre ein Navi auch fürs
Fahrrad ganz nett. Und auch Navi-Mäuse mit integriertem Tracker werden
immer billiger. Für Symbian Mobiltelefone gibts auch sehr brauchbare
Navisoftware, hat ein Kollege mit bis nach Holland gefunden. Da hat er
sich aber die Navi Maus klauen lassen...

Das sind ja alles Logger. Ein Tracker mit AVR und Handy hier:

http://www.opengpstracker.org/

So, ich habe mal alles brauchbare der Lade- und Reglerschaltung
exportiert. Befindet sich alles in der angehängten ZIP-Datei. Hoffe, du
kannst was damit anfangen. Die Anschlüsse für den Akku sind einfach nur
große Lötpads, Eingang und Ausgang sind in dem Fall nur Lötnägel. Die
Schaltung ist so ca. 3,5cm x 2cm groß, weil die Lötnägel und die großen
Lötpads recht viel Platz weg nehmen.

Was man dafür braucht, ist auf jeden Fall ein MAX1811ESA+ von Maxim und
als Linearregler habe ich einen TPS73030DBVT von Texas Instruments
benutzt.
Beides habe ich als Samples bekommen.
Dazu noch ein paar Keramik Kondensatoren und zwei Widerstände im 0805
SMD und das wars schon.
Habe die Sachen bei Farnell bestellt, weil ich KerKos in dieser Größe
(z.B. 10uF) woanders nicht gefunden habe. Dabei kamen 20€ Pauschale
dazu, weil viele Sachen aus den USA kamen. Da ich aber noch einiges mehr
bestellt hatte, hatte sich das wieder gelohnt, da viele Bauteile aus den
USA sehr günstig waren.
Könnte dir auch die Artikelnummern sagen, wenn es dich interessiert.

Der Akku vom W880i hat neu und original ca. 8€ inkl. Versand bei ebay
gekostet.

Wie gesagt, man müsste noch drauf achten, dass der Akku nicht
tiefentladen wird.

@martin, wo ist der unterschied zwischen tracker und logger?

track-verfolgen
log-aufzeichnen

http://dict.leo.org/ende?lp=ende&search=track&...
http://dict.leo.org/ende?lp=ende&search=log&am...

Jetzt hast Du's ins deutsche Übersetzt. Und wo ist jetzt der Unterschied
zwischen 'verfolgen' und 'aufzeichnen'? Wie ist 'verfolgen' definiert?

du bist woanders und siehst wo es ist.

Hans wrote:
> Jetzt hast Du's ins deutsche Übersetzt. Und wo ist jetzt der Unterschied
> zwischen 'verfolgen' und 'aufzeichnen'? Wie ist 'verfolgen' definiert?

Ahh also dem Link zu Folge ist wohl mit Tracker etwas gemeint, dass dann
auch noch zusätzlich 'live' eine andere Person über den Standort des
Trackers informieren kann.

Nein, in dem Fall meine ich dann wirklich einen GPS Logger.

--

@Daniel, vielen Dank für die Dokumente! Ich werd auch gleich mal nach
Samples anfragen.. sind die ICs in SMD Bauart? Gibt es diese auch in
'normal'? :-D

---

@Ernst Bachmann, ja, diese Seite war mitunter der Auslöser für meine
Lust an dem Projekt ;) Möchte aber möglichst viel selber
entwickeln/entwerfen um einfach ein bisschen neue Erfahrungen in
Richtung Elektronik zu machen :-)

Hätte ich einen Laserdrucker, wäre auch diese Direkt-Toner-Methode
(Siehe HP von Thomas Pfeifer) interessant für mich, da damit Platinen
herstellen relativ günstig zu sein scheint... naja dazu fehlt aber der
Drucker :P Wird vielleicht später irgendwann mal angeschafft.

Martin M. wrote:
> @Daniel, vielen Dank für die Dokumente! Ich werd auch gleich mal nach
> Samples anfragen.. sind die ICs in SMD Bauart? Gibt es diese auch in
> 'normal'? :-D

Die Bauteile sind leider alle in SMD Bauform. Bei Maxim finde ich auch
nur NiMh Lade-ICs in im DIP Gehäuse, der Rest ist SMD Bauweise.

Hast du keine Möglichkeit irgendwo eine Platine zu ätzen oder ätzen zu
lassen?

Ansonsten schau mal bei anderen Herstellern nach, ob die passende ICs
haben.

Soo, ich habe mal eine erste Schaltung gezeichnet (nein, ich bin nicht
unbedingt begabt in Eagle :-D).

Versorgt wird die Schaltung wie man sieht von 3AA NiMH Akkus. Sie kämen
im vollen Zustand auf insg. ~ 3,6V, was ja für alle Bauteile in Ordnung
wäre und so der Spannungsregler entfällt. Zum aufladen kann man sie dann
ja einfach aus der Schale nehmen und in ein Ladegerät packen.

Über S2 wird man dann die Aufzeichnung beginnen/stoppen können, die zwei
LED's zeigen Betriebsbereitschaft und Aufzeichnungsstatus an.

Wo ich nicht weiß, ob man das so machen darf, ist die Belegung von Port
B.
Einerseits soll über den SPI Anschluss die MMC Karte beschrieben werden
(laut HP von Ulrich Radig), andererseits muss dort aber auch der
Anschluss für den ISP liegen.

Wenn die SD Karte ausgeseckt ist, sollte es doch eigentlich mit dem
Brennen des Chips keine Probleme geben, oder?
Alternativ könnte man die MMC Karte auch an einen anderen Port hängen
und das beschriebene Software SPI verwenden.

Seht ihr ansonsten noch irgendwelche Groben Fehler oder gibt es
Verbesserungsmöglichkeiten?

Wenn der CS der Flash Karte nicht aktiv ist, sollte es der Karte egal
sein, was auf dem SPI abläuft. (?)

Dürüm Döner wrote:
> Wenn der CS der Flash Karte nicht aktiv ist, sollte es der Karte egal
> sein, was auf dem SPI abläuft. (?)

Stimmt, hört sich surchaus logisch an. Die Karte würde ich
sicherheitshalber trotzdem aus dem Slot ziehen.

Ist die Schaltung denn ansonsten in Ordnung so, oder muss ich noch etwas
verändern?

sollte nicht Rx und Tx vertauscht werden Rx -> Tx Tx->Rx ?

Avr Nix wrote:
> sollte nicht Rx und Tx vertauscht werden Rx -> Tx Tx->Rx ?

Stimmt, macht Sinn. Ist es denn bei der SD Karte und dem ISP Anschluss
richtig? Also MISO -> DI und MOSI -> DO?

Hab den Schaltplan mal ein wenig aktualisiert und den ISP Anschluss auf
den 3x2 Stecker abgeändert (hoffe, die Pinbelegung stimmt?)

MOSI: Master Output / Slave Input
MISO: Master Input / Slave Output
DI: Data In
DO: Data Out

Da es klar sein sollte, dass Daten vom Controller raus gehen (Master
Output) und bei der SD Karte rein gehen (Data Input) muss natürlich MOSI
mit DI verbunden werden. Das gleich Spiel in die andere Richtung -> MISO
an DO.

Daniel Reinke wrote:
> MOSI: Master Output / Slave Input
> MISO: Master Input / Slave Output

Okay, was die Abkürzungen genau bedeuten wusste ich bislang nicht, danke
dafür! Hab die Anschlüsse zur SD Karte jetzt vertauscht.

Dann würd ich sagen, die Schaltung ist erstmal so fertig, wenn niemand
noch etwas Fehlerhaftes findet.

Sollte ich vielleicht noch irgendwo zum Schutz/zur Stabilität Dioden
oder Kondensatoren setzen?

Ansonsten werde ich mich denke ich mal morgen bzw. Montag um die
Beschaffung der Bauteile kümmern =) Ich werde euch aufjedenfall auf dem
Laufenden halten (naja, eher "ich muss [...]", da ich mit Sicherheit
noch an das eine oder andere Problem gelange ;-))

Dass der 100nF Keramik Kondensator so nah wie möglich an die Vcc und GND
Anschlüsse des Controllers kommen, weiß du aber, oder? Ist aus dem
Schaltplan nicht so direkt ersichtlich, wie du den verlöten willst...

Ähem... natürlich wusste ich das :D ... und schon wieder habe ich etwas
neues dazugelernt, danke für den Tipp!
Mir erschließt sich nur nicht so ganz, wieso die Position hier von
Bedeutung ist, hauptsache zw. VCC und GND, oder nicht? Ich schau mal im
Internet nach, werds aber aufjedenfall im Schaltbild bzw. auf der
späteren Platine berücksichtigen.

Martin M. wrote:
> Ähem... natürlich wusste ich das :D ... und schon wieder habe ich etwas
> neues dazugelernt, danke für den Tipp!
> Mir erschließt sich nur nicht so ganz, wieso die Position hier von
> Bedeutung ist, hauptsache zw. VCC und GND, oder nicht? Ich schau mal im
> Internet nach, werds aber aufjedenfall im Schaltbild bzw. auf der
> späteren Platine berücksichtigen.

Je näher der Kondensator am uC ist, desto schneller/besser kann er Strom
nachliefern, wenn es zu einem Engpass kommt. Die Engpässe können
entstehen durch die recht hohen Schaltgeschwindigkeiten eines uC.
Dadurch fließen immer kurzzeitig recht hohe Ströme. Damit in dem Fall
die Versorgungsspannung nicht einbricht, wird eben ein 100nF Kondensator
nahe dem uC vorgesehen, der die Engpässe ausgleicht durch das Abgeben
der zuvor gespeicherten Engergie. In den Ruhephasen kann er sich dann
wieder aufladen.

Idealerweise sollte man Kondensatoren sogar als 4-Pol verdrahten. D.h.
dass keine "Stichleitungen" zu einem Kondensator gemacht werden. In dem
Fall würde die Wirkung nachlassen. Aber das ist ja nicht immer möglich
und nötig, ist eben eine ideale Vorgehensweise. ;)

Hallo!

Mein GPS Logger entwickelt sich im moment relativ sehr gut :-D

Die Hardware ist soweit fertig (für Lochraster hab ich es sogar ziemlich
klein bekommen), die Software so zu ca. 60%.
Das beduetet im Detail, über den Taster kann die Aufnhame schonmal
gestartet/gestoppt werden, auf die SD Karte kann
zugregriffen/geschrieben werden und die LEDs geben den Status an.

Das einzige, was mir noch fehlt, ist das GPS Modul. Dazu bin ich gerade
das Datenblatt des ATMega8 bezüglich USART am lesen (Ab Seite 130) und
mir stellt sich zur Zeit eine Frage:

Darf RXEN und TXEN gleichzeitig aktiviert sein? Also kann ich
gleichzeitig senden und Empfangen? Denn so wie ich das sehe, wird ja
sowohl das Eingehende als auch das Ausgehende in das UDR Register
geschrieben. Somit kann doch eigentlich nur eines der beiden
gleichzeitig funktionieren.

Im Beispiel-Sourcecode (Datenblatt Seite 136) wurde aber gesetzt :

/* Enable Receiver and Transmitter */
UCSRB = (1<<RXEN)|(1<<TXEN);

Es werden also beide Leitungen aktiviert, sehe ich das richtig?
Wenn dann während des Sendens etwas neues ankommt, müsste es doch zu
einem Konflikt kommen?

Ich hoffe ihr könnt mir da ein wenig auf die Sprünge helfen :) Im Anhang
ein kleines Foto des Loggers (das rechte Gehäuse ist die "Hauptplatine"
und der SD Karten Slot (auch zugänglich wenn das Gehäuse geschlossen
ist; für den Taster werde ich noch ein kleines Loch in den Deckel machen
kann, sodass er auch von außen zugänglich ist),
Im linken Gehäuse befindet sich der An/Aus Schalter, das GPS Modul und
auf der Unterseite die Akkus.
Die Gehäuse sind Maxim Sample Boxen =)

Ahh, hab folgendes gefunden:

The USART Transmit Data Buffer Register and USART Receive Data Buffer Registers
share the same I/O address referred to as USART Data Register or UDR. The Transmit
Data Buffer Register (TXB) will be the destination for data written to the UDR Register
location. Reading the UDR Register location will return the contents of the Receive Data
Buffer Register (RXB).

Das heißt, wenn ich das Register beschreibe, wird es Intern wo anders
gespeichert, als wenn ich es auslese, richtig?

Also sollte Gleichzeitiges Senden/Empfangen möglich sein, richtig?

P.S.: DEUTSCHLAAAAND :-D

Liest hier überhaupt noch jemand???

Naja, also das UART Problem habe ich nun gelöst, indem ich einfach eine
Library nehme (die von Peter Fleury). Es scheint soweit alles zu
funktionieren.

Jetzt brauche ich aber hilfe von Leuten, die schonmal mit diesen
Navilock GPS Modulen gearbeitet haben:


Frage 1:
Reicht es, einfach nur Spannung anzulegen, damit der sich mit Satteliten
verbindet, oder muss man dem Modul noch Befehle senden?



Zur Zeit sende ich theoretisch zuerst die Bytes um in den NMEA Modus zu
wechseln mit 9600 Baud, dann stelle ich auf 4800 Baud runter (kleinere
Fehlerrate bei 4 MHz Quarz) und sende den Befehl "101 -
NavigationInitalization" wobei ich einen Kaltstart auslöse (zumindest
theoretisch).

Ich weiß nicht, ob die Befehle auch richtig ankommen, beim Anschalten
der Schaltung leuchtet die LED am GPS Modul kurz auf und geht wieder aus
(so wie im Datenblatt beschrieben) aber danach geht sie nicht mehr an.
Laut Datenblatt dauert ein Fix beim Kaltstart 42 Sekunden -- Ich habe
deutlich länger gewartet ohne Erfolg (auf dem Balkon < kann das ein
Problem sein?).


Frage 2:
Und werden die Nachrichten vom Modul (z.B. GGA), die eig. jede Sekunde
gesendet werden sollen, auch gesendet, wenn kein Fix vorliegt?*



Beim ATMega kommt nämlich irgendwie nichts an - Oder mein Quellcode ist
noch Fehlerhaft...

Ich bitte um eine Antwort. Es wird doch bestimmt jemanden hier geben,
der mit diesem Modul schoneinmal gearbeitet hat, oder? =)

Ich hab bis jetzt noch nicht gezielt mit dem modul gearbeitet ....
normalerweise ist es so das die gps module anfangen die daten von allein
auszuspucken .... viele haben ne backupbatterie um die einstellungen zu
speichern .... bei den meisten modulen kannst du einstellen welcher
datensatz wie oft gesendet wird !

fix .... wie "offen" ist denn da nach oben ? häuserschlucht ? known
problem geh mal richtig raus .... bei ersten kalt start kanns bis zu 15
min dauern ...

hellboy wrote:

> Ich hab bis jetzt noch nicht gezielt mit dem modul gearbeitet ....
> normalerweise ist es so das die gps module anfangen die daten von allein
> auszuspucken ....

Klingt beruhigend, dass die Module von selbst anfangen, auszuspucken ->
Also möglicherweise erst nach einem Fix?

> viele haben ne backupbatterie um die einstellungen zu
> speichern ....

Also auf dem Modul befindet sich eine kleine Knopfzelle, das stimmt.
Allerdings kann er ja noch nichts gespeichert haben, da es noch nie
einen Fix gab.
Ich hab jetzt mal ohne jegliche überprüfung einfach jedes uart_getc()
auf die SD Karte geschrieben, es wurden nur NULlen geschrieben (0x00).
Vom Modul kommt also nichts.

> bei den meisten modulen kannst du einstellen welcher
> datensatz wie oft gesendet wird !

Also bei dem Befehl, von dem Binärmodus in den NMEA Modus zu wechseln,
gibt man an, welcher Datensatz wie oft gesendet werden soll. Ich habe
testweise alles ausgestellt, nur GGA sollte jede Sekunde komme.

>
> fix .... wie "offen" ist denn da nach oben ? häuserschlucht ? known
> problem geh mal richtig raus .... bei ersten kalt start kanns bis zu 15
> min dauern ...

Häuserschlucht würde ich jetzt nicht sagen, hab mal ein Foto angehängt,
mit Blick nach oben. Eigentlich ist ein großteil des Himmels frei. Aber
15 minuten habe ich noch nicht gewartet - Werde morgen auch mal unter
komplett freiem Himmel testen.

Vielen Dank schoneinmal

>Klingt beruhigend, dass die Module von selbst anfangen, auszuspucken ->
>Also möglicherweise erst nach einem Fix?

normalerweise senden die module immer auch wenn kein fix existiert... in
einem der strings ... ich weiss leider nicht mehr welchem steht  aber es
gibt einen string in welchen die aktuelle empfangslage drin steht ich
glaube er heist $GPGSV aber wenn nichts da ankommt solltest du eventuell
mal messen ob die kiste überhaupt was ausspuckt!(Oszi .... zur not tuts
auch ne low current led mit widerstand ... blinkts gehen daten drüber)
sonst wird an deinem programm denk ich noch irgendwas nicht richtig
funktionieren!

Bist du sicher das du jedes mal neu konfigurieren must ?

hellboy wrote:
>>Klingt beruhigend, dass die Module von selbst anfangen, auszuspucken ->
>>Also möglicherweise erst nach einem Fix?
>
> normalerweise senden die module immer auch wenn kein fix existiert... in
> einem der strings ... ich weiss leider nicht mehr welchem steht  aber es
> gibt einen string in welchen die aktuelle empfangslage drin steht ich
> glaube er heist $GPGSV aber wenn nichts da ankommt solltest du eventuell
> mal messen ob die kiste überhaupt was ausspuckt!


> (Oszi .... zur not tuts
> auch ne low current led mit widerstand ... blinkts gehen daten drüber)
> sonst wird an deinem programm denk ich noch irgendwas nicht richtig
> funktionieren!

Hallo!

Da ich kein Oszi habe (ist für mich auch etwas sehr teuer), habe ich es
mit der LED versucht.
Also auf dem RX Pin des GPS Moduls wird kurz nach dem Anschalten ein
wenig versendet, dann ist die Leitung konstant High (so sollte es denke
ich auch sein?)
Auf dem TX Pin kann man ein regelmäßiges Muster erkennen. Es würde auch
ungefähr dazu passen, dass jede Sekunde Daten versendet werden. Naja
kommt mir etwas kürzer vor als eine Sekunde. Aufjedenfall ist die Led
die ganze Zeit auf voller Helligkeit, und jede Sekunde dann für kurze
Zeit ein wenig 'gedimmt' (was ja dafür sprechen würde, dass viele Nullen
und Einsen gesendet werden).

Das Modul scheint also die Daten zu versenden, nur meine Software
bekommt irgendwie nichts.

>
> Bist du sicher das du jedes mal neu konfigurieren must ?

Hmm also ich denke doch mal ich muss zumindest vom Sirf-Binär in den
NMEA Modus wechseln, oder?

Naja ich geh jetzt erstmal was spazieren ;-) Werde dann später Berichten
ob es einen Fix gab.

Sooo... ich habe einen Fix bekommen!

Das Modul ist also in Ordnung, jetzt muss ich nur noch mit dem UART
kämpfen ;-) Hat so ca. 10 - 20 Minuten gedauert (ich habe nicht ständig
auf das Modul geschaut, deswegen kann ich nichts genaueres angeben).

Naja zum Glück funktioniert das schonmal. Jetzt muss ich noch schauen
wie das mit dem Kalt/Warmstart ist, ich möchte nämlich nicht unbedingt
jedes mal vor der Verwendung erst noch 20 Minuten warten ;-)

Aufjedenfall geht es, wenn man dem bei dem Befehl 101 einfach den
letzten Längen und Breitengrad angibt, aber speichert der dies
möglicherweise auch intern und man kann es über irgendeinen Befehl
abrufen?

Ich bin ein wenig weiter mit meinem Problem. Ich habe nun die
eingehenden Zeichen (uart_getc()) noch auf die Fehler überprüft, die
möglich sein können und das Ergebnis der Überprüfung dann auf die SD
Karte geloggt.
Es stellt sich heraus, dass ein Buffer Overflow stattfindet.

Trotzdem müsste im Datenteil (Lower-Byte) doch irgendetwas ankommen, und
nicht immer 0x00, oder?

Ich habe jetzt mal alle Delays beim Aufzeichnen entfernt, nun bekomme
ich nur noch am Anfang einen Buffer Overflow.

Danach kommen aber recht kryptische Daten:

ˆŒˆ
ŒHŠHˆN€(ókŒJÈL©hžÎYZ½ˆJŠ
ˆˆN‚ø¹ÎH
ˆ‚ŒŒŒJHˆŒÌxĹî¿))))©X:(óïYZ½ˆŒŒˆŒÌŒŒŒŒNŠ(ó÷™Y))))))Y•­ŒŽŒŒŽÌ
Ĺ¾ŠˆˆLŠJLŒŒŠŠHˆŒˆ
ŒŠˆŠNˆ(ówIII*jYLŠŒ
Š

Bzw. in Hex-Ansicht:

"000000000  88 0C 8C 88 0C 0A 8C 48-0C 8A 48 88 4E 80 28 F3   |ˆŒˆ.ŒHŠHˆN€(ó|"
"000000010  6B 18 8C 0C 4A 08 C8 08-4C A9 68 9E 90 CE 9D 59   |kŒJÈL©hžÎY|"
"000000020  5A BD 0E 88 4A 0C 8A 0A-88 0C 88 08 4E 82 F8 B9   |Z½ˆJŠ.ˆˆN‚ø¹|"
"000000030  CE 04 48 0A 08 0E 88 82-8C 8C 8C 4A 48 88 8C CC   |ÎH.ˆ‚ŒŒŒJHˆŒÌ|"
"000000040  78 C4 B9 EE BF 29 29 29-29 A9 58 3A 28 F3 EF 59   |xĹî¿))))©X:(óïY|"
"000000050  5A BD 0E 88 8C 8C 88 08-8C CC 8C 8C 8C 8C 4E 8A   |Z½ˆŒŒˆŒÌŒŒŒŒNŠ|"
"000000060  28 F3 F7 99 59 29 29 29-29 29 29 59 95 AD 8C 8E   |(ó÷™Y))))))Y•­ŒŽ|"
"000000070  8C 8C 8E CC 0A C4 B9 BE-08 8A 88 88 4C 8A 4A 4C   |ŒŒŽÌ.Ĺ¾ŠˆˆLŠJL|"
"000000080  8C 8C 8A 0C 8A 48 88 0C-8C 88 0C 0A 8C 08 0C 8A   |ŒŒŠŠHˆŒˆ.ŒŠ|"
"000000090  88 8A 4E 88 28 F3 77 49-49 49 2A 6A 59 4C 8A 8C   |ˆŠNˆ(ówIII*jYLŠŒ|"
"0000000A0  0A 0C 8A                                          |.Š             |"

Nach NMEA sieht das nicht unbedingt aus. Nach diesem Binär Protokoll
aber auch nicht, da dort alle Meldungen so wie ich das verstanden habe
mit A0 A2 .... Anfangen, solch ein Muster kann ich hier aber nicht
finden.

Aufjedenfall wiederholt sich dieser Datenblock dann fortlaufend,
manchmal mit kleinen Änderungen bei den Zeichen, aber im Groben ist es
der gleiche.



Was könnte das sein???

hab jetz nicht den ganzen Thread gelesen, aber das sieht nach falscher
Baudrate aus.

Hi

Mach doch mal einen RS232-Konverter dran und teste das Modul am Rechner.
Oder Programmiere dir einen anderen AVR so, das er einen NMEA-String
sendet.
Bist du sicher, das deine Baudrate stimmt?

MfG Spess

Hi

Noch was vergessen: Auf der Navilock-Webseite kannst du das Programm
'GPS-Info' herunterladen. Damit lassen sich die Module ganz gut testen.
Serieller Anschluss vorrausgesetzt.

MfG Spess

Juhuu!!!!

Ich habe nun einfach das Umschalten auf 4800 Baud abgestellt (d.H. der
Uart bleibt weiterhin in 9600 Baud) und es kommen richtige Daten an!

Was mich nur wundert ist, dass es genau garnicht dem entspricht, was ich
dort so bei dem Init Befehl eingestellt habe. Also eigentlich wollte ich
ja testweise nur die GPGGA Message 1 mal pro Sekunde haben, es werden
aber noch viel mehr versendet.
Außerdem habe ich eigentlich 4800 Baud eingestellt, trotzdem wird es
über 9600 Baud geschickt.
Naja aber das kann man ja noch mit Hilfe von NMEA Messages
'nachjustieren' ;-) 4800 Baud möchte ich, weil die
Fehlerwahrscheinlcihekit bei dem 4 MHz Quarz etwas geringer ist - Und
schnell genug für ein Datensatz pro Sekunde ist es allemal.

Naja aufjedenfall bin ich Glücklich, dass es endlich Funtkioniert hat :)
Vielen Dank für die Tipps bezüglich der Baudrate, wäre nie von selbst da
drauf gekommen (weil wie gesagt, eigentlich ist 4800 eingestellt...)

Hi

Sieh dir mal das angehängte Datenblatt an. Da sind weiter unten einige
Flowcharts drin. Anscheinend ist bei der Umprogrammierung ein bestimmter
Algorithmus einzuhalten.

MfG spess

Hmm irgendwie habe ich ein Problem dass ich bis jetzt noch nicht hatte.

Ich kann die SD Karte nicht mehr richtig auslesen oder beschreiben. Also
Initalisieren (sowohl MMC Init als auch InitFAT) funktioniert, nur bei
Befehlen wie "fexist_" oder "fopen_" wird mir eine 0 zurückgegeben (also
scheinbar ein Fehler). Die Datei die ich aber versuche, zu öffnen,
existiert definitiv und sogar wenn nicht, müsste fopen_ die Datei
erstellen, wenn ich den Quellcode der Lib richtig verstanden habe.

Hab auch versucht, die Karte nocheinmal zu Formatieren (FAT16,
Clustergröße 512 Byte) -- ohne Erfolg.

Was könnte hier die Ursache sein?

Für das FAT Dateisystem benutze ich MikroFAT16 von mikro-control.de, für
die MMC Ansteuerung die Lib von Ulrich Radig. Es hat alles Funktioniert,
erst seit kurzem will es nicht meht (und ich weiß nicht, wieso...).

Ich hab mal versucht, andere Libs zu benutzen, muss aber feststellen,
dass diese Kombination die einzige ist, die auf den ATMega8 passt. Bei
allen anderen (Ronald Riegel, Holger Klabunde..) sagt mir der
Compiler/Linker dass kein Platz mehr da ist.

Aber eig. muss es mit dieser Kombination funktionieren, es hat ja schon
einmal sehr gut Funktioniert (die Route war bis auf ein paar Zick-Zack
Linien sehr gut).

Formatiert habe ich mit der Arconis Disk Director Suite. Unter Windows
direkt (vista) kann man nicht in Fat16 formatieren..

Irgendwelche Vorschläge, was ich probieren könnte?

Ich hab es jetzt wieder zum laufen bekommen, musste dafür einfach nur
die Karte nocheinmal formatieren undzwar mit dem Tool von Panasonic,
dass hier vor kurzer Zeit durchs Forum gegeistert ist (gleiche Probleme
mit der SD Karte : Beitrag "SD Formatieren" )

Jetzt läuft es wieder und ich hab auch schon ein richtig gutes Ergebnis
gewonnen:

http://maps.google.com/maps/ms?ie=UTF&msa=0&am...

Bis auf ganz kleine Abweichungen (und, dass die Route insgesamt ein
wenig versetzt ist - aber das ist nicht so schlimm) wurde die Route
richtig gut aufgezeichnet. Heute nehm ich den Logger dann mal mit auf
eine lange Tour.

*<edit>*
Ich sehe geade, dass die Route in Google Earth irgendwie detallierter zu
sein scheint, also die Kurven sind nicht so eckig sondern etwas genauer
- Google Maps schient wohl ein paar Punkte zu entfernen ...
*</edit>*

Trotzdem werde ich aber noch einen richtigen Pegelwandler und geregelte
3,3V für die SD Karte einsetzen, da ich denke, dass sie die nicht ganz
so genaue Spannung nicht gut verträgt. Alles andere werde ich dann auf 5
Volt betreiben, liegt ja sowohl beim GPS Modul als auch beim AVR
innerhalb der Spezifikationen.
Als Pegelwandler habe ich mir ein Maxim Sample vom MAX3378 bestellt, ich
hoffe das ist der richtige.

Ansonsten hatte ich die Idee, das ganze zu einem simplen Navi zu
erweitern - Also dass man in Google Earth einfach einen Pfad mit ein
paar Wegpunkten erstellt, und mein Logger mich dann von Wegpunkt zu
Wegpunkt (über Luftlinie!! Nicht über eine Landkarte, das wär dann doch
zu aufwändig) leitet. Wenn man bei jeder Kurve einen Wegpunkt macht,
sollte das relativ praktikabel sein, denke ich.

Nur mein Problem ist im moment der Speicherplatz auf dem AVR. Durch die
FAT Lib hab ich nur noch ca. 1 KB auf dem Chip frei, das wird glaube ich
etwas zu eng für das ganze 'Navi'System.

Da ich aber nicht alles komplett umbauen möchte, suche ich nach einem
AVR gleicher Größe und gleicher Pinbelegung, nur mit mehr Speicher.

Kennt ihr da irgendeinen? Ich habe mir den ATMega168 ausgeguckt, aber
bin mir nicht sicher ob der nun einen schmalen oder breiten Sockel
besitzt (ich bräuchte den Schmalen IC Sockel, 28 Pins - So wie ein
ATMega8L8 eben :D)

Dann kämen dann nur noch 3 Leuchtdioden und ein Summer (oder evtl.
stattdessen ein LCD Display) dran und eben die Software, die die Route
einliest und mich leitet ;)

Ich hoffe ihr könnt mir bei der µC-Auswahl etwas helfen :) Vielen Dank.