Ein relativ einfaches und kleines Gerät, welches die Daten einer
GPS-MOUSE einliest und u.a. die Entfernung zum vorher einprogrammierten
Ziel hinreichend genau berechnet.

Gern nutze ich dieses Gerät, um bei Wanderungen oder Fahrrad-Touren die
gewohnte Frage meiner "besseren Hälfte"

"Wie weit ist es denn noch?"

glaubwürdig und motivierend zu beantworten ;)


------------------------------------------------------------

Berechnungsverfahren:

Nach dem der GPS-String (ca. 400...500 Byte) erfolgreich eingelesen
wurde, werden bestimmte Daten aus diesem String (z.B. die aktuellen
Koordinaten) herausgefiltert.

Nun erfolgt die Berechnung der Entfernung (Luftlinie) zum Ziel
in 2 Schritten:

1. Schritt:
Differenz Östliche Länge und Differenz Nördliche Breite
von GRD nach "m" bzw. "km" umrechnen.

Die Differenzen der Winkel werden mit einem Faktor (70km/GRD bzw
111km/GRD) multipliziert.

Die 70km/GRD gelten aber nur für den Bereich Deutschland
70Km/GRD= 111 x (cos 50 GRD)

2. Schritt
Vereinfachte Berechnung mittels rechtwinkligen Dreieck (c² = a² + b²)
Beide Differenzen werden quadriert, addiert und daraus die Wurzel
gezogen.

------------------------------------------------------------

Weitere Features:
- momentane Entfernung zum Ziel (bis 65.535m im m, dann km)
- momentane Geschwindigkeit (SOG)
- momentane Höhe (absolut/relativ)
- momentaner Kurs
- momentane Position (dezimal / GRD-Minute)
- momentane Abweichung zum Ziel (Länge/Breite im m/km)
- UTC-ZEIT
- Anzahl empfangener Satelliten
- Betriebsspannung
- Temperatur
- 11 fest einprogrammierte Referenz-Positionen (z.B. Zuhause)
- 3 frei speicherbare Referenz-Positionen
(z.B: wo habe ich gerade das Auto abgestellt)
-Betriebsstunden (interessant für Akku-Betrieb)
- alle LEDs lassen sich abschalten
- die rote LED (GPS A bzw. V) kann bei A leuchten, oder bei V
(A=GPS-aktiv   V=kein oder schlechter Empfang)

------------------------------------------------------------

Die einzelnen Menues werden mittels 4 Tasten programmiert:
(ESCAPE,MINUS,PLUS,ENTER)
Wobei beim betätigen der Taste ESCAPE immer das Hauptmenue angezeigt
wird.


Als Datei habe ich angefügt:
- Schaltplan
- Fuse-Bits
- Assembler-Code (4-Dateien)
- hex-File
- 2 Bilder


Bernhard


PS: Bei Gelegenheit werde ich dieses Projekt für einen anderen µC
umschreiben, denn der ATmega8 ist momentan ziemlich sehr voll.

Geplant zind folgende Features:
- Speicherung der Koordinaten und Höhenangaben im ext. TWI-65k-EEPROM
  (Fahrtenschreiber)
- manuelle Eingabe von Referenz-Koordinaten

wow das gefällt mir sehr gut :). wollte auch schon immer sowas in der
art bauen. Hört sich gar nicht so schwer an. Nur wo krieg ich eine
serielle GPS-Maus her?

@Philipp

>Nur wo krieg ich eine serielle GPS-Maus her?

relativ günstig bei e-bay, ca 40 EUR (muss nur eine serielle sein)


Bernhard

Gute Idee!
Was mich interessieren würde:
Wie genau ist denn die Entfernungsberechnung (Fern/Nahbereich)?
Ich hatte immer gedacht, dass man mit "einfacher" trigoneometrischer
Rechnung keine akzeptable Genauigkeit erreicht.
Ich hatte so etwas ähnliches auch mal probiert, bin aber dann (vorerst)
an den knappen Resourcen des uCs gescheitert.

@Holger

>Wie genau ist denn die Entfernungsberechnung (Fern/Nahbereich)?

Die Genauigkeit im Nahbereich ist vorallem von den gemeldeten
Positionsdaten des GPS-Empfängers abhängig.

Ein handelsüblicher GPS-Empfänger kann seine Position im Bereich von
3 bis 10 m genau bestimmen, vorausgestzt der Satellitenempfang wird
nicht durch örtliche Reflexionen und ungünstige Satellitenstellung
beeinflusst.

