Datum:
Angehängte Dateien: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
Datum:
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?
Datum:
@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
Datum:
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.
Datum:
@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
Datum:
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
Datum:
>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
Datum:
@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
Datum:
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
Datum:
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
Datum:
@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
Datum:
@Bernhard Schulz Klasse gemacht und die Diebstahlgeschichte per SMS wäre eine tolle Erweiterung. Kann man darauf hoffen?
Datum:
@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
Datum:
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.
Datum:
Soooo ... hab endlich n GPS empfänger gefunden Ebay-Artikel Nr. 9733731222 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: Ebay-Artikel Nr. 9733730552 Damit werde ich jetzt erst mal rumexperimentieren.
Datum:
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.
Datum:
>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
Datum:
@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
Datum:
Welchen controller ich genau verwende kann ich noch nich genau sagen aber der M32 wirds wohl sein ... sonst kanns ja nich passen :)
Datum:
Angehängte Dateien: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
Datum:
@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
Datum:
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
Datum:
@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
Datum:
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?
Datum:
@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
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
Super! Danke! Habe gerade schonmal eine Navilock NL-303P seriell gekauft! :-)) Gruß, Dennis
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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.
Datum:
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
Datum:
@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
Datum:
@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.
Datum:
@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
Datum:
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.
Datum:
@ALLE Ich erarbeite gerade ein neues Update der GPS-SOFTWARE, welches die Kompatibilität der GPS-Empfänger besser gewährleistet. Bernhard
Datum:
@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....)
Datum:
@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
Datum:
@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.
Datum:
@ 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
Datum:
Mist, habe ich vergessen:
> (also interner Oszillator),
Ich bin mir nicht sicher, ob das in Verbindung mit USART eine gute Idee
ist...
Dennis
Datum:
Hab' Deine main erhalten, Danke! Verbindung zu PC gab's bis jetzt nie Probleme, also mal seh'n.
Autor:
Axel R.
(axelr)
Datum:
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!
Datum:
@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
Autor:
Axel R.
(axelr)
Datum:
@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.
Datum:
> Ich werde in Zukunft nicht mehr vonna Arbeit aus posten.
Automotive? ;-)
Entschuldigung angenommen!
Dennis
Datum:
Angehängte Dateien: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
Datum:
@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
Autor:
Axel R.
(axelr)
Datum:
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.
Autor:
Axel R.
(axelr)
Datum:
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...
Datum:
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
Datum:
[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.
Datum:
@ Axel: > Bei meinem geht das mit: > $PXEMSNM,0101,01*51 Das kannte ich bisher nur als "103Query/Rate Control" mit z.B. $PSRF103,05,00,01,01*20 für VTG mit 1Hz. Hast Du evtl. eine Übersicht der Input-Befehle? Außerdem hätte ich gern ein kleines Tool zur Checksummenberechnung. Auf "manuelle Art" ist das immer etwas aufwändig. Hat jemand einen Tipp? Danke! Gruß, Dennis
Datum:
@ Axel: Ich glaube dass die Positionsdaten nicht 100%ig genormt sind. Bei meinem Empfänger (LassenIQ) werden immer Grad und Minuten, sowie 5 Dezimalstellen (glaube ich) der Minuten übertragen. Im Datenblatt steht, dass die Anzahl der Dezimalstellen variieren kann. Wahrscheinlich kocht hier also jeder sein eigenes Süppchen. Ein kurze Frage noch: Führst Du deine Berechnungen im float-Format durch oder machst Du alles im integer-Bereich? Ich hatte mir überlegt die Positionsdaten alle in 1000stel Minuten umzurechnen. Bei kleinen Entfernungen kann man dann glaube ich alles mit ulong erschlagen und muss keine aufwändigen float Berechnungen durchführen. Ich glaube Bernhard erledigt auch alles mit integer Werten. Muss mir seine Software aber auch mal genauer ansehen. Gruß, Ralf
Datum:
@AXEL >wie - besser wo - rechnest du die Grad, Minuten, zehntelminuten in >Grad und Zehntelgrad um? Sobald der GPS-$GPRMC -String komplett empfangen wurde, erfolgt sofort die Umrechnung in die Dezimal-Winkel siehe Datei: interrupt.asm >Liefert so ein GPS lt. NMEA Protokoll immer das gleiche (in bezug auf >LON und LAT) oder kocht hier jeder sein eigenes Süppchen? Diese beiden Felder scheinen bei allen GPS-Empfängern gleich zu sein >Man sieht, das auch die Zeit eine nachkommastelle spendiert bekam und >die Nullstellen anderer Felder sind auf die maximale Feldbreite >aufgefüllt. Hier gibt es erhebliche Unterschiede, desshalb ist die Auswertung eines Daten-Feldes nicht ganz einfach, es muss sozusagen bereinigt werden. >initialisierst Du den GPS Empfänger, sodass nur GGA und RMC >rauskommen? Nein, eine Initialisierung wird bewusst nicht vorgenommen. Kann aber bei Bedarf nachprogrammiert werden.
Datum:
Hallo Dennis, kannst du mir die Pinbelegung der Navimouse mailen,habe auch so eine. MfG Gerhardt
Datum:
Hallo Gerado, wenn ich deine Mailadresse wüsste, würde ich das glatt machen! Gruß, Dennis
Datum:
Hallo Dennis, ich hoffe so geht es. Gruß Gerhardt
Datum:
Die Pinbelegung der seriellen Navilock GPS Mäuse findet man unter: http://www.navilock.de/support/files/listfiles.php... Anmerkung: Es handelt sich nicht um "Draufsicht", wie angegeben, sondern um die Lötseite! Ist ein handelsüblicher PS/2 Stecker. Gruß, Dennis
Datum:
UPS, sorry, vergesst meine Anmerkung. Draufsicht auf Maus-Stecker Pinseite wie im Datenblatt zu sehen ist richtig. Sorry! Gruß, Dennis
Datum:
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 @Dennis wie oft pro Sekunde kommen jetzt die Daten? @all Kann mir jemand den Unterschied erklären: Bei vielen GPS System werden unterschiedliche Baud Raten angegeben die man einstellenkann. Und "Update Rate". Meist mit 1 Hz. Wo liegt da der Unterschied? Gruß Bernd
Datum:
Hallo Bernd, die Daten kommen nach wie vor 1 mal pro Sekunde (also mit 1Hz). Nur geht die eigentliche Übertragung nun viel schneller. D.h. mit 4800bps hat die Datenübertragung fast die ganze Zeit zwischen den Aktualisierungen beansprucht. Mit 38400bps eben nur noch einen Bruchteil davon. Somit hat man in den Pausen (bis zur nächsten Aktualisierung) mehr Zeit, andere Aufgaben zu erledigen. Die Update Rate beschreibt, wie oft / Sekunde aktualisierte Daten herausgegeben werden (nicht aber, mit welcher Geschwindigkeit diese gesendet werden). Gruß, Dennis
Datum:
Ah ja. Danke!. Jetz ist mir das auch klar. Gruß Bernd
Datum:
Kann mir evtl. jemand sagen, ob die Geschwindigkeitsangaben in "RMC" bzw. "VTG" unterschiedliche Bedeutung haben?! Oder sind die einfach redundant, wenn beide Strings ausgewertet werden? Danke! Dennis
Datum:
@Dennis >Kann mir evtl. jemand sagen, ob die Geschwindigkeitsangaben in "RMC" >bzw. "VTG" unterschiedliche Bedeutung haben?! Sind die gleichen Werte, nur in einem anderen String Bernhard
Datum:
>Sind die gleichen Werte, nur in einem anderen String
OK, danke! Dann spare ich mit jetzt die Umrechnung Knoten -> km/h,
indem ich nur noch den VTG String aktiviere und auswerte.
Gruß,
Dennis
Datum:
Hallo, habe den thread interessiert verfolgt. Jetzt hab ich bei e**y nach so ner GPS-Mouse geguckt, finde aber leider nur USB oder bluetooth. Jetzt die Frage: Es gibt ja für den AVR auch Software-USB-Lösungen. Kann man denn damit eine solche GPS-Maus nicht auch steuern, bzw. die Daten rausfiltern? Danke für Eure Hinweise. Gruß Bodo
Datum:
Hallo, zu der USB-Variante kann ich wenig sagen, aber bei dem von Dir genannten Auktionshaus gibt's doch eigentlich immer serielle GPS Mäuse. Einfach mal z.B. nach "navilock seriell" suchen lassen. Gruß, Dennis
Datum:
qBodoM
>Es gibt ja für den AVR auch Software-USB-Lösungen
Eine sehr interessante Frage!! Denn ich stelle auch immer wieder fest,
dass Serielle-GPS-Mäuse immer seltener zu finden sind.
Der Trend geht unumstritten in Richtung USB-GPS-Mouse.
Vielleicht hat jemand von Euch eine einfache Idee, wie man
USB nach seriell wandeln kann?
Bernhard
Datum:
Umwandlung USB - Seriell am besten über käuflichen Adapter (+ COM Emulation)
Datum:
-sh... vergiss den oberen Beitrag, war nur ein Schnellschuss. USB muss ja ein "Master" sein, an welchem die GPS Maus als "Slave" angeschlossen wird. Leider kenne ich keinen solchen Adapter.
Datum:
Die meisten USB-GPS mäuse dürften doch einen USB-Seriell wandler haben, einfach um mit den meisten Softwares kompatibel sein zu können. Deswegen denke ich, dass man zur not auch so ne USB maus nehmen könnte in dem man sie vor dem wandler anzapft.
Datum:
Hallo,
bin mir nicht sicher, ob das Protokoll RS232 -> USB gleich wär'.
> in dem man sie vor dem wandler anzapft
Schon mal in eine GPS-Maus reingeschaut? Da ist nicht viel zum
Anzapfen... Ziemlich integriert, das ganze.
Gruß,
Dennis
Datum:
also wenn du USB auf Seriell wandeln möchtest - kleiner Tipp: Schau mal unter: http://www.unitronic.de/ftdi/ hier wird das protokoll und die level konvertiert... hab den chip selbst mal verwendet um einen 8051 mit usb zu programmieren!
Datum:
und wer mal eine serielle GPS Mouse sucht - hab mir gestern eine gekauft bei: http://www.navilock.de/produkte/gruppen/3/Kabel_Em... die hat auch schon den verbesserten SIRF III Chipsatz!
Autor:
Simon K.
(simon)
Datum:
@Sebastian: den FTDI Chip kann man hier nicht verwenden, da er nur einen USB-Clienten bereitstellt. Gefordert ist allerdings ein USB-Host.
Datum:
@Simon: stimmt - mein Fehler! ups Aber da hab ich schon mal eine blöde Frage: wie gehts das eigentlich mit den USB-Mäusen bei PC's - ich hab da einenm ganz billigen Adapter, der aus USB ein PS2 - also ein stinknormlaes serielles Protokoll macht...???? grübel http://www.sfcable.com/Merchant2/graphics/00000001... als Beispiel...
Autor:
Simon K.
(simon)
Datum:
Die Mäuse, bei denen so ein Adapter beigelegt ist, müssen den USB Modus unterstützen. Das ganze ist so ausgelegt, dass der Mikrocontroller in der Maus "merkt" ob er am PS/2 hängt, oder per Adapter am USB. Dann stellt sich der Mikrocontroller auf das passende Protokoll ein. Sprich: In dem Adapter ist keinerlei Intelligenz. Ist einfach nur ein "physikalischer" Adapter.
Datum:
Angehängte Dateien:Update Version 3 Was ist neu: - per RS232 können mindestens 14 Referenzpositionen programmiert werden (z.B. Zuhause oder Urlaubsort) Bsp für Erfurt (Datensatz 03): $GPPROG,03;11020825;50987543;0250;ZUHAUSE_________;chr(13) chr(10) - per RS232 und einem einfachen Daten-Protokoll, kann ein GPS-Empfänger simuliert werden Bsp für Kap-Arkona: $GPPROG,90;13433210;54678720;0100;xxxxxxxxxxxxxxxx; chr(13) chr(10) - bei ausgeschaltetem GPS-Empfänger können die Entfernungen zu den einzelnen Referenz-Positionen berechnet werden (auch untereinander) - die Kontrastspannung kann per PWM-nachgeregelt werden (interessant für Akku-Betrieb) - Offset für Betriebsspannung und Kontrast - Reset auf Werkseinstellung Features : - momentane Entfernung zum Ziel (bis 65.535m im m, dann km) - momentane Geschwindigkeit (SOG) in km/h - momentane Höhe (umschaltbar auf absolut/relativ) - momentaner Kurs in Grad - momentane Position (dezimal / GRD-Minute) - momentane Abweichung zum Ziel (Länge/Breite im m/km) - UTC-ZEIT - Anzahl empfangener Satelliten und deren Signalqualität - Betriebsspannung (mit Offsetfunktion) - Kontrastspannung per PWM in Abhängigkeit der Betriebsspannung) und Offset - Temperatur - 3 frei speicherbare Referenz-Positionen (A+B+C) - 14 fest hinterlegte Referenz-Positionen im EEPROM(z.B. Zuhause) per RS232 programmierbar - Betriebsstunden (interessant für Akku-Betrieb) - alle LEDs lassen sich abschalten (Licht,LED-ROT+BLAU) - die rote LED (GPS A bzw. V) kann bei A leuchten, oder bei V (umschaltbar) (A=GPS-aktiv V=kein oder schlechter Empfang) - bei ausgeschaltetem GPS-Empfänger erfolgt die Berechnung zum Ziel mit zuletzt gespeicherten Positionsdaten und die aktuellen - aktuellen Positonsdaten können per RS232 simuliert werden und mit der "KOPIE REF=>GPS" - Funktion - Rücksetzen auf Werkseinstellung - Ursache des letzten Resets - Anzahl der Programmstarts - Erkennung eines Tastatur-Errors - µC-Takt: 16 MHz Anmerkung: Der Assembler-Code ist noch nicht sehr gut optimiert, bitte verzeiht mir, aber manche Routinen lassen so sich besser nachvollziehen. Als Datei habe ich angefügt: - Schaltplan - Fuse-Bits - Assembler-Code (4-Dateien) - hex-File Viel Spaß Bernhard
Datum:
Hallo, mal 'ne Frage an die Spezialisten: Weiß jemand aus Erfahrung, wie "gut" (bzw. schlecht) GPS Empfänger mit sich ändernder Geschwindigkeit zurechtkommen? Der von mir eingesetzte Empfänger hat eine Updaterate von 1Hz. Trotzdem scheint die ausgegebene Geschw. (aus VTG string) weitaus niedriger zu sein, als sie rechnerisch vor 1 Sekunde hätte sein müssen (Bsp.: Ich erwarte 50km/h nach ca. 2,5 Sekunden Beschleunigung aus dem Stand, ausgegeben wird aber z.B. 36km/h nach 3,5 Sekunden). Bin für jeden Denkanstoß dankbar! Gruß, Dennis
Datum:
Hier mal was zum Thema GPS-Maus mit USB. Soweit ich mich bisher in das Thema eingelesen habe, ist es ja so, das in Windows Standard-Geräte für USB (Device-Class) definiert sind. Wo anders habe ich eine Datei gefunden die eine Art Inf-Datei für Linux oder so für eine usb-gps-maus darstellen soll. Dort ist als Device-Class 00 (also HID) angegeben. In der Unterklasse ist dann die Serielle Class ausgewählt. In meinem jugendlichen Leichtsinn stelle ich mir es so vor. Man besorgt sich eben die Definition der seriell HID-Class und setzt diese auf einem microcontroller um. Dann müßte es doch gehen. Oder ? ;) Keine Angst ich glaube nicht wirklich, das das grad leicht ist. Aber vielleicht hilft das ja irgendwie weiter. Sollte mein Text noch irgendwie Erläuterungen brauchen, bitte ich um Nachricht. Ich schau auch gern nochmal nach den Quellen. Aber im Moment bin ich einfach Hundemüde. Wufff.
Datum:
Hallo, tolles Projekt! Ich habe es direkt nachgebaut. So weit so gut. Ich weiß jetzt nur nicht so recht mit welcher Bautrate die SOftware so zurecht kommt . Ich habe eine Gps Maus Em 9090 die spuckt mir auch Daten aus allerdings mit 9600 Baud .Ich habe mal im Datenblatt nachgesehen wie das Komando ist um die Bautrate zu ändern, nur leider weiß ich gerade mal nicht womit ich es an die Gps maus schicken soll über com 1 , sobald ich hyper terminal öffne flattern die Daten der Maus rein, nur wie bekomme ich es jetzt rüber? Kann mir jemand helfen stehe auf dem Schlauch. Gruß Peppe
Datum:
Angehängte Dateien:Hallo Peppe, >Ich habe eine Gps Maus Em 9090 die spuckt mir auch >Daten aus allerdings mit 9600 Baud Du kannst auch auch den Programm-Code auf 9600 Bd ändern. "GPS_allgemein.asm" Zeile: ".equ BRR...." Ich hab's mal schnell getan und lege das hex-file mit bei. Bernhard
Datum:
Hallo, ich habe für die Konfiguration der GPS Maouse nen AVR auf einem STK200 programmiert. Eigentlich sollte es aber auch über Hyperterminal gehen, da es sich letztlich ja nur um ASCII Zeichen handelt. Die Übertragung ist AFAIK duplex, so dass es nicht stört, wenn Daten von der Maus kommen. Einfach den Konfigurationsstring senden (natürlich beim Senden Hyperterminal noch 9600 baud betreiben...). String kopieren und in HT einfügen. Für 19200bps z.B. $PSRF100,1,19200,8,1,0*38 Für 38400 z.B.: $PSRF100,1,38400,8,1,0*3D Für 4800 bin ich jetzt gerade zu faul, die Checksumme auszurechnen ;-) Evtl. weiss es jemand so? Dennis
Datum:
Danke für die hex, damit funktioniert es. Danke werde mich die Tage mal hinsetzen und ein Layout fertig machen, Gruß peppe
Datum:
Ich hab endlich ne serielle GPS Maus aufgetrieben und gleich ne Frage dazu. Das Teil ist ohne Gehäuse (Bruchschaden) und auf dem Modul selbst ist kein Hersteller oder Typ auszumachen. Wie kriegt man in so einem Fall raus was man da eigentlich für ein Gerät hat? Ich hab das Ding mal an VisualGPS gehängt und da kommen nur die Grunddaten raus (also GPRMC Sätze). So wie ich die bisherigen Beiträge verstanden hab gibt es irgendwelche Befehle um dem Modul zu sagen was es tun soll. Gibts da was Einheitliches (ähnlich den AT-Befehlen beim Modem)? Die hier genannten Parameter hab ich mal im VisualGPS als Initialisierung eingetragen, konnte aber keine Änderung im Verhalten des Moduls feststellen. Auch die Baudratenumstellung klappt nicht. Hat da Jemand einen Tipp oder weiterreichende Literatur (vorzugsweise als Link)? Danke Frank
Datum:
Hallo, manche GPS-Mouse-Typen senden kurz nach Anlegen der Betriebsspannung einige Informationen über sich (Hersteller, Software usw.) Einfach mal mit einem Terminal-Programm überprüfen? Der GPRMC-String ist doch schon ganz aussagefähig, viele wichtigen Daten sind in ihm enthalten (A/V, Position, Zeit) Bernhard
Datum:
Hallo Bernhard. Stimmt, nach dem einschalten kommt ein String vom Modul: $PWRIRID,12,02.30,01/29/99,0003,*4A was das bedeuten soll bleibt mir allerdings verborgen. Die erweiterten Daten würd ich schon ganz gern sehen (wenn mein Modul das dann kann), schon um z.B. herauszufinden wieviele Satelliten das Modul findet. Die GPRMC Sätze kommen permanent aus dem Modul gepurzelt, auch wenn es mit Sicherheit keine Satelliten sehen kann, also würd ich schon ganz gern sehen wann mein Modul so einen Sputnik angepeilt hat. Mir ist dann noch eine Diskrepanz zwischen NMEA Protokoll und der Beschreibung der LEDs aufgefallen. Das A/V Flag wird im Protokoll mit Alert/Valid übersetzt. In deinem Post vom 15.8.06 steht aber was von A=GPS-aktiv V=kein oder schlechter Empfang. Das wär ja so ziemlich das Gegenteil. Oder hab ich da nur was falsch verstanden? bye Frank
Datum:
@bernhard schultz, Dennis hallo, ich habe mir auch eine gps navilock nl303p gekauft wie dennis. leider erhalte ich in Hyperterminal z.B. " nNN.n>>2NN*"nNN&>nNn>>*NnNN*"nNN&nNn>> ÊnNN.n>>nNN*"nNN&nNn>>2" und keine wirklichen GPS Daten. Ich habe die GPS-Maus an einen MAX232 angeschlossen (den mit den Elkos verdrahtet GND, VCC angelegt) und die Kabel richtig angeschlossen. Oben las ich etwas vom invertieren. Kann es sein, dass dieser Fehler weg ist, wenn ich an das Rx Signal einen 4,7kOhm Widerstand löte??? Oder ist der Fehler woanders?? LG
Datum:
Hallo Marc, es kommen doch daten an. Hast du es schon mal mit einer anderen Baud Rate versucht? und hast du dein Hypert auf 8N1 gestellt? Was willst du mit dem Widerstand bezwecken? Hast du mal gemessen welche Potentiale am Stecker der Navimaus anliegen, bei RX und TX. Ich kenne die Maus nicht aber es könnte auch sein, das die nicht mit TTL Pegel arbeitet, sondern mit 3,3 Volt dann brauchst du ein MAX3232 und nicht den Max 232. Miss ersteinmal die Spannungen an der Maus und schaumal wie dein Hyperterminal eingestellt ist im Datenblat steht was von 4800 Baud. Einfach mal ausprobieren. Gruß Peppe
Datum:
@MARC > ... leider erhalte ich in Hyperterminal z.B. " > nNN.n>>2NN*"nNN&>nNn>>*NnNN*"nNN&nNn>> ÊnNN.n>>nNN*"nNN&nNn>>2" und > keine wirklichen GPS Daten. kann es vielleicht sein, dass das RS232 Signal Deiner GPS Mouse nicht durch einen MAX232 aufbereitet werden muss? Vielleicht stellt diese GPS Mouse schon den richtigen Pegel für Deine PC Schnittstelle bereit? Bernhard
Datum:
Hi, A bedeudet bei den GPS-Signalen ACTIVE und V steht für VOID. Bei A kann man die Daten also weiterverarbeiten, bei V sollte man sich das überlegen (Zeit, Datum etc. werden auch dann korrekt übertragen, wenn keine Signale vom Sat kommen, aber die Grunddaten gepuffert sind. Die Positionsdaten werden aber falsch sein).
Datum:
Hallo Marc, ich habe auch eine Mouse von Navilock. Aus dem Sub-D-Stecker kommen die Signale mit RS232-Level heraus mit +/-5V, d. h. natürlich auch schon aus dem PS/2-Stecker. Norbert
Datum:
Hallo, also soweit ich weiß liegt der Pegel bei RS232 laut spezifikation bei +/- 12 Volt. NOrbert wie hast du die Pegel gemessen ? mit einem Scop oder mit einem Multim.? Angenommen es liegen wirklich +/- 12 V an dann brauchst du keine Wandler zwischen Maus und Pc. Dann brauchst du aber einen wenn du vom µc zur Maus willst... Peppe
Datum:
Hi Peppe, Du hast schon Recht, was den Pegel angeht! In der Regel werden aber selbst +/- 5V schon richtig ausgewertet!!! Ich habe den Pegel mit einem Scope gemessen. Mit diesen Pegeln gibt es keine Probleme. Bisher habe ich allerdings auch keine Befehle vom Rechner zur Mouse geschickt. Ich denke aber, dass das auch kein Problem sein sollte. Norbert
Datum:
Wegen der Diskussion hier bzgl. langsamer übertragungsraten: wieso ist das so ein problem ? man kann die daten von der seriellen schnittstelle doch interruptgesteuert abholen und dann quasiparallel in der zeit die berechnungen für den alten datensatz durchführen. hier 4Mhz oder gar 16Mhz für die 10% der zeit die man sie wirklich braucht in 90% der zeit mit warten zu verbraten ist ja nicht sinnvoll.
Datum:
Hallo, finde das Projekt recht gut, meine Frage wäre wie bekomme ich die daten zu meinem OSD? oder besser gesagt ich habe ein OSD Modul und würde gern die Daten dort mit einblenden Das OSD modul hat bereits einen Atmega 8 Drauf. http://www.dl1mfk.de/Projekte/OSD_IC/index.htm Danke schon mal für eure Hilfe. PS kennt jemand noch andere OSD IC'S bzw welche die noch gut verfügbar sind.
Datum:
Hallo OSD,
>meine Frage wäre wie bekomme ich die daten zu meinem OSD?
Momentan ist das Assembler-Programm für ein LCD-Display geschrieben.
Man könnte die Daten zusätzlich per USART (TXT stünde dafür zur
Verfügung), problemlos an ein OSD-Modul senden. Oder man verzichtet auf
das LCD-Display und verwendet die TWI-PINS oder die SPI-PINS.
Bernhard
Datum:
ok, muss dazusagen bin in der programierung noch anfänger, ich kann zwar php und cgi.... aber in diesem bereich habe ich noch keinerlei erfahrung. Was ist USART, TWI-PINS, SPI-PINS gelesen habe ich das schon, aber was kommt da genau raus, bzw was müsste ich dann im programm ändern?
Datum:
> Was ist USART, TWI-PINS, SPI-PINS http://www.mikrocontroller.net/articles/AVR-Tutorial http://www.mikrocontroller.net/forum/mikrocontroll...
Datum:
Hallo Leute, ich habe das Projekt heute gefunden und findes das echt "Geil". Nun habe ich an euch ne Frage: Gibt es solch ein Projekt ale Elektronischen Fartenschreiber fürs Auto? Es sollte die GPS Daten für dei fahrt aufzeichnen und diese dann später am PC ausgelesen werden und ggf. für ein Fahrtenbuch gespecihert werden.
Datum:
@Martin > und findes das echt "Geil". danke > Gibt es solch ein Projekt ale Elektronischen > Fartenschreiber fürs Auto? Es kommt nur auf Deine Logger-Bedürfnisse an. Soll nurt der Start und das Ziel geloggt werden oder soll sekundengenau mitgeschrieben werden? Um welche Datenmengen handelt es sich? Zum speichern der Daten könnte man den internen EEPROM oder einen externen TWI-EPROM oder eine SD-Karte verwenden. Bernhard
Datum:
Hallo Leute! Ich hab den NL-303P und möchte mit dem Befehl "$PSRF103...." alle Ausgaben bis auf die GGA deaktivieren. Wie rechne ich jedoch die Checksum am Ende des Befehls aus? Viele Grüße!
Datum:
Hi, schöne Projekt. Und schöner Menüaufbau. Hab jedoch ne Frage. Gibt es eine Möglichkeit, die Anzeige der GPS-Daten im Format zu ändern? Also von der Dezimalen Darstellung z.b. 50.04307 8.56037 auf N 50° 02.584 E 008° 33.622 mit Dezimal & Minuten zu ändern? MfG Stefan
Datum:
> schöne Projekt. Und schöner Menüaufbau. Danke > Gibt es > eine Möglichkeit, die Anzeige der GPS-Daten im Format zu ändern? Also > von der Dezimalen Darstellung z.b. 50.04307 8.56037 auf N 50° 02.584 E > 008° 33.622 mit Dezimal & Minuten zu ändern? > > MfG Stefan Die Möglichkeit besteht, allerdings müsste dazu die Software geändert werden. Momentan wird die von der GPS-MOUSE gelieferte Minutendarstellung extra in die Dezimaldarstellung umgerechnet (lässt sich besser berechnen). Bernhard
Datum:
Guten Tag. Wie funktioniert der Anschluss des PC an den Mega8 mit gleichzeitig angeschlossenem GPS-Modul? Hängen doch beide an der seriellen Schnittstelle... Leider fehlt der Pegelwandler und sein Anschluss im Schaltplan. Würde gern auch erstmal testen, ob mein Modul überhaupt was sinnvolles mitzuteilen hat und daher den empfangenen Datensatz einfach an den PC durchreichen. Kann mir jemand helfen? Danke.
Datum:
Also wie ein Pegelwandler zur RS232 Kommunikation angeschlossen wird, ist mir schon klar. Das GPS-Modul hängt aber doch auch am RX-Pin des Controllers. Solange nichts gleichzeitig passiert, könnte das ja vielleicht gut gehen... Aber die empfangenen Daten vom GPS-Modul an den PC durchreichen, wird so nicht funktionieren, oder? Vielleicht ist mein Problem so verständlicher...
Datum:
Normalaerweise geben die Mäuse ihre Signale im RS232 Pegel raus, diese lassen sich direk auch an den PC übertragen. Im Schaltplan macht der Transistor die Pegelanpassung an den TTL-Pegel der Schaltung. Hoffe der Hinweis hilft dir.
Datum:
Hm, das war nicht meine Frage... Der Pegel meines GPS-Moduls (keine GPS-Maus) ist 0V oder ca. 2,4V. Ich möchte wissen, wie die Verschaltung sein muss, damit der Controller mit dem PC reden kann (bidirektional), aber gleichzeitig das GPS-Modul am Controller angeschlossen ist. So stell ich mir das zumindest nach der Beschreibung im Post vom 15.08.2006 23:25 vor (per RS232 können mindestens 14 Referenzpositionen programmiert werden). Der Atmega8 hat ja aber nur einen UART. Wenn ich das richtig verstanden habe, redet bei der Schaltung hier der PC nicht direkt mit dem GPS-Modul, sondern dient nur zum Konfigurieren des Controllers... Hängt das Modul dann an einem anderen Pin und das Einlesen der Daten wird per Software (Software-UART) gemacht?
Datum:
>Der Pegel meines GPS-Moduls (keine GPS-Maus) ist 0V oder ca. 2,4V. das ist schonmal ganz gut, müsste reichen, damit der Transistor schaltet und die Pegelwandlung vornehmen kann >Ich möchte wissen, wie die Verschaltung sein muss, damit der Controller >mit dem PC reden kann (bidirektional), aber gleichzeitig das GPS-Modul >am Controller angeschlossen ist. Das GPS Modul muss dazu vom µC getrennt werden. Die PC Daten werden dann auf die gleiche Transistorstufe (zur Pegelwandlung) geschaltet. >So stell ich mir das zumindest nach der >Beschreibung im Post vom 15.08.2006 23:25 vor (per RS232 können >mindestens 14 Referenzpositionen programmiert werden). >Der Atmega8 hat ja aber nur einen UART. Wird ja auch alles über einen RXD-Pin programmiert. >Wenn ich das richtig verstanden habe, redet bei der Schaltung hier der >PC nicht direkt mit dem GPS-Modul, sondern dient nur zum Konfigurieren >des Controllers... korrekt >Hängt das Modul dann an einem anderen Pin und das Einlesen der Daten >wird per Software (Software-UART) gemacht? nein, alles geschieht über den RXD-Pin
Ok, danke. Hab das Modul jetzt über nen Pegelwandler am PC und es spukt mir auch Daten aus. Die gucke ich mir mit Visual GPS an. Leider empfange ich keinen Satelliten. $GPGSA,A,1,,,,,,,,,,,,,,,*1E Das wird vermutlich an meiner Antenne liegen. Ich benutze eine kleine Keramik Patch Antenne (siehe Anhang). Den Pin habe ich an RF_GND gehängt und die zweite Fläche habe ich kontaktiert und auf RF_INPUT gepackt. Bei dem Modul handelt es sich um ein EB712A von navibe. Irgendwelche Ideen, wie das mit dieser Antenne oder einer anderen klappen könnte?
Autor:
Axel R.
(axelr)
Datum:
>Irgendwelche Ideen, wie das mit dieser Antenne oder einer anderen >klappen könnte? mit gelbem Klingeldraht zum Anschluss der Antenne geht das nicht.
Datum:
Leider hat das Modul keinen Antennenstecker. Ne Idee, wie man das hinbekommt?
Autor:
Axel R.
(axelr)
Datum:
nun mal im Ernst: Die Antenne muss mit einer 50 Ohm Leitung am Antenneneingang angeschlossen werden. Ein stückchen RG316 oder 174 solltest Du dafür nehmen. Die beiden Enden ganz kurz abisolieren und dann sollte es gehen. Gruß Axelr.
Datum:
Hab es jetzt mal mit einem kurzen Stück RG174 versucht. Ist ziemlich fummelig und ich habe den halben Anschluss von RF-Input durch mechanische Belastung abgerissen. Leider tut sich immer noch nichts. Ich denke, da habe ich keine Chance. Werde mich nach einem Modul mit integrierter Antenne umsehen...
Datum:
Hört sich nicht schlecht an. Denke aber, die TTL-Version ist besser geeignet. Zum Testen am PC habe ich nen Pegelwandler. Aber später soll das Modul ja an nen uC. Was mir nicht gefällt, sind die 4 bis 6 V Eingangsspannung, da die Zielschaltung auf 3,3V laufen soll (wegen der SD-Karte).
Datum:
Habe gerade gesehen, dass die TTL-Version auch mit 3,3V läuft...
Datum:
Hallo, hat die Entfernungsberechnung schon jemand in C umgesetzt? Gruß Gerd
Datum:
Bei mir ist es schon einige Zeit umgesetzt. Hatte die Formeln damals auf einer Seite gefunden die sich mit "Seenavigation" und ähnlichem beschäftigt hat. Dort waren 3 unterschiedliche Beispiele mit Rechenumfang und entsprechender Genauigkeit verglichen. Jedoch finde ich die Seite momentan nicht in meinen gespeicherten Links. Gruß Stefan
Datum:
Naja, ich kämpfe gerade damit, wie ich es am Geschicktesten anstelle. Die normale Berechnung bedarf acos, cos und sin. Bei der Berechnung hier muss ich aus einem double Wurzel ziehen, wenn ich das richtig verstehe.
Datum:
So, hab die Seite gefunden. Es ist zwar nicht die eigentliche die ich hatte, aber für weitere Infos hatte ich mir diese gespeichert. http://www.kompf.de/gps/distcalc.html Ich hab ne abgwandelte Form der "verbesserte Methode" verwendet. Das Ergebnis ist für mich vollkommend ausreichend genau. Gruß Stefan
Datum:
Vielen Dank! Mittlerweile funktioniert das Gerät gut. Ich habe die einfache Berechnung für meine Gegend leicht angepasst. Die "verbesserte Methode" teste ich gerade, habe aber noch einen Fehler drin. Aber das wird schon. Gruß Gerd
Datum:
Habe bei meinem eigenen GPS-System die verbesserte Methode implementiert. Anhand einiger aufgezeichnter Wege (käufliches GPS-Gerät; wenige hundert Meter bis 141km), die ich während der Entwicklung über einen GPS-Simulator abspiele, kann ich sagen, dass die Abweichung bzgl. Streckenlänge gegenüber Google Earth bei unter 1,5% liegt. Das ist schon gut und vollkommen ausreichend. Gruß Christoph
Datum:
Die verbesserte Variante funktioniert mittlerweile gut. Da ich momentan nur einen Radius von 200km benötige, komme ich klar damit. Gruß Gerd
Datum:
Hallo Bernhard, ich habe mir Deine Schaltung fürs Boot nachgebaut, ich wollte eigentlich nur eine Geschwindigkeitsanzeige haben, aber so ists natürlich noch besser. Jetzt mit V3 läufts ansich schon ganz gut, aber -warum wird die Temperatur ohne Punkt angezeigt? Also mom. 234 Grad - irgendwie zeigt die Betriebspannungsanzeige immer das Gleiche an 8,079V, egal wie ich die Versorgungsspannung variiere. Ansonsten bin ich mit der Schaltung und dem Programm sehr zufrieden. Gruß Marco
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten