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
@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-blox-ag-SONDERANGEBOT_W0QQitemZ9733731222QQcategoryZ77777QQrdZ1QQcmdZViewItem 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-U-Blox-GPS-Empfaenger_W0QQitemZ9733730552QQcategoryZ27736QQrdZ1QQcmdZViewItem 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 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
Angehängte Dateien:
-
BERNHARD_RS232.GIF
4 KB
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
Angehängte Dateien:
-
sirf_kommando.png
16 KB
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&sid=90bab45543520910233285d749944cfd 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.
@ 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
@ 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
@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.
Hallo Dennis, kannst du mir die Pinbelegung der Navimouse mailen,habe auch so eine. MfG Gerhardt
Hallo Gerado, wenn ich deine Mailadresse wüsste, würde ich das glatt machen! Gruß, Dennis
Hallo Dennis, ich hoffe so geht es. Gruß Gerhardt
Die Pinbelegung der seriellen Navilock GPS Mäuse findet man unter: http://www.navilock.de/support/files/listfiles.php?action=getFile&id=31&filename=nl-41d285c449d9a&cfilename=BR-305+Pin+Belegung.pdf Anmerkung: Es handelt sich nicht um "Draufsicht", wie angegeben, sondern um die Lötseite! Ist ein handelsüblicher PS/2 Stecker. Gruß, Dennis
UPS, sorry, vergesst meine Anmerkung. Draufsicht auf Maus-Stecker Pinseite wie im Datenblatt zu sehen ist richtig. Sorry! Gruß, Dennis
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
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
Ah ja. Danke!. Jetz ist mir das auch klar. Gruß Bernd
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
@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
>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
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
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
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
Umwandlung USB - Seriell am besten über käuflichen Adapter (+ COM Emulation)
-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.
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.
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
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!
und wer mal eine serielle GPS Mouse sucht - hab mir gestern eine gekauft bei: http://www.navilock.de/produkte/gruppen/3/Kabel_Empfaenger/61423_NL-303P.html die hat auch schon den verbesserten SIRF III Chipsatz!
@Sebastian: den FTDI Chip kann man hier nicht verwenden, da er nur einen USB-Clienten bereitstellt. Gefordert ist allerdings ein USB-Host.
@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/10usb-ps2.jpg als Beispiel...
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.
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
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
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.
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
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
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
Danke für die hex, damit funktioniert es. Danke werde mich die Tage mal hinsetzen und ein Layout fertig machen, Gruß peppe
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
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
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
@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
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
@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
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).
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
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
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
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.
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.
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
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?
> Was ist USART, TWI-PINS, SPI-PINS http://www.mikrocontroller.net/articles/AVR-Tutorial http://www.mikrocontroller.net/forum/mikrocontroller-elektronik?filter=usart
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.
@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
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!
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
> 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
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.
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...
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.
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?
>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
Angehängte Dateien:
-
Gps.JPG
89 KB
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?
>Irgendwelche Ideen, wie das mit dieser Antenne oder einer anderen >klappen könnte? mit gelbem Klingeldraht zum Anschluss der Antenne geht das nicht.
Leider hat das Modul keinen Antennenstecker. Ne Idee, wie man das hinbekommt?
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.
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...
http://www.naviman24.de/FALCOM-FSA02__i_922B-LF-SM.html?SID=872fec7486b4d24b765f3bc723915f21 probier die
http://www.hanobox.de/product_info.php?language=de&info=p2011_NAVILOCK-NL-503ERS-MTK-RS232-Modul-60412.html würde dieses bevorzugen
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).
Habe gerade gesehen, dass die TTL-Version auch mit 3,3V läuft...
Hallo, hat die Entfernungsberechnung schon jemand in C umgesetzt? Gruß Gerd
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
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.
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
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
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
Die verbesserte Variante funktioniert mittlerweile gut. Da ich momentan nur einen Radius von 200km benötige, komme ich klar damit. Gruß Gerd
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
Moin, Ich weiß, ich bin etwas spät dran aber....ist der TO noch da? Hab mir die Schaltung nachgebaut. Funktioniert auch soweit. Nur bei der Geschwindigkeit und dem Kurs wird die letzte Stellw nicht angezeigt. Bei 40 kmh steht dann da nur 4kmh Bei 320° Kurs steht nur 32° Bin nicht so asm bewandert. Nutze ein 4x20 lcd. Könnte es daran liegen weil ich kein 2x16 lcd nutze?
Das Problem habe ich auch. Dachte erst das ° Zeichen überdeckt die letzte Stelle aber wenn man es weglässt dann kommen Gradzahlen wie 322, 122, 233, 77, 177 usw. Also immer doppelte letzte Stelle
So, es läuft jetzt!! Habe die Menüs noch was angepasst und auf 4x20 LCD optimiert. Außerdem das Hauptmenü noch was ordentlicher gemacht und ein paar Formatierungen geändert.
Dominik schrieb: > So, es läuft jetzt!! Dann solltest du auch andere Interessenten profitieren lassen, indem du das gefixte Paket hier hochlädtst…
Das kann ich machen! Hatte nach meiner unbeantworteten Frage jetzt nicht gedacht, dass noch einige hier mitlesen in dem alten Thread. Werde den Code noch was aufräumen und hochladen.
Beitrag #5843854 wurde von einem Moderator gelöscht.
Beitrag #5843939 wurde von einem Moderator gelöscht.
Beitrag #5844908 wurde von einem Moderator gelöscht.
Beitrag #5844919 wurde von einem Moderator gelöscht.
Beitrag #5844946 wurde von einem Moderator gelöscht.
Beitrag #5845001 wurde von einem Moderator gelöscht.
Beitrag #5845030 wurde von einem Moderator gelöscht.
Uhu U. schrieb im Beitrag #5845001: > Leider gibt es aber immer mal wieder Leute, die ihren Fix zwar nicht > beschreiben, geschweigedenn veröffentlichen, aber dem Rest großspurig > mitteilen, dass sie den Fehler repariert haben um dann nichts mehr von > sich hören lassen. Ich hätte auch gar nicht mitteilen müssen, dass ich das Problem gefunden habe, denn 1. hat mir eh niemand vorher geantwortet, also warum sollte ich dann noch schreiben 2. hat der original Quelltext bei zig Usern ja wohl funktioniert. Also kann davon ausgegangen werden, dass ich wohl ein anderes Problem hatte mit dem Display und "mein" Problem individuell war Wenn kein anderer dieses Problem hat und auch kein anderer ein solches Problem hier meldet, dann ist das auch kein öffentlicher Fix den ich gemacht habe!!! H. Jason schrieb im Beitrag #5845030: > @ Dom > > Um den zu ärgern - nichts veröffentlichen. :-)
Beitrag #5845055 wurde von einem Moderator gelöscht.
Beitrag #5845093 wurde von einem Moderator gelöscht.
Beitrag #5845130 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
20190517_122732.jpg
220 KB -
20190517_122746.jpg
220 KB -
20190517_122830.jpg
190 KB -
20190517_122854.jpg
240 KB
Soooo... anbei mal der aktuelle Stand! HAUPTANZEIGE - Aktueller Kurs (COG) - Verbindung aktiv/inaktiv (A/V) - aktueller Wegpunkt (Waypoint) - Entfernung zum Wegpunkt (Luftlinie, umschaltbar km/nm) - Geschwindigkeit über Grund (SOG), umschaltbar km/h oder kn - Höhe MENÜS - aktuelle Position (Breiten-/Längengrad dezimal) - Wegpunkt Position - X/Y Differenz - UTC Zeit - Wegpunkt laden - Wegpunkt speichern - Satelliten - Online / Offline - Betriebsstunden bzw. Reisezeit - Optionsmenü OPTIONSMENÜ - Höhen Offset - Hintergrundbeleuchtung LCD - Einheiten (km/nm) - Betriebsstunden zurücksetzen - RESET Neu hinzugekommen ist die Einheitenumschaltung von km in nm (Seemeilen) bzw. Knoten. Die Umrechnung habe ich noch nicht vorgenommen. Kommt aber noch! Dann lässt sich der Navigator auch zur See oder in der Luft nutzen. Der Schaltplan ist gleich geblieben. Bis auf die Leuchtdioden, die habe ich wegrationalisiert. Außerdem sind ein paar Sachen rausgeflogen die ich für entbehrlich hielt. Die Bedienung und Übersichtlichkeit ist nun aber besser geworden. In der Hauptanzeige oben links ist noch ein Buchstabe zu sehen. Da bin ich noch dabei. Das soll später mal ein Kompass werden. Dauert aber noch was, ich bin in Assembler nicht so bewandert. Die .asm Dateien habe ich wie folgt aufgeteilt: - GPS_ALLGEMEIN.asm (Registerzuordnungen, Initialisierungen, etc.) - GPS_ANZEIGEN.asm (Anzeigefunktionen für die Texte) - GPS_BERECHNUNG.asm (Alle Berechnungsalgorithmen) - GPS_EEPROM.asm (Alle EEPROM Routinen) - GPS_FUNKTIONEN.asm (Funktionsbibliothek) - GPS_INTERRUPT.asm (GPS String Auswertung) - GPS_LCD.asm (LCD Routinen, Funktionen, etc.) - GPS_MENU.asm (Menü- und Optionsroutinen) - GPS_TEXTE.asm (Alle angezeigten Texte und Strings) Für den Kurs und die Geschwindigkeit musste ich bei mir eine Division ändern. Und zwar wird jetzt bei der GPS String Auswertung der Kurs nicht durch 100 sondern durch 10 geteilt. Ebenso bei der Geschwindigkeit war eine "0" zuviel bei der Division. Kurs und Geschwindigkeit wird nun korrekt angezeigt. Abgeglichen mit einem anderen GPS.
Sorry, Fehlerteufel war unterwegs! Da hab ich den Code wohl doch zu flott hochgeladen...tja... In der Entfernungsberechnung stimmte das Format nicht! Ist jetzt korrigiert!
So... Umstellung auf nm bzw. kn ist vollbracht. Morgen im Livebetrieb mal testen. Es ist schon erstaunlich... als der Thread 2006 startete war das Projekt noch weitestgehend nützlich. Heute freue ich mich aus dem GPS String Daten rausfiltern zu können obwohl sogut wie jeder mit seinem Smartphone überlegen ist was die Navigation betrifft. Im Gegensatz zu 2006. Aber was solls. Basteln macht Spaß! Jetzt müsste ich nur noch eine Heading Funktion einbauen um "auf Kurs" zu bleiben und das Gerät ist prima für die Schifffahrt geeignet :)
Wie macht man denn eine Tangensfunktion in asm? Mit einer Lookup Tabelle? Oh jeh... gibts auch Inline C für asm? :)))))
Dom schrieb: > Wie macht man denn eine Tangensfunktion in asm? tan(x) = sin(x) / cos(x) sin(x) kann man durch eine Taylorreihe approximieren, cos(x) ist nur ein phasenverschobener Sinus. > Oh jeh... gibts auch Inline C für asm? :))))) Nein, das wäre der Gaul von hinten aufgezäumt… Aber man kann eine in C geschriebene Lib dazubinden.
:
Bearbeitet durch User
Danke für den Tipp! Ich hab gesehen, dass Bernhard bereits eine sin(x) Funktion in asm gebastelt hatte 2006. Allein die würde jetzt den Flash vom Atmega8 sprengen. Schade! Uhu U. schrieb: > Aber man kann eine in C > geschriebene Lib dazubinden. Das geht? Werde mich mal schlau machen. Wobei selbst wenn es geht, ich glaube das passt alles nicht mehr in den momentanen Flash! Gerade Sinus mit Tabelle braucht zuviel Platz :( Schade, mit dem Tangens hätte ich einen Richtungswinkel berechnen können. So hätte das Navi den aktuellen Kurs sowie den Richtungskurs anzeigen können.
Dom schrieb: > Gerade Sinus mit Tabelle braucht zuviel Platz :( Hier ist beschrieben, wie man sin/cos mit einer Taylorreihe berechnet. Man braucht dazu nur die vier Grundrechenarten: http://www2.hs-esslingen.de/~mohr/praes/taylor_fourier_praes_handout.pdf > Uhu U. schrieb: >> Aber man kann eine in C geschriebene Lib dazubinden. > > Das geht? Man muss die Aufrufkonventionen der betreffenden C-Implementierung beachten - in asm ist das kein Problem, denn damit kann man alles machen, was der C-Compiler kann und noch einiges an mehr oder weniger "fiesen Tricks" mehr. Lehrreich ist, sich den ASM-Code anzusehen, den der C-Compiler erzeugt. (Häufig übersetzen C-Compiler den C-Code in asm und der wird dann durch den Assembler geschickt, z.B. gcc.)
:
Bearbeitet durch User
Uah...ich kriegs einfach nicht hin. Dank mangelnder asm Kentnisse wird das so wohl nichts. Schade. Vlt. würde ich es noch schaffen eine Sinus/Cosinus Funktion einzubauen anhand einiger Beispiele. Aber selbst dann würde der Richtungskurs nur zwischen 0-180° liegen. Ich müsste also irgendwie noch mit dem Tangens arbeiten. Schwierig, schwierig... :( So wird es wohl nur ein halbes Navi bleiben. Mh... vielleicht könnte man aber anhand der Korrdinaten bestimmen ob der Wegpunkt nördlich, südlich, westlich oder östlich von der aktuellen Position liegt?
Wohl eher was für's Museum :) Also Umschaltung auf Seemeilen funktioniert jetzt einwandfrei. Auch habe ich die Einheiten km, kn und nm als eigenständiges Sonderzeichen gemacht und mich da etwas an das Garmin GPS 100 orientiert. Ebenso mit dem Startbildschirm. Ja, jetzt fehlt nur noch der Richtungskurs :(
Dominik schrieb: > Uah...ich kriegs einfach nicht hin. > Dank mangelnder asm Kentnisse wird das so wohl nichts. Schade. Schreib die betreffende Routine in C, teste sie in einem Testbett aus und sieht dir dann den vom Compiler erzeugten ASM-Code an und passe ihn für die ASM-Anwendung an. > Aber selbst dann würde der Richtungskurs nur zwischen 0-180° liegen. Ich > müsste also irgendwie noch mit dem Tangens arbeiten. Ein klein wenig Kenntnisse über die Winkelfunktionen helfen darüber hinweg. Man muss nur den Sinus um pi/4 als Taylorreihe entwickeln - dann sind die Ungenauigkeiten am Rand des [0, pi/2] Intervalls sehr klein. Dafür transformiert man dann das Argument für die Berechnung des sin in dieses Intervall, bevor man den Wert berechnet. Wenn das ursprüngliche Argument zwischen pi/2 und 2pi liegt, muss man das Ergebnis noch negieren. Den cos kann man aus dem sin mit transformiertem Argument berechnen, den tan aus sin/cos…
:
Bearbeitet durch User
Ich habe jetzt mal klein angefangen und mir anhand der Entfernung zum Ziel ausrechnen lassen ob ich mich annähere oder entferne. Das lässt sich sogar per Optionen in der Sensitivität einstellen. Habe mir testweise anzeigen lassen durch ein '+' '++' '-' und '--' ob ich mich stark annähere und entferne oder schwach. Noch bezieht sich das auf die Gesamtentfernung. Übertrage ich das jetzt aber auf die X und Y Ausrichtung und der Gesamtentfernung, dann kann ich daraus einen einfachen CDI machen. Also einen Indikator ob ich auf Kurs bin oder nicht. Das ist für die Straße jetzt zwar eher ungeeignet aber zu Wasser und in der Luft würde es funktionieren. Damit wäre dann der Navigator ein richtiger Navigator :) Achso... zum testen des CDI muss ich mich jedes Mal ins Auto setzen und ein paar Meter fahren.
Moin, möchte das Thema nochmal aufwärmen, da ich das Projekt auf einen ATmega16 übertragen und etwas ausgeweitet habe, da ich mehr Flash brauchte. Vielleicht gibt es ja noch Bastler die eine RS232 GPS Maus rumfliegen haben. Ich habe jetzt noch einen "kleinen grafischen" Kompass integriert sowie Referenz und Wegpunkt Navigation mit Peilungskurs. Das Ganze zwar noch sehr sporadisch aber es läuft! Selbst nach so vielen Jahren macht es einfach noch Spaß damit zu basteln und zu programmieren :)
Dom schrieb: > Vielleicht gibt es ja noch Bastler die eine RS232 GPS Maus rumfliegen > haben. Momentan verwende ich: DEBO GPS Entwicklerboards - GPS Breakout-Platine, MTK3339 Kostet allerdings 46 EUR https://www.reichelt.de/entwicklerboards-gps-breakout-platine-mtk3339-debo-gps-p235482.html?search=gps
Hallo Bernhard, schön das du auch noch hier bist :) Ich habe wie gesagt das Projekt mal auf einen ATmega16 ausgelagert. Obwohl ich keine bis kaum ASM Kenntnisse habe. Dennoch habe ich einige neue Funktionen eingebaut.
Dom schrieb: > Ich habe wie gesagt das Projekt mal auf einen ATmega16 ausgelagert Wenn Du möchtest, dann stell uns doch mal Deinen Assemblercode zur Verfügung. ir würden uns freuen.
Ich finde ein GSP-Mouse sollte so funktionieren. Jemand ist auf ein Fußballfeld und hat ein GPS-Mouse bei sich. Eine andere sitzt im Publikumsfeld und schreit, 10 Schritte nach Links, 2 nach Oben und jetzt Doppelspringen bitte. Dann wird auf sein Laptop der Mouse dementsprechend bewegt.
Andras H. schrieb: > Ich finde ein GSP-Mouse sollte so funktionieren. Ein GPS-Empfänger stellt uns nur seine berechneten Koordinaten der Position seiner Antenne zu Verfügung. > Dann wird auf sein Laptop der > Mouse dementsprechend bewegt. Das wäre ein ganz spezieller Anwendungsfall. Vom Prinzip her kein Problem, die Daten der Fußballfeld-Mouse müssten in irgend einer Form (z.B. per Draht, Funk, optisch, akustisch) zum Laptop gesendet werden.
Angehängte Dateien:
-
20220315_115548__2_.jpg
240 KB
Hallo zusammen, ich habe jetzt mal weiter gemacht an dem Projekt auf ATmega16 Basis. Bin noch nicht ganz fertig aber dann werde ich den Code mal posten. Die Hardware habe ich in kompakter Sandwich-Weise gebaut damit es als Einschub eingebaut werden kann. Das Layout der Navigationsansicht ist dem Garmin GPS 100 sowie dem GPS 250XL nachempfunden (lässt sich im Optionsmenü umschalten). Hinzugekommen sind 4 weitere Tasten mit denen ich unter anderem direkten Zugriff auf die Wegpunkte habe. Die 4. Taste ist die MESSAGE Taste, neben der auch eine kleine LED ist. Sobald die LED leuchtet liegt eine neue Nachricht im Gerät vor. Betätigt man nun die MESSAGE Taste so gelangt man in das entsprechende Menü und kann sich die Nachrichten anzeigen lassen (Fehlermeldungen, etc.) Da mein Assemblerwissen so weit fortgeschritten ist wie ich ein Klavier werfen kann, konnte ich leider keine Funktionen einbauen um den Richtungskurs zum Ziel anzeigen zu lassen. Deshalb habe ich getrickst und den Kurs per X/Y Koordinate und Bewegungsrichtung "bestimmt". Es wird also die grobe Richtung in Grad dargestellt (in 15° Schritten). Das CDI in der ersten Zeile zeigt an ob sich das Ziel links oder rechts von der eigenen Position befindet. Je weiter sich der Strich vom CDI an die Außenseite bewegt, desto mehr muss man sein Vehicle drehen. Soviel erstmal zu den größten Neuerungen.
So... ich habe jetzt noch ein kleines VB Tool geschrieben mit dem man ganz easy die Wegpunkte in das "Navi" übertragen kann. Ein MAX232 sitzt jetzt mit auf der Platine. Ich überlege ob ich für das Atmega16 Projekt mal einen neuen Thread aufmachen soll
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.