Im Berechnungsverfahren habe ich aus diesem Grund sogar auf eine
Kommastelle verzichtet, da ich merkte, dass eine übertriebene
Berechnung für die Entfernungsberechnung keine Vorteil brachte.

Höhenunterschiede :

Das vorgestellte Berechnungsverfahren verzichtet auf eine Berechnung
des Höhenunterschiedes.
D.h. bewegt man sich von einem Berg abwärts bekommt man weniger
gemeldet als man wirklich zurückgelegt hat.
Aber dieser Fehler ist bei einer Entfernung von 1000m und einem
Höhenunterschied von 100m vertretbar (5m)

Berechnung Nördliche Breite:
Die Entfernung auf einem Breitengrad, wenn man sich exakt auf den
Geografischen Nordpol zubewegt wird hinreichend genau mit 111 km pro
Grad berechnet.

Berechnung Östliche Länge:
Hier gibt es das größte Problem, da der Längengrad bei jeder
Breitengradänderung einen anderen Wert hat.
In der Nähe des Nordpoles wären es
ca. 2km pro GRD, auf dem Äquator  ca. 111 km pro GRD, für Mitte
Deutschland habe ich 70 km pro GRD festgelegt.

Nach meinem derzeitigen Erkenntnisstand beträgt die Fehlerabweichung
zwischen 1...10% bei einer Entfernung unter 500km und wenn eine
Positionsangabe (momentan / Referenz) auf dem 51 Breitengrad
(Thüringen) ist.


Bernhard

Könnte man nicht aus der position herausfinden, auf welchem breitengrad
man sich befindet, und so mit einer tabelle den richtigen wert für den
längengrad bestimmen?

Nur so eine Idee. So wird das gerät auch im urlaub nutzbar :P

>Könnte man nicht aus der position herausfinden, auf welchem
>breitengrad man sich befindet, und so mit einer tabelle den >richtigen
wert für den längengrad bestimmen?

Da gebe ich Dir Recht, würde man die Cosinus-Werte von 0 bis 90 GRD in
einer Tabelle speichern, dann könnte man zumindest in dieser Hinsicht
die Genauigkeit der Berechnung verbessern.

Bernhard

wäre die ideale Hardware dafür nicht ein AVR Butterfly?

@Johannes

>wäre die ideale Hardware dafür nicht ein AVR Butterfly?

Wenn man den Programm-Code stark dezimiert (derzeit 8k) und sich nur
auf die wesentlichsten Berechnungen konzentriert, warum nicht.

Bernhard

Klasse Projekt! Sowas find ich mal wieder richtig gut. Mal sehen wann
mir ne serielle GPS-Maus über den Weg läuft, dann bau ich mir auch
Eins.

bye

Frank

Ich denke auch, dass ich sowas (und vielleicht deinen code als anregung
;) ) In meinem nächsten projekt einsetzen werde.
Ich will einen GPS empfänger an nen µC hängen, der dann, wenn das
handy, welches auch am µC hängt mit ner SMS mit nem bestimmten text
drin erhält Die Position per SMS an eine eingestellte Nummer schickt
:P

Frei nach dem Motto "Jetzt neu im Spaarabo: Schicke 'P1' an die
01734684654(Frei erfunden ... falls es wen getroffen hat sorry ^^) um
die Position deines Autos zu erfahren."

Und so will ich halt auch noch in die SMS schreiben, wie groß die
entfernung zu ein paar festgelegten zielen ist und vielleicht noch die
aktuelle geschwindigkeit o.ä. also werden deine berechnungen mir wohl
helfen :P

@Frank

> Klasse Projekt!

Danke.

Den Prototyp habe ich vor einem Jahr an mein Fahrrad montiert,
scherzhafterweise bezeichnete ich ihn als Fahrradlampe mit
GPS-Funktion.

@Hauke

>Ich will einen GPS empfänger an nen µC hängen, der dann, wenn das
>handy, welches auch am µC hängt mit ner SMS mit nem bestimmten text
>drin erhält Die Position per SMS an eine eingestellte Nummer schickt

Sehr interessante Idee, geht in die Richtung Diebstahl-Schutz.

Bernhard

@Bernhard Schulz
Klasse  gemacht und die Diebstahlgeschichte per SMS wäre eine tolle
Erweiterung.
Kann man darauf hoffen?

@Bernd

> die Diebstahlgeschichte per SMS wäre eine tolle
> Erweiterung. Kann man darauf hoffen?

Ich hoffe, dass sich Hauke mit dieser Problematik beschäftigen kann,
denn mir fehlen leider die technischen Möglichkeiten.

Bernhard

Ja ich habe einem Freund versprochen, das für ihn zu realisieren. Werde
dann das gesammte Projekt auch hier veröffentlichen!
Immoment warte ich nur auf einen günstigen GPS empfänger bei ebay. N
altes Handy und soweiter hab ich schon hier.

Soooo ... hab endlich n GPS empfänger gefunden
http://cgi.ebay.de/1-GPS-Empfaenger-GPS-MS1E-der-b...
zu dem hab ich im internet shcon n bisschen was gelesen. Soll von der
leistung zwar nicht der allerbeste sein, aber der preis ist unschlagbar
günstig.
Antenne muss man extra kaufen:
http://cgi.ebay.de/GPS-Keramikantenne-Anschluss-f-...
Damit werde ich jetzt erst mal rumexperimentieren.

Ich würde gerne die Gps-Geschichte nachbauen bzw. verwenden.
Meine Assemblerkenntnisse sind eher bescheiden, läßt sich des Code in
Bascom AVR ohne weiteres einbeziehen, wenn ja gebt mir ein Beispiel wie
danndie Variablen behandelt werden.

>Meine Assemblerkenntnisse sind eher bescheiden, läßt sich des Code in
>Bascom AVR ohne weiteres einbeziehen.....

Ich kann Dir aber nicht sagen, ob dann das Programm in Bascom in den µC
passt?

Bernhard

@Bernhard
Ich wollte das Ass-Prg. dann in Bascom aufrufen können. Der
Controllertyp kann doch auch ein Mega32 werden, oder?
Wenn das andere User mit 'ner SMS-Routine verwenden wollen, werden die
wohl auch einen grösseren Speicher brauchen.
MfG

Welchen controller ich genau verwende kann ich noch nich genau sagen
aber der M32 wirds wohl sein ... sonst kanns ja nich passen :)

Wem's denn gefällt:

hier nen gezipptes Excel-sheet, das die Entfernung zwischen zwei
Koordinaten auf der Erdoberfläche berechnet, natürlich ohne
Berücksichtigung unterschiedlicher Höhen, aber ansonsten 'richtig'.

Cheers
Detlef

@Detlef

Danke für Dein Excel-Sheet, habs mir gerade mal angeschaut.
Sehr interessant.

Könntest Du vielleicht mal ganz kurz und knapp den Rechenweg erklären?

Danke

Bernhard

Hallo Bernhard,

bißchen verquer, die Rechnung, aber eleganter konnte ich nicht: Ich
rechne die Kugelkoordinaten der Länge/Breite auf kartesische
Koordinaten um, das steht in den Formelsammlungen. Dann berechne ich
die Entfernung der Punkte, also die Länge des 'Tunnels' ohne
Berücksichtigung der Erdkrümmung, der vom Startort zum Zielort führt.
Zu der Länge des 'Tunnels' berechne ich dann den zugehörigen Weg auf
der Erdoberfläche, der 'Tunnel' ist ja ne Sehne an einen Kreis.

Cheers
Detlef

@Detlef

Ich werde bei Gelegenheit mal das genauere Berechnungsverfahren incl.
Erdkrümmung mit meinem stark vereinfachten vergleichen und die
Fehlerabweichung ermitteln.

Könntest Du vielleicht mal Dein Berechnungsverfahren mit meinem
vereinfachten berechnungsverfahren in eine Excel-Sheet vereinen?

Danke

Bernhard

Google doch mal nach:
Benutzerhandbuch GPSiSy
da wird ein Gps-System auf Basis MyAVR vorgestellt. Da benutzen die
auch Karten zur Darstellung der Koordinaten.
Könnte man dieses Programm hier auch benutzen, und wo gibt es Info's?

@Detlef

konnte mich gerade etwas intensiver mit Deiner Excel-Berechnung
beschäftigen.

Danke nochmals.

Interessant ist die Fehler-Abweichung zischen dem vereinfachten
Berechnungsverfahren und Deinem genaueren Verfahren.

Ich war erstaunt, dass der Berechnungsfehler, innerhalb Deutschlands,
im einstelligen Prozent-Bereich liegt.

Ich werde das Ergebnis dieser Fehleruntersuchung bei Gelegenheit hier
grafisch darstellen.

Bernhard

Ich freu mich drauf :)

Ich habe Detlef A sein ausfürrliches und genaueres

Berechnungsverfahren mit dem vereinfachten Berechnungsverfahren

verglichen.


Beispiel: Erfurt - Flensburg (kommt bestimmt bekannt vor)

Bei einer errechneten Wegstrecke von 435km beträgt die Abweichung
ca. 900 Meter (0,2%).

Ich denke, dieser Fehler ist vertretbar.


Bernhard

Hallo Bernhard,
ich habe mir dein GPS auf Lochraster
nachgebaut,es will aber nicht so richtig laufen!!
Vielleicht kannst du mir ein wenig auf die Sprünge helfen.
MfG Gerhardt

Hallo Gerhardt,

>es will aber nicht so richtig laufen

Welches Fehlerbild zeigt sich?

Liegen alle Spannungen am µC an?

Fuse-Bits richtig gesetzt?

Zeigt das Display etwas an?

Bernhard

Moin moin,

die kürzeste Verbindung zweier Punkte auf einer Kugelobefläche liegt
immer auf einem Großkreis, also einer Schnittfläche durch die Kugel,
die durch den Kugelmittelpunkt und die beiden Punkte auf der Oberfläche
geht. Dies wird in der Fliegerei verwendet. Damit sollte sich eine
wirklich exakte Berechnung der Entfernung durchführen lassen, egal wo
man sich auf der Erde befindet.

Die Formel findet sich z.B. hier:
http://williams.best.vwh.net/avform.htm#Dist
http://de.wikipedia.org/wiki/Gro%C3%9Fkreis

Viel Spaß und Gruss
Hans-Christian

Hallo Hans-Christian,

>Damit sollte sich eine
>wirklich exakte Berechnung der Entfernung durchführen lassen, egal wo
>man sich auf der Erde befindet.

Da gebe ich Dir gerne Recht, aber diese Berechnungsverfahren sind sehr
umfangreich und auf einem 8-BIT-µC nur schwer zu realisieren.


Bernhard

Hallo Bernhard,

OK, in Assembler möchte ich daß auch nicht machen, aber es gibt ja den
GCC, und damit sollte es leicht zu implementieren sein. Schnell genug
ist so ein ATmega ja und die Berechnung muß bestenfalls nur sekündlich
erfolgen. Ich bin immer wieder von der Leistungsfähigkeit der AVRs
begeistert.

Gruss
Hans-Christian

Hallo,

mich würde als GPS-Info erst einmal nur das relativ genaue
Geschwindigkeitssignal (speed over ground) interessieren. Woher bekomme
ich nun Info üer den Aufbau des GPS-String (bzw. des zugehörigen
Protokolls)? Evtl kann Bernhard mir aber auch direkt verraten, an
welchem Offset die Geschwindigkeit steht und wie diese zu
interpretieren ist (vermutlich m/s als 16bit-Wert?)

Danke im Voraus!

Super Projekt, übrigens! :-))

Gruß,
Dennis

Hallo Dennis,

>mich würde als GPS-Info erst einmal nur das relativ genaue
>Geschwindigkeitssignal (speed over ground) interessieren. Woher
>bekomme ich nun Info üer den Aufbau des GPS-String (bzw. des
>zugehörigen Protokolls)?

Den Aufbau der GPS NMEA-Datensätze findes Du im Internet BSP:

http://www.kowoma.de/gps/zusatzerklaerungen/NMEA.htm

Mit einem Terminal-Programm kannst Du Dir die ausgegebenen
NMEA-Datensätze anschauen.

Manchmal gibt es bei den GPS-Empfängern kleine Abweichungen in den
Protokollen.

>Evtl kann Bernhard mir aber auch direkt verraten, an
>welchem Offset die Geschwindigkeit steht und wie diese zu
>interpretieren ist (vermutlich m/s als 16bit-Wert?)

SOG steht im GPRMC-Datensatz als ASCII in Knoten/h, in diesem Beispiel
ist SOG LEER , da die GPS-Mouse bei mir im Fensterbrett lag:


$GPGGA,213926.206,0000.0000,N,00000.0000,E,0,00,0.0,0.0,M,,,,0000*07
$GPGLL,0000.0000,N,00000.0000,E,213926.206,V*2A
$GPGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0*30
$GPGSV,3,1,12,05,89,000,31,30,81,000,,24,61,000,,04,53,000,*77
$GPGSV,3,2,12,17,48,000,,23,43,000,,09,33,000,,25,26,000,*7D
$GPGSV,3,3,12,06,21,000,,10,11,000,,14,06,000,,07,-15,000,*53
$GPRMC,213926.206,V,0000.0000,N,00000.0000,E,,,140606,,*18

Schau mal hier, hier findest Du weitere Infos:

http://www.mikrocontroller.net/forum/read-1-367657.html


Bernhard

Super! Danke! Habe gerade schonmal eine Navilock NL-303P seriell
gekauft! :-))

Gruß,
Dennis

Ein kleines Beispiel um mit einfachen Mitteln den Aktiv-Zustand des
GPS-EMPFÄNGERS mit zei LEDs zu siganlisieren.

Eingelesen wird das NMEA-Protokoll und anschließend wird der
GPRMC-String ausgewertet.


http://www.mikrocontroller.net/forum/read-4-375249.html

Bernhard

Hallo,

die Navilock Maus (s.o.) signalisiert den Zustand dank eingebauter LED
;-)
Nachdem ich ein wenig mit der Pinbelegung des Navilock-Steckers
gekämpft habe (GRRR), konnte ich zumindest schon mal Daten am PC über
RS232 empfangen (s.Anhang). Leider bin ich ein wenig enttäuscht, dass
die Daten doch nur sehr langsam aktualisiert werden. Die Datei im
Anhang entspricht einer Aufzeichnungsdauer von 10 Sekunden. D.h. gerade
einmal 1 Geschwindikeitsinfo (GPRMC) / Sekunde... Zudem dauert die
Übertagung mit 4800bps eine "Ewigkeit". Jetzt muss ich mal schauen,
wie ich die Geschwindigkeitsinfo mit möglichst wenig Overhead in den
MEGA16 zur Weiterverarbeitung bekomme...
Eine Frage noch: Kann man eigentlich auch Daten (Parameter) an das
GPS-Modul senden? À la "SET_BAUDRATE 19200" ?

Gruß,
Dennis

Hallo Dennis,

>die Navilock Maus (s.o.) signalisiert den Zustand dank eingebauter
>LED ;-)

Du hast es gut, ich musste mich 3 Tage mit diesem Problem
auseinandersetzen, um eine ATtiny12 - Lösung zu schaffen.

>...Daten doch nur sehr langsam aktualisiert werden...
>...einmal 1 Geschwindikeitsinfo (GPRMC) / Sekunde...
>...Zudem dauert die Übertagung mit 4800bps eine "Ewigkeit".

Da gebe ich Dir Recht, die meisten GPS-Empfänger geben ihr
NMEA-Protokoll im Sekundentakt aus. Mehr könnten die Empfänger auch
nicht bei 4800Bd senden (ca. 480 Zeichen bei 8N1)

Bei mir dauert die Übertragung ca. 800...900ms, die verbleibenden 100
ms werden genutzt, um die Berechnungen durchzuführen, deshalb auch der
hoche 16MHz Takt, damit man das nächste NMEA-Paket vom GPS-Empfänger
wieder einlesen kann.




>Jetzt muss ich mal schauen,
>wie ich die Geschwindigkeitsinfo mit möglichst wenig Overhead in den
>MEGA16 zur Weiterverarbeitung bekomme...

Eigentlich bräuchtest Du nur den _$GPRMC_ -String herausfiltern und
auswerten

$GPRMC,091138.699,A,5059.2623,N,01101.2472,E,0.11,11.70,010706,,*3E
                                              ^
                                             SOG

Alle anderen Strings ==> Dummy (werden ignoriert)


>Eine Frage noch: Kann man eigentlich auch Daten (Parameter) an das
>GPS-Modul senden? À la "SET_BAUDRATE 19200" ?


Schau mal in die Produktbeschreibung.

Würde Dir aber auch nichts nutzen, da die Daten nur im Sekundentakt
aktuallisiert werden.


Gruß


Bernhard

Also bei dem GPS empfänger den ich habe (das teil von ebay GPS-MS1E)
Kann man beim Fashen der Firmware einstellen wie oft die daten gesendet
werden und mit welcher baudrate.

Hallo!

>Schau mal in die Produktbeschreibung.

Naja, die ist nicht wirklich auf "Bastler" ausgelegt. Dort geht man
davon aus, dass man sich ordnungsgemäß ein Adapterkabel kauft und dann
die mitgelieferte Testsoftware auf nem PC installiert, wo man dann
"schön bunt" die Satelliten angezeigt bekommt. Es gibt aber eine
"NL_Sirf3_Chipsatz_Schnittstellenbeschreibung_22092005_328.pdf" in
der etwas von einstellbarer Baudrate steht. Allerdings ist mir noch
nicht klar, ob sich das auf den nackten SIRF3 Chip bezieht, oder auf
das fertige Navilock Produkt.

> Würde Dir aber auch nichts nutzen, da die Daten nur im Sekundentakt
> aktuallisiert werden.

Naja, Du schreibst doch selbst, dass Du 16MHz brauchst, um in den
verbleibenden 100ms alles berechnet zu kriegen. Mal zur Anwendung: Ich
habe 4MHz, werte 1600 mal pro Sekunde nen Beschleunigungssensor aus (2
Achsen je 800 mal mit Mittelwertbildung), überwache auf Tastendrücke
und die Batteriespannung, schreibe alle 100ms ein LCD, berechne 100 mal
pro Sekunde die Geschwindigkeit und 10 mal pro Sekunde die aktuelle
Leistung ((long) p = 0.5  m  v²) und schreibe im Durchschnitt 160
Bytes / Sekunde Messdaten auf eine SD-Card. Achja, eine Real Time Clock
(als Stoppuhr) läuft auch noch mit. Tja, da wird die Luft leider
mittlerweile seeeehr dünn ;-) Allerdings bin ich echt immer wieder
überrascht, was man mit dem kleinen 8-Bitter @ 4MHz schon stemmen kann
:-))

Gruß,
Dennis

@Denis

Da hat ja Dein µC ja einiges zu leisten, aber um die Daten der
GPS-Mouse einzulesen und SOG auszuwerten, benötigtst Du unterm Strich
nur wenige Takte.

Wärend die GBS-Bytes bei Dir tropfenweise eintrudeln, kann man doch
problemlos andere Aufgaben erledigen.

Einmal pro Sekunde wird dann SOG aktuallisiert.

Denke daran, SOG ist nicht gleich Geschwindigkeit. In einer steilen
Kurve kann SOG sogar gegen Null gehen.

Bernhard

Hallo Bernhard,

bzgl. SOG in Kurven kann ich ja prüfen, ob die Querbeschl. z.B. <= 0.5g
UND v > x km/h ist und nur dann SOG als gültig zulassen. So vermeide ich
Fehlinterpretation in eng gefahrenen Kurven.

Danke für den Tipp in deinem Schaltplan, dass das RS232-Signal vom
GPS-Sender invertiert werden muss, wenn man keinen MAX232 o.ä.
dazwischen setzt! Da hätte ich einige Stunden dran gesessen, bis ich
darauf gekommen wäre (nachdem die dargestellten Zeichen "etwas"
anders aussahen, als die in Hyperterminal ;-))

Was mir noch aufgefallen ist:
Du lässt in dem "RS232-Inverter" einen, wie ich finde, relativ
großzügigen Strom zu (s. Anhang). Bei mir funktioniert es bei 3,3V mit
nem 4k7 Widerstand einwandfrei. D.h. 2,4mA weniger Strombedarf!

Gruß,
Dennis

@Denis

>Du lässt in dem "RS232-Inverter" einen, wie ich finde, relativ
>großzügigen Strom zu (s. Anhang). Bei mir funktioniert es bei 3,3V
>mit nem 4k7 Widerstand einwandfrei. D.h. 2,4mA weniger Strombedarf!

Du hast Recht, ein hochohmiger Widerstand tut es genauso, schließlich
arbeiten wir nur mit ca. 4800Bd, also 4800 Bit pro Sekunde.

Danke für den Tipp.

Bernhard

die Sirf Teile lassen sich sehr wohl kommandieren. Die einzelnen Befehle
fangen mit $PSRF an. Ich such das mal raus. Die Protokollbeschreibungen
(NMEA INput+OUTput) gibt es bei ublox auf der Seite. ist kein
Geheimnis.
38400Baud sind maximal beim MS1E drinn.
Es gibt auch GPS-Empf. die mit 10hz akutalisieren...
VlG
AxelR.

@Dennis Kleine-Beck:
Ich möchte mir für mein Moped ein GPS-Logger auf Basis ATmega8 (o.ä.)
bauen, der die Daten einer GPS-Maus nur auf einer SD - Karte ablegt.
Soweit ich Dein projekt weiter oben beurteilen kann, hast Du all das
schon gelöst. Darf ich etwas bei Dir "abgucken"?
Mit den besten Grüßen
Hans

Hallo Hans,

vom GPS nutze ich wirklich nur die SOG. Alle anderen Daten verwerfe ich
(bisher). Das GPS ist nur ein rel. kleiner Teil meiner Gesamtanwendung.
Zum Schreiben auf die MMC/SD-Card habe ich mich am Quellcode von Ulrich
Radig orientiert (http://www.ulrichradig.de bzw. hier in der
Codesammlung
http://www.mikrocontroller.net/forum/read-4-125350.html#new). Zudem
habe ich für mein aktuelles Projekt bisher kaum Doku geschrieben.

Bei konkreten Fragen unterstütze ich gern, aber "ganz allg." wüsste
ich jetzt erstmal nicht, was ich Dir zur Verfügung stellen könnte.

Gruß,
Dennis

P.S.: Solltest Du vorhaben, evtl. auch noch ein LCD anzusteuern,
empfehle ich dringend einen MEGA16, sonst reicht das FLASH nicht.

@ALLE

Ich erarbeite gerade ein neues Update der GPS-SOFTWARE,

welches die Kompatibilität der GPS-Empfänger besser gewährleistet.


Bernhard

@Dennis:
Muss mir noch eine GPS-Maus kaufen, möglichst von der Stange, also nur
an den ser. Port anstecken und gut.
Zum anderen ist der SD Zugriff noch nicht ganz klar: Eigentlich möchte
ich mit "Hardware SPI - Routinen" arbeiten. Leider fehlt mir noch der
Durchblick. Habe ein STK500 zur Verfügung (kein eigenes, aber ich darf
es benutzen). Wie soll ich die SD - Karte anschliessen? (Eine 128 MB
Karte kann ich zu Tode quälen....)

@Hans:

ich muss meinen Schaltplan in Eagle mal updaten (in Bezug auf die
GPS-Maus-Anbindung). Heute werde ich vermutlich nicht mehr dazu kommen.
Evtl. morgen abend könnte ich dir die entsprechenden Teile dann
zumailen. Die Beschaltung der SD / MMC - Card ist kompatibel zu Ulrich
Radigs Code (d.h. HW SPI).

Das mit "seriellen Port anstecken und gut" funktioniert bei mir
leider noch nicht so, wie ich es gern hätte. Die Geschwindigkeit in
km/h wird zwar schon schön auf dem LCD angezeigt (nachdem Verbindung zu
Satelliten hergestellt wurde und Daten gültig sind), nach ein paar
Minuten kommt es dann sporadisch zu Fehlern... Muss noch rausfinden,
woran das liegt.

Dennis

@Dennis:
Wie gross ist denn Deine Platine?
Meine soll ein Minimalsystem werden (also interner Oszillator), nur
Programmierpins, ser. Anschluss, SD Karte und Stromversorgung (vom 12V
KFZ) + ein paar Pins, um Taster und LEDs anzuschliessen.

Habe auch schon mit dem Schaltplan begonnen - nur der Anschluss der SD
war noch unklar.

@ Hans:

Den schaltplan müsstest Du per mail schon erhalten haben.
Die Abmessung meiner Platine ist etwa 80x60mm beim Prototypen in
Lochrasteraufbau mit Mischbestückung.

Gruß,
Dennis

Mist, habe ich vergessen:

> (also interner Oszillator),

Ich bin mir nicht sicher, ob das in Verbindung mit USART eine gute Idee
ist...

Dennis

Hab' Deine main erhalten, Danke!
Verbindung zu PC gab's bis jetzt nie Probleme, also mal seh'n.

Dann mailt euch mal alle weiter gegenseitig an.
Vielen Dank für daraus gewonnen Informationen...
Noch besser, als die Infos gefallen mir die Designhinweise, die sich
daraus ergeben und die angesprochenen Projekte erst "vollkommen"
werden lassen.
Ich bin aus diesem Thread raus!

@AxelR:

Ich wollte das mit Hans eigentlich bewusst per mail weiterführen, da es
vom ursprünglichen Thread, also Bernhards Projekt, inzwischen doch stark
abdriftet. Also nicht meinen Senf in eine Projektbeschreibung eines
anderen mischen. Mit Info vorenthalten hat das IMHO wenig zu tun, bzw.
sollte nicht so rüberkommen.

Kein Grund, gleich pampig zu werden, oder?

Fiel mir oben übrigens auch schon ein wenig negativ auf:
> die Sirf Teile lassen sich sehr wohl kommandieren.

KEIN Mensch in diesem Thread hat zuvor das Gegenteil behauptet,
lediglich gefragt, ob das geht.

Dennis

@Dennis,
Ja klar, Entschuldigung. du hast Recht.

Passiert mir hin und wieder. Ich werde in Zukunft nicht mehr vonna
Arbeit aus posten. Nur noch stressfrei von zu Hause nach minimum einer
Stunde Aklimatisierungsphase. VERSPROCHEN!

Viele Grüße und weiterhin viel Spaß

AxelR.

> Ich werde in Zukunft nicht mehr vonna Arbeit aus posten.

Automotive? ;-)

Entschuldigung angenommen!

Dennis

Aktuelles UPDATE Version 2


Was ist neu:

- das Einlesen des NMEA-Protokolls wurde verbessert,
  es gab Probleme mit manchen GPS-Empfängern

- Es wird nur nach folgenden Datensätzen gesucht:
   $GGARMC $GPGGA und $GPGSV

- die Umschaltung der Entfernungsberechnung von m auf km erfolgt
  bei 65.535 m

- die Empfangsqualität einzelner Satelliten wird ausgelesen und als
  Summe dargestellt

- die Berechnete Entfernung wird zusätzlich an TXD-PIN herausgegeben

- beim Einschalten des Gerätes werden die alten Positionsdaten der
  GPS-MOUSE geladen, selbst wenn kein Empfänger angeschlossen ist.

- bei Programmstart wird nach einem Tastatur-Error gesucht

- der Programmcode wurde etwas optimiert und versucht ihn
  übersichtlicher und nachvollziehbarer zu gestalten



Danksagung:

Hiermit möchte ich allen danken, die mir zwischenzeitlich sehr
wertvolle Tipps und Hinweise bei der Verbesserung des Programms und der
Hardware gaben.

Viele dieser Tipps habe ich umsetzen können.


Es wird sicherlich noch nicht das letzte Update gewesen sein.

Bernhard

@AxelR

"Es gibt auch GPS-Empf. die mit 10hz akutalisieren...
VlG
AxelR."

Hast du da ne bezugsquelle wo es sowas als fertiges modul oder als Maus
gibt?

Gruß Bernd

wenn ich wieder auf Arbeit bin, such ich was raus.
Di aktuellen LEA Module von sirf können max.4Hz, weiss ich jetzt aber
nicht genau.

http://www.bgc.de/kunden/sirf/produkte.htm
http://www.navtechgps.com/supply/gps16.asp
http://www.kowoma.de/gpsforum/viewtopic.php?p=3983...

das ist das, was ich erstmal auf die schnelle finden konnte...

Hallo,

zur Vollständigkeit:

Habe gerade erfolgreich durch Senden von "$PSRF100,1,38400,8,1,0*3D"
die serielle Schnittstelle meiner GPS-Maus von 4800 auf 38400bps
geändert!

Somit geht die Datenübertragung mit Faktor 8 nun "erträglich schnell"
;-)

Gruß,
Dennis

[binichnichteingeloggt?!?]

Bernhard, ich muss nochmal kurz fragen:

wie - besser wo - rechnest du die Grad, Minuten, zehntelminuten in Grad
und Zehntelgrad um?
Mein GPS liefert 5221.61300 in der Latitude und 01305.52435 in der
Longitude.
Sind also nur GRAD(52), Minuten(21) und die Sekunden sind schon
Minutenbruchteile (0.61300).
Meine komplizierte Rechnerei funktioniert zwar

(ICH UND MATHE O|O )

und liefert korrekte 52.36023 und 13.09365 aber dafür ist mein Flash
jetzt schon fast voll :-((
Nun hatte ich in deinem ASM Text versucht, herauszufinden, ob Du das
evtl. anders machst.

Na ich sehe nochmal drüber. Vielleicht finde ich ja nochwas.

Liefert so ein GPS lt. NMEA Protokoll immer das gleiche (in bezug auf
LON und LAT) oder kocht hier jeder sein eigenes Süppchen?
auf http://www.kowoma.de/gps/zusatzerklaerungen/NMEA.htm
sieht der Datensatz"RMC" so aus:
$GPRMC,191410,A,4735.5634,N,00739.3538,E,0.0,0.0,181102,0.4,E,A*19
bie mir ist ua. bei LAT und LON eine Stelle mehr hinter dem Komma und
sieht (bei gültigen Daten) so aus:
$GPGGA,194026.0,5221.58953,N,01305.59147,E,1,05,1.76,00056,M,045,M,,*5C
$GPRMC,194026.0,A,5221.58953,N,01305.59147,E,000.0,218.7,130706,00.0,E,A*3D

Man sieht, das auch die Zeit eine nachkommastelle spendiert bekam und
die Nullstellen anderer Felder sind auf die maximale Feldbreite
aufgefüllt.

Ein Anmerkung/Frage noch zum Schluß:

initialisierst Du den GPS Empfänger, sodass nur GGA und RMC rauskommen?
Bei meinem geht das mit:
$PXEMSNM,0101,01*51
GSV werte ich nicht aus - mir reicht die Anzahl der Satelliten.
Gruß
AxelR.